From 45e207be4d99247c9b33fb5a44a0bdc038b2d945 Mon Sep 17 00:00:00 2001 From: protolambda Date: Mon, 14 Mar 2022 18:54:54 +0100 Subject: [PATCH] EIP-4844 consensus-specs review fixes Co-Authored-By: terenc3t Co-Authored-By: djrtwo --- specs/bellatrix/p2p-interface.md | 2 +- specs/eip4844/beacon-chain.md | 43 +++++++++++++++++++++++++------- specs/eip4844/p2p-interface.md | 18 ++++++------- specs/eip4844/validator.md | 7 +++--- 4 files changed, 45 insertions(+), 25 deletions(-) diff --git a/specs/bellatrix/p2p-interface.md b/specs/bellatrix/p2p-interface.md index 60a9be774..21badce83 100644 --- a/specs/bellatrix/p2p-interface.md +++ b/specs/bellatrix/p2p-interface.md @@ -110,7 +110,7 @@ The following gossip validation from prior specifications MUST NOT be applied if ### Transitioning the gossip See gossip transition details found in the [Altair document](../altair/p2p-interface.md#transitioning-the-gossip) for -details on how to handle transitioning gossip topics for Bellatrix. +details on how to handle transitioning gossip topics for EIP-4844. ## The Req/Resp domain diff --git a/specs/eip4844/beacon-chain.md b/specs/eip4844/beacon-chain.md index 4ac7cf3d1..1bcab3a98 100644 --- a/specs/eip4844/beacon-chain.md +++ b/specs/eip4844/beacon-chain.md @@ -31,10 +31,7 @@ ## Introduction -This upgrade adds transaction execution to the beacon chain as part of Bellatrix upgrade. - -Additionally, this upgrade introduces the following minor changes: -* Penalty parameter updates to their planned maximally punitive values +This upgrade adds blobs to the beacon chain as part of EIP-4844. ## Custom types @@ -53,6 +50,11 @@ Additionally, this upgrade introduces the following minor changes: | `FIELD_ELEMENTS_PER_BLOB` | `4096` | | `BLS_MODULUS` | `52435875175126190479447740508185965837690552500527637822603658699938581184513` | +### Domain types + +| Name | Value | +| - | - | +| `DOMAIN_BLOBS_SIDECAR` | `DomainType('0x0a000000')` | ## Preset @@ -91,11 +93,36 @@ class BeaconBlockBody(Container): sync_aggregate: SyncAggregate # Execution execution_payload: ExecutionPayload - blob_kzgs: List[KZGCommitment, MAX_OBJECT_LIST_SIZE] # [New in EIP-4844] + blob_kzgs: List[KZGCommitment, MAX_BLOBS_PER_BLOCK] # [New in EIP-4844] ``` ## Helper functions +### KZG core + +KZG core functions. These are also defined in EIP-4844 execution specs. + +#### `blob_to_kzg` + +```python +def blob_to_kzg(blob: Blob) -> KZGCommitment: + computed_kzg = bls.Z1 + for value, point_kzg in zip(blob, KZG_SETUP_LAGRANGE): + assert value < BLS_MODULUS + computed_kzg = bls.add( + computed_kzg, + bls.multiply(point_kzg, value) + ) + return computed_kzg +``` + +#### `kzg_to_versioned_hash` + +```python +def kzg_to_versioned_hash(kzg: KZGCommitment) -> VersionedHash: + return BLOB_COMMITMENT_VERSION_KZG + hash(kzg)[1:] +``` + ### Misc #### `tx_peek_blob_versioned_hashes` @@ -120,9 +147,7 @@ def verify_kzgs_against_transactions(transactions: Sequence[Transaction], blob_k for tx in transactions: if opaque_tx[0] == BLOB_TX_TYPE: all_versioned_hashes.extend(tx_peek_blob_versioned_hashes(tx)) - return all_versioned_hashes == [ - kzg_to_versioned_hash(kzg) for kzg in blob_kzgs - ] + return all_versioned_hashes == [ksg_to_version_hash(kzg) for kzg in blob_kzgs] ``` ## Beacon chain state transition function @@ -138,7 +163,7 @@ def process_block(state: BeaconState, block: BeaconBlock) -> None: process_eth1_data(state, block.body) process_operations(state, block.body) process_sync_aggregate(state, block.body.sync_aggregate) - process_blob_kzgs(state, block.body) # [New in EIP-4844] + process_blob_kzgs(state, block.body) # [New in EIP-4844] ``` #### Blob KZGs diff --git a/specs/eip4844/p2p-interface.md b/specs/eip4844/p2p-interface.md index 6b3ac9bc9..ff2a11e25 100644 --- a/specs/eip4844/p2p-interface.md +++ b/specs/eip4844/p2p-interface.md @@ -37,13 +37,13 @@ The specification of these changes continues in the same format as the network s | Name | Value | | - | - | -| `LIMIT_BLOBS_PER_SIDECAR` | `uint64(2**4)` (= 16) | +| `MAX_BLOBS_PER_BLOCK` | `uint64(2**4)` (= 16) | ## Configuration | Name | Value | Description | |------------------------------------------|-------------------------------|---------------------------------------------------------------------| -| `MAX_REQUEST_BLOBS_SIDECARS` | `2**10` (= 1024) | Maximum number of blobs sidecars in a single request | +| `MAX_REQUEST_BLOBS_SIDECARS` | `2**7` (= 128) | Maximum number of blobs sidecars in a single request | | `MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS` | `2**13` (= 8192, ~1.2 months) | The minimum epoch range over which a node must serve blobs sidecars | @@ -56,8 +56,7 @@ The specification of these changes continues in the same format as the network s class BlobsSidecar(Container): beacon_block_root: Root beacon_block_slot: Slot - shard: uint64 # [ Forward compatibility ] - blobs: List[Blob, LIMIT_BLOBS_PER_SIDECAR] + blobs: List[Blob, MAX_BLOBS_PER_BLOCK] ``` ### `SignedBlobsSidecar` @@ -117,12 +116,12 @@ Alias `sidecar = signed_blobs_sidecar.message`. - _[REJECT]_ the `sidecar.blobs` are all well formatted, i.e. the `BLSFieldElement` in valid range (`x < BLS_MODULUS`). - _[REJECT]_ the beacon proposer signature, `signed_blobs_sidecar.signature`, is valid -- i.e. ```python -domain = get_domain(state, DOMAIN_BLOBS_SIDECAR, blobs_sidecar.beacon_block_slot / SLOTS_PER_EPOCH) +domain = get_domain(state, DOMAIN_BLOBS_SIDECAR, blobs_sidecar.beacon_block_slot // SLOTS_PER_EPOCH) signing_root = compute_signing_root(blobs_sidecar, domain) assert bls.Verify(proposer_pubkey, signing_root, signed_blob_header.signature) ``` where `proposer_pubkey` is the pubkey of the beacon block proposer of `blobs_sidecar.beacon_block_slot` -- _[IGNORE]_ The sidecar is the first sidecar with valid signature received for the `(proposer_index, sidecar.beacon_block_root)` combination, +- _[IGNORE]_ The sidecar is the first sidecar with valid signature received for the `(proposer_index, sidecar.beacon_block_slot)` combination, where `proposer_index` is the validator index of the beacon block proposer of `blobs_sidecar.beacon_block_slot` Note that a sidecar may be propagated before or after the corresponding beacon block. @@ -132,7 +131,7 @@ Once both sidecar and beacon block are received, `verify_blobs_sidecar` can unlo ### Transitioning the gossip See gossip transition details found in the [Altair document](../altair/p2p-interface.md#transitioning-the-gossip) for -details on how to handle transitioning gossip topics for Bellatrix. +details on how to handle transitioning gossip topics for this upgrade. ## The Req/Resp domain @@ -181,7 +180,6 @@ Request Content: ( start_slot: Slot count: uint64 - shard: uint64 ) ``` @@ -195,8 +193,6 @@ Response Content: Requests blobs sidecars in the slot range `[start_slot, start_slot + count)`, leading up to the current head block as selected by fork choice. -The request and response format is forward-compatible with sharded sidecar sync, but MUST enforce `shard == 0` for now. - The response is unsigned, i.e. `BlobsSidecarsByRange`, as the signature of the beacon block proposer may not be available beyond the initial distribution via gossip. @@ -232,7 +228,7 @@ participating in the networking immediately, other peers MAY disconnect and/or temporarily ban such an un-synced or semi-synced client. Clients MUST respond with at least the first blobs sidecar that exists in the range, if they have it, -and no more than `MAX_REQUEST_BLOBS_SIDECARS` blocks. +and no more than `MAX_REQUEST_BLOBS_SIDECARS` sidecars. The following blobs sidecars, where they exist, MUST be sent in consecutive order. diff --git a/specs/eip4844/validator.md b/specs/eip4844/validator.md index 0bdf947ba..2a1c0a24a 100644 --- a/specs/eip4844/validator.md +++ b/specs/eip4844/validator.md @@ -28,7 +28,7 @@ This document represents the changes to be made in the code of an "honest valida ## Prerequisites -This document is an extension of the [Bellatrix -- Honest Validator](../altair/validator.md) guide. +This document is an extension of the [Bellatrix -- Honest Validator](../bellatrix/validator.md) guide. All behaviors and definitions defined in this document, and documents it extends, carry over unless explicitly noted or overridden. All terminology, constants, functions, and protocol mechanics defined in the updated [Beacon Chain doc of EIP4844](./beacon-chain.md) are requisite for this document and used throughout. @@ -56,13 +56,12 @@ def is_data_available(slot: Slot, beacon_block_root: Root, kzgs: Sequence[KZGCom ```python def verify_blobs_sidecar(slot: Slot, beacon_block_root: Root, expected_kzgs: Sequence[KZGCommitment], blobs_sidecar: BlobsSidecar): - assert blobs_sidecar.shard == 0 # always zero, placeholder for future sharding assert slot == blobs_sidecar.beacon_block_slot assert beacon_block_root == blobs_sidecar.beacon_block_root blobs = blobs_sidecar.blobs assert len(kzgs) == len(blobs) for kzg, blob in zip(expected_kzgs, blobs): - assert blob_to_kzg(blob) == kzg + assert blob_to_kzg(blob) == kzg ``` @@ -81,7 +80,7 @@ After retrieving the execution payload from the execution engine as specified in the blobs are retrieved and processed: ```python -# execution_payload = xecution_engine.get_payload(payload_id) +# execution_payload = execution_engine.get_payload(payload_id) # block.body.execution_payload = execution_payload # ...