Learn About Rollup Protocol

The Optimistic Rollup is the key concept that enables optimism. We’ll go through a high-level explanation of how Optimistic Rollups function. Then we’ll describe why Optimism is designed as an Optimistic Rollup and why we feel it’s the greatest option for a system that meets all of our design objectives.

Optimistic Rollups TL;DR

Optimism is an “Optimistic Rollup,” which is a fancy way of saying a blockchain that benefits from the security of another “parent” blockchain. Specifically, Optimistic Rollups use their parent chain’s consensus process (such as PoW or PoS) rather than supplying their own. This parent blockchain in Optimism’s instance is Ethereum.

Block Storage

All Optimism blocks are saved in a special Ethereum smart contract called the Canonical Transaction Chain (opens in a new window) (or CTC for short). Inside the CTC, optimism blocks are stored in an append-only list (we’ll describe how blocks are added to this list in the following section). The Optimism blockchain is formed by this append-only list.

The CanonicalTransactionChain comprises code that ensures that new Ethereum transactions cannot modify the existing list of blocks. This promise, however, can be violated if the Ethereum blockchain is rearranged and the sequencing of previous Ethereum transactions is altered. The Optimism mainnet is built to withstand block reorganisations of up to 50 Ethereum blocks. If Ethereum undergoes a broader reorg, Optimism will also undergo a reorg.

Avoiding such major block reorganisations is a core security aim of Ethereum. Optimism is, therefore, safe from huge block reorganisations as long as the Ethereum consensus process is. Optimism obtains its security features from Ethereum (at least in part) through this link.

Block Production

The production of optimism blocks is generally coordinated by a single entity known as the “sequencer,” who assists the network by offering the following services:

Offering real-time transaction confirmations and status changes.

L2 block construction and execution

L1 is receiving user transactions.

There is no mempool in the sequencer. Thus, transactions are accepted or denied in the order they were received. When a user submits a transaction to the sequencer, it validates it (pays a suitable fee) and then adds the transaction to its local state as a pending block. These pending blocks are frequently submitted to Ethereum in big batches for finalization. This batching approach drastically decreases overall transaction expenses by distributing fixed costs and transactions within a batch. The sequencer employs some rudimentary compression methods to reduce the quantity of data broadcast to Ethereum.

Because the sequencer has priority write access to the L2 chain, it can ensure what state will be completed as soon as it settles on a new pending block. In other words, the consequence of the transaction is accurately known. As a result, the L2 state may be changed consistently and fast. This provides a quick, rapid user experience, with features such as near-real-time Uniswap pricing changes.

Alternately, users can completely omit the sequencer and instead submit their transactions to the CanonicalTransactionChain by means of an Ethereum transaction. One is often more expensive since the user pays the whole fixed cost of submitting this transaction, which is not amortized across many such transactions. However, this alternate submission approach has the advantage of being immune to sequencer censoring. Even if the sequencer deliberately blocks a user, they may still utilize Optimism and use this approach to get their money back.

For the time being, the lone block producer is Optimism PBC.

Block Execution

Ethereum nodes obtain blocks from Ethereum’s peer-to-peer network. Instead, optimism nodes download blocks straight from the Canonical TransactionChain contract’s append-only list of blocks. For additional details on how blocks are kept within this contract, see the section on block storage above.

The Optimism client software and the Ethereum data indexer are the two main components of Optimism nodes. The Ethereum data indexer (or DTL) rebuilds the Optimism blockchain from blocks submitted to the Canonical Transaction Chain contract. The DTL looks for events generated by the Canonical Transaction Chain that indicate the publication of fresh Optimism blocks. It then looks at the transactions that generated these events to recreate the published blocks using the typical Ethereum block format.

The Optimism client program, the second component of the Optimism node, is a nearly vanilla version of Geth. This implies that behind the hood, Optimism is nearly identical to Ethereum. Specifically, Optimism and Ethereum share the same Ethereum Virtual Machine , account and state structure, gas metering system, and fee schedule. This design is known as “EVM Equivalence”, and it implies that the majority of Ethereum tools (including the most complicated ones) “simply work” with Optimism.

The DTL is constantly monitored by the Optimism client program for freshly indexed blocks. When a new block is indexed, the client program downloads it and performs the transactions contained inside it. To execute a transaction on Optimism, use the identical steps as on Ethereum: first, load the Optimism state, then apply the transaction against it. Finally, record the state changes that arise. This method is then repeated for each new DTL-indexed block.

Bridging Assets Between Layers

Optimism allows users to transmit arbitrary messages between Optimism and Ethereum smart contracts. This allows assets, especially ERC20 tokens, to be transferred across the two networks. The precise technique by which this communication takes place varies based on the direction in which information is transmitted.

This capability of the Standard bridge is used by Optimism to enable users to transfer assets (ERC20 tokens and ETH) from Ethereum to Optimism. Users can withdraw the same assets from Optimism and send them back to Ethereum.

Transitioning From Ethereum To Optimism

Users merely need to activate the Canonical Transaction Chain contract on Ethereum to generate a new block on the Optimism block to convey messages from Ethereum to Optimism. For further information, see the section on block creation above. Blocks that users generate may include transactions that seem to come from that address.

Moving From Optimism To Ethereum

In the same manner that Ethereum contracts may easily produce transactions on Optimism, this is not feasible for contracts on Optimism. As a result, returning data from Optimism to Ethereum requires a little more effort. We need to be able to make verifiable claims about the optimism of Ethereum-based contracts rather than automatically producing verified transactions.

Making claims about the state of optimism that can be proven needs a cryptographic commitment in the form of the trie’s root. This commitment will alter after each block since optimism’s status is changed. Approximately once or twice per hour, a smart contract on Ethereum called the State Commitment Chain publishes commitments.

Users can use these promises to produce Merkle tree proofs regarding the optimistic situation. Ethereum smart contracts can verify these proofs. The L1 Cross Domain Messenger, a handy cross-chain communication contract that Optimism manages, may validate these proofs on behalf of other contracts.

These proofs may support verifiable claims regarding the information stored in any contract on Optimism at a particular block height. Then, using this fundamental capability, it will be possible for contracts on Optimism to communicate with contracts on Ethereum. Contracts on Optimism can utilize the L2ToL1MessagePasser contract (predeployed to the Optimism network) to store a message in the state of Optimism. Users may then demonstrate to Ethereum contracts that a certain Optimism contract wanted to deliver a specific message by demonstrating that the L2ToL1MessagePasser contract has saved the message’s hash.

Fault Proofs

Fault proofs Instead, for a while, these promises are regarded as pending (called the “challenge window”). A proposed state commitment is deemed final if it is not contested during the challenge window, which is presently set to seven days. On Ethereum, smart contracts may securely receive evidence about the status of Optimism based on a commitment after it is deemed to be final.

When a state promise is contested, a “defect proof” procedure—previously known as a “fraud-proof” method—can be used to render it invalid. If the challenge is successful, the commitment is withdrawn from the State Commitment Chain, at which point another proposed commitment will take its place. It’s crucial to understand that only the publicly available promises on the status of the chain are reversed by a successful challenge, not Optimism itself. A fault-proof challenge leaves the transaction sequencing and optimism unaltered.

The November 11th EVM Equivalence update is adversely influencing the fault-proof process, which is now undergoing significant rebuilding. The Protocol specifications area of this website has further information about this procedure.