Optimism Bedrock Wrap-Up Series 2 [ENG]

Bedrock upgrade key changes

(01.17.24) Updated incorrect information about how EIP 1559 burning works on Optimism)

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

Special Thanks to Theo Lee, Suah Kim, Steven Lee, Justin Gee, and Ethan.K for their contributions to this post.

You can check the Korean version of this article here.

Fig. Illustration of Optimism Bedrock (Source: OpLabs)

This post is the second installment of the ‘Optimism Bedrock Wrap-Up Series,’ comprising five planned articles by Onther, covering key changes after the Bedrock upgrade.

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

Series 1. Overview of the Bedrock Upgrade: It provides an overview of the Bedrock upgrade, its components, and the smart contracts deployed within its layers.

Optimism Bedrock Wrap-Up Series 1 [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]

Key Changes: Legacy → Bedrock Upgrade

Notably, Optimism optimizes its functionality by utilizing Ethereum as a data availability layer, leading to an enriched experience for both Ethereum users and developers. Especially through the utilization of Ethereum as a data availability layer, Optimism aims to enhance the experience for both Ethereum users and developers.

The Bedrock upgrade stands as a pivotal enhancement for both L1 and L2 networks within the Optimism ecosystem, significantly boosting scalability and performance. This is anticipated to foster innovation and progress across various sectors, including finance, gaming, DeFi, NFTs, and more, driven by the platform’s improved performance.

In this series, we aim to provide a brief overview of the key changes following the Bedrock upgrade.

Block Creation

Fig. Generation Path of L2 Blocks

In the above diagram, the transmission path of L2 transactions originating from L1 is briefly summarized using a simple example. In L1, blocks are generated at intervals of 12 seconds, and the 30 transactions accumulated in L1 over this period are forwarded to L2 and stored in the Mempool. Subsequently, the Sequencer in L2 rearranges the transactions based on their priority and block size. The rearrangement process involves pre-setting “pending transactions” to facilitate the generation of a block every 2 seconds. (Additional details on the prioritization for rearrangement are extensively discussed in the Mempool section.)

When comparing the block generation processes of Ethereum and Optimism, the most significant difference lies in the decentralization of the Mempool and Sequencer.

Ethereum: Generates blocks in a network consisting of decentralized nodes.

1. When users initiate various transactions such as executing smart contracts or transferring assets, these transactions are stored in the Mempool of the Ethereum network and enter the queue.
2. All validators staking ETH on the network verify the transactions in the Mempool and confirm their validity (e.g., transaction format, signatures, etc.)
3. Among the validator’s staking pool, a Block Proposer is randomly selected, and the selected Proposer gains the authority to create the next block. The new block is broadcast throughout the Ethereum network, and other nodes receive the block and add it to their blockchain.

Optimism: A centrally operated Sequencer in the protocol generates blocks.

1. When the centralized Sequencer receives user transactions through the Mempool, it undergoes a validation process for these transactions, providing immediate approval or rejection based on the results of transactions.
2. After validation, the transaction is defined in the local state and registered as a pending transaction. Here, a pending transaction refers to the state in which it awaits processing by the Execution Engine in L2 before the actual transaction is executed.
3. The Execution Engine then processes the most recent pending transaction, updating the state of the L2 chain.

Mempool

Fig. Priority Fee and Base Fee on OP Mainnet (Source: optimistic.grafana.net)

In the Legacy version, each transaction had a direct 1:1 correspondence with a block, resulting in the sequential processing of newly created transactions. However, in the Bedrock version, supporting EIP-1559, a ‘Mempool’ is required to store pending transactions during the process of generating blocks at fixed intervals.

When transactions are stored in the mempool, it’s not just passive storage; it significantly influences the order of block processing.

• You can enhance the likelihood of a transaction being processed in the next L2 block by specifying a higher Priority Fee.
• Priority Fee, a fee measured based on real-time network usage, allows network users to choose between Slow, Medium, and Fast fees or pay any desired Priority Fee amount. Mempool can dynamically calculate network usage and set a higher or lower estimate for the Priority Fee (Slow, Medium, or Fast). By adjusting this estimate, it can exert some control over the network’s congestion.
• If the Priority Fee is too low, transactions may persist in the mempool. In such cases, users can either resubmit the transaction with the same nonce to cancel it or resubmit it with a higher priority fee using a different nonce.

(Optimism’s Mempool is private, ensuring that transactions remain confidential until they are officially included in an L2 block.)

EIP-1559

Fig. Illustration titled “Will Ethereum be Deflationary with EIP-1559?”, (Source: moralismoney)

Optimism has updated its network to support EIP-1559 through the Bedrock upgrade. EIP-1559 enhances the fundamental fee mechanism of both Ethereum and Optimism by dynamically calculating and predictably managing fees and traffic for all transactions within generated blocks in real time.

Under EIP-1559, the gas unit cost comprises two elements (as elaborated in the Mempool explanation).

Fig. Block Size Variation Depending on Tx Size

Under EIP-1559, block size is dynamically adjusted within a range twice the maximum block size before the update. If demand increases due to transaction requests, block size (capacity) also increases, and conversely, it decreases with reduced demand.

Base Fee: The Base Fee is similarly measured within a ±12.5% range based on changes in block size. If more transactions occur than the system’s target block size, the Base Fee rises to suppress demand. Conversely, if transaction demand is lower than the target block size, the Base Fee decreases to encourage transaction occurrence. In contrast to the traditional method of adjusting fees based solely on the network’s TPS (Transactions Per Second), this mechanism enables the prediction of changes in block size, effectively curbing sudden fluctuations in fees.

Priority Fee: Users can elevate their transaction priority by paying a Priority Fee, up to their maximum willingness to pay. Sequencer will then process the transaction by adopting the highest priority fee first.

Furthermore, EIP-1559 marks a substantial shift in how user fees are managed, diverting them away from miners and choosing to burn them instead. This adjustment addresses the concern of decreasing ETH value in the face of a growing supply. By burning fees, the protocol aims to counterbalance the supply increase, fostering a scenario where if more ETH is burned than mined, a deflationary impact is induced, contributing to an upswing in ETH value. Consequently, the more active the network, the greater the amount of ETH burned.

H̶o̶w̶e̶v̶e̶r̶,̶ ̶a̶s̶ ̶O̶p̶t̶i̶m̶i̶s̶m̶ ̶d̶o̶e̶s̶ ̶n̶o̶t̶ ̶i̶n̶c̶l̶u̶d̶e̶ ̶a̶ ̶b̶u̶r̶n̶i̶n̶g̶ ̶m̶e̶c̶h̶a̶n̶i̶s̶m̶,̶ ̶t̶h̶e̶ ̶b̶u̶r̶n̶i̶n̶g̶ ̶p̶r̶o̶c̶e̶s̶s̶ ̶i̶s̶ ̶r̶e̶p̶l̶a̶c̶e̶d̶ ̶b̶y̶ ̶p̶e̶r̶m̶a̶n̶e̶n̶t̶l̶y̶ ̶l̶o̶c̶k̶i̶n̶g̶ ̶f̶e̶e̶s̶ ̶i̶n̶ ̶t̶h̶e̶ ̶b̶r̶i̶d̶g̶e̶.̶ ➠In the context of Optimism, the base fee is not burned; rather, it is stored in the baseFeeVault contract. This mechanism facilitates withdrawals to Layer 1, activated each time the accumulated amount reaches the _minWithdrawalAmount threshold. The designated recipient is specified within the contract — currently set as the simpleWallet constructed as a multi-sig wallet. Consequently, this process leads to the transfer of ETH from the Optimism Chain to the Ethereum chain, diverging from the conventional practice of burning(Revised on 01.17.24).

The opcodes and APIs for the EIP-1559 update are listed below.

Opcodes

• BASEFEE: Returns the Base Fee of the current block.

API

• eth_maxPriorityFeePerGas: Returns the ‘Priority Fee’ per gas to include a transaction in the current Ethereum block.
• eth_feeHistory: Returns gas fee information from previous blocks to reference when setting the Priority Fee.
  (If you want to read more about EIP-1559, you can follow this link).

L1 Attributes Deposited Transaction

Optimism has implemented a new concept of a System Transaction called ‘L1 Attributes Deposited Transaction’ for all blocks generated in L2.

Fig. 109,880,905th Block with 8 Transactions (Source: optimistic.etherscan.io)

In the captured image from optimistic.etherscan.io, we observe 8 transactions within the 109,880,905th block. Notably, the transaction at the bottom corresponds to the L1 Attributes Deposited Transaction. A closer examination of the ‘Input Data’ for this transaction reveals that it encapsulates comprehensive block information, encompassing details such as L1BlockNumber, timestamp, basefee, hash, and more.

The primary function of the L1 Attributes Deposited Transaction is to convey the latest information from every L1 block to op-geth, facilitating the update of the state of L2 accounts. Initially, the term ‘Deposited Transaction’ might suggest transactions involving the deposit of ETH or ERC-20 tokens. However, in Bedrock, it encompasses all L2 transactions and events triggered by L1, collectively referred to as ‘Deposit Transactions.’ While a majority of Deposit Transactions involve the deposit of assets like ETH or ERC-20 tokens, it’s essential to note that they can also encapsulate calls to contracts deployed on L2 without the transfer of assets.

Ultimately, the L1 Attributes Deposited Transaction ensures that the Sequencer can attach accurate information about the L1 block, providing a reliable reference. By directly incorporating L1 block information within each transaction, contracts deployed on L2 can receive the latest L1 block data without the need for cross-chain calls.

Block Derivation

Fig. Summary of Block Derivation Process

Rollup Nodes play a crucial role in monitoring the progress and state of the L2 chain. When the Sequencer creates an L2 block and the Batch Submitter submits data for the L2 block to L1 (BatchInbox), the Verifier should be able to reconstruct the L2 chain with the submitted data. This process of reconstructing the L2 chain based on data submitted to L1 is referred to as ‘Block Derivation.’

In the context of Bedrock, blocks are categorized into three types: unsafe, safe, and finalize. To comprehend the distinctions, it is essential to grasp two fundamental concepts. The first is the aforementioned ‘Block Derivation,’ and the second is the concept of ‘Finality’ in the Ethereum mainnet chain.

• Finality in Ethereum signifies a critical step in validating and irreversibly confirming a transaction by verifying it through checkpoints at regular block intervals after processing. A lack of finality indicates that the transaction has not been fully confirmed, as a re-org (reorganization of the blockchain) might occur. Conversely, once a transaction is finalized, it is irreversibly confirmed, and no re-org takes place, signifying complete verification and trust on the blockchain.
• In the event of a re-org on L1, the order of blocks in the OP chain, already processed in L2, may change, or some transactions may be missing. Blocks that have not attained finality may be impacted by the re-org, affecting L2 as well. This is why Optimism has also prepared for the L2 re-org as a backup to the L1 re-org.

In case of an L1 re-org, L2 reorganizes itself to align with L1. Consequently, the Optimism network needs to recreate previously submitted batches or output roots. To address this, blocks are classified into three types with specific criteria for network operation:

1. Unsafe: This indicates that the block has been generated in L2 but lacks finalization in Ethereum, and Block Derivation has not transpired on the RollupNode. The block is either recently created and yet to be rolled up or has undergone rolling up without progressing through Block Derivation. Consequently, the Unsafe block can be rearranged in the event of an L1 reorganization.
2. Safe: The batch of blocks has been submitted to L1, and the block derivation has taken place, but the block has not yet been finalized by L1, so it is less likely to be reorganized than an unsafe block, but there is still a chance that it could be.
3. Finalize: The block is considered finalized, meaning that it has already reached a sufficient depth. This means that the block derivation has been completed and the block has been finalized on the L1 Ethereum chain. Therefore, a finalized block cannot be re-organized.

Two-Phase Withdrawals

“The Bedrock upgrade will introduce a new two-step withdrawal process to the Optimism Mainnet bridge that will improve its security & make exploits much more difficult.”

- Optimism Labs -

In the Bedrock, when transferring funds from the Optimism to L1, the withdrawal process on L2 is initiated, and the withdrawal is now confirmed through two distinct steps: ‘proveWithdrawalTransaction’ and ‘finalizeWithdrawalTransaction.’

• In the earlier version, the withdrawal process was a single-step operation, with both the ‘prove’ and ‘finalize’ steps occurring concurrently after a 7-day challenge period. However, this approach had a vulnerability where an attacker could manipulate the ‘Merkle Proof’ and exploit a withdrawal process bug to steal a user’s assets without monitoring the Merkle Proof.
• To address this, the upgraded ‘proof’ phase in Bedrock commences by storing the withdrawal message and its corresponding proof together in a Merkle Patricia tree. By proactively publishing the proofs, on-chain monitoring tools gain sufficient time to identify fraudulent withdrawal proofs and initiate necessary corrective actions.

Fig. Two-step withdrawal: Step 1

To initiate a withdrawal process, the user is required to promptly provide evidence as soon as the output of the L2 block, containing the withdrawal transaction, is appended to the L2OutputOracle in L1.

The withdrawal process unfolds as follows:

1. The user initiates a withdrawal message from L2.
2. The user awaits the on-chain status output, a process that may take up to 1 hour.
3. Subsequently, the user actively participates by posting and verifying their proof, accomplished by invoking the proveWithdrawalTransaction function on the OptimismPortal.

Fig. Two-step withdrawal: Step 2

4. Challenges to the withdrawal proof are presented to the user during the 7-day challenge period. If the proof remains unchallenged by the end of this period, it is deemed a valid withdrawal, allowing the user to proceed with the withdrawal.

5. The user confirms that the challenge period has passed and calls the finalizeWithdrawal function in the OptimismPortal to withdraw their assets.

(A detailed code-level analysis of the withdrawal will be covered in the third part of the series).

Closing thoughts

In conclusion, here’s a brief overview of the significant transformations introduced by the Bedrock upgrade. The upgrade has not only ushered in substantial changes but has also infused a sense of enthusiasm into the Optimism ecosystem.

In the upcoming segment of this series, I will delve into a detailed examination of the deposit and withdrawal processes at the code level.

Reference:

Introducing op-erigon: how the Bedrock upgrade unlocks client diversity

Grafana

OP Mainnet Block #109880905 | Optimism

Welcome to the Optimism Docs

EIP-2718: Typed Transaction Envelope

EIP-1559: Fee market change for ETH 1.0 chain

WalletSimple | Address 0xa3d596EAfaB6B13Ab18D40FaE1A962700C84ADEa | Etherscan

Increasing Confidence in the OP Mainnet Bridge with Two-Step Withdrawals

Withdrawal Flow

What is EIP-1559 and Will Ethereum Go Deflationary With It? - Moralis Academy