Skip to content

Commit dc01baf

Browse files
authored
Merge pull request ethereum#16560 from baiwfg2/fix-attestation-desc
fix: rephrase meaning of attestations,signature,beacon_block_root(#16
2 parents 6397579 + 4ee5446 commit dc01baf

1 file changed

Lines changed: 24 additions & 24 deletions

File tree

  • public/content/developers/docs/blocks

public/content/developers/docs/blocks/index.md

Lines changed: 24 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -50,36 +50,36 @@ There is a lot of information contained within a block. At the highest level a b
5050

5151
The block `body` contains several fields of its own:
5252

53-
| Field | Description |
54-
| :------------------- | :------------------------------------------------- |
55-
| `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 in favor of the current block |
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 |
53+
| Field | Description |
54+
| :------------------- | :----------------------------------------------- |
55+
| `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 |
6565

6666
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:
6767

68-
| Field | Description |
69-
| :----------------- | :---------------------------------------------------------- |
70-
| `aggregation_bits` | a list of which validators participated in this attestation |
71-
| `data` | a container with multiple subfields |
72-
| `signature` | aggregate signature of all attesting validators |
68+
| Field | Description |
69+
| :----------------- | :------------------------------------------------------------- |
70+
| `aggregation_bits` | a list of which validators participated in this attestation |
71+
| `data` | a container with multiple subfields |
72+
| `signature` | aggregate signature of a set of validators against `data` part |
7373

7474
The `data` field in the `attestation` contains the following:
7575

76-
| Field | Description |
77-
| :------------------ | :------------------------------------------------------- |
78-
| `slot` | the slot the attestation relates to |
79-
| `index` | indices for attesting validators |
80-
| `beacon_block_root` | the root hash of the Beacon block containing this object |
81-
| `source` | the last justified checkpoint |
82-
| `target` | the latest epoch boundary block |
76+
| Field | Description |
77+
| :------------------ | :-------------------------------------------------------------- |
78+
| `slot` | the slot the attestation relates to |
79+
| `index` | indices for attesting validators |
80+
| `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 |
8383

8484
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:
8585

0 commit comments

Comments
 (0)