smartcontracts
commented
8 months ago I think this can be best resolved by the protocol docs refresh, we can just link to the protocol docs then
Closed cpengilly closed 6 months ago
smartcontracts
commented
8 months ago I think this can be best resolved by the protocol docs refresh, we can just link to the protocol docs then
"getting stared" (https://stack.optimism.io/docs/build/getting-started/#generate-some-keys) tutorial and looking to understand what separates the Sequencer from the Batcher. In the tutorial, the Sequencer address is never funded or used, only lists addresses for the batcher and the proposer.
0x6887246668a3b87F54DeB3b94Ba47a6f63F32985- "Optimism: Sequencer" (should be updated now to show “OP Mainnet Batcher” in Etherscan) 0x473300df21D047806A082244b417f96b32f13A33- "Optimism: State Root Proposer"
Docs clarification to make: Sequencer includes txs from mempool into new blocks, and shares these blocks offchain. Has a P2P-Sequencer-Key to sign these blocks before gossiping them.
Batcher takes blocks from sequencer op-geth, packages the inputs into batch data, and submits them to the L1 inbox for others to reproduce. Uses a special L1 account, other data txs in the inbox are ignored by verifiers.
Verifiers take unsafe blocks from sequencer via p2p gossip, and then later verify (or reconstruct, if they never received the offchain blocks gossip) the L2 blocks. If any tx is invalid, the block input as a whole is ignored, and alternative block inputs are awaited. L1 inputs take precedence if the gossiped block data is not the same.
Proposer runs an archive verifier node (or is directly attached to sequencer) and monitors it. Every N blocks (after they are finalized w.r.t. irreversible inputs that are finalized on L1) it constructs an “output root”, a claim about the L2 state. This is then submitted to L1. The L1 contract validates the output root is submitted from a specific authorized proposer account. In the future, once we have fault proof tech live, this proposal process will be permissionless (and possibly part of the user withdrawal-flow responsibilities).
Future: challenger monitors the onchain L1 claims from the proposer and other challengers, and counter-claims when necessary, as part of the fault-proof bisection game.
Is it possible to Update guide with addresses of all accounts so users can observe the txn flow end-to-end? Note that the addresses of the batcher and proposer may change, to enable key-rotation.
The SystemConfig contract on L1 (OP Mainnet: https://etherscan.io/address/0x229047fed2591dbec1eF1118d64F7aF3dB9EB290 ) is the source of truth for the batcher. But yes, 0x6887246668a3b87f54deb3b94ba47a6f63f32985 is the current batcher address (it can be read from the batcherHash attribute in the contract).
And the proposer is defined in the ouput oracle contract on L1 (OP Mainnet: https://etherscan.io/address/0xdfe97868233d1aa22e815a266982f2cf17685a27 ), from the PROPOSER attribute in the contract). And yes, 0x473300df21D047806A082244b417f96b32f13A33 is the current proposer.
The p2p sequencer key is not used onchain, only for offchain execution-payload (L2 block gossip data) signing. It can be found in the L1 SystemConfig as well.