✳flâneur — a map of the web's best reading

Upgrading Ethereum | 3.3.4 Beacon state

eth2book.info · 1,822 words · saved by 1 readers

All roads lead to the BeaconState. Maintaining this data structure is the sole purpose of all the apparatus in all the spec documents. This state is the focus of consensus among the beacon nodes; it is what everybody, eventually, must agree on. The beacon chain's state is monolithic: everything is bundled into a single state object (sometimes referred to as the "God object"). Some have argued for more granular approaches that might be more efficient, but at least the current approach is simple. Let's break this thing down. How do we know which chain we're on, and where we are on it? The information here ought to be sufficient. A continuous path back to the genesis block would also suffice. genesis_validators_root is calculated at Genesis time (when the chain starts) and is fixed for the life of the chain. This, combined with the fork identifier, should serve to uniquely identify the chain that we are on. genesis_time is used by the fork choice rule to work out what slot we're in, and (

Upgrading Ethereum | 3.3.4 Beacon state Part 3: Annotated Specification Containers Beacon state BeaconState class BeaconState ( Container ) : # Versioning genesis_time : uint64 genesis_validators_root : Root slot : Slot fork : Fork # History latest_block_header : BeaconBlockHeader block_roots : Vector [ Root , SLOTS_PER_HISTORICAL_ROOT ] state_roots : Vector [ Root , SLOTS_PER_HISTORICAL_ROOT ] historical_roots : List [ Root , HISTORICAL_ROOTS_LIMIT ] # Frozen in Capella, replaced by historical_summaries # Eth1 eth1_data : Eth1Data eth1_data_votes : List [ Eth1Data , EPOCHS_PER_ETH1_VOTING_PER

Explore this link on the map →

related reading