Bootloader
Learn about Bootloader, the entry point of the system
The bootloader is the component responsible for implementing the general blockchain protocol. Roughly, this means:
Initializing the system.
Reading the block context from the oracle.
Reading and parsing the first transaction.
Validating the transaction.
Executing the transaction.
Saving the transaction result.
Repeat from 3 until there are no more transactions.
Finalizing the block.
Configuration
The bootloader can be configured with the following parameters:
ONLY_SIMULATE: skips the validation step when processing a transaction. Used for call simulation in the node.IS_PROVING_ENVIRONMENT: to skip some checks during sequencing.SPECIAL_ADDRESS_SPACE_BOUND: the range of addresses (starting from 0) where system contracts can be deployed.AA_ENABLED: whether native account abstraction is enabled.
In addition, the basic_bootloader crate has the following compilation flags:
code_in_kernel_space: to enable normal contract execution for addresses in the range[0, SPECIAL_ADDRESS_SPACE_BOUND].transfers_to_kernel_space: to enable token transfers to addresses in the range[0, SPECIAL_ADDRESS_SPACE_BOUND]. Note: the bootloader itself has a special formal address (0x8001) that is always allowed to receive token transfers. This is used to collect fees.charge_priority_fee: to enable charging for the EIP-1559 tip (priority fee) on top of the base fee.evm-compatibility: enables all the previous flags, needed for the EVM test suite.
Code Execution
For transaction execution, the bootloader has to execute some contract code. This contract code corresponds to one of the supported VMs, and is executed through the Execution Environment (EE) module.
A contract call is executed through an interplay between the bootloader and (potentially different) execution environments. Indeed, a contract executing in a given EE can call to contracts that run on a different EE or to a System Hook. This interplay is described under Runner Flow.
Block Header
At the end of the execution, the bootloader outputs the block header.
For the block header, the Ethereum format will be used. However, some fields will be set differently in the initial version for simplification.
The block header should fully determine the block, i.e., include all the necessary inputs to execute the block.
parent_hash
previous block hash
previous block hash
owners_hash
0x1dcc4de8dec75d7aab85b567 b6ccd41ad312451b948a7413f 0a142fd40d49347 (post merge)
0x1dcc4de8dec75d7aab 85b567b6ccd41ad312451b 948a7413f0a142fd40d49347
hash of empty RLP list
beneficiary
block proposer
Operator (fee) address
state_root
state commitment
0
transactions_root
transactions trie (Patricia Merkle tree) root
transactions rolling hash
receipts_root
receipts trie (Patricia Merkle tree) root
0
logs_bloom
2048-bit bloom filter over logs’ addresses and topics
0
difficulty
0 (post merge)
0
number
block number
block number
gas_limit
block gas limit
constant, not defined yet, 10–15 M most likely
gas_used
block gas used
block gas used
TBD — with or without pubdata
timestamp
block timestamp
block timestamp
extra_data
any extra data included by proposer
TBD, possibly gas_per_pubdata
mix_hash
beacon-chain-provided random, (post merge)
0
after consensus will be provided random
nonce
0 (post merge)
0
base_fee_per_gas
base_fee_per_gas
base_fee_per_gas
Last updated