EIP-4844 consensus-specs review fixes

Co-Authored-By: terenc3t <terence@prysmaticlabs.com>
Co-Authored-By: djrtwo <dannyjryan@gmail.com>

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
 

specs/eip4844/beacon-chain.md

@@ -31,10 +31,7 @@
 
 ## Introduction
 
-This upgrade adds transaction execution to the beacon chain as part of Bellatrix upgrade.
+This upgrade adds blobs to the beacon chain as part of EIP-4844.
-
-Additionally, this upgrade introduces the following minor changes:
-* Penalty parameter updates to their planned maximally punitive values
 
 ## 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 == [
+   return all_versioned_hashes == [ksg_to_version_hash(kzg) for kzg in blob_kzgs]
-      kzg_to_versioned_hash(kzg) for kzg in blob_kzgs
-   ]
 ```
 
 ## Beacon chain state transition function

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, MAX_BLOBS_PER_BLOCK]
-    blobs: List[Blob, LIMIT_BLOBS_PER_SIDECAR]
 ```
 
 ### `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.
 

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,7 +56,6 @@ 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
@@ -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
 # ...