Optimism Bedrock Wrap-Up Series 1 [ENG]

Overview of the Bedrock Upgrade

Onther aims to deliver valuable information for current developers interested in Optimism and the evolution of the Ethereum ecosystem.

Special Thanks to Theo Lee, Steven Lee, Austin Oh, and Justin Gee for their contributions to this post.

You can check the Korean version of this article here.

Fig. Bedrock (Source: Optimism)

This post is the first installment of the ‘Optimism Bedrock Wrap-Up Series,’ comprising five planned articles by Onther. It provides an overview of the Bedrock upgrade, its components, and the smart contracts deployed within its layers.

Given the interconnected nature of the series, we recommend reading the articles sequentially for a cohesive understanding.

Series 2. Key Changes Since the Bedrock Upgrade: In this section, we aim to unravel the substantial changes introduced by the Bedrock upgrade, laying the groundwork for a comprehensive understanding to navigate the upcoming segments of the series.

Optimism Bedrock Wrap-Up Series 2 [ENG]

Series 3. Analysis of the Deposit/Withdrawal Process: We will conduct a step-by-step analysis of the deposit/withdrawal process, unraveling the core code logic within its layers.

Optimism Bedrock Wrap Up Series 3 [ENG]

Series 4. Block Derivation: Once blocks are generated on the Layer 2(Optimism mainnet), the system initiates a process to roll-up these blocks to Layer 1. Subsequently, in the Block Derivation phase, L2 blocks are reconstructed using exclusively the data that has been rolled up. We will provide detailed guidance through each step of the block derivation process, offering code examination along the way.

Optimism Bedrock Wrap-Up Series 4 [ENG]

Series 5. Roles and Behavior of Optimism Bedrock Components: We comprehensively examine the roles and operational logic of Op-Batcher and Op-Proposer as the final components of this series.

Optimism Bedrock Wrap-Up Series 5 [ENG]

Introduction

The Bedrock upgrade carried out six months ago as of the date of writing, marked a transformative advancement for Optimism’s Layer 2 solution. The term ‘Bedrock’ signifies a collection of rocks forming the crust of a continent. This metaphor is employed to convey the notion of laying the essential foundation for the envisioned ‘SuperChain,’ a substantial continent within the Optimism ecosystem.

Fig. Superchain (Source: Optimism)

SuperChain embodies Optimism’s fundamental value of “Bridging people together” and serves as a decentralized blockchain platform consisting of multiple L2 chains built on Optimism’s OP Stack. Notably, various L2 solutions like Coinbase’s Base and Binance’s opBNB have recently integrated into the OP ecosystem, fostering ongoing collaboration.

Optimism Bedrock Upgrade Ultimate Mission

Fig. OP STACK and the Layer-by-Layer Modularization Structure (Source:Optimism)

1. Fast Transaction Speed: The goal is to minimize the latency associated with user transaction transmission, ensuring convenience and reliability. The Bedrock upgrade has notably reduced the deposit delay from 10 minutes to within 3 minutes.
2. Enhanced Scalability: The system’s ability to process a significant number of transactions per second is essential for providing users with low fees. Prior to the Bedrock upgrade, Optimism handled Layer 2 transaction outcomes within smart contracts on Layer 1. However, Bedrock optimizes this process by storing results in EOA and employing batch compression, yielding over 40% in gas fee savings.
3. Modularity: The design philosophy of Optimism revolves around modularizing layers responsible for consensus, execution, and transaction finality. This approach reduces complexity and facilitates the implementation of parallel functionalities. This, in turn, allows for the straightforward implementation of intricate software within the Optimism module, fostering the versatility of a wide range of DApps and structural simplification on the Optimism chain (e.g., OP Stack, Superchain).
4. EVM Compatibility: Optimism’s dedication to upholding Ethereum protocol standards is evident in the creation of the op-geth client for Bedrock. Minimal logic additions for rollup functionality were incorporated beyond Ethereum’s ‘geth’ client. The present OVM in Optimism displays only minor distinctions, totaling approximately 1–2 thousand lines when compared to Ethereum EVM. This strategic approach is designed to ease the transition for mainnet developers into the Optimism ecosystem, highlighting minimal differences with Ethereum client software (e.g., L2geth, Code re-use, Derivation).
5. Potential for Decentralization: If we were to pinpoint a current limitation within Optimism, it would be the centralization of the Sequencer. Presently, no roll-up solution has achieved full decentralization of the Sequencer (the network’s smooth operation is attributed to the centralization of the Sequencer). In response, Optimism is actively planning to decentralize the Sequencer by introducing multiple instances. Upon successful implementation, this would open up participation in the network as an L2 block producer to anyone interested.

Components by Layers

Fig. Correlation between components by Bedrock tier (Source:Optimism)

OptimismPortal: OptimismPortal is a contract responsible for handling deposits and withdrawals.

• For deposits, it initiates a deposit request transaction (DepositTransaction event) to the Rollup-Node. Ethereum/ERC-20 tokens deposited here undergo a locking process on L1, followed by minting on L2 through the deposit transaction.
• For withdrawals, it is responsible for retrieving withdrawal transactions from L2. During this process, it oversees the withdrawal status of the sender (withdrawer, L2Sender) in the withdrawal verification process, managing the entire process until the withdrawal is completed.
• OptimismPortal can be temporarily paused or resumed by a Guardian (an address with the authority to temporarily pause deposits and withdrawals).

BatchInbox: BatchInbox is the L1 address where the Sequencer stores transaction batches. It serves as the repository for all batches of transactions processed on L2, functioning as the storage for L2 transaction data. Batches here can be thought of as a collection of ‘optimized transactions.’ Transaction batches include comprehensive details of transactions, such as the calldata and timestamp of L2 transactions.

• The BatchInbox functioned as an alternative for Legacy Optimism’s CanonicalTransactionChain (CTC) contract. In contrast to the CTC contract, the BatchInbox employed an EOA address, leading to reduced gas costs by avoiding the execution of the EVM code.

L2OutputOracle: L2OutputOracle is a storage for the output root(state root)of every block generated on L2. Proposers periodically query the latest output root of L2 chain and store it in this contract.

• L2OutputOracle serves as the alternative to the StateCommitmentChain (SCC) contract.

L2 Components

Rollup-Node(OP-Node: Sequencer / Verifier): The Rollup-Node has two main roles, namely, acting as a Sequencer responsible for block creation and as a Verifier for validating blocks.

Fig. Two roles of Rollup-Node [Validator (blue), Sequencer (red)] (Source:Optimism)

Sequencer mode: it’s essential to consider two types of transactions: One is the Deposit Transaction originating from L1, received through the OptimismPortal whenever a deposit occurs. The other involves transactions not derived from L1 but generated within L2 itself (e.g., transactions from L2 DApps or transactions between L2 accounts).

• Currently, these two transaction types work together to form a new block on the L2 chain. The Sequencer employs the Engine API to transmit data related to the new block, and the Execution Engine ultimately generates and incorporates the block into the L2 chain.

Verifier mode: The Verifier compares the output root of the chain constructed by itself with the L2OutputRoot submitted by Sequencer.

• By fetching the rollup data on L1, the Rollup-Node independently generates a chain and verifies it against the L2 chain. During this verification process, the Verifier compares the output root of the chain locally generated by itself, with the L2OutputRoot already uploaded to the L2OutputOracle (L1).

Hence, the Rollup-Node operates in two modes (Sequencer mode / Validator mode), and understanding these two roles separately is more straightforward.

Execution Engine (EE): Created by slightly modifying Ethereum’s Geth client, it provides the Engine API to the Rollup-Node. Once the Rollup-Node is ready to create a block, the actual block is generated on the Execution Engine using the Engine API, also known as the Engine JSON-RPC API — a collection of methods implemented by execution clients.

Batch Submitter (Op-Batcher): Responsible for submitting a batch of transactions to the BatchInbox’s EOA account. (Detailed information will be covered in the fifth part of the series.)

Output Submitter (Op-Proposer): it submits the output root — the result of a transaction processed in L2 — to L2OutputOracle (Details will be covered in the fifth part of this series.)

*Currently, the Sequencer serves as both the Batch Submitter and Output Submitter. To achieve decentralization, these roles need to be separated and made accessible to the public.

Smart Contracts Deployed in Each Layer

L1 contracts

OptimismPortal: As explained in the L1 component section above, serves as both the entrance and exit for L2. It provides a low-level API for the movement of assets and messages between layers.

L2OutputOracle: Similar to the description in the L1 component section, the Verifier undergoes a verification process when the Sequencer publishes the L2 output root.

• If the output root of the locally generated chain by the Verifier does not match the output root in L2outputOracle submitted by the Sequencer, fault-proofing should be subsequently initiated. However, as of now, the fault-proofing feature is not yet supported and is under testing.

Contracts that still exist for Legacy Optimism Users

• L1CrossDomainMessenger: A contract that manages messages moving between layers.
• L1StandardBridge: A contract that offers a standard interface for transferring Ethereum or ERC tokens between layers.

L2 Contracts

L1Block: Users can retrieve details about the latest L1 block through the L1Block contract. The information in this contract is updated once per epoch. An epoch represents a grouping of blocks that validators bundle together during verification, defining the block interval between checkpoints. In the case of Optimism, blocks are generated at a rate of one every two seconds, so we set an epoch of six blocks.

Fig. ‘L1BlockValues’ information in block 109844341 (Source: optimistic.etherscan.io)

In the captured image from optimistic etherscan, the leftmost picture shows blocks being generated every 2 seconds, and the rightmost picture displays the ‘L1BlockValue’ of the 109844341st block (generated by the L1Block contract). From this, we can observe that the ‘_sequenceNumber’ is 000…000, indicating it’s the first block of that epoch. The 109844347th block, which is the 6th block after, will mark the beginning of the next epoch.

The address of the L1Block contract is 0x4200000000000000000000000000000000000015, and you can obtain the following parameters through the ‘getter’ function:

• number: The number of the most recent L1 block on L2.
• timestamp: The timestamp of the most recent L1 block.
• basefee: The base fee of the most recent L1 block.
• hash: The hash of the most recent L1 block.
• sequenceNumber: The sequence number of the L2 blocks in the epoch (the epoch changes when there is a new L1 block).

The purpose of the L1Block contract is as follows:

1. Calculate the L1 gas price to be used while processing transactions in L2.
2. Validate information about the L1 block submitted by the sequencer.
3. Determine whether a specific L1 transaction was successfully processed on L2.

The latest L1 block is updated with a delay of 24 seconds using 2 block confirmations to minimize the impact of reorgs.

SequencerFeeVault: A vault that stores the transaction fee on L2 that will be passed to the sequencer. This is the default fee charged in ETH for making a transaction on L2.

L2ToL1MessagePasser: A dedicated contract to store messages sent from L2 to L1, used to initiate withdrawals internally from L2CrossDomainMessenger.

• Legacy contract address: 0x4200000000000000000000000000000000000000
• Bedrock contract address: 0x4200000000000000000000000000000000000016

Contracts that still exist for Legacy Optimism Users

• L1BlockNumber: A contract that provides the number of the latest L1 block.
• L2CrossDomainMessenger: A contract used to send messages from L2 to L1.
• L2StandardBridge: A contract that provides a standard interface for transferring Ethereum or ERC tokens between layers.
• WETH9: A standard contract for implementing Wrapped Ether.

Closing Thoughts

To sum up, we’ve provided a comprehensive overview of the Bedrock upgrade, highlighting its pivotal role in shaping the Optimism ecosystem. Our exploration delved into the intricate components spanning different layers, elucidating their functions and interconnections. The ongoing collaboration among diverse L2 chains operating on the OP Stack lays the foundation for continuous evolution and improvement.

As we delve deeper into the next segments of our series, we will elucidate the significant changes and enhancements brought by the Bedrock upgrade.

Reference:

OP in Denver: Rollup Recap

Announcing OPCraft: an Autonomous World built on the OP Stack

Rollup Protocol Overview

https://optimism.mirror.xyz/2jk3D1Y8hid8YOCUUa6yXmsyzNCYYyFJP0Nhaey9x0https://github.com/ethereumoptimism/optimism/blob/develop/specs/overview.md

https://github.com/ethereumoptimism/optimism/blob/develop/specs/overview.md