The Native Rollups Book
Table of Contents
What are native rollups?
A native rollup is a new type of EVM-based rollup that directly makes use of Ethereum's execution environment for its own state transitions, removing the need for complex and hard-to-maintain custom proof systems.
Problem statement
Governance risk
Today, EVM-based rollups need to make a trade-off between security and L1 equivalence. Everytime Ethereum forks, EVM-based rollups need to go through bespoke governance processes to upgrade the contracts and maintain equivalence with L1 features. A rollup governance system cannot be forced to follow Ethereum's governance decisions, and thus is free to arbitrarily diverge from it. Because of this, the best that an EVM-based rollup that strives for L1 equivalence can do is to provide a long exit window for their users, to protect them from its governance going rogue.
Exit windows present themselves with yet another trade-off:
- They can be short and reduce the un-equivalence time for users, but reducing at the same time the cases in which the exit window is effective. All protocols that require long enough time delays (e.g. vesting contracts, staking contracts, timelocked governance) would not be protected by the exit window.
- They can be long to protect more cases, at the cost of increased un-equivalence time. It's important to remember though that no finite (and reasonable) exit window length can protect all possible applications.
The only way to avoid governance risk today is to give up upgrades, remain immutable and accept that the rollup will increasingly diverge from L1 over time.
Bug risk
EVM-based rollups need to implement complex proof systems just to be able to support what Ethereum already provides on L1. Such proof systems, even though they are getting faster and cheaper over time, are still considered not safe to be used in production in a permissionless environment. Rollups today aim to reduce this problem by implementing multiple independent proof systems that need to agree before a state transition can be considered valid, which increases protocol costs and complexity.
The EXECUTE precompile
Native rollups solve these problems by replacing complex proof systems with a call to the EXECUTE precompile, which under the hood implements a recursive call to Ethereum's own execution environment. As a consequence, every time Ethereum forks, native rollups automatically adopt the new features without the need for dedicated governance processes. Moreover, the EXECUTE precompile is "bug-free" by construction, in the sense that any bug in the precompile is also a bug in Ethereum itself which will always be forked and fixed by the Ethereum community. At the same time, the Ethereum community will focus on hardening the guarantees of L1 execution with extensive testing, multiple client implementations and formal verification, and native rollups will be able to benefit from all these efforts automatically.
Purpose of this book
This book is designed to serve as a comprehensive resource for understanding and contributing to our work on native rollups.
Goals of this book include:
- Provide in-depth explanations of the inner workings of the
EXECUTEprecompile. - Provide technical guidance on how native rollups can be built around the precompile.
- Educate readers on the benefits of native execution and how the proposal compares to other scalability solutions.
- Provide a starting point for community members to discuss and contribute to the design and implementation of native rollups.
The EXECUTE precompile
Table of Contents
Re-execution vs ZK enforcement
The original proposal for the EXECUTE precompile presented two possible enforcement mechanisms: re-execution and ZK proofs. While the latter requires the L1 ZK-EVM upgrade to take place, the former can potentially be implemented beforehand and set the stage for the ZK version, in a similar way that proto-danksharding was first introduced without PeerDAS.
The re-execution variant would only be able to support optimistic rollups with a bisection protocol that goes down to single or few-L2-blocks sized steps, and that are EVM-equivalent. Today there are three stacks with working bisection protocols, namely Orbit stack (Arbitrum), OP stack (Optimism) and Cartesi. Cartesi is built to run a Linux VM so they wouldn't be able to use the precompile, and Orbit supports Stylus which doesn't make them fully EVM-equivalent, unless a Stylus-less version is implemented, but even in this case it wouldn't be able to support Arbitrum One. OP stack is mostly EVM-equivalent, but still requires heavy modifications to support native execution. It's therefore unclear whether trying to implement the re-execution version of the precompile is worth it, or if it's better to wait for the more powerful ZK version.
While the L1 ZK-EVM upgrade is not needed for the re-execution version, statelessness is, as we want L1 validators to be able to verify the precompile without having to hold all rollups' state. It's not clear whether the time interval between statelessness and L1 ZK-EVM will be long enough to justify the implementation of the re-execution variant.
Design principles
The EXECUTE precompile should re-use as much as possible the existing STF infrastructure, while also trying to provide the highest possible level of customization. As of the time of writing, the current goal is to to leave untouched the apply_body or the state_transition function of the execution spec, while providing maximum flexibility around it. As a consequence, it's currently not possible to add custom transaction types, custom precompiles, or custom fee markets, as any change would potentially also affect the L1 execution environment, and as the proposal becomes more complex, it also becomes more controversial and with lower chances of being accepted. Any changes to the execution environment should be considered only if they would largely prevent the adoption of the EXECUTE precompile.
Significant parts of the design depend on its tech dependencies design, which might still be in development. The precompile tries to be specified as if such features were already implemented, without trying to predict exact details. Significant changes are therefore expected once they mature.
(WIP) Specification
Two variants are presented here, one that recursively calls apply_body, and one that calls state_transition. The former skips some checks and just provides the necessary data to perform the block execution, while the latter contains all header information and checks that L1 performs too.
apply_body variant
def execute(evm: Evm) -> None:
data = evm.message.data
...
charge_gas(...) # TBD
...
# Inputs
chain_id = ... buffer_read(...) # likely hard-coded in a contract
number = ... buffer_read(...)
pre_state = ... buffer_read(...)
post_state = ... buffer_read(...)
post_receipts = ... buffer_read(...) # TODO: consider for L2->L1 msgs
block_gas_limit = ... buffer_read(...) # TBD: depends on ZK gas handling
coinbase = ... buffer_read(...)
prev_randao = ... buffer_read(...)
transactions = ... buffer_read(...) # TBD: this should be a ref to blobs. TODO: think whether it should also support storage and memory
parent_gas_limit = ... buffer_read(...) # needed for base fee calculation
parent_gas_used = ... buffer_read(...) # needed for base fee calculation
parent_base_fee_per_gas = ... buffer_read(...) # needed for base fee calculation
l1_anchor = ... buffer_read(...) # TBD: arbitrary info that is passed from L1 to L2 storage
# Disable blob-carrying transactions
for tx in map(decode_transaction, transactions):
if isinstance(tx, BlobTransaction):
raise ExecuteError
# This is normally performed in `validate_header` in `state_transition`
base_fee_per_gas = calculate_base_fee_per_gas(
block_gas_limit,
parent_gas_limit,
parent_gas_used,
parent_base_fee_per_gas
)
block_env = vm.BlockEnvironment(
chain_id =chain_id,
state =pre_state, # NOTE: this is an L2 state!
block_gas_limit =block_gas_limit,
block_hashes =..., # TBD: depends how it will look like post-7709
coinbase =coinbase,
number =number, # TBD: they probably need to be strictly sequential
base_fee_per_gas =base_fee_per_gas,
time =..., # TBD: depends if we want to use sequencing or proving time
prev_randao =prev_randao, # NOTE: assigning `evm.message.block_env.prev_randao` prevents ahead-of-time sequencing
excess_blob_gas =0, # TBD: might be useful for L2 pricing. Ignored for now
parent_beacon_block_root=... # TBD
)
# Handle L1 anchoring. The system tx is `unchecked` because projects might decide to not use it at all
process_unchecked_system_transaction(
block_env =block_env,
target_address=L1_ANCHOR_ADDRESS, # TBD: exact predeploy address + implementation. Also: does it even need to be a fixed address?
data =l1_anchor # TBD: exact format
)
block_output = apply_body(
block_env =block_env,
transactions=transactions,
withdrawals =() # TODO: consider using this for deposits
)
# NOTE: some things might look different with statelessness
block_state_root = state_root(block_env.state)
receipt_root = root(block_output.receipts_trie)
# TODO: consider using requests_hash for withdrawals
# TODO: consider adding a gas_used top-level param
if block_state_root != post_state:
raise ExecuteError # TODO: check if this is the proper way to handle errs
if receipt_root != post_receipts:
raise ExecuteError
evm.output = ... # TBD: maybe block_gas_used?
state_transition variant
def execute(evm: Evm) -> None:
data = evm.message.data
...
charge_gas(...) # TBD
...
# Inputs: the equivalent of a `BlockChain` and a `Block`
# -- `BlockChain` inputs --
pre_state = ... buffer_read(...) # corresponds to `BlockChain.state`, but assuming statelessness
chain_id = ... buffer_read(...) # corresponds to `BlockChain.chain_id`
# it is assumed that `BlockChain.blocks` will be dropped with statelessness
# we conveniently replace it with the parent `Block.Header` inputs
# -- `Block` inputs --
# ---- `Block.header` inputs ----
parent_hash = ... buffer_read(...) # corresponds to `Block.header.parent_hash`
# `ommers_hash` is a constant, no need to pass it as input
coinbase = ... buffer_read(...) # corresponds to `Block.header.coinbase`
post_state = ... buffer_read(...) # corresponds to `Block.header.state_root`
transactions_root = ... buffer_read(...) # corresponds to `Block.header.transactions_root`
receipts_root = ... buffer_read(...) # corresponds to `Block.header.receipts_root`
# it is assumed that `Block.header.bloom` will become a constant with EIP-7668
# `difficulty` is a constant, no need to pass it as input
number = ... buffer_read(...) # corresponds to `Block.header.number`
gas_limit = ... buffer_read(...) # corresponds to `Block.header.gas_limit`
gas_used = ... buffer_read(...) # corresponds to `Block.header.gas_used`
timestamp = ... buffer_read(...) # corresponds to `Block.header.timestamp`
extra_data = ... buffer_read(...) # corresponds to `Block.header.extra_data`
prev_randao = ... buffer_read(...) # corresponds to `Block.header.prev_randao`
# `nonce` is a constant, no need to pass it as input
base_fee_per_gas = ... buffer_read(...) # corresponds to `Block.header.base_fee_per_gas`
# `withdrawals_root` can be set to be empty
# `blob_gas_used` can be set to 0
# `excess_blob_gas` can be set to 0
parent_beacon_block_root = ... buffer_read(...) # corresponds to `Block.header.parent_beacon_block_root`
# `requests_hash` can be set to empty
# ---- `Block.body` inputs ----
transactions = ... buffer_read(...) # ref to blobs
# `Block.body.ommers` is a constant, no need to pass it as input
# `Block.body.withdrawals` can be set to empty
# -- parent `Block.Header` ---
# chain_id is assumed to be the same as the current block
parent_parent_hash = ... buffer_read(...) # corresponds to `Block.header.parent_hash`
parent_coinbase = ... buffer_read(...) # corresponds to `Block.header.coinbase`
# parent_state_root is `pre_state`
parent_transactions_root= ... buffer_read(...) # corresponds to `Block.header.transactions_root`
parent_receipts_root = ... buffer_read(...) # corresponds to `Block.header.receipts_root`
parent_number = ... buffer_read(...) # corresponds to `Block.header.number`
parent_gas_limit = ... buffer_read(...) # corresponds to `Block.header.gas_limit`
parent_gas_used = ... buffer_read(...) # corresponds to `Block.header.gas_used`
parent_timestamp = ... buffer_read(...) # corresponds to `Block.header.timestamp`
parent_extra_data = ... buffer_read(...) # corresponds to `Block.header.extra_data`
parent_prev_randao = ... buffer_read(...) # corresponds to `Block.header.prev_randao`
parent_base_fee_per_gas = ... buffer_read(...) # corresponds to `Block.header.base_fee_per_gas`
parent_parent_beacon_block_root = ... buffer_read(...) # corresponds to `Block.header.parent_beacon_block_root`
# -- Extras --
l1_anchor = ... buffer_read(...) # TBD: arbitrary info that is passed from L1 to L2 storage
# Disable blob-carrying transactions
for tx in map(decode_transaction, transactions):
if isinstance(tx, BlobTransaction):
raise ExecuteError
parent_header = blocks.Header(
parent_hash =parent_parent_hash,
ommers_hash =EMPTY_OMMER_HASH,
coinbase =parent_coinbase,
state_root =pre_state,
transactions_root =parent_transactions_root,
receipts_root =parent_receipts_root,
bloom =(),
difficulty =0,
number =parent_number,
gas_limit =parent_gas_limit,
gas_used =parent_gas_used,
timestamp =parent_timestamp,
extra_data =parent_extra_data,
prev_randao =parent_prev_randao,
nonce =b"\x00\x00\x00\x00\x00\x00\x00\x00",
base_fee_per_gas =parent_base_fee_per_gas,
withdrawals_root =EMPTY_TRIE_ROOT,
blob_gas_used =0,
excess_blob_gas =0,
parent_beacon_block_root=parent_parent_beacon_block_root,
requests_hash =EMPTY_REQUESTS_HASH
)
chain = fork.BlockChain(
state =pre_state,
chain_id =chain_id,
parent_header=parent_header,
)
header = blocks.Header(
parent_hash =parent_hash,
ommers_hash =EMPTY_OMMER_HASH,
coinbase =coinbase,
state_root =post_state,
transactions_root =transactions_root,
receipts_root =receipts_root,
bloom =(),
difficulty =0,
number =number,
gas_limit =gas_limit,
gas_used =gas_used,
timestamp =timestamp,
extra_data =extra_data,
prev_randao =prev_randao,
nonce =b"\x00\x00\x00\x00\x00\x00\x00\x00",
base_fee_per_gas =base_fee_per_gas,
withdrawals_root =EMPTY_TRIE_ROOT,
blob_gas_used =0,
excess_blob_gas =0,
parent_beacon_block_root=parent_beacon_block_root,
requests_hash =EMPTY_REQUESTS_HASH
)
block = blocks.Block(
header =header,
transactions=transactions,
ommers =(),
withdrawals =()
)
# NOTE: this is needed to push the system transaction
block_env = vm.BlockEnvironment(
chain_id =chain.chain_id,
state =chain.state,
block_gas_limit =block.header.gas_limit,
block_hashes =EMPTY_BLOCK_HASHES
coinbase =block.header.coinbase,
number =block.header.number,
base_fee_per_gas =block.header.base_fee_per_gas,
time =block.header.timestamp,
prev_randao =block.header.prev_randao,
excess_blob_gas =block.header.excess_blob_gas,
parent_beacon_block_root=block.header.parent_beacon_block_root,
)
# Handle L1 anchoring. The system tx is `unchecked` because projects might decide to not use it at all
process_unchecked_system_transaction(
block_env =block_env,
target_address=L1_ANCHOR_ADDRESS, # TBD: exact predeploy address + implementation. Also: does it even need to be a fixed address?
data =l1_anchor # TBD: exact format
)
state_transition(blockchain, block)
evm.output = ... # TBD: maybe block_gas_used?
(WIP) Usage example
The following example shows how an ahead-of-time sequenced rollup can use the EXECUTE precompile to settle blocks.
contract Rollup {
struct L2Block {
bytes32 blobHash;
bytes32 prevRandao;
bytes32 anchor;
}
uint64 public constant chainId = 1234321;
uint public gasLimit;
// latest settled state
bytes32 public state;
// receipts of latest settled block
bytes32 public receipts;
// block number to be sequenced next
uint public nextBlockNumberToSequence;
// block number to be settled next
uint public nextBlockNumberToSettle;
// ahead-of-time sequenced blocks
mapping(uint => L2Block) public blocks;
// assumes that one blob is one block
// NOTE: if preconfs need to be supported, then it should not use current block info
function sequence(uint _blobIndex) public {
blocks[nextBlockNumberToSequence] = L2Block({
blobHash: blobhash(index),
prevRandao: block.prevrandao,
anchor: blockhash(block.number - 1)
});
nextBlockNumberToSequence++;
}
function settle(
bytes32 _newState,
bytes32 _receipts,
) public {
(bytes32 blobHash, bytes32 prev_randao, bytes32 anchor) = blocks[nextBlockNumberToSettle];
EXECUTE(
chainId,
nextBlockNumberToSettle,
state,
_newState,
_receipts,
gasLimit,
msg.sender,
prev_randao,
blobhash, // TBD: this should be a ref to past blobs. Currently a placeholder, assumes blobs are uniquely identified by their blobhash, which is not true today.
anchor // to be used for anchoring L1 -> L2 msgs on L2
)
state = _newState;
receipts = _receipts;
nextBlockNumberToSettle++;
}
}
Tech dependencies
Table of Contents
Statelessness (EIP-7864)
L1 validators shouldn't store the state of all rollups, therefore the EXECUTE precompile requires its verification to be stateless. The statelessness upgrade is therefore required, with all its associated EIPs.
Some adjacent EIPs that are relevant in this context are:
- EIP-2935: Serve historical block hashes from state (live with Pectra).
- EIP-7709: Read BLOCKHASH from storage and update cost (SFI in Fusaka).
L1 ZK-EVM
The ZK version of the EXECUTE precompile requires the L1 ZK-EVM upgrade to take place first and it will influence how exactly the precompile will be implemented:
- Offchain vs onchain proofs: influences whether the precompile needs to take a ZK proof (or multiple proofs) as input.
- Gas limit handling: influences whether the precompile needs to take a gas limit as an input or not. Some L1 ZK-EVM proposals suggest the complete removal of the gas limit, as long as the block proposer itself is also required to provide the ZK proof (see Prover Killers Killer: You Build it, You Prove it).
FOCIL (EIP-7805)
While not strictly required, the addition of FOCIL would help simplifying the design of forced transaction mechanisms, as described in the FOCIL section of the Forced transactions page.
RISC-V (or equivalent)
⚠️ This is only to be considered for future versions of native rollups. General compatibility should still be kept in mind.
Non-EVM-based native rollups can be supported if L1 migrates it's low-level architecture to RISC-V or equivalent. At that point, L1 execution can provide two services to native rollups:
- A RISC-V or equivalent ISA that can be accessed directly. L1 will provide multi-proofs, audits, formal verification, and a socially "bug-free" implementation.
- An EVM host program that sits on top, which can be again considered socially bug-free and it's automatically upgraded through L1 governance process. Under the hood, the RISC-V or equivalent infrastructure is used.
One idea is to then split the EXECUTE into two versions: a EVMEXECUTE and a RISCVEXECUTE precompile, where non-EVM rollups would choose to call the second one with a custom host program. Note that this is highly speculative and heavily depends on the specific implementation of the RISC-V proposal. Open questions remain around how to guarantee availability of host programs to be able to detect bugs in the ZK verification process.
L1 Anchoring
Table of Contents
Overview
To allow messaging from L1 to L2, a rollup needs to be able to obtain some information from the L1 chain, with the most general information being an L1 block hash. The process of placing a "cross-chain validity reference" is tipically called "anchoring". In practice, projects relay from L1 various types of information depending on their specific needs.
Current approaches
We first discuss how some existing rollups handle the L1 anchoring problem to better inform the design of the EXECUTE precompile.
OP stack
[spec]
A special L1Block contract is predeployed on L2 which processes "L1 attributes deposited transactions" during derivation. The contract stores L1 information such as the latest L1 block number, hash, timestamp, and base fee. A deposited transaction is a custom transaction type that is derived from the L1, does not include a signature and does not consume L2 gas.
It's important to note that reception of L1 to L2 messages on the L2 side does not depend on this contract, but rather on "user-deposited transactions" that are derived from events emitted on L1, which again are implemented through the custom transaction type.
Linea
Linea, in the L2MessageService contract on L2, adds a function that allows a permissioned relayer to send information from L1 to L2:
function anchorL1L2MessageHashes(
bytes32[] calldata _messageHashes,
uint256 _startingMessageNumber,
uint256 _finalMessageNumber,
bytes32 _finalRollingHash
) external whenTypeNotPaused(PauseType.GENERAL) onlyRole(L1_L2_MESSAGE_SETTER_ROLE)
The permissioned relayer is supposed to only relay rolling hashes that are associated with L1 blocks that are finalized. On L1, a wrapper around the STF checks that the "rolling hash" being relayed is correct, otherwise proof verification fails. Since anchoring is done through regular transactions, the function is permissioned, otherwise any user could send a transaction with an invalid rolling hash, which would be accepted by the L2 but rejected during settlement. In other words, blocks containing invalid anchor transactions are not considered no-ops.
Taiko
[docs] An anchorV3 function is implemented in the TaikoAnchor contract which allows a GOLDEN_TOUCH_ADDRESS to relay an L1 state root to L2. The private key of the GOLDEN_TOUCH_ADDRESS is publicly known, but the node guarantees that the first transaction is always an anchor transaction, and that other transactions present in the block revert.
function anchorV3(
uint64 _anchorBlockId,
bytes32 _anchorStateRoot,
uint32 _parentGasUsed,
LibSharedData.BaseFeeConfig calldata _baseFeeConfig,
bytes32[] calldata _signalSlots
)
external
nonZeroBytes32(_anchorStateRoot)
nonZeroValue(_anchorBlockId)
nonZeroValue(_baseFeeConfig.gasIssuancePerSecond)
nonZeroValue(_baseFeeConfig.adjustmentQuotient)
onlyGoldenTouch
nonReentrant
Since proposing blocks in Taiko is untrusted, some additional checks are performed on the validity of anchor blocks, which are passed on L1. In particular, it is checked that the anchor block number is not more than 96 blocks in the past, that it is less than current block number, and that it is greater than the latest anchor block.
The validity of the _anchorStateRoot value is explicitly checked by Taiko's proof system. L2 blocks containing an invalid anchor block are skipped.
Orbit stack
Orbit stack chains relay information from L1 to L2 per message, similarly to the OP stack. New transaction types without signatures are introduced which are derived and authenticated by L1. In particular, the following types are added:
ArbitrumDepositTxType = 0x64
ArbitrumUnsignedTxType = 0x65
ArbitrumContractTxType = 0x66
ArbitrumRetryTxType = 0x68
ArbitrumSubmitRetryableTxType = 0x69
ArbitrumInternalTxType = 0x6A
ArbitrumLegacyTxType = 0x78
ArbOS handles the translation from message types to transaction types. For example, a L1MessageType_L2FundedByL1 message generates two transactions, one with type ArbitrumDepositTxType for funding and a ArbitrumUnsignedTxType for the actual message.
As opposed to other chains, retryable messages are implemented as a new transaction type instead of being implemented within smart contract logic.
Proposed design
An L1_ANCHOR system contract is predeployed on L2 that receives an arbitrary bytes32 value from L1 to be saved in its storage. The contract is intended to be used for L1->L2 messaging without being tied to any specific format, as long it is encoded as a bytes32 value. Validation of this value is left to the rollup contract on L1. The exact implementation of the contract is TBD, but EIP-2935 can be used as a reference. A messaging system can be implemented on top of this by passing roots and providing proofs of inclusions on the L2. Such mechanisms are better discussed in L1 to L2 messaging.
Other approaches
One approach consists in re-using the parent_beacon_block_root field to pass an arbitrary bytes32 value, which is saved in the BEACON_ROOTS_ADDRESS predeploy on L2 as defined in EIP-4788. This would allow not to have an additional system transaction in the EXECUTE precompile and an additional predeploy, at the cost of changing the semantics of parent_beacon_block_root if data that is not a beacon block root is passed. Some projects might want to both pass the beacon block root and a custom L1 anchor value.
Another proposed design suggests passing arbitrary bytes as in-memory context instead of a bytes32 that gets saved in storage. This requires an additional precompile on L2 to be able to read such context, which would not be usable on L1.
L1 to L2 messaging
Table of Contents
Current approaches
L1 to L2 messaging systems are built on top of the L1 anchoring mechanism. We first discuss how some existing rollups handle L1 to L2 messaging to better understand how similar mechanisms can be implemented on top of the L1 anchoring mechanism proposed here for native rollups.
OP stack
There are two ways to send messages from L1 to L2, either by using the low-level API of deposited transactions, or by using the high-level API of the "Cross Domain Messenger" contracts, which are built on top of the low-level API.
Deposited transactions are derived from TransactionDeposited events emitted in the OptimismPortal contract on L1. Deposited transactions are a new transaction type with prefix 0x7E that have been added in the OP stack STF, which are fully derived on L1, they cannot be sent to L2 directly, and do not contain signatures as the authentication is already performed on L1. The deposited transaction on the L2 specifies the tx.origin and the msg.sender as the msg.sender of the transaction on L1 that emitted the TransactionDeposited event if EOA, if not, the aliased msg.sender is used to prevent conflicts with L2 contracts that might have the same address. Moreover the function mints L2 gas tokens based on the value that is sent on L1.
The Cross Domain Messengers are contracts built on top of this mechanism. The sendMessage function on L1 calls OptimismPortal.depositTransaction, and will therefore be the (aliased) msg.sender on the L2 side. The actual caller of the sendMessage function is passed as opaque bytes to be later unpacked. On L2, the corresponding Cross Domain Messenger contract receives a call to the relayMessage function, which checks that the msg.sender is the aliased L1 Cross Domain Messenger. A special xDomainMsgSender storage variable saves the actual L1 cross domain caller, and finally executes the call. The application on the other side will then be able to access the xDomainMsgSender variable to know who sent the message, and the msg.sender will be the Cross Domain Messenger contract on L2. If the sender on L1 was a contract, the address is not and doesn't need to be aliased as checking the xDomainMsgSender already scopes callers to just L1 callers and no conflict with L2 contracts can happen.
It's important to note that such messaging mechanism is completely disconnected from the onchain L1 anchoring mechanism that saves the L1 block information in the L2 L1Block contract, as it is fully handled by the derivation logic.
Linea
The sendMessage function is called on the LineaRollup contract on L1, also identified as the "message service" contract by others. A numbered "rolling hash" is saved in a mapping with the content of the message to be sent on L2. During Linea's anchoring process, such rolling hash is relayed on the L2 together with all the message hashes that make up the rolling hashes that are then saved in the inboxL1L2MessageStatus mapping. The message is finally executed by calling the claimMessage function on the L2MessageService, which references the message status mapping. The destination contract can call the sender() function on the L2MessageService to check who was the original sender of the message on L1. The value is set only for the duration of the call and is reset to default values after the call returns. If the sender on L1 was a contract, the address is not and doesn't need to be aliased as checking the sender() already scopes callers to just L1 callers and no conflict with L2 contracts can happen.
Taiko
To send a message from L1 to L2, the sendSignal function is called on the SignalService contract on L1, which stores message hashes in its storage at slots computed based on the message itself. On the L2 side, after anchoring of the L1 block state root, the proveSignalReceived function is called on the SignalService L2 contract, with complex merkle proofs that unpack the so-passed state root and gets to the message hashes saved in storage of the L1 SignalService contract.
A higher-level Bridge contract is deployed on L1 that performs the actuall contract call through the processMessage function given the informations received by the SignalService L2 contract. The destination contract can call the context() function on the Bridge to check what was the origin chain and the origin sender of the message. The context() is set only for the duration of the call and it is reset to default values after the call returns. If the sender on L1 was a contract, the address is not and doesn't need to be aliased as checking the context() already scopes callers to just L1 callers and no conflict with L2 contracts can happen.
Orbit stack
Messages are sent from L1 to L2 by enqueuing "delayed messages" on the Bridge contract using authorized Inbox contracts. Those messages can have different "kinds" based on their purposes:
uint8 constant L2_MSG = 3;
uint8 constant L1MessageType_L2FundedByL1 = 7;
uint8 constant L1MessageType_submitRetryableTx = 9;
uint8 constant L1MessageType_ethDeposit = 12;
uint8 constant L1MessageType_batchPostingReport = 13;
uint8 constant L2MessageType_unsignedEOATx = 0;
uint8 constant L2MessageType_unsignedContractTx = 1;
Those message types will then internally correspond to different transaction types, as already listed in Orbit's L1 Anchoring section. For those messages to be included on the L2, the permissioned sequencer needs to either explicitly include them in an L2 block, or if they are not processed within some time they can be forced included by the user. On the L2, transactions magically appear and have no signature, without the need to explicitly claim them, and have the proper msg.sender from L1, which is aliased if the sender on L1 is a contract.
Proposed design
Designs can be classified into two categories, those that support L1 to L2 messages with the proper msg.sender on the L2, and those that don't. Using the proper L1 msg.sender (aliased if the sender is a contract) for the L2 transaction has the advantage that many contracts don't need to be modified to explicitly support L1 to L2 messages, as access control works in the usual way by checking the msg.sender. The downside is that this requires the addition of a new transaction type without signature, that needs to be scoped for native rollups usage only and prohibited on L1.
Following the design principles, and the fact that existing projects can already handle L1 to L2 messaging without an additional transaction type, it is preferred not to add a new transaction type. The downside is that now contracts need to be explicitly modified to support the L1 to L2 message interface for crosschain message authentication. Many projects already do this, and effort can be made to standardize the interface across projects.
Messages need to be claimed against the hashed relayed during the anchoring process using inclusion proofs, and contextual information can be saved in the contract state for the duration of the call, as already done in the projects discussed above, or alternatively passed directly to the destination contract.
L2 to L1 messaging
Table of Contents
Current approaches
While L2 -> L1 messaging can be built on top of the state root that the EXECUTE precompile already exposes, some projects expose a shallower interface to make it easier to provide inclusion proofs. We first discuss how existing projects implement L2 -> L1 messaging, to better understand how similar mechanisms can be implemented in native rollups.
OP stack
[spec] The piece of data that is used on the L1 side of the L2->L1 messaging bridge is a "block output root, which is defined as:
struct BlockOutput {
bytes32 version;
bytes32 stateRoot;
bytes32 messagePasserStorageRoot;
bytes32 blockHash;
}
Inclusion proofs are verified against the messagePasserStorageRoot instead of the stateRoot, which represents the storage root of the L2ToL1MessagePasser contract on L2. On the L2 side, the L2ToL1MessagePasser contract takes a message, hashes it, and stores it in a mapping.
Linea
[docs] Linea uses a custom merkle tree of messages which is then provided as an input during settlement and verified as part of the validity proof. On the L2 side, an MessageSent event from the L2->L1 message.
Taiko
[docs] Taiko uses the same mechanism as L1->L2 messaging with a SignalService. The protocol is general enough to support both providing proofs againt a contract storage root or against a state root, by also providing an account proof.
Orbit stack
WIP.
Proposed design
At this point it's not clear whether it is possible to easily expose a custom data structure from L2 to L1. The EXECUTE precompile naturally exposes the state root, and the block_output can also expose the receipts_trie in some form, for example by exposing its root.
In principle, EIP-7685: General purpose execution layer requests could be used, but this requires overloading its semantic from EL->CL to L2->L1 requests, and adding a new type of request that also "pollutes" the L1 execution environment.
On the other hand, it is expected that statelessness will help in reducing the cost of providing inclusion proofs directly against a state root, which might remove the need to provide a shallower interface.
Gas token deposits
Table of Contents
Overview
Rollup users need a way to obtain the gas token to be able to send transactions on the L2. Existing solutions divide into two approaches: either an escrow contract contains preminted tokens that are unlocked through the L2 to L1 messaging channel, or a new transaction type that is able to mint the gas token is added to the STF. This page will also discuss two more approaches that are currently not used in any project.
Current approaches
OP stack
The custom DepositTransaction type allows to mint the gas token based on TransactionDeposited event fields. On L2, the gas token magically appears in the user's balance.
Linea
Linea uses preminted tokens in the L2MessageService contract, which are then unlocked when L1 to L2 messages are processed on the L2. No new transaction type that can mint gas token is added to the STF.
Taiko
Taiko uses preminted tokens in the L2 Bridge contract, which are then unlocked when L1 to L2 messages are processed on the L2. No new transaction type that can mint gas token is added to the STF.
Orbit stack
Orbit stack uses a custom transaction type that is able to mint the gas token based on the ArbitrumDepositTx type. On L2, the gas token magically appears in the user's balance.
Other approaches
Manual state manipulation
Before (and after) calling the EXECUTE precompile, projects are free to modify the L2 state root directly with custom execution, including dedicated proving systems. This can be used to touch balances, but it requires doing all updates either before or after block execution. This strategy cannot be used to support arbitrary intra-block gas-token deposits.
Beacon chain withdrawals
Another possible mechanism is to use the beacon chain withdrawal mechanisms which mints the gas token on L1. Withdrawals are processed at the end of a block, so they wouldn't be able to allow deposits to be processed intra-block. As of now, no existing project uses beacon chain withdrawals for gas token deposits, but the mechanism can be left open for use.
Proposed design
Following the design principles, it is preferred not to add a new transaction type that can mint gas tokens, as existing projects already handle gas token deposits through other means. The preferred approach is to use a predeployed contract that contains preminted tokens, which are then unlocked when L1 to L2 messages are processed on the L2. This design fully supports custom gas tokens as it is not opinionated on what type of message unlocks the gas token on L2, it being ETH, an ERC20, NFTs, or mining mechanisms.
The first deposit problem
WIP.
To be discussed:
- How can a user claim on L2 the first deposit if they don't have any gas token to pay for the transaction fees?
L2 fee market
Table of Contents
Fee collection
The EXECUTE precompile exposes the coinbase address as an input parameter so that projects can decide by themselves how to collect priority fees on the L2.
While L1 burns the base fee, most L2s in production today decide to redirect it to a dedicated address. This is not possible to be supported by native rollups out of the box, and requires additional changes to the L1 protocol.
One proposal consists in exposing in the block_output the cumulative fee that is burned in the block, both by the effective_gas_fee and the blob_gas_fee. We highlight in green the two additional lines that need to be added to the BlockOutput class and to the process_transaction function to support this feature.
+++ vm/__init__.py
class BlockOutput:
block_gas_used
transactions_trie
receipts_trie
receipt_keys
block_logs
withdrawals_trie
blob_gas_used
requests
+ burned_fees
+++ fork.py
def process_transaction(block_env: ethereum.osaka.vm.BlockEnvironment, block_output: ethereum.osaka.vm.BlockOutput, tx: Transaction, index: Uint) -> None:
"""
Execute a transaction against the provided environment.
This function processes the actions needed to execute a transaction.
It decrements the sender's account after calculating the gas fee and
refunds them the proper amount after execution. Calling contracts,
deploying code, and incrementing nonces are all examples of actions that
happen within this function or from a call made within this function.
Accounts that are marked for deletion are processed and destroyed after
execution.
Parameters
----------
block_env :
Environment for the Ethereum Virtual Machine.
block_output :
The block output for the current block.
tx :
Transaction to execute.
index:
Index of the transaction in the block.
"""
trie_set(
block_output.transactions_trie,
rlp.encode(index),
encode_transaction(tx),
)
intrinsic_gas, calldata_floor_gas_cost = validate_transaction(tx)
(
sender,
effective_gas_price,
blob_versioned_hashes,
tx_blob_gas_used,
) = check_transaction(
block_env=block_env,
block_output=block_output,
tx=tx,
)
sender_account = get_account(block_env.state, sender)
if isinstance(tx, BlobTransaction):
blob_gas_fee = calculate_data_fee(block_env.excess_blob_gas, tx)
else:
blob_gas_fee = Uint(0)
effective_gas_fee = tx.gas * effective_gas_price
gas = tx.gas - intrinsic_gas
increment_nonce(block_env.state, sender)
sender_balance_after_gas_fee = (
Uint(sender_account.balance) - effective_gas_fee - blob_gas_fee
)
set_account_balance(
block_env.state, sender, U256(sender_balance_after_gas_fee)
)
access_list_addresses = set()
access_list_storage_keys = set()
access_list_addresses.add(block_env.coinbase)
if isinstance(
tx,
(
AccessListTransaction,
FeeMarketTransaction,
BlobTransaction,
SetCodeTransaction,
),
):
for access in tx.access_list:
access_list_addresses.add(access.account)
for slot in access.slots:
access_list_storage_keys.add((access.account, slot))
authorizations: Tuple[Authorization, ...] = ()
if isinstance(tx, SetCodeTransaction):
authorizations = tx.authorizations
tx_env = vm.TransactionEnvironment(
origin=sender,
gas_price=effective_gas_price,
gas=gas,
access_list_addresses=access_list_addresses,
access_list_storage_keys=access_list_storage_keys,
transient_storage=TransientStorage(),
blob_versioned_hashes=blob_versioned_hashes,
authorizations=authorizations,
index_in_block=index,
tx_hash=get_transaction_hash(encode_transaction(tx)),
)
message = prepare_message(block_env, tx_env, tx)
tx_output = process_message_call(message)
# For EIP-7623 we first calculate the execution_gas_used, which includes
# the execution gas refund.
tx_gas_used_before_refund = tx.gas - tx_output.gas_left
tx_gas_refund = min(
tx_gas_used_before_refund // Uint(5), Uint(tx_output.refund_counter)
)
tx_gas_used_after_refund = tx_gas_used_before_refund - tx_gas_refund
# Transactions with less execution_gas_used than the floor pay at the
# floor cost.
tx_gas_used_after_refund = max(
tx_gas_used_after_refund, calldata_floor_gas_cost
)
tx_gas_left = tx.gas - tx_gas_used_after_refund
gas_refund_amount = tx_gas_left * effective_gas_price
# For non-1559 transactions effective_gas_price == tx.gas_price
priority_fee_per_gas = effective_gas_price - block_env.base_fee_per_gas
transaction_fee = tx_gas_used_after_refund * priority_fee_per_gas
# refund gas
sender_balance_after_refund = get_account(
block_env.state, sender
).balance + U256(gas_refund_amount)
set_account_balance(block_env.state, sender, sender_balance_after_refund)
# transfer miner fees
coinbase_balance_after_mining_fee = get_account(
block_env.state, block_env.coinbase
).balance + U256(transaction_fee)
if coinbase_balance_after_mining_fee != 0:
set_account_balance(
block_env.state,
block_env.coinbase,
coinbase_balance_after_mining_fee,
)
elif account_exists_and_is_empty(block_env.state, block_env.coinbase):
destroy_account(block_env.state, block_env.coinbase)
for address in tx_output.accounts_to_delete:
destroy_account(block_env.state, address)
block_output.block_gas_used += tx_gas_used_after_refund
block_output.blob_gas_used += tx_blob_gas_used
+ block_output.burned_fees +=
+ effective_gas_fee - gas_refund_amount - transaction_fee + blob_gas_fee
receipt = make_receipt(
tx, tx_output.error, block_output.block_gas_used, tx_output.logs
)
receipt_key = rlp.encode(Uint(index))
block_output.receipt_keys += (receipt_key,)
trie_set(
block_output.receipts_trie,
receipt_key,
receipt,
)
block_output.block_logs += tx_output.logs
This value can be exposed as an output of the EXECUTE precompile for projects to decide how to handle it. For example, for those projects whose gas token is bridged through L1, the L1 bridge can decide to credit the burned fees to a dedicated address.
Pricing
WIP.
To be discussed:
- handling of DA costs in the L2 transactions fee market.
Forced transactions
Table of Contents
Overview
Rollups with centralized sequencers must implement a forced transaction mechanism if they wish to preserve L1 censorship resistance properties. Users need to be able to permissionlessly send transactions to L1 and have the guarantee that they will be eventually included on L2 if they are accepted on L1.
Fundamentally, proposed forced transactions do not need to include an L2 transaction signature because they can be authenticated using the L1 transaction signature, assuming that they are supposed to be the same address on L1 and L2. In existing implementations, forced transactions are usually pushed through calldata on L1, given that using a blob would leave most of the space unused and might therefore be cost-inefficient. Forced transaction mechanisms should be designed not to interfere with centralized preconfirmations where possible.
Brainstorming
⚠️ The following are just examples to demonstrate that forced transaction mechanisms are compatible with native rollups and that their implementations isn't unrealistic. Projects are free to design their own mechanisms and the precompile aims to be flexible enough to accommodate them.
The EXECUTE precompile can only support transactions with signatures, so forced transactions must include a signature too. On L1, one exception is made for withdrawals from the beacon chain, which are not authenticated on the execution layer. The limitation of withdrawals is that they only cover ETH minting and they cannot be used as a replacement for general message passing.
One approach consists in having a mechanism to detect whether sequenced blocks contain individual forced transactions from a queue on L1 that are older than a certain time threshold, and if not, revert the block submission. It's unclear whether proving inclusion of arbitrary bytes in blobs is feasible to be done on L1 or if it requires a dedicated ZK verifier. This design alone doesn't solve for a sequencer that is not only censoring but is completely offline, and therefore an additional fallback mechanism that removes the sequencer whitelist might be needed.
Another solution is to allow the EXECUTE precompile not only to reference blobs, but also storage or calldata. In this way users can save their forced txs in storage and the contract around the EXECUTE calls can force the transactions input to be read from that storage if forced txs older than a certain time threshold are present.
FOCIL (EIP-7805)
FOCIL introduces a new inclusion_list_transactions parameter to the state_transition function and the apply_body function, that conditions the validity of the block with a validate_inclusion_list_transactions function. In particular, it is checked that block transactions include all valid transactions from the IL that can fit in the block. The execution spec diff on top of osaka can be found here.
Native rollups can re-use such logic where the IL comes from a smart contract as opposed to the CL. Custom logic can be applied that act as an additional filter, or that add delays to preserve the validity of already issued preconfirmations. The IL would therefore become another input to the EXECUTE precompile. In this case, FOCIL inclusion on L1 becomes an obvious tech dependency.
It is still an open question how to properly manage the equivalent of a mempool within a smart contract, potential DoS attacks and re-submissions. Some of these problems are not unique to this "L2 FOCIL" design and might be present in existing forced transaction mechanisms too.
L1 vs L2 diff
Table of Contents
Blob-carrying transactions
Since rollups are not (supposed to be) connected to a dedicated consensus layer that handles blobs, they cannot support blob-carrying transactions and related functionality. This is solved by the EXECUTE by filtering all type-3 transactions before calling the state transition function.
As a consequence, all blocks will simply not contain any blob-carrying transactions, which allows maintaing BLOBHASH and point evaluation operations untouched, since they would behave the same as in an L1 block with no blob-carrying transactions.
Since the EXECUTE precompile does a recursive call to apply_body and not state_transition, header checks are skipped, and block_env values can either be passed as an input, or re-use the values from L1. Since no blob-carrying transactions are present, the excess_blob_gas would default to zero, unless another value is passed from L1. It's important to note that L1 exposes block.blobbasefee and not excess_blob_gas, so some translation would be needed to have the proper input for block_env, or some other changes on L1 needs to be made.
RANDAO
The block.prevrandao behaviour across existing rollups varies. Orbit stack chains return the constant 1. OP stack chains return the value from the latest synced L1 block on L2. Linea returns the constant 2. Scroll returns the constant 0. ZKsync returns the constant 2500000000000000.
The current proposal is to leave the field as an input to the EXECUTE precompile so that projects can decide by themselves how to handle it.
Beacon roots storage
Not all projects support EIP-4788: Beacon block root in the EVM as rollups are not directly connected to the beacon chain. The EXECUTE precompile leaves the parent_beacon_block_root as an input so that projects can decide by themselves how to handle it.
- Chains with support: OP stack.
- Chains without support: Orbit stack, Taiko, Linea, Scroll, ZKsync Era.
Open problems
Table of Contents
apply_body mutability
The apply_body interface is not immutable, and has changed in the past with the addition of withdrawals and will change in the future with the addition of inclusion_list_transactionsin FOCIL. Usage of state_transition instead of apply_body might appear to be more stable at first, as it just takes a Blockchain and a Block, but FOCIL adds inclusion_list_transactions there too.
Every time the apply_body interface changes, the EXECUTE precompile needs to be updated to potentially add "default values" that leave untouch the EXECUTE interface. As a consequence, native rollups would not be able to automatically benefit from new features that are added outside the apply_body function but that affect it too. It's an open question if is always possible to add default values for new parameters.
Past blobs references
WIP.
Customization
Table of Contents
WIP.
To be discussed:
- custom gas tokens.
- custom sequencing.
- custom VMs.
NR vs sharding
Table of Contents
WIP.
To be discussed:
- how native rollups compare with other sharding designs, e.g. Near, Anoma.
Stacks review
Table of Contents
WIP
Orbit stack
Table of Contents
Sequencing
The main function used to sequence blobs in the orbit stack is the addSequencerFromBlobsImpl function, whose interface is as follows:
function addSequencerL2BatchFromBlobsImpl(
uint256 sequenceNumber,
uint256 afterDelayedMessagesRead,
uint256 prevMessageCount,
uint256 newMessageCount
) internal {
Example of calls:
-
Block:
22866981(link)sequenceNumber:934316afterDelayedMessagesRead:2032069prevMessageCount:332968910newMessageCount:332969371(+461)
-
Block:
22866990(+9) (link)sequenceNumber:934317(+1)afterDelayedMessagesRead:2032073(+4)prevMessageCount:332969371(+0)newMessageCount:332969899(+528)
-
Block:
22867001(+11) (link)sequenceNumber:934318(+1)afterDelayedMessagesRead:2032073(+0)prevMessageCount:332969899(+0)newMessageCount:332970398(+499)
It's important to note that when a batch is submitted, also a "batch spending report" is submitted with the purpose of reimbursing the batch poster on the L2. The function will be analyzed later on.
The formBlobDataHash function is called to prepare the data that is then saved in storage. Its interface is as follows:
function formBlobDataHash(
uint256 afterDelayedMessagesRead
) internal view virtual returns (bytes32, IBridge.TimeBounds memory, uint256)
First, the function fetches the blob hashes of the current transaction using a Reader4844 yul contract. Then it creates a "packed header" using the packHeader function, which is defined as follows:
function packHeader(
uint256 afterDelayedMessagesRead
) internal view returns (bytes memory, IBridge.TimeBounds memory) {
The function takes the rollup's bridge "time bounds" and computes the appropriate bounds given the maxTimeVariation values, the current timestamp and block number. Such values are then returned together with the afterDelayedMessagesRead value.
A time bounds struct is defined as follows:
struct TimeBounds {
uint64 minTimestamp;
uint64 maxTimestamp;
uint64 minBlockNumber;
uint64 maxBlockNumber;
}
and the maxTimeVariation is a set of four values representing how much in the past or in the future the time or blocks can be from the current time and block number. This is done to prevent reorgs from invalidating sequencer preconfirmations, while also establishing some bounds.
For Arbitrum One, these values are set to:
delayBlocks:7200blocks (24 hours at 12s block time)futureBlocks:64blocks (12.8 minutes at 12s block time)delaySeconds:86400seconds (24 hours)futureSeconds:768seconds (12.8 minutes)
The formBlobDataHash function then computes the blobs cost by taking the current blob base fee, the (fixed) amount of gas used per blob and the number of blobs. Right after, the following value is returned:
return (
keccak256(bytes.concat(header, DATA_BLOB_HEADER_FLAG, abi.encodePacked(dataHashes))),
timeBounds,
block.basefee > 0 ? blobCost / block.basefee : 0
);
Now that the dataHash is computed, the addSequencerL2BatchImpl function is called, which is defined as follows:
function addSequencerL2BatchImpl(
bytes32 dataHash,
uint256 afterDelayedMessagesRead,
uint256 calldataLengthPosted,
uint256 prevMessageCount,
uint256 newMessageCount
)
internal
returns (uint256 seqMessageIndex, bytes32 beforeAcc, bytes32 delayedAcc, bytes32 acc)
The function, after some checks, calls the enqueueSequencerMessage on the Bridge contract, passing the dataHash, afterDelayedMessagesRead, prevMessageCount and newMessageCount values.
The enqueueSequencerMessage function is defined as follows:
function enqueueSequencerMessage(
bytes32 dataHash,
uint256 afterDelayedMessagesRead,
uint256 prevMessageCount,
uint256 newMessageCount
)
external
onlySequencerInbox
returns (uint256 seqMessageIndex, bytes32 beforeAcc, bytes32 delayedAcc, bytes32 acc)
The function, after some checks, fetches the previous "accumulated" hash and merges it with the new dataHash and the "delayed inbox" accumulated hash given the current afterDelayedMessagesRead. This new hash is then pushed in the sequencerInboxAccs array, which represents the canonical list of inputs to the rollup state transition function.
Where are these inputs used?
- When creating a new assertion, to ensure that the caller is creating an assertion on the expected inputs;
- When "fast confirming" assertions (in the context of AnyTrust);
- When validating the inputs in the last step of a fraud proof, specifically inside the
OneStepProverHostIocontract.
Batch spending report
TODO
Proving
State roots are proved using an optimistic proof system involving an interactive bisection protocol and a final onchain one-step execution. In particular, a bisection can conclude with a call to the confirmEdgeByOneStepProof function, which ultimately references the inputs that have been posted onchain.
The bisection protocol is divided into 3 "levels", depending on the size of the step: block level, big step level, and small step level. The interaction between these levels is non-trivial and also effects its economic guarantees.
A dedicated smart contract, the OneStepProofEntry, manages a set of sub-contracts depending on the type of step that needs to be executed onchain, and finally returns the post-execution state hash to the caller.
The proveOneStep function in OneStepProofEntry is defined as follows:
function proveOneStep(
ExecutionContext calldata execCtx,
uint256 machineStep,
bytes32 beforeHash,
bytes calldata proof
) external view override returns (bytes32 afterHash)
The ExecutionContext struct is defined as follows:
struct ExecutionContext {
uint256 maxInboxMessagesRead;
IBridge bridge;
bytes32 initialWasmModuleRoot;
}
where the maxInboxMessagesRead is set to the nextInboxPosition of the previous assertion, which can be seen as the "inbox" target set by the previous assertion to the new assertion. This value should at least be one more than the inbox position covered by the previous assertion, and is set to the current sequencer message count for the next assertion. If an assertion reaches the maximum number of blocks allowed but doesn't reach the nextInboxPosition, it is considered an "overflow" assertion which has its own specific checks.
The OneStepProofEntry contract populates the machine value and frame stacks and registries given the proof. A machine hash is computed using these values and the wasmModuleRoot, which determines the program to execute. Instructions and necessary merkle proofs are deserialized from the proof. Based on the opcode to be executed onchain, a sub-contract is selected to actually execute the step. The ones that require referencing the inbox inputs are the ones that require calling the OneStepProverHostIo contract. An Instruction is simply defined as:
struct Instruction {
uint16 opcode;
uint256 argumentData;
}
If the instruction is READ_INBOX_MESSAGE, the executeReadInboxMessage function is called, which either references the sequencer inbox or the delayed inbox, depending whether the argument is INBOX_INDEX_SEQUENCER or INBOX_INDEX_DELAYED. The functions compute the appropriate accumulated hash given its inputs, fetched from the sequencerInboxAccs or delayedInboxAccs, and checks that it matches the expected one.
The executeReadPreImage function is instead used to execute a "read" out of either a keccak256 preimage or a blob hash preimage, using the 4844 point evaluation precompile. It is made sure that the correct point is used for the evaluation.
L1 to L2 messaging
Different types of messages can be sent from L1 to L2, and each of them is identified by a "kind" value, as follows:
uint8 constant L2_MSG = 3;
uint8 constant L1MessageType_L2FundedByL1 = 7;
uint8 constant L1MessageType_submitRetryableTx = 9;
uint8 constant L1MessageType_ethDeposit = 12;
uint8 constant L1MessageType_batchPostingReport = 13;
uint8 constant L2MessageType_unsignedEOATx = 0;
uint8 constant L2MessageType_unsignedContractTx = 1;
uint8 constant ROLLUP_PROTOCOL_EVENT_TYPE = 8;
uint8 constant INITIALIZATION_MSG_TYPE = 11;
In ArbOS, other message types can be found, whose purpose is TBR (To Be Researched):
const (
L1MessageType_L2Message = 3
L1MessageType_EndOfBlock = 6
L1MessageType_L2FundedByL1 = 7
L1MessageType_RollupEvent = 8
L1MessageType_SubmitRetryable = 9
L1MessageType_BatchForGasEstimation = 10 // probably won't use this in practice
L1MessageType_Initialize = 11
L1MessageType_EthDeposit = 12
L1MessageType_BatchPostingReport = 13
L1MessageType_Invalid = 0xFF
)
Gas token deposit (ETH)
To deposit ETH on the L2 to be used as a gas token, the depositEth function on the Inbox contract (also called "delayed inbox") is used, which is defined as follows:
function depositEth() public payable whenNotPaused onlyAllowed returns (uint256)
Here's an example transaction.
The onlyAllowed modifier checks an "allow list", if enabled. The control passes to the _deliverMessage function, which is defined as follows:
function _deliverMessage(
uint8 _kind,
address _sender,
bytes memory _messageData,
uint256 amount
) internal returns (uint256)
The message kind used here is L1MessageType_ethDeposit. Ultimately, the enqueueDelayedMessage function is called on the Bridge contract. The function ultimately pushes an accumulated hash to the delayedInboxAccs array.
TODO
Derivation
The derivation logic for Arbitrum and Orbit chains is defined in the nitro node.
The L1 node connection is done through the L1Reader in the getL1Reader function in arbnode/node.go. All necessary addresses are fetched from the /cmd/chaininfo/arbitrum_chain_info.json file. For example, here's the configuration for Arbitrum One:
{
"chain-name": "arb1",
"parent-chain-id": 1,
"parent-chain-is-arbitrum": false,
"sequencer-url": "https://arb1-sequencer.arbitrum.io/rpc",
"secondary-forwarding-target": "https://arb1-sequencer-fallback-1.arbitrum.io/rpc,https://arb1-sequencer-fallback-2.arbitrum.io/rpc,https://arb1-sequencer-fallback-3.arbitrum.io/rpc,https://arb1-sequencer-fallback-4.arbitrum.io/rpc,https://arb1-sequencer-fallback-5.arbitrum.io/rpc",
"feed-url": "wss://arb1-feed.arbitrum.io/feed",
"secondary-feed-url": "wss://arb1-delayed-feed.arbitrum.io/feed,wss://arb1-feed-fallback-1.arbitrum.io/feed,wss://arb1-feed-fallback-2.arbitrum.io/feed,wss://arb1-feed-fallback-3.arbitrum.io/feed,wss://arb1-feed-fallback-4.arbitrum.io/feed,wss://arb1-feed-fallback-5.arbitrum.io/feed",
"has-genesis-state": true,
"block-metadata-url": "https://arb1.arbitrum.io/rpc",
"track-block-metadata-from": 327000000,
"chain-config": {
"chainId": 42161,
"homesteadBlock": 0,
"daoForkBlock": null,
"daoForkSupport": true,
"eip150Block": 0,
"eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
"eip155Block": 0,
"eip158Block": 0,
"byzantiumBlock": 0,
"constantinopleBlock": 0,
"petersburgBlock": 0,
"istanbulBlock": 0,
"muirGlacierBlock": 0,
"berlinBlock": 0,
"londonBlock": 0,
"clique": {
"period": 0,
"epoch": 0
},
"arbitrum": {
"EnableArbOS": true,
"AllowDebugPrecompiles": false,
"DataAvailabilityCommittee": false,
"InitialArbOSVersion": 6,
"InitialChainOwner": "0xd345e41ae2cb00311956aa7109fc801ae8c81a52",
"GenesisBlockNum": 0
}
},
"rollup": {
"bridge": "0x8315177ab297ba92a06054ce80a67ed4dbd7ed3a",
"inbox": "0x4dbd4fc535ac27206064b68ffcf827b0a60bab3f",
"rollup": "0x5ef0d09d1e6204141b4d37530808ed19f60fba35",
"sequencer-inbox": "0x1c479675ad559dc151f6ec7ed3fbf8cee79582b6",
"validator-utils": "0x9e40625f52829cf04bc4839f186d621ee33b0e67",
"validator-wallet-creator": "0x960953f7c69cd2bc2322db9223a815c680ccc7ea",
"stake-token": "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",
"deployed-at": 15411056
}
}
Then an InboxReader is created using the NewInboxReader function in arbnode/inbox_reader.go, which, among other things, takes in input the L1 reader, the sequencer inbox address and the delayed inbox address.
Transaction data from the sequencer is fetched using the LookupBatchesInRange method on the SequencerInbox type, which returns a list of SequencerInboxBatch values.
Transaction data from the sequencer inbox is processed using the getSequencerData method on the SequencerInboxBatch type in arbnode/sequencer_inbox.go. The method is called in the Serialize method.
The SequencerInboxBatch type is defined as follows:
type SequencerInboxBatch struct {
BlockHash common.Hash
ParentChainBlockNumber uint64
SequenceNumber uint64
BeforeInboxAcc common.Hash
AfterInboxAcc common.Hash
AfterDelayedAcc common.Hash
AfterDelayedCount uint64
TimeBounds bridgegen.IBridgeTimeBounds
RawLog types.Log
DataLocation BatchDataLocation
BridgeAddress common.Address
Serialized []byte // nil if serialization isn't cached yet
}
--- TODO ---
If the segment type is BatchSegmentKindAdvanceTimestamp or BatchSegmentKindAdvanceL1BlockNumber, the timestamp or the referenced block number is increased accordingly. If the segment type is BatchSegmentKindL2Message or BatchSegmentKindL2MessageBrotli, a MessageWithMetadata is created:
msg = &arbostypes.MessageWithMetadata{
Message: &arbostypes.L1IncomingMessage{
Header: &arbostypes.L1IncomingMessageHeader{
Kind: arbostypes.L1MessageType_L2Message,
Poster: l1pricing.BatchPosterAddress,
BlockNumber: blockNumber,
Timestamp: timestamp,
RequestId: nil,
L1BaseFee: big.NewInt(0),
},
L2msg: segment,
},
DelayedMessagesRead: r.delayedMessagesRead,
}
Messages are then passed to the TransactionStreamer by calling the AddMesageAndEndBatch method.