diff --git a/specs/eip4844/beacon-chain.md b/specs/eip4844/beacon-chain.md
index 600793a3f..94aa665a6 100644
--- a/specs/eip4844/beacon-chain.md
+++ b/specs/eip4844/beacon-chain.md
@@ -23,7 +23,6 @@
 - [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)
@@ -162,27 +161,6 @@ 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`.
-
-Without the sidecar the block may be processed further optimistically,
-but 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
@@ -238,9 +216,6 @@ 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, note: Can sync optimistically without this condition, see note on `is_data_available`
-    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
index f031b3723..bbd18e34c 100644
--- a/specs/eip4844/p2p-interface.md
+++ b/specs/eip4844/p2p-interface.md
@@ -10,24 +10,22 @@ 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)
-- [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)
+- [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)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 <!-- /TOC -->
@@ -259,15 +257,4 @@ 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.
-
-# 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.
+if their fork choice changes the view of the chain in the context of the request.
\ No newline at end of file