Merge 366b28a into b3e1657

ethereum · Mar 4, 2023 · bb8db28 · bb8db28
2 parents b3e1657 + 366b28a
commit bb8db28
Showing 1 changed file with 12 additions and 10 deletions.
diff --git a/EIPS/eip-4844.md b/EIPS/eip-4844.md
@@ -54,6 +54,7 @@ Compared to full data sharding, this EIP has a reduced cap on the number of thes
 | `MAX_ACCESS_LIST_SIZE` | `2**24` |
 | `MAX_ACCESS_LIST_STORAGE_KEYS` | `2**24` |
 | `MAX_TX_WRAP_KZG_COMMITMENTS` | `2**12` |
+| `MAX_TX_WRAP_KZG_PROOFS` | `2**12` |
 | `LIMIT_BLOBS_PER_TX` | `2**12` |
 | `DATA_GAS_PER_BLOB` | `2**17` |
 | `HASH_OPCODE_BYTE` | `Bytes1(0x49)` |
@@ -71,12 +72,12 @@ Compared to full data sharding, this EIP has a reduced cap on the number of thes
 
 ### Cryptographic Helpers
 
-Throughout this proposal we use cryptographic methods and classes defined in the corresponding [consensus 4844 specs](https://github.com/ethereum/consensus-specs/blob/23d3aeebba3b5da0df4bd25108461b442199f406/specs/eip4844).
+Throughout this proposal we use cryptographic methods and classes defined in the corresponding [consensus 4844 specs](https://github.com/ethereum/consensus-specs/tree/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb).
 
-Specifically, we use the following methods from [`polynomial-commitments.md`](https://github.com/ethereum/consensus-specs/blob/23d3aeebba3b5da0df4bd25108461b442199f406/specs/eip4844/polynomial-commitments.md):
+Specifically, we use the following methods from [`polynomial-commitments.md`](https://github.com/ethereum/consensus-specs/blob/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb/polynomial-commitments.md):
 
-- [`verify_kzg_proof()`](https://github.com/ethereum/consensus-specs/blob/23d3aeebba3b5da0df4bd25108461b442199f406/specs/eip4844/polynomial-commitments.md#verify_kzg_proof)
-- [`verify_aggregate_kzg_proof()`](https://github.com/ethereum/consensus-specs/blob/23d3aeebba3b5da0df4bd25108461b442199f406/specs/eip4844/polynomial-commitments.md#verify_aggregate_kzg_proof)
+- [`verify_kzg_proof()`](https://github.com/ethereum/consensus-specs/blob/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb/polynomial-commitments.md#verify_kzg_proof)
+- [`verify_kzg_proof_batch()`](https://github.com/ethereum/consensus-specs/blob/86fb82b221474cc89387fa6436806507b3849d88/specs/deneb/polynomial-commitments.md#verify_kzg_proof_batch)
 
 ### Helpers
 
@@ -150,12 +151,12 @@ The `TransactionNetworkPayload` wraps a `TransactionPayload` with additional dat
 this wrapping data SHOULD be verified directly before or after signature verification.
 
 When a blob transaction is passed through the network (see the [Networking](#networking) section below),
-the `TransactionNetworkPayload` version of the transaction also includes `blobs` and `kzgs` (commitments list).
+the `TransactionNetworkPayload` version of the transaction also includes `blobs`, `kzgs` (commitments list) and `proofs`.
 The execution layer verifies the wrapper validity against the inner `TransactionPayload` after signature verification as:
 
 - All hashes in `blob_versioned_hashes` must start with the byte `BLOB_COMMITMENT_VERSION_KZG`
 - There may be at most `MAX_DATA_GAS_PER_BLOCK // DATA_GAS_PER_BLOB` total blob commitments in a valid block.
-- There is an equal amount of versioned hashes, kzg commitments and blobs.
+- There is an equal amount of versioned hashes, kzg commitments, blobs and proofs.
 - The KZG commitments hash to the versioned hashes, i.e. `kzg_to_versioned_hash(kzg[i]) == versioned_hash[i]`
 - The KZG commitments match the blob contents. (Note: this can be optimized with additional data, using a proof for a
   random evaluation at two points derived from the commitment and blob data)
@@ -228,7 +229,7 @@ For the first post-fork block, `parent.excess_data_gas` is evaluated as `0`.
 ### Beacon chain validation
 
 On the consensus-layer the blobs are now referenced, but not fully encoded, in the beacon block body.
-Instead of embedding the full contents in the body, the contents of the blobs are propagated separately, as a "sidecar".
+Instead of embedding the full contents in the body, the blobs are propagated separately, as a "sidecar".
 
 This "sidecar" design provides forward compatibility for further data increases by black-boxing `is_data_available()`:
 with full sharding `is_data_available()` can be replaced by data-availability-sampling (DAS) thus avoiding all blobs being downloaded by all beacon nodes on the network.
@@ -334,7 +335,7 @@ class BlobTransactionNetworkWrapper(Container):
     # BLSFieldElement = uint256
     blobs: List[Vector[BLSFieldElement, FIELD_ELEMENTS_PER_BLOB], LIMIT_BLOBS_PER_TX]
     # KZGProof = Bytes48
-    kzg_aggregated_proof: KZGProof
+    blob_proofs: List[KZGProof, MAX_TX_WRAP_KZG_PROOFS]
 ```
 
 We do network-level validation of `BlobTransactionNetworkWrapper` objects as follows:
@@ -344,11 +345,12 @@ def validate_blob_transaction_wrapper(wrapper: BlobTransactionNetworkWrapper):
     versioned_hashes = wrapper.tx.message.blob_versioned_hashes
     commitments = wrapper.blob_kzgs
     blobs = wrapper.blobs
+    proofs = wrapper.blob_proofs
     # note: assert blobs are not malformatted
     assert len(versioned_hashes) == len(commitments) == len(blobs)
 
-    # Verify that commitments match the blobs by checking the KZG proof
-    assert verify_aggregate_kzg_proof(blobs, commitments, wrapper.kzg_aggregated_proof)
+    # Verify that commitments match the blobs by checking the KZG proofs
+    assert verify_blob_kzg_proof_batch(blobs, commitments, proofs)
 
     # Now that all commitments have been verified, check that versioned_hashes matches the commitments
     for versioned_hash, commitment in zip(versioned_hashes, commitments):