Optimism Preliminary Research (Old)
1. Agents
We identify the following actors that interact with the system:
- User
- Rollup Operator (includes sequencer, verifier, batcher, proposer roles)
- Challenge Agent
- Settlement and DA Layer
User
User can:
- Submit L2 transaction to the L2 sequencer.
- Deposit assets to the rollup via Ethereum contract call (L1).
- Submit an L2 transaction for inclusion via a L1 contract call (bypassing the sequencer)
Rollup Operator
This is made up of 2 sub-actors(Verifier, Sequencer)
Verifier:
- A rollup node that does not produce blocks.
- Looks for new deposits and L2 blocks posted to L1 (in a L1 contract) to update its local state (could also do this optimistically by trusting the sequencer but with much higher trust assumptions)
- Receives transactions from users and broadcasts them over P2P network (sequencer can receive these to prepare L2 block).
Sequencer (also consists of 2 sub-components → batcher, proposer):
- The sequencer is the primary L2 block producer. It is the primary party involved with maintaining liveness of the Optimism chain.
- Receives off-chain transactions
- Observes on-chain transactions (deposit events from L1, or L2 transactions submitted directly from L1)
- Orders transactions and produces L2 blocks.
- Sends produced blocks across P2P network as well as to the batcher for publishing to L1.
- Batcher:
- Receives an L2 block and publishes it to L1
- Proposer:
- Posts the latest L2 state root to L1.
Challenge Agent
The challenge agent will look at L2 blocks and corresponding L2 state roots posted to L1 and will initiate a challenge game if a discrepancy is found. If the challenge agent successfully proves that a L2 block is invalid, the sequencer node responsible for the publishing of the block will have their bond slashed and part of it rewarded to the challenge agent.
A challenge agent would typically run a verifier node alongside an Ethereum full node.
The actor interaction is visualised with the diagram below:
2. Characteristics
Settlement
Optimistic rollup. Fraud proof mechanism used in combination with optimistic security assumptions (only one honest or rational actor required to initiate the cryptoeconomic validity game).
Execution Environment
EVM Equivalent (complete alignment with the EVM specification)
It is essentially a Geth client with minor modifications to cater for Optimism’s execution specifications. In this environment, L2 state is maintained and updated according to explicit state transition rules.
Sequencing Rules
The sequencer is currently centralised and run in permissioned manner by Optimism.
The plan is to decentralise the role of sequencer once fraud proofs are enabled on Optimism. There are various proposals for how to manage transaction ordering once this role becomes permissionless such as “sequencer auctions”, mechanisms designed about value extraction flowing to public goods or retroactive public good funding DAOs.
Economics
Optimism has a native token called the OP Token.
3. Rollup Operator Composition
Sequencer
Currently there is a single, permissioned sequencer run by Optimism.
It is responsible for collecting transactions, locally applying them and computing new state roots, and then submitting the L2 transactions (in the form of compressed transaction bundles) along with the new L2 state root to Ethereum (via an L1 contract call).
Executor
The OVM runs transactions through a state transition function and produces new state and corresponding state roots.
Publisher
Batcher is responsible for publishing L2 blocks to L1.
Proposer is responsible for publishing L2 state roots to L1.
Both these sub-components are the responsibility of the sequencer actor.
Prover
- MIPS fraud verifier written in Solidity (using bisection game to find misstep)
Currently still in development (Cannon)
4. Data Publication
Data Availability:
L2 transactions and state roots are published to Ethereum, hence all the data required to reconstruct the Optimism chain is available on Ethereum.
Settlement:
Arbitration (validity games via fraud proof mechanisms) are managed by a smart contract living on Ethereum.
Longer Notes:
optimism/l2geth/rollup/client.go (batch struct is defined here)- Batch represents the data structure that is submitted with a series of transactions to layer one.
- EthContext represents the L1 EVM context that is injected into the OVM at runtime. It is updated with each enqueue transaction and needs to be fetched from a remote server to be updated when too much time has passed between enqueue transactions.
- L1GasPrice represents the gas price of L1. It is used as part of the gas estimation logic.
- There is also a RollupClient interface. RollupClient is able to query for information that is required by SyncService.
- There is a
getLatestTransactionBatch()method.
- There is a
getTransactionBatch(index uint64)
optimism/l2geth/internal/ethapi/backend.go - Backend interface provides the common API services (these are provided by both full and light clients) with access to necessary functions.
go-ethereum/rpc/client.go (callContext is defined here, it performs a JSON-RPC call with the given arguments, some sort of HTTP client)Useful References
Blog Posts
Analytics (Dune, Notebooks)
Specs
Discussions
Podcasts
Twitter
Wikipedia Glossary