(1/21) @ethereum Fundamentals: PoS Blocks
In less than 1 week, the Ethereum blockchain will Merge with the Beacon Chain and the World Computer will transition from PoW to PoS. The blockchain will never be the same.
A field-by-field guide to on-chain future.
(2/21) @ethereum is the World Computer: a globally shared utility that exists between a network of 1000s of computers, each running a local version of the Ethereum Virtual Machine (EVM).
From genesis in 2015 until now, Ethereum has coordinated with a system called Proof of Work.
(3/21) In a few days, the @ethereum blockchain will Merge with the Beacon Chain, creating the new canonical PoS $ETH.
As the name "The Merge" suggests, Ethereum blocks will be a combination of the old blocks (execution layer) and the new Beacon Chain blocks (consensus layer).
(4/21) Prerequisite - Merkle Trees
Merkle Tree: data structure used to organize and encrypt huge data sets. Merkle Proofs can be used to efficiently verify that data exists in a dataset (confirmation a piece of data exists without transferring the whole dataset).
twitter.com/SalomonCrypto/status/1567638108937801728
(5/21) Under PoS, an @ethereum block is made up of 3 parts:
- Administration, the metadata of the block
- Consensus, the layer coordinating the Beacon Chain providing the cryptographic security of PoS
- Execution, the data of the block, (almost) exactly mirroring PoW blocks
(6/21) Administration - information about the block
The attached images show all the administration fields. We will discuss the non-obvious ones in below.
state_root - the root hash of a Merkle tree which stores the state of the Beacon Chain (BeaconState)
(7/21) randao_reveal - protocol-verified randomness, generated between all block proposers during an epoch.
Randomness is critical to the Beacon Chain; security depends on being able to unpredictably and uniformly select block proposers and committee members.
(8/21) graffiti - an (optional) 32-byte field in which block proposers can put anything they want. Often used by mining pools to log their blocks.
(9/21) signature - the signature the block proposer creates to take responsibility (add to blockchain and collect reward if good, get slashed if bad). Created by combining the BeaconState, BeaconBlock and the proposer's private key.
(10/21) Consensus - information necessary to coordinate and verify blockchain consensus and implement PoS
The attached images show all the consensus fields. We will discuss the non-obvious ones in below.
(11/21)deposit_root - the root hash of a Merkle tree which stores the $ETH deposits into the staking contract (required to become a validator)
attestations - a list of all validators that attested to this block
(12/21) @ethereum PoS elects a proposer who is charged with building (or selecting) a block and proposing it to the network. Attesters review the block and, if it's valid, sign it with their keys.
attestations - a list of these signatures, represented in this data structure:
(13/21) deposits - @beaconcha_in defines this field as "amount of validator deposits which have been included in this block by the block proposer." Interestingly, the only non-0 value I could find was in the genesis block
voluntary_exits - withdrawals from the staking contract
(14/21) proposer_slashings and attester_slashings - validators that have performed a hostile action against the network (for example, proposing or attesting to an invalid block). The network confiscates a portion of their staked $ETH and ejects them from the validator set.
(15/21) A sync committee is a group of 512 validators, randomly assigned once every 256 epochs (~27 hours). This committee creates the signatures needed for an efficient light client.
(16/21) sync_committee_bits - efficient representation of committee participation
sync_committee_signature - the signature the sync committee creates to take responsibility for the block/epoch
(17/21) Execution - the payload of the @ethereum block, including all transaction data.
The attached images show all the execution fields.
(18/21) For many purposes (particularly backwards compatibility), the execution payload of a PoS block looks almost identical to a PoW block. For more information, please see this thread.
We will cover the (minor) changes below.
twitter.com/SalomonCrypto/status/1568233231748841474
(19/21) difficulty - set to 0 (PoS does not have difficulty)
nonce - set to 0x0000000000000000 (PoS does not use a nonce)
mixHash - has been renamed to prev_randao now stores the randao value from the previous block
(20/21) sha3Uncles and uncles - because proof of stake does not naturally produce uncle blocks, these fields will be set to 0 (or the hash of an empty list in the case of sha3Uncles). These fields have become irrelevant.
(21/21) And there you have it! That's an @ethereum (Proof of Stake) block!