Optimism Study
(1) Brief Description of Rollup Solution
- Optimistic Rollup with fraud proof mechanism (in the works)
- Transaction data is available on L1 as well as a history of submitted L2 state roots.
- General-purpose rollup
(2) System Actors
1. Sequencer
- This is a rollup node that produces blocks.
- It gossips out blocks as it creates them.
2. Verifier/Replica
- This is a rollup node that does not produce blocks.
3. Batcher
- This actor is responsible for publishing L2 blocks to L1.
4. Proposer
- This actor publishes L2 state roots (and additional information) to L1 to enable withdrawals.
- When a Proposer publishes an L2 state root, this is where a challenge period begins.
5. Challenge Agent
- This actor challenges L2 state proposals when faults occur.
(3) Actor Relationships
Relationship Information
- Sequencers and Verifiers are the same piece of software, and they communicate with each other (observe the P2P communication link in the diagram).
- Sequencers and Verifiers read data from L1.
- Batcher looks for L2 blocks from the Sequencer, publishes batches to L1.
- Verifiers detect new batches and deposits published to L1.
- Users can submit L2 transactions to either the Verifier or Sequencer, there is going to be a mempool to facilitate transaction gossip.
- To do a withdrawal, User fetches Merkle proof from a Verifier (holding canonical state), and then submits it to L1.
Additional Actor Information
- Sequencer/Verifier are a combination of the rollup node client and L2 execution client.
- Sequencer/Verifier requires an L2 execution engine as well as a consensus client (this client can be found in Optimism codebase as
op-nodeand also consists of the rollup node client).
- Batcher and Proposer are logically separate from the Sequencer, the binaries are also separate.
- The Sequencer, Batcher, Proposer are currently all trusted. With the introduction of Cannon, the Proposer and Batcher will be decentralised.
- The Sequencer is the primary actor capable of extracting MEV.
(4) Rollup Characteristics
| Title | Description |
| Settlement | - Optimistic rollup - Fraud proof mechanism used with optimistic security assumption (atleast one honest or rational actor) - Fraud proof mechanism consists of leveraging MIPs computation in bisection game to prove invalid state transition between intermediate state roots (shares). |
| Execution Environment | L2-Geth (A simpler geth-implementation hence EVM-equivalent) |
| Sequencing Rules | - A centralised sequencer is entirely responsible for transaction ordering currently. - Deposit transactions (initiated on L1) must be added to the beginning of an L2 block. - After Cannon upgrade (introduction of fault proof system), sequencer decentralisation will be the next priority. - “Sequencer Auctions” are being proposed to democratise MEV opportunities. Mechanisms around retroactive public goods funding are also being considered. |
| Economics | Optimism has introduced a native token called OP. Currently no significant role other than being used as a signalling mechanism for delegating support of protocol changes. |
Fraud Proof Mechanism
With the Bedrock upgrade, Cannon will be introduced. Cannon is the generic optimistic fault proof system that will be leveraged by the Optimism chain.
When a Challenge Agent identifies invalid state within a submitted state root’s challenge period, they will bond and initiate the cryptoeconomic validity game (L2 dispute game).
On L1, there will exist a MIPS fraud verifier contract which essentially will re-execute L2 transactions from intermediate state roots to the point that has been identified as the invalid state transition (or multiple). Therefore if the Challenge Agent is correct about their claim of invalid state, they will be rewarded with a slashed bond from the proposer/sequencer who posted the state root and batch containing invalid data to L1.
(5) Data Publication
State Validation
Currently, the system permits invalid state roots being submitted to the system (since the Proposer is currently trusted, there is no reason for this to happen but in theory it could happen if the proposer attempted to do so currently).
This is a risk, because user funds may be stolen by carrying out invalid state transitions without any mechanisms enshrined to prevent this outside of trust.
Data Availability
Transaction data is published on L1 to a contract, therefore anyone observing the contract can compute the canonical state with all the transaction history being full available on L1.
zlib compression utilised to represent L2 blocks as compressed batches.Sequencer Failure
The system currently has a centralised sequencer. If the sequencer experiences failure, a user can force a transaction on L1 via the CTC contract hence allowing a user to circumvent censorship.
Validator Failure
If a whitelisted validator (Replica/Verifier) goes down, there is no mechanism in place to process a withdrawal, even in the case that you have the Merkle proof to the account state.
(6) Rollup Milestone Status
Stage 0 (Full training wheels)
- Optimism posts all transaction data on-chain.
- It has a rollup full node that reads the L1 chain, and computes rollup chain state.
- It is able to allow withdrawal of assets without operator cooperation (trustless).
- The operator cannot freeze of steal users’ assets by censoring users.
Prerequisites for Stage 1 (limited training wheels):
- Fraud proof scheme needs to be operational.
- Multisig-based override mechanism (security council) required that can override fraud proof system in the case that the system code is bugged. This multisig is required to be 6 or 8 participants. There must also exist a quorum-blocking group that is able to prevent the multisig from acting and must exist outside of the organisation that is running the rollup.
- If upgrade mechanism exists, it must have lower threshold than the multisig. Upgrades must have a activation delay of atleast 7 days or the max length of the fraud proof game (whichever is longer)
Curated References
External References
Blog Posts
Analytics (Dune, Notebooks)
Specs
Discussions
Podcasts
Twitter
Wikipedia Glossary