How is Bedrock Different?

Bedrock is the next major release of the Optimism network, planned for the first quarter of 2023. Here are the major changes:

# Guide by persona

If you want to jump directly to the parts relevant to your job role, here are the parts we think will be most useful

Wallet developer

As a wallet developer you are most likely to interact with the JSON RPC, and your users want to know how much their transactions are going to cost. Timing may also be relevant.

Dapp frontend developer

As an application developer you are probably interested in the fact bedrock has a mempool and the changes in transaction fees. You might also be interested in changes in the RPC interface and block timing.

Dapp backend (protocol) developer

As an application developer you are probably interested in the fact bedrock has a mempool and the changes in transaction fees. You might also be interested in changes in the RPC interface and block timing.

Infrastructure provider (or anybody else running a node)

To run a node you need to understand the executables required to run it. You might also be interested in the existence of the mempool and the changes in block timing, fess, and the JSON RPC.

See here for a more detailed guide.

Bridge developer

As a bridge developer you are likely most interested in deposits into Optimism and withdrawals back into Ethereum L1.

# The EVM

  • There is no longer an L1BLOCKNUMBER opcode.
  • Bedrock includes an upgrade to the London fork, so the BASEFEE opcode is now supported.
  • TIMESTAMP will now be updated every two seconds (every new block).
  • BLOCKNUMBER will advance every two seconds because we'll create a new block every two seconds, regardless of the number of transactions.

# Contracts

# L1 contracts

# L2OutputOracle

The L2OutputOracle contract (opens new window) contains the state root of the Optimism blockchain. Once fault proofs are activated, it will be the one that receives the result of the fault proof process.

This is the contract that replaces the old State Commitment Chain.

# OptimismPortal

The OptimismPortal contract (opens new window) provides the new API for communications between layers.

# Existing interface

These contracts provide the same interface as existed pre-bedrock so dapps don’t have to be modified to run on bedrock.

# L2 contracts (predeploys)

# L1Block

The L1Block contract (opens new window) sits at address 0x4200000000000000000000000000000000000015. You can use the getter functions (opens new window) to get these parameters:

  • number: The latest L1 block number known to L2 (the L1BlockNumber contract is still supported to avoid breaking existing applications)
  • timestamp: The timestamp of the latest L1 block
  • basefee: The base fee of the latest L1 block
  • hash: The hash of the latest L1 block
  • sequenceNumber: The number of the L2 block within the epoch (the epoch changes when there is a new L1 block)

Currently the L1 information is delayed by ten block confirmations (~2.5 minutes) to minimize the impact of reorgs. This value may be reduced in the future.

# SequencerFeeVault

The SequencerFeeVault contract (opens new window) handles funding the sequencer on L1 using the ETH base fee on L2.

The fees are calculated using EIP 1559 (opens new window), the same mechanism that Ethereum uses (but with different parameter values).

# L2ToL1MessagePasser

The L2ToL1MessagePasser contract (opens new window) is used internally by L2CrossDomainMessenger to initiate withdrawals.

# Existing interface

These contracts provide the same interface as existed pre-bedrock so dapps don’t have to be modified to run on bedrock.

# Historical contracts

These are contracts that are no longer relevant, but are kept as part of the state in case there is a call in any dapp that uses them.


  • Bedrock supports eth_sendMessage and eth_getAccounts.
  • The non standard eth_getBlockRange is no longer supported.

# Communication between layers

In Optimism terminology "deposit" refers to any message going from the Ethereum blockchain to Optimism, whether it has any assets attached or not. Similarly, "withdrawal" refers to any message going from Optimism to Ethereum.

See here for the messenger specs (opens new window) and here for the bridge specs (opens new window).

# Gas cost changes

The gas costs for communication between layers are going to change, they will probably get lower. More information will be posted here once we have more exact information after we profile a test network.

# Deposits (from Ethereum to Optimism)

To create a deposit we recommend that you use the pre-bedrock contracts L1StandardBridge (opens new window) and L1CrossDomainMessenger (opens new window). OptimismPortal (opens new window) also has deposit functionality.

With the portal’s depositTransaction function you can do from L1 anything you can do by contacting L2 directly: send transactions, send payments, create contracts, etc. This provides an uncensorable alternative in case the sequencer is down. Even though the sequencer is down, verifiers (nodes that synchronize the Optimism state from L1) are still going to receive such transactions and modify the state accordingly. When the sequencer is back up it has to process the transactions in the same order to have a valid state.

Deposits that come from contracts still use address aliasing.

Deposits will also be faster, probably about 2.5 minutes or less, rather than the 10-20 minutes they take now.

You can read the full deposit specifications here (opens new window).

# Withdrawals (from Optimism to Ethereum)

The withdrawal process is similar, but not identical.

  1. You initialize withdrawals with an L2 transaction, the same you did prior to bedrock.

  2. Wait for the next output root to be submitted to L1 (up to an hour on mainnet, less than that on the test network) then submit the withdrawal proof using proveWithdrawalTransaction. This new step makes the proof available during the challenge period, which makes it much easier to identify faulty proofs. Having the proof available for off-chain testing helps us guard against a whole class of vulnerabilities based on invalid fault proofs.

  3. After the fault challenge period ends (a week on mainnet, less than that on the test network), finalize the withdrawal.

You can read the full withdrawal specifications here (opens new window)

# Blockchain

In general, the blockchain in bedrock is a lot closer to Ethereum, at least post-merge Ethereum, than the current incarnation.

# Blocks

# Block timing

In bedrock blocks are produced every two seconds, regardless of whether there are transactions to put in them or not. This brings us closer to post-merge Ethereum, where blocks are expected every twelve seconds (opens new window). Before bedrock an Optimism block was produced for every transaction, and if there were no transactions no block was produced.

The period between different Ethereum blocks is called an epoch. Normally we'd expect to have six Optimism blocks per epoch, but it is expected that in some cases mainnet will miss a block (because the proposer is offline), and in those cases we'll have epochs with twelve Optimism blocks.

# Data structure

The transactions in a block are divided into either two or three transaction types.

  1. The first transaction is an L1 attributes deposit transaction (opens new window). This transaction sets the parameters of the L1Block contract. One of the attributes is the sequential number of the block within the epoch.

  2. In the first block of an epoch (the first L2 block produced after an L1 block) there can be user deposit transactions (opens new window).

  3. Finally there are the normal L2 transactions.

# Transactions

Currently transactions are privately forwarded from nodes directly to the sequencer, at which point they are either accepted and processed immediately or rejected (for low gas price, insufficient ETH, etc.).

In bedrock transactions are still privately forwarded from nodes directly to the sequencer, but now they get placed into a private mempool. The private mempool’s operation is similar to the Ethereum L1’s mempool. The sequencer will order transactions the way miners do, based on priority fee.

# Transaction fees

In bedrock the transaction's L2 execution gas price is determined using the same mechanism that is used on Ethereum, EIP 1559 (opens new window).

In EIP-1559 the cost of a unit of gas is composed of two components:

  • Base fee: This fee is the same for all transactions in a block. It varies between blocks based on the difference between the actual size of the blocks (which depends on the demand for block space) and the target block size. When the block uses more gas than the target block size the base fee goes up to discourage demand. When the block uses less gas than the target block size the base fee goes down to encourage demand.

  • Priority fee: This fee is specified in the transaction itself and varies between transactions. Miners (and after The Merge, proposers) are expected to select the transactions that offer them the highest priority fees first.

There are some differences between Ethereum and Optimism in this regard:

  • ETH is not burned, but used to pay protocol expenses. Burning ETH on L2 would only lock it in the bridge forever.

  • The EIP 1559 parameters have different values. Once those values are finalized they will be posted here.

The L1 security fee, which is normally the majority of the transaction cost, uses the same mechanism as before the upgrade. However, we are going to submit the transactions to L1 on a non-contract address. Between that and improved compression, we hope to reduce the L1 security fee by about 20%.

Estimating L1 gas prices

The OVM_GasPrice interface is likely to change, so for estimating transaction prices we recommend using the SDK (opens new window).

# Executables

The information in this section is primarily useful to people who run an Optimism network node, either as a replica or as an independent development node.

In bedrock processing is divided between two components:

Note that while op-geth is similar to the previous version's l2geth, there is no bedrock equivalent to the DTL.

# op-node

The op-node (Optimism's implementation of a rollup node (opens new window)) provides the L1 information that op-geth uses to derive the L2 blocks. The op-node always provides the L2 state root to op-geth, because that's the root of trust that needs to come from L1. It can also provide all the transactions from L1 for synchronization, but that mechanism is slower than snap sync (see next section).

# op-geth

op-geth (Optimism's implementation of an execution engine (opens new window)) runs a slightly modified version of geth. In terms of EVM equivalence, it is even closer to upstream geth than the current version.

One important feature that we inherit from upstream geth is their peer to peer synchronization, which allows for much faster synchronization (from other op-geths). Note that peer to peer synchronization is allowed, not required. For censorship resistance, op-geth can synchronize purely from the op-node that receives data from L1. There are two types of synchronization possible:

  1. Snap sync, which only synchronizes the state up to the point that has been submitted to L1.

  2. Unsafe block sync, which includes everything the sequencer created, even if it hasn't been written to L1 yet.

# Legacy requests

We need to provided history from the final regenesis (November 11th, 2021) until the introduction of bedrock. At the same time, we do not want to put anything in op-geth that doesn't need to be there. The closer it is to upstream geth the better.

The solution is to have two additional components:

  1. Daisy chain, an RPC proxy that routes read requests from before bedrock to the legacy geth, and everything else to op-geth.
  2. Legacy geth, a stripped down version of the previous version's l2geth with a read only database containing the pre-bedrock history.

# Behind the scenes

This section discusses some of the changes in Optimism internals.

# The transaction trail

There is no longer a CTC (cannonical transaction chain) contract. Instead, L2 blocks are saved to the Ethereum blockchain using a non-contract address (0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0001), to minimize the L1 gas expense.

The block and transaction format is also different (opens new window).

# ETH balances

In bedrock ETH is treated exactly as it is in Ethereum.

In the previous version ETH was stored in a system level contract at 0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000. This is no longer the case.