Block Numbers and Time
As in Ethereum, Arbitrum clients submit transactions, and the system (usually) executes those transactions at some later time. In Arbitrum Rollup, clients submit transactions by posting messages to the Ethereum chain, either through the Sequencer or via the chain's delayed inbox.
Once in the chain's core inbox contract, transactions are processed in order. Generally, some time will elapse between the time when a message is put into the inbox (and timestamped) and the time when the contract processes the message and carries out the transaction requested by the message.
Block Numbers: Arbitrum vs. Ethereum
Arbitrum blocks are assigned their own L2 block numbers, distinct from Ethereum's block numbers.
A single Ethereum block could include multiple Arbitrum blocks within it; however, an Arbitrum block cannot span across multiple Ethereum blocks. Thus, any given Arbitrum transaction is associated with exactly one Ethereum block and one Arbitrum block.
Ethereum Block Numbers Within Arbitrum
Accessing block numbers within an Arbitrum smart contract (i.e.,
block.number in Solidity) will return a value close to (but not necessarily exactly) the L1 block number at which the Sequencer received the transaction.
// some Arbitrum contract:
block.number // => returns L1 block number ("ish")
As a general rule, any timing assumptions a contract makes about block numbers and timestamps should be considered generally reliable in the longer term (i.e., on the order of at least several hours) but unreliable in the shorter term (minutes). (It so happens these are generally the same assumptions one should operate under when using block numbers directly on Ethereum!)
Arbitrum Block Numbers
Arbitrum blocks have their own block numbers, starting at 0 at the Arbitrum genesis block and updating sequentially.
ArbOS and the Sequencer are responsible for delineating when one Arbitrum block ends and the next one begins. However, block creation depends entirely on chain usage, meaning that blocks are only produced when there are transactions to sequence. In active chains, one can expect to see Arbitrum blocks produced at a relatively steady rate. In more quiet chains, block production might be sporadic depending on the rate at which transactions are received.
A client that queries an Arbitrum node's RPC interface (for, ie., transaction receipts) will receive the transaction's Arbitrum block number as the standard block number field. The L1 block number will also be included in the added
const txnReceipt = await arbitrumProvider.getTransactionReceipt('0x...');
txnReceipt.blockNumber => Arbitrum block number
txnReceipt.l1BlockNumber => L1 block number ("ish")
The Arbitrum block number can also be retrieved within an Arbitrum contract via ArbSys precompile:
ArbSys(100).arbBlockNumber() // returns Arbitrum block number
|Wall Clock time||12:00 am||12:00:15 am||12:00:30 am||12:00:45 am||12:01 am||12:01:15 am|
|Arbitrum Block number (from RPCs)||370000||370005||370006||370008||370012||370015|
block.number: updated to sync with L1
block.number ~ every minute; thus over time, it will, like the L1
block.number, average to ~15 seconds per block.
Arbitrum Block number from RPCs: note that this can be updated multiple times per L1 block (this lets the sequencer give sub-L1-block-time transaction receipts.)
Case Study: Multicall
The Multicall contract offers a great case study for the differences between L1 and L2 block numbers.
The canonical implementation of Multicall returns the value of
block.number. If attempting to use out-of-the-box, some applications might face unintended behaviour.
You can find a deployed version of the adapted Multicall2 at 0x842eC2c7D803033Edf55E478F461FC547Bc54EB2.
By default the
aggregate functions return the L2 block number. This allows you to use this value to compare your state against the tip of the chain.
getL1BlockNumber function can be queried if applications need to surface the L1 block number.