[Core Protocol] The responsibilities & relationship of sequencer & self-hosted op-node

[johnhckuo]

Did you check the documentation?

• Yes

Did you read the specs?

• Yes
• No

Did you check for duplicate questions?

• Yes

Issue Description

Hi,

I've been digging into the op stack spec & document. However, there are still some missing parts that I do not quite understand, that as the relationship between sequencer & self-hosted op node and their responsibilities in the whole network.
As far as I know, there's a centralized sequencer held by the Optimism foundation itself that is responsible for receiving L2 transactions & producing block templates, and then triggering the forkChoiceUpdate method provided by op-geth to generate new L2 blocks.

So regarding this process, I have some questions:

1. From where does the sequencer receive L2 transactions? initially, I thought users could only submit transactions through the RPC eth_sendRawTransaction and send this request directly to the sequencer URL.
   However, how come other third-party providers also provide this endpoint? Taking Quicknode for example, they also offer eth_sendRawTransaction on https://www.quicknode.com/docs/optimism/eth_sendRawTransaction.
   Does normal op-node unconditionally forward the transactions to the sequencer as well? if that's the case, will some transactions be deliberately ignored by these op-nodes?

2. What does the normal op-node do? it seems like the op-node repository offers you two choices, one is to be a sequencer, and another is to be a verifier. So since the sequencer should be run by the Optimism foundation, I guess all the other nodes inside the Optimism network are all default to verifier? This means it will be mainly in charge of three things: 1. receive L2 transactions and forward to sequencer 2. Start derivation and construct L2 blocks from L1 data and 3. Expose all other RPC methods defined on this page: https://docs.optimism.io/builders/node-operators/json-rpc. Is this correct?

3. I'm assuming the block number of unsafe safe finalized won't be the same for each verifier, the reasons are:

• for unsafe: it depends on the progress of transaction gossip received from other verifiers
• for safe: it depends on the derivation parameters and progress of the verifier itself. Especially I see there's OP_NODE_VERIFIER_L1_CONFS env variables that can be used to postpone the derivation progress by x number of L1 blocks.
• for finalize: same for the above reason.
  are these statement correct?

4. I was looking into the Optimism derivation spec and saw that it mentioned there are possibilities that Optimism blocks can be reorged. One of them is due to consolidation failure.
   According to this section: https://specs.optimism.io/protocol/derivation.html#l1-consolidation-payload-attributes-matching, it mentioned:

If consolidation fails, .....
The payload attributes are chosen in favor of the previous unsafe L2 block, creating an L2 chain reorg on top of the current safe block

So the question is
How does the verifier trigger such reorg to all other nodes after it finds out that consolidation failed? Does it signal the sequencer of such an event, and the sequencer then re-produces new block templates and block heads and then calls the forkChoiceUpdate again to achieve reorg?

5. Since the sequencer will trigger the forkChoiceUpdate method provided by op-geth to generate a new L2 block, which op-geth node will this be? Is it the one that is also run by the Optimism Foundation? After the op-geth successfully produces the unsafe block, then it will propagate this block to other op-nodes?

Sorry for so many questions, but these missing pieces keep bugging me when reading the spec doc.
Would appreciate if anyone could help me answer or figure out these questions, thank you so much! :)

Additional Information

My reading sources include:

• https://docs.optimism.io/stack/protocol/rollup/overview
• https://www.quicknode.com/docs/optimism/eth_sendRawTransaction
• https://specs.optimism.io/protocol/derivation.html
• [Core Protocol] op-geth sync methods #210

Feedback

No response

[joohhnnn]

Personal Opinions (Corrections Welcome)

1. Sequencer Transaction Handling

• The sequencer receives Layer 2 (L2) transactions both directly through its own RPC and indirectly via non-RPC nodes that forward these transactions.
• Non-sequencer nodes assess the validity of L2 transactions upon receipt and forward valid transactions to the sequencer node. These nodes maintain their own mempool and do not broadcast transactions to a public mempool.
• According to the current codebase the sequencer won't reject any transaction.
  I'm guessing you're asking whether it's possible for a sequencer to intentionally act maliciously, resulting in some transactions never being included. And according the data from L2beat, the Optimism network exhibits self-sequencing properties.
  

2. Yes you are right

• I can give you a more specie example here. Centralized exchanges (CEXs) like Binance and Coinbase run their own nodes to verify deposits on the Optimism network. Without their own nodes, they would need to rely on Optimism’s recommended seven-day safety window to ensure transaction validity, which is impractical for user experience. Instead, these CEXs use their own logic to confirm transactions, such as a specific number of minutes or blocks after an L2 block is produced.

3. Block Number Consistency

• The block number remains consistent throughout its creation and transmission. For example roles such as sequencer node A and non-sequencer nodes B, C, D, and E (broadly referring to op-node + op-geth) are involved. Nodes B, C, D, and E continually receive and forward transactions to A, which orders these transactions and generates block N. The block number is fixed as it is transmitted through networks like gossip among nodes B, C, D, and E, unaffected by the speed of receipt or transmission.

4. For Reorganizations, Refer to Question 450

• Discussion on GitHub

5. Operational Details

• Yes, it is the one operated by the Optimism Foundation, and it will propagate to other op-geth nodes.

[joohhnnn]

so it means that all unsafe blocks originally all come from the Optimism hosted sequencer(op-node), and as for safe & finalized blocks, they are being marked by each verifier through the derivation pipeline, and it won't be propagated to other op-node since op-node only gossip unsafe blocks right?

Safe and finalized blocks are also actually shared among op-geth instances to exchange data, for example, used for fast snap synchronization with new nodes.

Yes I've seen this thread, thanks for the reference. However, it didn't mentioned that if the consolidation made by the verifier is failing(e.g. the tx data posted on L1 is inconsistent with L2 data), how does the verifier triggers reorg throughout the whole optimism network. Do you know the detail steps of this process?

I'm not entirely sure, but I think it's somewhat similar to the solution for the ETH TheDAO event. However, since there is currently only one sequencer, there would only be one new direction unless the community itself runs sequencer nodes and all contracts are deployed independently. CC @ajsutton

[ajsutton]

The sequencer doesn't actively do anything to trigger a reorg if the batch data on L1 doesn't match the unsafe chain - the derivation process each node runs just prefers following L1 batch data to what the sequencer publishes so once they process the conflicting L1 data they will automatically reorg to that chain which invalidates the unsafe blocks. Since the sequencer's derivation pipeline will perform the same reorg, the sequencer will wind up building a new set of unsafe blocks on top of the new safe head. So not at all like the DAO fork - just a regular application of the fork choice rules of the protocol.

Also re 2 - running your own node (eg op-node and op-geth or one of the alternate clients) is the only way to validate the OP Stack chain. The output root proposals that are just to give L1 a view of the L2 chain state, but L1 can't directly verify them. The fault proof system is effectively how L1 "runs a node", but it depends on having honest actors that do run a node and will challenge invalid outputs. Those published output roots never trigger a reorg on L2 - they aren't read as part of the derivation process at all and are only used to facilitate L2->L1 messaging such as withdrawals. It's in running your own node that you actually execute the derivation process which is what validates the correctness of the chain.

[johnhckuo]

That makes a lot of sense, thanks @ajsutton for the detailed answer :)

[doukhahmed]

Hello @johnhckuo and thanks for your detailed answer .
I have one follow up question; can i run the entire OP Stack locally ?

[johnhckuo]

@doukhahmed yes of course, please refer to https://docs.optimism.io/chain/testing/dev-node