From d27d0b6b9caab81bef84c172e871007339c79ce2 Mon Sep 17 00:00:00 2001 From: Joe Date: Fri, 29 Jul 2022 14:45:31 +0100 Subject: [PATCH 1/4] update block page --- src/content/developers/docs/blocks/index.md | 62 +++++++++++++-------- 1 file changed, 38 insertions(+), 24 deletions(-) diff --git a/src/content/developers/docs/blocks/index.md b/src/content/developers/docs/blocks/index.md index 473138a3eed..d82b16353ce 100644 --- a/src/content/developers/docs/blocks/index.md +++ b/src/content/developers/docs/blocks/index.md @@ -19,47 +19,61 @@ To ensure that all participants on the Ethereum network maintain a synchronized ![A diagram showing transaction in a block causing state changes](./tx-block.png) _Diagram adapted from [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ -By spacing out commits, we give all network participants enough time to come to consensus: even though transaction requests occur dozens of times per second, blocks on Ethereum are committed approximately once every fifteen seconds. +By spacing out commits, we give all network participants enough time to come to consensus: even though transaction requests occur dozens of times per second, blocks are only created and committed on Ethereum once every six seconds. ## How blocks work {#how-blocks-work} To preserve the transaction history, blocks are strictly ordered (every new block created contains a reference to its parent block), and transactions within blocks are strictly ordered as well. Except in rare cases, at any given time, all participants on the network are in agreement on the exact number and history of blocks, and are working to batch the current live transaction requests into the next block. -Once a block is put together (mined) by some miner on the network, it is propagated to the rest of the network; all nodes add this block to the end of their blockchain, and mining continues. The exact block-assembly (mining) process and commitment/consensus process is currently specified by Ethereum’s “proof-of-work” protocol. +Once a block is put together by some validator on the network, it is propagated to the rest of the network; all nodes add this block to the end of their blockchain, and a new validator is selected to create the next block. The exact block-assembly process and commitment/consensus process is currently specified by Ethereum’s “proof-of-stake” protocol. -### A visual demo {#a-visual-demo} +## Proof-of-stake protocol {#proof-of-work-protocol} - +Proof-of-stake means the following: -## Proof-of-work protocol {#proof-of-work-protocol} +- Validating nodes have to stake at least 32 ETH into a deposit contract as collateral against bad behaviour. This helps protect the network because provably dishonet activity leads to some or all of that stake being destroyed. +- In every slot (spaced 6 seconds apart) a validator is randomly selected to be the block proposer. They bundle transactions together, execute them and determine a new 'state'. They wrap this information int a block and pass it around to other validators. +- Other validators who hear about a new block re-execute the transactions to ensure they agree with the proposed change to the global state. Assuming the block is valid they add it to their own database. +- If a validator hears about two conflicting blocks for the same slot they use their fork-choice algorithm to pick the one supported by the most staked ETH. -Proof-of-work means the following: - -- Mining nodes have to spend a variable but substantial amount of energy, time, and computational power to produce a “certificate of legitimacy” for a block they propose to the network. This helps protect the network from spam/denial-of-service attacks, among other things, since certificates are expensive to produce. -- Other miners who hear about a new block with a valid certificate of legitimacy must accept the new block as the canonical next block on the blockchain. -- The exact amount of time needed for any given miner to produce this certificate is a random variable with high variance. This ensures that it is unlikely that two miners produce validations for a proposed next block simultaneously; when a miner produces and propagates a certified new block, they can be almost certain that the block will be accepted by the network as the canonical next block on the blockchain, without conflict (though there is a protocol for dealing with conflicts as well in the case that two chains of certified blocks are produced almost simultaneously). - -[More on mining](/developers/docs/consensus-mechanisms/pow/mining/) +[More on proof-of-stake](/developers/docs/consensus-mechanisms/pos) ## What's in a block? {#block-anatomy} -- `timestamp` – the time when the block was mined. -- `blockNumber` – the length of the blockchain in blocks. -- `baseFeePerGas` - the minimum fee per gas required for a transaction to be included in the block. -- `difficulty` – the effort required to mine the block. -- `mixHash` – a unique identifier for that block. -- `parentHash` – the unique identifier for the block that came before (this is how blocks are linked in a chain). -- `transactions` – the transactions included in the block. -- `stateRoot` – the entire state of the system: account balances, contract storage, contract code and account nonces are inside. -- `nonce` – a hash that, when combined with the mixHash, proves that the block has gone through [proof-of-work](/developers/docs/consensus-mechanisms/pow/). +There is a lot of information contained within a block. At the highest level a block contains the following fields: + +``` +slot: the slot the block belongs to +proposer_index: the ID of the validator proposing the block +parent_root: the hash of the preceding block +state_root: the root hash of the state object +body: an object containing several fields, as defined below +``` + +The block `body` contains several fields of its own: + +``` +randao_reveal: a value used to select the next blockl proposer +eth1_data: information about the deposit contract +graffiti: arbitrary data used to tag blocks +proposer_slashings: list of validators to be slashed +attester_slashings: list of validators to be slashed +attestations: list of attestations in favour of the current block +deposits: list of new deposits to the deposit contract +voluntary_exits: list of validators exiting the network +sync_aggregate: subset of validators used to serve light clients +execution_payload: transactions passed from the execution client +``` + +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. ## Block time {#block-time} -Block time refers to the time it takes to mine a new block. In Ethereum, the average block time is between 12 to 14 seconds and is evaluated after each block. The expected block time is set as a constant at the protocol level and is used to protect the network's security when the miners add more computational power. The average block time gets compared with the expected block time, and if the average block time is higher, then the difficulty is decreased in the block header. If the average block time is smaller, then the difficulty in the block header will be increased. +Block time refers to the time separating blocks. In Ethereum, time is divided up into 6 second units called 'slots'. In each slot a single validator is selected to propose a block. Assuming all validators are online and fully functional there will be a block in every slot, meanign the block time is 6s. However, occasionally validators might be offline when called to propose a block, meaning slots can sometimes go empty. This is different to proof-of-work based systems where block times are probabilistic and tuned by the mining difficulty. ## Block size {#block-size} -A final important note is that blocks themselves are bounded in size. Each block has a target size of 15 million gas but the size of blocks will increase or decrease in accordance with network demands, up until the block limit of 30 million gas (2x target block size). The total amount of gas expended by all transactions in the block must be less than the block gas limit. This is important because it ensures that blocks can’t be arbitrarily large. If blocks could be arbitrarily large, then less performant full nodes would gradually stop being able to keep up with the network due to space and speed requirements. +A final important note is that blocks themselves are bounded in size. Each block has a target size of 15 million gas but the size of blocks will increase or decrease in accordance with network demands, up until the block limit of 30 million gas (2x target block size). The total amount of gas expended by all transactions in the block must be less than the block gas limit. This is important because it ensures that blocks can’t be arbitrarily large. If blocks could be arbitrarily large, then less performant full nodes would gradually stop being able to keep up with the network due to space and speed requirements. The larger the block, the greater the computing power required to process them in time for the next slot. This is a centralizing force, which is resisted by capping block sizes. ## Further reading {#further-reading} @@ -67,6 +81,6 @@ _Know of a community resource that helped you? Edit this page and add it!_ ## Related topics {#related-topics} -- [Mining](/developers/docs/consensus-mechanisms/pow/mining/) - [Transactions](/developers/docs/transactions/) - [Gas](/developers/docs/gas/) +- [proof-of-stake](/developers/docs/consensus-mechanisms/pos) From 9b6f1b08fc32410b93d9cc752a677e297900df83 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Thu, 25 Aug 2022 14:48:48 +0100 Subject: [PATCH 2/4] Apply suggestions from code review Co-authored-by: Paul Wackerow <54227730+wackerow@users.noreply.github.com> --- src/content/developers/docs/blocks/index.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/content/developers/docs/blocks/index.md b/src/content/developers/docs/blocks/index.md index d82b16353ce..d30d88f13a0 100644 --- a/src/content/developers/docs/blocks/index.md +++ b/src/content/developers/docs/blocks/index.md @@ -19,7 +19,7 @@ To ensure that all participants on the Ethereum network maintain a synchronized ![A diagram showing transaction in a block causing state changes](./tx-block.png) _Diagram adapted from [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ -By spacing out commits, we give all network participants enough time to come to consensus: even though transaction requests occur dozens of times per second, blocks are only created and committed on Ethereum once every six seconds. +By spacing out commits, we give all network participants enough time to come to consensus: even though transaction requests occur dozens of times per second, blocks are only created and committed on Ethereum once every twelve seconds. ## How blocks work {#how-blocks-work} @@ -31,8 +31,8 @@ Once a block is put together by some validator on the network, it is propagated Proof-of-stake means the following: -- Validating nodes have to stake at least 32 ETH into a deposit contract as collateral against bad behaviour. This helps protect the network because provably dishonet activity leads to some or all of that stake being destroyed. -- In every slot (spaced 6 seconds apart) a validator is randomly selected to be the block proposer. They bundle transactions together, execute them and determine a new 'state'. They wrap this information int a block and pass it around to other validators. +- Validating nodes have to stake 32 ETH into a deposit contract as collateral against bad behavior. This helps protect the network because provably dishonest activity leads to some or all of that stake being destroyed. +- In every slot (spaced twelve seconds apart) a validator is randomly selected to be the block proposer. They bundle transactions together, execute them and determine a new 'state'. They wrap this information into a block and pass it around to other validators. - Other validators who hear about a new block re-execute the transactions to ensure they agree with the proposed change to the global state. Assuming the block is valid they add it to their own database. - If a validator hears about two conflicting blocks for the same slot they use their fork-choice algorithm to pick the one supported by the most staked ETH. @@ -53,12 +53,12 @@ body: an object containing several fields, as defined below The block `body` contains several fields of its own: ``` -randao_reveal: a value used to select the next blockl proposer +randao_reveal: a value used to select the next block proposer eth1_data: information about the deposit contract graffiti: arbitrary data used to tag blocks proposer_slashings: list of validators to be slashed attester_slashings: list of validators to be slashed -attestations: list of attestations in favour of the current block +attestations: list of attestations in favor of the current block deposits: list of new deposits to the deposit contract voluntary_exits: list of validators exiting the network sync_aggregate: subset of validators used to serve light clients @@ -69,7 +69,7 @@ Executing the transactions in the `execution_payload` updates the global state. ## Block time {#block-time} -Block time refers to the time separating blocks. In Ethereum, time is divided up into 6 second units called 'slots'. In each slot a single validator is selected to propose a block. Assuming all validators are online and fully functional there will be a block in every slot, meanign the block time is 6s. However, occasionally validators might be offline when called to propose a block, meaning slots can sometimes go empty. This is different to proof-of-work based systems where block times are probabilistic and tuned by the mining difficulty. +Block time refers to the time separating blocks. In Ethereum, time is divided up into twelve second units called 'slots'. In each slot a single validator is selected to propose a block. Assuming all validators are online and fully functional there will be a block in every slot, meaning the block time is 12s. However, occasionally validators might be offline when called to propose a block, meaning slots can sometimes go empty. This is different to proof-of-work based systems where block times are probabilistic and tuned by the mining difficulty. ## Block size {#block-size} @@ -83,4 +83,4 @@ _Know of a community resource that helped you? Edit this page and add it!_ - [Transactions](/developers/docs/transactions/) - [Gas](/developers/docs/gas/) -- [proof-of-stake](/developers/docs/consensus-mechanisms/pos) +- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos) From 3404039d7adf83bf078deccbdbdd869bc354b699 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Thu, 25 Aug 2022 15:00:04 +0100 Subject: [PATCH 3/4] add execution payload details --- src/content/developers/docs/blocks/index.md | 40 ++++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/src/content/developers/docs/blocks/index.md b/src/content/developers/docs/blocks/index.md index d30d88f13a0..404717b5568 100644 --- a/src/content/developers/docs/blocks/index.md +++ b/src/content/developers/docs/blocks/index.md @@ -65,7 +65,45 @@ sync_aggregate: subset of validators used to serve light clients execution_payload: transactions passed from the execution client ``` -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. +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: + +The `execution_payload_header` contains the following fields: + +``` +parent_hash: hash of the parent block +fee_recipient: account address for paying transaction fees to +state_root: root hash for the global state after applying changes in this block +receipts_root: hash of the transaction receipts trie +logs_bloom: data structure containign event logs +prev_randao: value used in random validator selection +block_number: the number of the current block +gas_limit: maximum gas allowed in this block +gas_used: the actual amount of gas used in this block +timestamp: the block time +extra_data: arbitrary additional data as raw bytes +base_fee_per_gas: the base fee value +block_hash: Hash of execution block +transactions_root: root hash of the transactions in the payload +``` + +The `execution_payload` itself contains the following (notice this is idential to the header except that instead of the root hash of the transactions it includes the actual list of transactions: + +``` +parent_hash: hash of the parent block +fee_recipient: account address for paying transaction fees to +state_root: root hash for the global state after applying changes in this block +receipts_root: hash of the transaction receipts trie +logs_bloom: data structure containign event logs +prev_randao: value used in random validator selection +block_number: the number of the current block +gas_limit: maximum gas allowed in this block +gas_used: the actual amount of gas used in this block +timestamp: the block time +extra_data: arbitrary additional data as raw bytes +base_fee_per_gas: the base fee value +block_hash: Hash of execution block +transactions: list of transactions to be executed +``` ## Block time {#block-time} From 0c48a2f9c16ba19596d78628020bc33bd3ee0079 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Fri, 26 Aug 2022 09:51:56 +0100 Subject: [PATCH 4/4] add attestation data --- src/content/developers/docs/blocks/index.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/src/content/developers/docs/blocks/index.md b/src/content/developers/docs/blocks/index.md index 404717b5568..4495bfa6f8e 100644 --- a/src/content/developers/docs/blocks/index.md +++ b/src/content/developers/docs/blocks/index.md @@ -65,6 +65,24 @@ sync_aggregate: subset of validators used to serve light clients execution_payload: transactions passed from the execution client ``` +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: + +``` +aggregation_bits: a list of which validators participated in this attestation +data: a container with multiple subfields +signature: aggregate signature of all attesting validators +``` + +The `data` field in the `attestation` contains the following: + +``` +slot: the slot the attestation relates to +index: indices for attesting validators +beacon_block_root: the root hash of the Beacon block containing this object +source: the last justified checkpoint +target: the latest epoch boundary block +``` + 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: The `execution_payload_header` contains the following fields: