Phase 0 design notes === 1) Deposits 2) Genesis 3) Hashing and Merkleisation 4) Signatures 5) Incentivisation 6) Types 7) Randomness and shuffling 8) Blocks 9) Attestations 10) Light clients 11) Versioning 12) Checkpointing and finality 13) Design principles 14) Technicalities **Deposits and Eth1 voting** 1) **economic bootstrap** (basic): The Eth2 proof-of-stake consensus is economically bootstrapped using ETH deposits from Eth1. This allows Eth2 to benefit from the present value and distribution of ETH. 2) **deposit contract** (basic): The [deposit contract](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/deposit-contract.md) is a minimal Eth1 contract to make deposits. ETH sent to the deposit contract is made unspendable on Eth1 and eventually gets credited 1-for-1 to a validator balance on the beacon chain. 3) **deposit root** (intermediate): The [`get_deposit_root`](https://github.com/ethereum/eth2.0-specs/blob/dev/deposit_contract/contracts/validator_registration.vy#L46) function of the deposit contract returns the deposit root which uniquely identifies the set of deposits made so far. 4) **Eth1 voting** (intermediate): A simple honest-majority voting mechanism to create a one-way bridge from Eth1 to the beacon chain. Votes (see [the `Eth1Data` object](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#eth1data)) contain deposit roots. 5) **Eth1 voting committees** (intermediate): Eth1 voting is committee-based in the form of beacon block proposers for a stretch of slots. Committees have size of 1024 (see [`SLOTS_PER_ETH1_VOTING_PERIOD`](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#time-parameters)) and the voting threshold is 1/2 (see [`process_eth1_data`](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#eth1-data)). When the threshold is met, the corresponding deposit root becomes the new source of truth against which Eth1 deposits are authenticated. 6) **honest Eth1 voting strategy** (intermediate): Some level of extra-consensus coordination is required for Eth1 voters to converge on the same Eth1 data. The specified "honest" voting strategy is formalised in [`get_eth1_vote`](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/validator.md#get_eth1_data). The strategy is based on tallying upon the most popular valid deposit root. 7) **Eth1 follow distance** (intermediate): The [`ETH1_FOLLOW_DISTANCE` constant](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/validator.md#misc) specifies the minimum age (measured in Eth1 blocks from the subjective tip) that deposit roots should have for honest Eth1 voters to consider valid. It corresponds to about 4 hours which should be sufficiently large to ensure that a deposit root that passes the 1/2 threshold never gets reverted in the eth1 PoW chain. (If such a reversion happens emergency manual intervention may be required.) 8) **forced deposit processing** (advanced): The beacon chain requires pending deposits (up to the `MAX_DEPOSITS` limit) to be processed in beacon blocks to mitigate DoS and grinding attacks that withhold deposits. See the first `assert` in [`process_operations`](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#operations). 9) **deposit contract address** (intermediate): The deposit contract address `DEPOSIT_CONTRACT_ADDRESS` is [currently marked as "TBD"](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/deposit-contract.md#constants). The intent is to well-publicise this address across EF blog, client blogs, and other sources to set the address in an effort to mitigate scam deposit addresses. The ENS name `depositcontract.eth` may be programmed to immutably point to the deposit contract address for 128 years. 10) **minimum deposit amount** (intermediate): As an anti-spam mechanism the deposit contract enforces a minimum deposit amount of 1 ETH (see`MIN_DEPOSIT_AMOUNT`). Eth1 holders with less than 1 ETH have to pool funds or use alternative infrastructure such as exchanges to get an Eth2 validator balance. 11) **no maximum deposit amount** (intermediate): There is no maximum deposit amount to facilitate transferring large Eth1 balances to Eth2 without breaking them into smaller pieces. 12) **no serialisation** (advanced): The deposit contract Merkleises the deposit data without serialising it. This is part of an effort to decouple object serialisation from consensus. 13) **proof of possession** (advanced): The deposit data `signature` field is a BLS proof of possession, i.e. a proof that the private key corresponding to the `pubkey` is known by the signer. This is a mechanism to avoid so-called rogue key attackers with BLS aggregation. The proof of possession is not verified in the deposit contract on the eth1 chain, saving significant gas especially that Eth1 does not have BLS12-381 precompiles. Note that [process_deposit](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#deposits) only checks the proof of possession for the first deposit for a particular `pubkey`. 14) **sparse deposit tree** (advanced): The deposit tree is a sparse Merkle tree respecting the Merkleisation of an object of SSZ-type `List[DepositData]`. (Notice the [last line of `get_deposit_root`](https://github.com/ethereum/eth2.0-specs/blob/dev/deposit_contract/contracts/validator_registration.v.py#L55) is the `List` length mixin.) This makes deposit roots friendly to SSZ partials. 15) **deposit proof** (advanced): The deposit tree has 2**32 leaves. As such, deposit proofs (Merkle branches) consist of 32 nodes, plus 1 for the length mix-in (see `depth=DEPOSIT_CONTRACT_TREE_DEPTH + 1` in `process_deposit`). 16) **deposit tree size** (intermediate): The deposit tree has 2\*\*32 leaves where each deposit consumes one leaf. Given the minimum deposit amount, as well as restrictions on Eth1 ETH supply, the deposit contract should not fill up. 17) **Gwei** (intermediate): The atomic unit of account for the beacon chain is the Gwei (10^9 wei) to allows for balances to be represented using 64 bits. The deposit contract [rounds down deposit amounts to the closest Gwei](https://github.com/ethereum/eth2.0-specs/blob/dev/deposit_contract/contracts/validator_registration.vy#L75). 18) **no two-way bridge** (intermediate): Infrastructure for a two-way ETH bridge between Eth1 and the beacon chain is not present in phase 0. A safe bridge requires a robust and mature beacon chain, as well as a fork to Eth1 to be a light client of Eth2. In early phases of Eth2, there is no source of liquidity on validator balances (i.e. no `Transfer` operation). Either Eth1 will be fully integrated into Eth2 _or_ a two-way bridge will be built before validator liquidity is enabled. 19) **block hash voting** (advanced): The Eth1 votes contain a `block_hash` field. This field identifies one of multiple Eth1 chains that could correspond to the same deposit root. It is also infrastructure that may be useful to finalise Eth1 using the Eth2 finality mechanism, and build a two-way bridge. **Genesis** 22) **genesis stake** (basic): A minimum of 2^19 ETH (about 500k ETH) at stake is required for Eth2 genesis. (Multiply [`MIN_GENESIS_ACTIVE_VALIDATOR_COUNT`](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#misc) by `MAX_EFFECTIVE_BALANCE`.) This minimum is a balance between being low enough to achieve in the early/untrusted system, yet large enough is a mitigation against an attacker monopolising the beacon chain early on. I 23) **earliest genesis time** (basic): The `MIN_GENESIS_TIME` constant specifies the earliest time for the Eth2 genesis. A placeholder of January 3, 2020 is currently specified. A specific date will be chosen following successful audits and testnets. 24) **genesis trigger flexibility** (intermediate): The [`is_valid_genesis_state`](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#genesis-state) function formalises the genesis trigger. It is defined outside of the deposit contract to make use of the expressibility of `get_active_validator_indices`, and for it to be redefined if necessary. For example, `MIN_GENESIS_TIME` may be push back depending on the expected production-readiness of implementations. 25) **alignment to 00:00 UTC** (intermediate): Given `MIN_GENESIS_DELAY == 1 day`, the genesis block is constrained to happen at 00:00 UTC (see `genesis_time=eth1_timestamp - eth1_timestamp % MIN_GENESIS_DELAY` in [`initialize_beacon_state_from_eth1`](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#genesis)). Since `MIN_GENESIS_DELAY * SLOTS_PER_EPOCH` divides `MIN_GENESIS_DELAY`, an epoch transition will occur every day at 00:00 UTC. 26) **one-day advance notice** (intermediate): The `genesis_time` is designed to give validators at least one day of advance notice before the genesis block (see `+ 2 * MIN_GENESIS_DELAY` in `initialize_beacon_state_from_eth1`). This allows the Eth1 block triggering Eth2 genesis to be safely confirmed, and allow validators to manually check or configure the genesis block if required. Note that `MIN_GENESIS_DELAY` is configurable to smaller values for ease in kicking off testnets 27) **genesis underflows** (intermediate): Unsigned integer underflows related to `GENESIS_EPOCH` are prevented on an adhoc basis with simple `if` statements in `get_previous_epoch`, `process_justification_and_finalization`, and `process_rewards_and_penalties`. 28) **no Eth1 fork** (intermediate): The Eth1 consensus does not need to be forked for Eth2 genesis. Indeed, the only Eth2-specific infrastructure on Eth1 is the deposit contract, which lies at the application layer. **Hashing and merkleisation** 28) **SHA256** (basic): The enshrined hash function is SHA256. It is secure (not known to be less secure than, say, SHA3 or Blake2) and fast (~40% faster than SHA3 on CPUs). It is the blockchain standard (90%+ of present and future blockchains use it for Merkleisation) and [NIST encourages it for applications requiring interoperability](https://csrc.nist.gov/Projects/Hash-Functions/NIST-Policy-on-Hash-Functions). 29) **roots vs hashes** (basic): Consensus objects in Eth2 are Merkleised into roots. This contrasts with certain Eth1 consensus objects (such as blocks) which are hashed as monoliths. The nomenclature for identifiers reflects that change. For example we speak of "block roots" in Eth2, in contrast to "block hashes" in Eth1. 30) **partial Merkleisation** (intermediate): An object that contains a root can be thought of as the partial Merkleisation of a bigger "extension" object where the root is unrolled by a corresponding object. For example, the `state.eth1_data` object is the partial Merkleisation of the same object with `deposit_root` replaced by the deposit tree. Other examples of partial Merkleisations include `header.parent_root`, `header.block_root`, `header.state_root`, `crosslink.parent_root`, `state.historical_roots[i]`. 31) **maximal extensions** (intermediate): Given an object one can recursively extend its roots into objects until its maximal extension (which is unique and well-defined) is reached. As a consequence of how the beacon state and blocks are defined, every consensus object part of the history of an Eth2 chain is part of the maximal extension the state root (or block root) of the tip of the chain and can therefore be accessed with a single Merkle path. 32) **historical roots** (intermediate): The `historical_roots` (along with `block_roots` and `state_roots`) in the beacon state allow for any historical consensus object in a beacon chain to be accessed with a bounded-size Merkle path. The historical roots infrastructure can be thought of a constant-size append-only accumulator with permanent witnesses. 33) **block root** (intermediate): The block root of a `block` is defined as `hash_tree_root(block)` (not the `hash_tree_root(signed_beacon_block)`. In other words, the signature is excluded from the block identifier. (There is a one-to-one correspondence between `hash_tree_root(block)` and `hash_tree_root(signed_block)` because BLS signature are unique.) 35) **latest block root** (advanced): Excluding signatures from block roots allows for the beacon state to contain enough information (stored in `latest_block_header`) to compute the block root of its latest block. This allows for the state transition function check `block.parent_root` is valid from the state only, i.e. without oracle access to the parent root. 36) **balances** (advanced): The validator registry is split over two fields in the beacon state, namely `validators` and `balances`. The high-churn `balances` are segregated as a Merkleisation optimisation. Indeed, `validators` change comparatively infrequently and fully re-Merkleising `balances` at every epoch is significantly cheaper than re-Merkleising the full registry. 37) **xxHash** (advanced): A significant computational overhead when running the state transition function is hashing. To speed up heavy-duty testing such as fuzzing, the preferred non-cryptographic drop-in replacement to SHA256 is xxHash. 38) **effective balance hysteresis**: A hysteresis mechanism makes it hard to frequently change a validator's effective balance stored in `state.validators`. This is a DoS-protection mechanism to avoid unnecessary hashing and to prevent minor changes to balance having much effect on fork choice stability. See `balance < validator.effective_balance or validator.effective_balance + 3 * HALF_INCREMENT < balance` in [`process_final_updates`](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#final-updates). **Signatures** 39) **signature aggregation** (basic): The BLS signature scheme (named after Boneh, Lynn, Shacham) allows for signature aggregation, and is used to aggregate the same attestation by different committee members into a single attestation plus an aggregation bitfield. 40) **large aggregations** (intermediate): The marginal verification cost per attestation in an aggregated attestation is low. This enables the beacon chain to support large committees and hence allows the minimum activation balance to safely be set as low as 32 ETH. (A 32 ETH activation balance yields, in the worst case, committes of size 2048 and 2^22 active validators.) 41) **onchain pubkeys** (intermediate): Every validator has its pubkey in the beacon chain state. Unlike Bitcoin or Ethereum addresses, the pubkey is stored raw (i.e. it is not hashed). This allows the beacon chain to build aggregated pubkeys from aggregation bitfields. 42) **aggregation bitfield** (intermediate): Aggregated signatures in attestations are verified against an aggregated pubkey corresponding to the set of signers. Given a well-defined committee with ordered members, the aggregation bitfield specifies (using just one bit per committee member) the set of pubkeys to aggregate. 45) **BLS standardisation** (basic): An Eth2 design goal is to maximise interoperability and be a leader in standardisation. The [BLS functions used in eth2](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#bls-signatures) are pulled directly from various IETF standards—[pairing-friendly curves](https://datatracker.ietf.org/doc/draft-yonezawa-pairing-friendly-curves/), [hashing to elliptic curves](https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/), and [BLS signatures](https://datatracker.ietf.org/doc/draft-boneh-bls-signature/). 46) **no signature abstraction** (intermediate): The beacon chain does not support signature abstraction, i.e. does not allow validators to programmatically choose a signature scheme for signing consensus objects. The infrastructure to support abstraction introduces significant consensus complexity (including a VM and metering) and impedes the efficiency benefits of monopolistically enshrining BLS signatures. 47) **signature domains** (intermediate): To avoid a signature for a given message type to be reinterpreted as a signature for another message type, each type of signed message has a different signature domain type. The signature domains are defined [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#domain-types). 48) **BLS12-381** (intermediate): We use BLS12-381 as the pairing-friendly curve for BLS signatures. It was developed for Zcash as a more secure alternative to BN128 and is becoming the de facto blockchain standard. Newer curves (such as [Zexe](https://eprint.iacr.org/2018/962.pdf)'s BLS12-377 which allows for one level of SNARK recursion) are being considered for a future release. 49) **G1 vs G2** (intermediate): The BLS12-381 pairing is an asymmetric pairing over two different groups traditionally known as G1 and G2. Either group can host signatures, with the other hosting pubkeys. Elements in G2 are twice the size of elements in G1 (96 bytes vs 48 bytes—48 bytes is ~381 bits, hence the name). Elements in G2 are also more expensive to work with (addition is ~4,500ns vs ~1,350ns). Pubkeys are strategically chosen to be in G1 to reduce the cost of onchain pubkey aggregation (see `bls_aggregate_pubkeys`). (Notice signature aggregation is done offchain so the performance of G2 additions matters much less, but at the expense of larger messages on gossip channels.) 50) **hash to G2** (advanced): With signatures in G2 a hash function mapping messages (strings of bytes) to G2 is required. While not necessary for the security signatures, a constant-time hash function is preferred in the context of standardisation. A recent construction by [Wahby and Boneh](https://eprint.iacr.org/2019/403.pdf) improves upon the Fouque-Tibouchi approach. 51) **quantum-secure roadmap** (basic): BLS signatures are not quantum-secure. The long-term roadmap (think Ethereum 3.0) is to replace non-quantum secure constructions with STARK-based alternatives. 52) **quantum apocalypse backup** (advanced): _[Still being discussed]_ Validators are asked to embed within `withdrawal_credentials` a tree of secret hashes. In case of a quantum apocalypse, BLS signatures will be deactivated (e.g. by redefining `bls_verify` to always return `False`) and Lamport signatures can ensure a safe transition for validators. 53) **pool friendliness** (intermediate): Eth2 is designed so that a given validator can be operated through multiple pubkeys in an m-of-n threshold setup. This allows pool operators to control a single validator (effectively lowering the minimum activation balance) as well as allowing a distributed operation across multiple machines. 54) **batch BLS verification** (advanced): Multiple BLS signatures (for different messages) can batch-verified as a cost smaller than verifying individual signatures. (See [here](https://ethresear.ch/t/fast-verification-of-multiple-bls-signatures/5407) for a description of the scheme.) Since blocks contain multiple signatures, batch verification allows for faster block validation, and is currently in use in at least 1 client implementation today. 55) **withdrawal prefix** (intermediate): The [`BLS_WITHDRAWAL_PREFIX` constant](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#initial-values) specifies the format of the validator withdrawal credentials. This allows, for example, for different signatures to be specified in the future. 56) **header signature compression** (advanced): Passing along a series of `BeaconBlock`s (rather than `SignedBeaconBlocks`) allows for the consecutive headers to be verified via communicating a single aggregated signature. **Incentivisation** 50) **sub-linear reward schedule** (intermediate): The overall reward schedule grows sub-linearly with the amount of ETH at stake (i.e. scales with the square root of total deposits). This means issuance rewards per validator decrease as the validator pool grows. This allows for market discovery of validator revenue. 51) ** 52) Strike a balance between encouraging security and allowing for market discovery. Notice that `integer_squareroot` is equivalent to `math.floor(math.sqrt(n))`, and was implemented using Newton's method to avoid external dependencies. 53) **Maximum issuance**: The `BASE_REWARD_FACTOR` constant (assuming `SECONDS_PER_SLOT` and `SLOTS_PER_EPOCH` fixed) dictates the issuance schedule. It was chosen to issue at most 2^21 ETH (~2 million ETH) per year in the worst-case. The worst-case corresponds to 2^27 ETH effective balance (i.e. all ETH in existence today and some), with all validators making perfect attestations (matching source, target, head, and crosslink) that are perfectly included on-chain. In practice, the issuance is expected incur significantly less than 1% dilution per year. 54) **Compound interest**: Rewards are based upon a validators `effective_balance` which has a cap of `MAX_EFFECTIVE_BALANCE`, so in practice rewards do no compound. A validator is expected to eventually withdraw rewards and split across multiple validators to reap the benefits of compounding. 55) **Dust balances**: Validator entries with zero balance will eventually be cleared from the beacon chain. To prevent spam, the transfer and withdrawal mechanisms will disallow dust balances. 56) **Quadratic leak**: 57) **Slashing**: Slashing is a heavy-handed penalty mechanism for attributable bad behaviour. Slashed validators will lose at least 1/32 (see `MIN_SLASHING_PENALTY_QUOTIENT`) of their effective balance. So if a validator has 32 ETH of effective balance they will lose at least 1 ETH. 58) **Inactivity penalty**: A mechanism for the voting power of offline validators (relative to online validators) to diminish over time. This allows for finality and crosslinking to always eventually resume, even with validators permanently going offline. **Types** 57) **Basic types** (intermediate): Beacon chain objects are statically typed. Only three basic types are used: `uint8` (a byte) `uint64` (unsigned 64-bit integer) and `bool`. 58) **Composite types** (intermediate): Composites type are recursively built from basic types using vectors, lists, and containers. 59) **Unsigned integers** (intermediate): All arithmetic (except blackboxed cryptographic primitives) is expressed using unsigned integers. Signed integers are avoided for simplicity. (Negative numbers are avoided when accessing lists and vectors by compensating subtractions.) 60) **64-bit integers** (intermediate): All integers (except blackboxed cryptographic primitives) are 64-bit for both simplicity and hardware friendliness. In particular, hardware-unfriendly 256-bit integers of the EVM1.0 are avoided. 61) **No big integers** (intermediate): Big integers are avoided. In particular, when hashes need to be compared we use lexicographic ordering (e.g. in `get_head` for tie breaking). **Randomness and shuffling** 62) **No stalling** (intermediate): The epoch number is mixed into the seed (see `+ int_to_bytes(epoch, length=32)` in `get_seed`) to avoid the randomness beacon producing the same seed across epochs with all skip slots. 64) **One reveal per block**: 65) **BLS-based vs hash-based PRF**: 66) **XORing vs hash chain** (advanced): Using `xor` in `process_randao` is (slightly) more secure than using `hash`. To illustrate why, imagine an attacker can grind randomness in the current epoch such that two of his validators are the last proposers, in a different order, in two resulting samplings of the next epochs. The commutativity of `xor` makes those two samplings equivalent, hence reducing the attacker's grinding opportunity for the next epoch versus `hash` (which is not commutative). The strict security improvement may simplify the derivation of RANDAO security formal lower bounds. 67) **VDFs** (advanced): An upgrade to the randomness is planned for phase 2 with VDFs. 68) **Seed lookahead**: Give at least one epoch of lookahead for a block proposer to prepare (see `MIN_SEED_LOOKAHEAD`). 69) **`MAX_SEED_LOOKAHEAD`**: In adversarial conditions (attacker with a large stake and/or poor liveness) it is possible for an attacker to predict the randomness from RANDAO some time in advance. This "lookahead" could be used by an attacker to manipulate committee shufflings by grinding activations and exits (e.g. using self-slashing). We protect against this by delaying activations and exits by this certain security parameter. 70) **`MAX_SEED_LOOKAHEAD - MIN_SEED_LOOKAHEAD`**: This security parameter (set to 3) ensures with high probability that an attacker cannot unfairly manipulate the shuffling (e.g. to craft invalid or unavailable crosslinks). Indeed, even if there's only 10% of validators that are honest and online then the probability an attacker can know the randomness 3 epochs beyond `MIN_SEED_LOOKAHEAD` is (1 - 10%)**(3*64), which is about 1 in a billion. 71) **Statistically representation** (basic): 72) **Swap or not** (intermediate): The shuffling mechanism is a cryptographically-secure permutation called "[swap or not](https://link.springer.com/content/pdf/10.1007%2F978-3-642-32009-5_1.pdf)". It has the property of being locally computable. That is, one can compute in constant time the permutation for any given permuted index without computing the permutation over the full set. This is useful for light clients who are computationally restricted. 73) **`SHUFFLE_ROUND_COUNT`** (intermediate): Notice that `SHUFFLE_ROUND_COUNT` is not a power of two because swap or not can be considered a black box. 74) **Swap or not intuition** (advanced): One could consider the shuffling function (specifically, `compute_shuffled_index`) as a cryptographic black box and trust the cryptographers. Having said that, intuitively, the shuffling is just the repeated iteration (`SHUFFLE_ROUND_COUNT` times) of a simple reflection permutation around a pseudo-randomly selected pivot. 75) `randao_mixes`: Allow for far-reaching reconstructions of shufflings. **Blocks** 76) **Graffiti** (intermediate): Similar to the `extraData` field in Eth1 blocks, beacon blocks have a free-form 32-bytes "graffiti". Graffiti are meant to be a vector for permissionless innovation. 77) **Block body**: 78) **Block header**: Beacon block headers are partial Merkleisations of beacon blocks. Specifically, the `body_root` is the Merkleisation of a `BeaconBlockBody`. 79) **Operation limits**: The size of beacon blocks is capped by capping the number of "operations" per block (see `MAX_PROPOSER_SLASHINGS`, `MAX_ATTESTER_SLASHINGS`, etc.). [TODO: Add maximum block size.] This is a DoS protection mechanism. 81) **`latest_block_header`**: The beacon state keeps track of information the latest processed block header. For circularity reasons, it does not keep track of the `signature`, and only adds the `state_root` in the next slot. 82) **Parent root check**: The `latest_block_header` allows for a clean `(BeaconState, BeaconBlock) -> BeaconState` transition function where the `parent_root` is internally calculated and checked without "oracle access" (see `assert block.parent_root == hash_tree_root(state.latest_block_header)` in `process_block_header`). **Validators** 83) **FAR_FUTURE_EPOCH**: The constant acts as a flag to indicate that `Validator` status epochs have not been written to. 84) **Fair proposer selection**: Notice that the `while True` loop in `compute_proposer_index` will terminate **Attestations** 85) **Pending attestations** (intermediate): Pre-processed attestations. The `signature` is stripped off after being verified as they are no longer needed and we can save space/hashing in the `BeaconState`. The `inclusion_delay` and `proposer_index` are added for incentivisation purposes—see "Proposer and inclusion delay micro-rewards" in `get_attestation_deltas`. 87) **Slashed vs unslashed** (advanced): 88) **Indexed attestation** (advanced): 89) **Attester slashing**: Using two `IndexedAttestation` is slightly more powerful than using just one. 90) **Aggregation bits**: The BLS aggregation scheme requires specifying the set of pubkeys for which signatures are being aggregated. A compact pubkey set representation for committees is `aggregation_bits` which consumes just one bit per committee member. 91) **Proposer equivocation**: Block proposers are expected to propose at most one block in their assigned slot and are liable to slashing if not (see `process_proposer_slashing`). 93) **Sorted indices**: The indices in an attestation are required to be sorted—`indices == sorted(set(indices))`—to allow for network-level compression like SPDY. 94) **`MIN_ATTESTATION_INCLUSION_DELAY`**: **Light clients** 95) **`compact_validators`**: Reduce hashing overhead, and more efficient light clients. `compact_balance` chosen to have 15 bits for future-proofness, e.g. if STARK-based signatures force us to increase the minimum deposit size. 96) `historical_roots`: A really neat append-only accumulator. Notice that witnesses are permanent. 97) **`CHURN_LIMIT_QUOTIENT`**: The churn in the active validator pool, i.e. the amount by which validators activate and exit, is limited so that light clients can safely resync after being disconnected, up to some weak subjectivity bound. **Versioning** 98) **Phases**: The Ethereum 2.0 roadmap is split into three key deployment phases. Phase 0 is the "system layer" consisting of a central proof-of-stake chain called the beacon chain. Expected to launch early 2020. Phase 1 is the "data layer" which consists of 64 shard chains for user transactions. Expected to launch late 2020. Phase 2 is the "execution layer" which allows for shard data to be executed in a virtual machine. Expected to launch in 2021. 99) **Fork versioning**: Forks (such as consensus upgrades) are versioned (see the `Fork` object which contains `previous_version` and `current_version`). The fork versioning ties into the signature scheme as a replay protection mechanism. 100) **Unix time**: Timestamps in Eth2 (and Eth1) are defined to be Unix times. In particular, they are denominated in seconds. Note that leap seconds mean that slots will occasionally have a duration of `SECONDS_PER_SLOT` plus or minus one second. 101) **Slots** (basic): Time is divided into contiguous 12-second intervals. Every beacon block is assigned a slot and there at most one block per slot in a chain. The regularity of Eth2 slot duration contrasts with the Poisson distribution of proof-of-work Eth1 block durations. Versioning in "time". 102) **Block proposer** (basic): For a given chain, a unique block proposer is pseudo-randomly selected for every slot in the current and next epoch. This validator has monopoly power during that to suggest a block to extend the beacon chain. 103) **Skip slots** (basic): Slots in a beacon chain without blocks are called skip slots. To simplify the design and minimise forking opportunities, there is no mechanism for validators other than the sampled block proposer to extend the beacon chain. 104) **Epochs** (basic): An epoch is an aligned batch of 32 contiguous slots. This batching in time is an optimisation, in a similar vein to how Eth1 blocks batch transactions in space. 105) **Epochs vs slots** (basic): Epochs are emphasised over slots as the more "native" unit of time for the beacon chain. You can think of slots as merely an implementation detail to deal with block progression. 106) **Slot duration**: The `SECONDS_PER_SLOT` constant defines the number as part of the fork choice rule (as opposed to the state transition function). As small as we can safely get it. A block is only accepted into the view of the fork choice if the current time is at least `state.genesis_time + block.slot * SECONDS_PER_SLOT`. **Checkpointing and finality** 108) **Checkpoints**: A checkpoint uniquely represents a given chain at a specific epoch transition. It is a block root plus an epoch number. A block root alone is insufficient to describe a checkpoint because block roots do not change with skip slots because there is no block. 109) **Finality**: Eth2 has an "economic finality" mechanism called the Friendly Finality Gadget (FFG) which endows checkpoints with a "finalised" status. Validators are liable to slashing for producing conflicting finalised checkpoints. **Design principles** 111) **Total complexity**: While there are hundreds of design considerations that have gone into designing the phase 0 spec, the code complexity is small. The deposit contract, state transition function, and fork choice rule are expressible in 128, 1024 and 256 lines of code respectively. 112) **Dependencies**: The phase 0 spec only has two black-box dependencies, namely a hash function (SHA256) and a signature scheme (BLS signatures). 113) **WWIII**: A key design goal is to survive WWIII. 114) **Liveness over safety**: A liveness favoring protocol can simulate a one favoring safety, whereas the opposite is not true. 115) **Serialisation agnosticism**: **Technicalities** 116) **Little-endian**: 117) **Divisions by zero**: See `max(1,` in `get_committee_count_at_slot` and `get_total_balance`. 118) **Clock assumption**: 119) **Powers of two**: 120) **Underflows**: **Draft** 26) **`MAX_ATTESTATIONS` vs `MAX_COMMITTEES_PER_SLOT // SLOTS_PER_EPOCH`**: Notice that `MAX_ATTESTATIONS` is 2 times larger than `MAX_COMMITTEES_PER_SLOT // SLOTS_PER_EPOCH` (128 vs 16). This buffer allows for the beacon chain to absorb some amount of imperfectly-aggregated attestations for the same committee, as well as provide resilience against skip slots. 31) **Honest majority thresholds**: Notice the Eth1 voting threshold is different from crosslink/justification threshold (1/2 vs 2/3). The low Eth1 voting threshold is safe because voting committees are large (of size `SLOTS_PER_ETH1_VOTING_PERIOD == 1024`). Crosslink committees can be as small as `TARGET_COMMITTEE_SIZE == 128`. 4) **Beacon chain**: The name historically derived "randomness beacon". 8) `MAX_...`: DoS mitigation by capping the maximum size of beacon blocks. 11) **Adaptive attacks**: 12) **Beacon chain state availability**: The beacon chain state is expected to be one of the most well-maintained state in the world. No additional infrastructure is required to ensure its availability.