Skip to content

Commit f39cd95

Browse files
authored
make beacon block lower case
1 parent 220ae80 commit f39cd95

File tree

1 file changed

+3
-3
lines changed
  • src/content/developers/docs/consensus-mechanisms/pos/block-proposal

1 file changed

+3
-3
lines changed

src/content/developers/docs/consensus-mechanisms/pos/block-proposal/index.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -22,7 +22,7 @@ Only one block proposer is selected in each slot. Under normal conditions, a sin
2222

2323
## How is the block created? {#how-is-a-block-created}
2424

25-
The block proposer is expected to broadcast a signed Beacon Block that builds on top of the most recent head of the chain according to the view of their own locally-run fork choice algorithm. The fork choice algorithm applies any queued attestations left over from the previous slot, then finds the block with the greatest accumulated weight of attestations in its history. That block is the parent of the new block created by the proposer.
25+
The block proposer is expected to broadcast a signed beacon block that builds on top of the most recent head of the chain according to the view of their own locally-run fork choice algorithm. The fork choice algorithm applies any queued attestations left over from the previous slot, then finds the block with the greatest accumulated weight of attestations in its history. That block is the parent of the new block created by the proposer.
2626

2727
The block proposer creates a block by collecting data from its own local database and view of the chain. The contents of the block are shown in the snippet below:
2828

@@ -42,9 +42,9 @@ class BeaconBlockBody(Container):
4242

4343
The `randao_reveal` field takes a verifiable random value that the block proposer creates by adding some of its own entropy to the accumulated RANDAO value from previous blocks. `eth1_data` is a vote for the block proposer's view of the deposit contract, including the root of the deposit Merkle trie and the total number of deposits that enable new deposits to be verified. `graffiti` is an optional field that can be used to add a message to the block. `proposer_slashings` and `attester_slashings` are fields that contain proof that certain validators have committed slashable offenses according to the proposer's view of the chain. `deposits` is a list of new validator deposits that the block proposer is aware of, and `voluntary_exits` is a list of validators that wish to exit that the block proposer has heard about on the consensus layer gossip network. The `sync_aggregate` is a vector that shows which validators that were previously assigned to a sync committee (a subset of validators that serve light client data) actually participated in signing data.
4444

45-
The `execution_payload` enables information about transactions to be passed between the execution and consensus clients. The `execution_payload` is a block of execution data that gets nested inside a Beacon block. The fields inside the `execution_payload` reflect the block structure outlined in the Ethereum yellow paper, except that there are no ommers and `prev_randao` exists in place of `difficulty`. The execution client has access to a local pool of transactions that it has heard about on its own gossip network. These transactions are executed locally to generate an updated state trie known as a post-state. The transactions are included in the `execution_payload` as a list called `transactions` and the post-state is provided in the `state-root` field.
45+
The `execution_payload` enables information about transactions to be passed between the execution and consensus clients. The `execution_payload` is a block of execution data that gets nested inside a beacon block. The fields inside the `execution_payload` reflect the block structure outlined in the Ethereum yellow paper, except that there are no ommers and `prev_randao` exists in place of `difficulty`. The execution client has access to a local pool of transactions that it has heard about on its own gossip network. These transactions are executed locally to generate an updated state trie known as a post-state. The transactions are included in the `execution_payload` as a list called `transactions` and the post-state is provided in the `state-root` field.
4646

47-
All of these data are collected in a Beacon block, signed, and broadcast to the block proposer's peers, who propagate it on to their peers, etc.
47+
All of these data are collected in a beacon block, signed, and broadcast to the block proposer's peers, who propagate it on to their peers, etc.
4848

4949
Read more about the [anatomy of blocks](/developers/docs/blocks).
5050

0 commit comments

Comments
 (0)