Revert previous changes. Remove optimistic wording

ethereum · Nov 29, 2022 · 339b788 · 339b788
1 parent 3624742
commit 339b788
Show file tree

Hide file tree

Showing 2 changed files with 54 additions and 17 deletions.
diff --git a/specs/eip4844/beacon-chain.md b/specs/eip4844/beacon-chain.md
@@ -23,6 +23,7 @@
 - [Helper functions](#helper-functions)
   - [Misc](#misc)
     - [`validate_blobs_sidecar`](#validate_blobs_sidecar)
+    - [`is_data_available`](#is_data_available)
     - [`kzg_commitment_to_versioned_hash`](#kzg_commitment_to_versioned_hash)
     - [`tx_peek_blob_versioned_hashes`](#tx_peek_blob_versioned_hashes)
     - [`verify_kzg_commitments_against_transactions`](#verify_kzg_commitments_against_transactions)
@@ -161,6 +162,26 @@ def validate_blobs_sidecar(slot: Slot,
     assert verify_aggregate_kzg_proof(blobs, expected_kzg_commitments, kzg_aggregated_proof)
 ```
 
+#### `is_data_available`
+
+The implementation of `is_data_available` is meant to change with later sharding upgrades.
+Initially, it requires every verifying actor to retrieve the matching `BlobsSidecar`,
+and validate the sidecar with `validate_blobs_sidecar`.
+
+The block MUST NOT be considered valid until a valid `BlobsSidecar` has been downloaded.
+
+```python
+def is_data_available(slot: Slot, beacon_block_root: Root, blob_kzg_commitments: Sequence[KZGCommitment]) -> bool:
+    # `retrieve_blobs_sidecar` is implementation dependent, raises an exception if not available.
+    sidecar = retrieve_blobs_sidecar(slot, beacon_block_root)
+    if sidecar == "TEST":
+        return True  # For testing; remove once we have a way to inject `BlobsSidecar` into tests
+    validate_blobs_sidecar(slot, beacon_block_root, blob_kzg_commitments, sidecar)
+
+    return True
+```
+
+
 #### `kzg_commitment_to_versioned_hash`
 
 ```python
@@ -216,6 +237,9 @@ def process_block(state: BeaconState, block: BeaconBlock) -> None:
     process_operations(state, block.body)
     process_sync_aggregate(state, block.body.sync_aggregate)
     process_blob_kzg_commitments(state, block.body)  # [New in EIP-4844]
+
+    # New in EIP-4844
+    assert is_data_available(block.slot, hash_tree_root(block), block.body.blob_kzg_commitments)
 ```
 
 #### Execution payload

diff --git a/specs/eip4844/p2p-interface.md b/specs/eip4844/p2p-interface.md
@@ -10,22 +10,24 @@ The specification of these changes continues in the same format as the network s
 <!-- START doctoc generated TOC please keep comment here to allow auto update -->
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 
-- [Configuration](#configuration)
-- [Containers](#containers)
-  - [`BlobsSidecar`](#blobssidecar)
-  - [`SignedBeaconBlockAndBlobsSidecar`](#signedbeaconblockandblobssidecar)
-- [The gossip domain: gossipsub](#the-gossip-domain-gossipsub)
-  - [Topics and messages](#topics-and-messages)
-    - [Global topics](#global-topics)
-      - [`beacon_block`](#beacon_block)
-      - [`beacon_block_and_blobs_sidecar`](#beacon_block_and_blobs_sidecar)
-  - [Transitioning the gossip](#transitioning-the-gossip)
-- [The Req/Resp domain](#the-reqresp-domain)
-  - [Messages](#messages)
-    - [BeaconBlocksByRange v2](#beaconblocksbyrange-v2)
-    - [BeaconBlocksByRoot v2](#beaconblocksbyroot-v2)
-    - [BeaconBlockAndBlobsSidecarByRoot v1](#beaconblockandblobssidecarbyroot-v1)
-    - [BlobsSidecarsByRange v1](#blobssidecarsbyrange-v1)
+  - [Configuration](#configuration)
+  - [Containers](#containers)
+    - [`BlobsSidecar`](#blobssidecar)
+    - [`SignedBeaconBlockAndBlobsSidecar`](#signedbeaconblockandblobssidecar)
+  - [The gossip domain: gossipsub](#the-gossip-domain-gossipsub)
+    - [Topics and messages](#topics-and-messages)
+      - [Global topics](#global-topics)
+        - [`beacon_block`](#beacon_block)
+        - [`beacon_block_and_blobs_sidecar`](#beacon_block_and_blobs_sidecar)
+    - [Transitioning the gossip](#transitioning-the-gossip)
+  - [The Req/Resp domain](#the-reqresp-domain)
+    - [Messages](#messages)
+      - [BeaconBlocksByRange v2](#beaconblocksbyrange-v2)
+      - [BeaconBlocksByRoot v2](#beaconblocksbyroot-v2)
+      - [BeaconBlockAndBlobsSidecarByRoot v1](#beaconblockandblobssidecarbyroot-v1)
+      - [BlobsSidecarsByRange v1](#blobssidecarsbyrange-v1)
+- [Design decision rationale](#design-decision-rationale)
+  - [Why are blobs relayed as a sidecar, separate from beacon blocks?](#why-are-blobs-relayed-as-a-sidecar-separate-from-beacon-blocks)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 <!-- /TOC -->
@@ -257,4 +259,15 @@ Of note, blocks from slots before the finalization MUST lead to the finalized bl
 Clients MUST respond with blobs sidecars that are consistent from a single chain within the context of the request.
 
 After the initial blobs sidecar, clients MAY stop in the process of responding
-if their fork choice changes the view of the chain in the context of the request.
+if their fork choice changes the view of the chain in the context of the request.
+
+# Design decision rationale
+
+## Why are blobs relayed as a sidecar, separate from beacon blocks?
+
+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.
+
+Such sharding design may introduce an updated `BlobsSidecar` to identify the shard,
+but does not affect the `BeaconBlock` structure.