eth2.0-specs/specs/merge/beacon-chain.md

387 lines
14 KiB
Markdown
Raw Normal View History

# The Merge -- The Beacon Chain
2021-03-11 12:33:36 +00:00
**Notice**: This document is a work-in-progress for researchers and implementers.
## Table of contents
<!-- TOC -->
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
- [Introduction](#introduction)
2021-03-29 18:56:43 +00:00
- [Custom types](#custom-types)
2021-03-11 12:33:36 +00:00
- [Constants](#constants)
- [Execution](#execution)
2021-07-30 10:10:33 +00:00
- [Configuration](#configuration)
2021-08-10 11:15:07 +00:00
- [Genesis testing settings](#genesis-testing-settings)
2021-09-17 10:54:06 +00:00
- [Transition settings](#transition-settings)
2021-03-11 12:33:36 +00:00
- [Containers](#containers)
- [Extended containers](#extended-containers)
- [`BeaconBlockBody`](#beaconblockbody)
- [`BeaconState`](#beaconstate)
- [New containers](#new-containers)
- [`ExecutionPayload`](#executionpayload)
- [`ExecutionPayloadHeader`](#executionpayloadheader)
2021-03-11 12:33:36 +00:00
- [Helper functions](#helper-functions)
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
- [Predicates](#predicates)
- [`is_merge_complete`](#is_merge_complete)
- [`is_merge_block`](#is_merge_block)
- [`is_execution_enabled`](#is_execution_enabled)
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
- [Misc](#misc)
- [`compute_timestamp_at_slot`](#compute_timestamp_at_slot)
- [Beacon chain state transition function](#beacon-chain-state-transition-function)
- [Execution engine](#execution-engine)
- [`on_payload`](#on_payload)
2021-03-11 12:33:36 +00:00
- [Block processing](#block-processing)
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
- [Execution payload processing](#execution-payload-processing)
2021-07-26 14:09:57 +00:00
- [`is_valid_gas_limit`](#is_valid_gas_limit)
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
- [`process_execution_payload`](#process_execution_payload)
- [Testing](#testing)
2021-03-11 12:33:36 +00:00
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
<!-- /TOC -->
## Introduction
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
This patch adds transaction execution to the beacon chain as part of the Merge fork.
2021-03-11 12:33:36 +00:00
## Custom types
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
*Note*: The `Transaction` type is a stub which is not final.
| Name | SSZ equivalent | Description |
| - | - | - |
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
| `OpaqueTransaction` | `ByteList[MAX_BYTES_PER_OPAQUE_TRANSACTION]` | a [typed transaction envelope](https://eips.ethereum.org/EIPS/eip-2718#opaque-byte-array-rather-than-an-rlp-array) structured as `TransactionType \|\| TransactionPayload` |
| `Transaction` | `Union[OpaqueTransaction]` | a transaction |
2021-03-11 12:33:36 +00:00
## Constants
### Execution
| Name | Value |
| - | - |
| `MAX_BYTES_PER_OPAQUE_TRANSACTION` | `uint64(2**20)` (= 1,048,576) |
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
| `MAX_TRANSACTIONS_PER_PAYLOAD` | `uint64(2**14)` (= 16,384) |
| `BYTES_PER_LOGS_BLOOM` | `uint64(2**8)` (= 256) |
| `GAS_LIMIT_DENOMINATOR` | `uint64(2**10)` (= 1,024) |
2021-07-26 13:30:50 +00:00
| `MIN_GAS_LIMIT` | `uint64(5000)` (= 5,000) |
2021-09-17 12:23:21 +00:00
| `MAX_EXTRA_DATA_BYTES` | `2**5` (= 32) |
2021-03-11 12:33:36 +00:00
2021-07-30 10:10:33 +00:00
## Configuration
2021-08-10 11:15:07 +00:00
### Genesis testing settings
2021-07-30 10:10:33 +00:00
*Note*: These configuration settings do not apply to the mainnet and are utilized only by pure Merge testing.
| Name | Value |
| - | - |
| `GENESIS_GAS_LIMIT` | `uint64(30000000)` (= 30,000,000) |
2021-08-16 12:35:11 +00:00
| `GENESIS_BASE_FEE_PER_GAS` | `Bytes32('0x00ca9a3b00000000000000000000000000000000000000000000000000000000')` (= 1,000,000,000) |
2021-07-30 10:10:33 +00:00
2021-09-17 10:20:25 +00:00
### Transition settings
| Name | Value |
| - | - |
| `TERMINAL_TOTAL_DIFFICULTY` | **TBD** |
2021-09-17 10:20:25 +00:00
2021-03-11 12:33:36 +00:00
## Containers
### Extended containers
#### `BeaconBlockBody`
```python
class BeaconBlockBody(Container):
randao_reveal: BLSSignature
eth1_data: Eth1Data # Eth1 data vote
graffiti: Bytes32 # Arbitrary data
# Operations
proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
attestations: List[Attestation, MAX_ATTESTATIONS]
deposits: List[Deposit, MAX_DEPOSITS]
voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
sync_aggregate: SyncAggregate
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
# Execution
execution_payload: ExecutionPayload # [New in Merge]
2021-03-11 12:33:36 +00:00
```
#### `BeaconState`
```python
2021-07-22 18:01:50 +00:00
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]
# Eth1
eth1_data: Eth1Data
eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH]
eth1_deposit_index: uint64
# Registry
validators: List[Validator, VALIDATOR_REGISTRY_LIMIT]
balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT]
# Randomness
randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR]
# Slashings
slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] # Per-epoch sums of slashed effective balances
# Participation
previous_epoch_participation: List[ParticipationFlags, VALIDATOR_REGISTRY_LIMIT]
current_epoch_participation: List[ParticipationFlags, VALIDATOR_REGISTRY_LIMIT]
# Finality
justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] # Bit set for every recent justified epoch
previous_justified_checkpoint: Checkpoint
current_justified_checkpoint: Checkpoint
finalized_checkpoint: Checkpoint
# Inactivity
inactivity_scores: List[uint64, VALIDATOR_REGISTRY_LIMIT]
# Sync
current_sync_committee: SyncCommittee
next_sync_committee: SyncCommittee
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
# Execution
latest_execution_payload_header: ExecutionPayloadHeader # [New in Merge]
2021-03-11 12:33:36 +00:00
```
### New containers
#### `ExecutionPayload`
2021-03-11 12:33:36 +00:00
2021-08-16 12:35:11 +00:00
*Note*: The `base_fee_per_gas` field is serialized in little-endian.
2021-03-11 12:33:36 +00:00
```python
class ExecutionPayload(Container):
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
# Execution block header fields
2021-04-08 08:48:03 +00:00
parent_hash: Hash32
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
coinbase: Bytes20 # 'beneficiary' in the yellow paper
2021-03-11 12:33:36 +00:00
state_root: Bytes32
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
receipt_root: Bytes32 # 'receipts root' in the yellow paper
logs_bloom: ByteVector[BYTES_PER_LOGS_BLOOM]
random: Bytes32 # 'difficulty' in the yellow paper
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
block_number: uint64 # 'number' in the yellow paper
2021-03-11 12:33:36 +00:00
gas_limit: uint64
gas_used: uint64
timestamp: uint64
2021-09-17 12:23:21 +00:00
extra_data: ByteList[MAX_EXTRA_DATA_BYTES]
2021-08-16 12:35:11 +00:00
base_fee_per_gas: Bytes32 # base fee introduced in EIP-1559, little-endian serialized
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
# Extra payload fields
block_hash: Hash32 # Hash of execution block
transactions: List[Transaction, MAX_TRANSACTIONS_PER_PAYLOAD]
2021-03-11 12:33:36 +00:00
```
#### `ExecutionPayloadHeader`
2021-04-02 14:48:02 +00:00
```python
class ExecutionPayloadHeader(Container):
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
# Execution block header fields
2021-04-08 08:48:03 +00:00
parent_hash: Hash32
2021-04-02 14:48:02 +00:00
coinbase: Bytes20
state_root: Bytes32
receipt_root: Bytes32
logs_bloom: ByteVector[BYTES_PER_LOGS_BLOOM]
random: Bytes32
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
block_number: uint64
2021-04-02 14:48:02 +00:00
gas_limit: uint64
gas_used: uint64
timestamp: uint64
2021-09-17 12:23:21 +00:00
extra_data: ByteList[MAX_EXTRA_DATA_BYTES]
base_fee_per_gas: Bytes32
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
# Extra payload fields
block_hash: Hash32 # Hash of execution block
transactions_root: Root
2021-04-02 14:48:02 +00:00
```
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
## Helper functions
2021-05-10 13:48:37 +00:00
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
### Predicates
2021-05-10 13:48:37 +00:00
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
#### `is_merge_complete`
2021-05-10 13:48:37 +00:00
```python
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
def is_merge_complete(state: BeaconState) -> bool:
return state.latest_execution_payload_header != ExecutionPayloadHeader()
2021-05-10 13:48:37 +00:00
```
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
#### `is_merge_block`
2021-03-11 12:33:36 +00:00
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
```python
def is_merge_block(state: BeaconState, body: BeaconBlockBody) -> bool:
return not is_merge_complete(state) and body.execution_payload != ExecutionPayload()
```
2021-03-11 12:33:36 +00:00
#### `is_execution_enabled`
```python
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
def is_execution_enabled(state: BeaconState, body: BeaconBlockBody) -> bool:
return is_merge_block(state, body) or is_merge_complete(state)
```
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
### Misc
2021-03-11 12:33:36 +00:00
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
#### `compute_timestamp_at_slot`
2021-03-11 12:33:36 +00:00
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
*Note*: This function is unsafe with respect to overflows and underflows.
2021-03-11 12:33:36 +00:00
```python
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
def compute_timestamp_at_slot(state: BeaconState, slot: Slot) -> uint64:
slots_since_genesis = slot - GENESIS_SLOT
return uint64(state.genesis_time + slots_since_genesis * SECONDS_PER_SLOT)
2021-03-11 12:33:36 +00:00
```
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
## Beacon chain state transition function
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
### Execution engine
The implementation-dependent `ExecutionEngine` protocol encapsulates the execution sub-system logic via:
* a state object `self.execution_state` of type `ExecutionState`
* a state transition function `self.on_payload` which mutates `self.execution_state`
#### `on_payload`
```python
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
def on_payload(self: ExecutionEngine, execution_payload: ExecutionPayload) -> bool:
"""
Returns ``True`` iff ``execution_payload`` is valid with respect to ``self.execution_state``.
"""
...
```
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
The above function is accessed through the `EXECUTION_ENGINE` module which instantiates the `ExecutionEngine` protocol.
2021-03-11 12:33:36 +00:00
### Block processing
2021-09-01 14:59:16 +00:00
*Note*: The call to the `process_execution_payload` must happen before the call to the `process_randao` as the former depends on the `randao_mix` computed with the reveal of the previous block.
2021-03-11 12:33:36 +00:00
```python
def process_block(state: BeaconState, block: BeaconBlock) -> None:
process_block_header(state, block)
if is_execution_enabled(state, block.body):
process_execution_payload(state, block.body.execution_payload, EXECUTION_ENGINE) # [New in Merge]
2021-03-11 12:33:36 +00:00
process_randao(state, block.body)
process_eth1_data(state, block.body)
2021-03-11 12:33:36 +00:00
process_operations(state, block.body)
process_sync_aggregate(state, block.body.sync_aggregate)
2021-03-11 12:33:36 +00:00
```
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
### Execution payload processing
2021-03-11 12:33:36 +00:00
2021-07-26 13:30:50 +00:00
#### `is_valid_gas_limit`
```python
def is_valid_gas_limit(payload: ExecutionPayload, parent: ExecutionPayloadHeader) -> bool:
parent_gas_limit = parent.gas_limit
# Check if the payload used too much gas
2021-07-26 13:30:50 +00:00
if payload.gas_used > payload.gas_limit:
return False
# Check if the payload changed the gas limit too much
if payload.gas_limit >= parent_gas_limit + parent_gas_limit // GAS_LIMIT_DENOMINATOR:
2021-07-26 13:30:50 +00:00
return False
if payload.gas_limit <= parent_gas_limit - parent_gas_limit // GAS_LIMIT_DENOMINATOR:
2021-07-26 13:30:50 +00:00
return False
# Check if the gas limit is at least the minimum gas limit
2021-07-26 13:30:50 +00:00
if payload.gas_limit < MIN_GAS_LIMIT:
return False
return True
```
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
#### `process_execution_payload`
2021-03-11 12:33:36 +00:00
```python
2021-06-22 08:23:26 +00:00
def process_execution_payload(state: BeaconState, payload: ExecutionPayload, execution_engine: ExecutionEngine) -> None:
# Verify consistency of the parent hash, block number, base fee per gas and gas limit
# with respect to the previous execution payload header
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
if is_merge_complete(state):
assert payload.parent_hash == state.latest_execution_payload_header.block_hash
assert payload.block_number == state.latest_execution_payload_header.block_number + uint64(1)
2021-07-26 13:30:50 +00:00
assert is_valid_gas_limit(payload, state.latest_execution_payload_header)
# Verify random
assert payload.random == get_randao_mix(state, get_current_epoch(state))
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
# Verify timestamp
assert payload.timestamp == compute_timestamp_at_slot(state, state.slot)
# Verify the execution payload is valid
assert execution_engine.on_payload(payload)
2021-07-07 12:44:22 +00:00
# Cache execution payload header
state.latest_execution_payload_header = ExecutionPayloadHeader(
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
parent_hash=payload.parent_hash,
coinbase=payload.coinbase,
state_root=payload.state_root,
receipt_root=payload.receipt_root,
logs_bloom=payload.logs_bloom,
random=payload.random,
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
block_number=payload.block_number,
gas_limit=payload.gas_limit,
gas_used=payload.gas_used,
timestamp=payload.timestamp,
2021-09-17 12:23:21 +00:00
extra_data=payload.extra_data,
2021-07-26 13:30:50 +00:00
base_fee_per_gas=payload.base_fee_per_gas,
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
block_hash=payload.block_hash,
transactions_root=hash_tree_root(payload.transactions),
2021-04-02 14:48:02 +00:00
)
2021-03-11 12:33:36 +00:00
```
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
## Testing
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
*Note*: The function `initialize_beacon_state_from_eth1` is modified for pure Merge testing only.
*Note*: The function `initialize_beacon_state_from_eth1` is modified: (1) using `MERGE_FORK_VERSION` as the current fork version, (2) utilizing the Merge `BeaconBlockBody` when constructing the initial `latest_block_header`, and (3) initialize `latest_execution_payload_header`.
```python
def initialize_beacon_state_from_eth1(eth1_block_hash: Bytes32,
eth1_timestamp: uint64,
deposits: Sequence[Deposit]) -> BeaconState:
fork = Fork(
previous_version=GENESIS_FORK_VERSION,
current_version=MERGE_FORK_VERSION, # [Modified in Merge]
epoch=GENESIS_EPOCH,
)
state = BeaconState(
genesis_time=eth1_timestamp + GENESIS_DELAY,
fork=fork,
eth1_data=Eth1Data(block_hash=eth1_block_hash, deposit_count=uint64(len(deposits))),
latest_block_header=BeaconBlockHeader(body_root=hash_tree_root(BeaconBlockBody())),
2021-06-22 08:23:26 +00:00
randao_mixes=[eth1_block_hash] * EPOCHS_PER_HISTORICAL_VECTOR, # Seed RANDAO with Eth1 entropy
)
# Process deposits
leaves = list(map(lambda deposit: deposit.data, deposits))
for index, deposit in enumerate(deposits):
deposit_data_list = List[DepositData, 2**DEPOSIT_CONTRACT_TREE_DEPTH](*leaves[:index + 1])
state.eth1_data.deposit_root = hash_tree_root(deposit_data_list)
process_deposit(state, deposit)
# Process activations
for index, validator in enumerate(state.validators):
balance = state.balances[index]
validator.effective_balance = min(balance - balance % EFFECTIVE_BALANCE_INCREMENT, MAX_EFFECTIVE_BALANCE)
if validator.effective_balance == MAX_EFFECTIVE_BALANCE:
validator.activation_eligibility_epoch = GENESIS_EPOCH
validator.activation_epoch = GENESIS_EPOCH
# Set genesis validators root for domain separation and chain versioning
state.genesis_validators_root = hash_tree_root(state.validators)
# Fill in sync committees
# Note: A duplicate committee is assigned for the current and next committee at genesis
state.current_sync_committee = get_next_sync_committee(state)
state.next_sync_committee = get_next_sync_committee(state)
polish merge/beacon-chain.md (#2472) Polish `merge/beacon-chain.md` with mostly non-substantive changes. **Non-substantive changes** * rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD` - rename "execution transaction" to just "transaction" as per discussion with Danny * rename `compute_time_at_slot` to `compute_timestamp_at_slot` - the function returns a Unix timestamp - "timestamp" matches `execution_payload.timestamp` * be explicit about `ExecutionEngine.execution_state` for clarity * rename `ExecutionPayload.number` to `ExecutionPayload.block_number` - more specific ("number" is pretty vague) - consistent with `ExecutionPayload.block_hash` * rename `new_block` to `on_payload` - the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers)) - the `_payload` suffix is more to the point given the function accepts an `execution_payload` - avoids conflict with `on_block` which is already used in the fork choice * rework the table of contents for consistency * order `is_execution_enabled` after `is_transition_completed` and `is_transition_block` - `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block` * rename "transition" to "merge" - "transition" is a bit vague—we will have other transitions at future hard forks - there is no need for two words to refer to the same concept * add a bunch of inline comments, e.g. in `process_execution_payload` * make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body` * remove `TRANSITION_TOTAL_DIFFICULTY` - to be put in `merge/fork-choice.md` where it is used * various misc cleanups **Substantive changes** * reorder `ExecutionPayload` fields - for consistency with yellow paper and Eth1 - same for `ExecutionPayloadHeader` - added comments separating out the execution block header fields from the extra fields (cosmetic)
2021-06-18 10:09:30 +00:00
# [New in Merge] Initialize the execution payload header (with block number set to 0)
state.latest_execution_payload_header.block_hash = eth1_block_hash
state.latest_execution_payload_header.timestamp = eth1_timestamp
2021-06-22 08:23:26 +00:00
state.latest_execution_payload_header.random = eth1_block_hash
2021-07-30 10:10:33 +00:00
state.latest_execution_payload_header.gas_limit = GENESIS_GAS_LIMIT
state.latest_execution_payload_header.base_fee_per_gas = GENESIS_BASE_FEE_PER_GAS
return state
```