You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
|`randao_reveal`| a value used to select the next block proposer |
56
+
|`eth1_data`| information about the deposit contract |
57
+
|`graffiti`| arbitrary data used to tag blocks |
58
+
|`proposer_slashings`| list of validators to be slashed |
59
+
|`attester_slashings`| list of attesters to be slashed |
60
+
|`attestations`| list of attestations made against previous slots|
61
+
|`deposits`| list of new deposits to the deposit contract |
62
+
|`voluntary_exits`| list of validators exiting the network |
63
+
|`sync_aggregate`| subset of validators used to serve light clients |
64
+
|`execution_payload`| transactions passed from the execution client |
65
65
66
66
The `attestations` field contains a list of all the attestations in the block. Attestations have their own data type that contains several pieces of data. Each attestation contains:
|`beacon_block_root`| the root hash of the Beacon block seen as the head of the chain|
81
+
|`source`| the last justified checkpoint |
82
+
|`target`| the latest epoch boundary block |
83
83
84
84
Executing the transactions in the `execution_payload` updates the global state. All clients re-execute the transactions in the `execution_payload` to ensure the new state matches that in the new block `state_root` field. This is how clients can tell that a new block is valid and safe to add to their blockchain. The `execution payload` itself is an object with several fields. There is also an `execution_payload_header` that contains important summary information about the execution data. These data structures are organized as follows:
0 commit comments