Couple beacon block and blob sidecar for p2p

specs/eip4844/p2p-interface.md

@@ -58,6 +58,14 @@ class SignedBlobsSidecar(Container):
     signature: BLSSignature
 ```
 
+### `SignedBeaconBlockAndBlobsSidecar`
+
+```python
+class SignedBeaconBlockAndBlobsSidecar(Container):
+    beacon_block: SignedBeaconBlock
+    blobs_sidecar: SignedBlobsSidecar
+```
+
 ## The gossip domain: gossipsub
 
 Some gossip meshes are upgraded in the fork of EIP4844 to support upgraded types.
@@ -75,33 +83,25 @@ The new topics along with the type of the `data` field of a gossipsub message ar
 
 | Name | Message Type |
 | - | - |
-| `beacon_block` | `SignedBeaconBlock` (modified) |
-| `blobs_sidecar` | `SignedBlobsSidecar` (new) |
+| `beacon_block_and_blob_sidecar` | `SignedBeaconBlockAndBlobsSidecar` (new) |
 
-Note that the `ForkDigestValue` path segment of the topic separates the old and the new `beacon_block` topics.
 
 #### Global topics
 
-EIP4844 changes the type of the global beacon block topic and introduces a new global topic for blobs-sidecars.
+EIP4844 introduces a new global topic for beacon block and blobs-sidecars.
 
-##### `beacon_block`
+##### `beacon_block_and_blob_sidecar`
 
-The *type* of the payload of this topic changes to the (modified) `SignedBeaconBlock` found in EIP4844.
+This topic is used to propagate new signed and coupled beacon blocks and blobs sidecars to all nodes on the networks.
 
-In addition to the gossip validations for this topic from prior specifications,
-the following validations MUST pass before forwarding the `signed_beacon_block` on the network.
-Alias `block = signed_beacon_block.message`, `execution_payload = block.body.execution_payload`.
+The following validations MUST pass before forwarding the `signed_beacon_block_and_blobs_sidecar` on the network;
+Alias `signed_beacon_block = signed_beacon_block_and_blobs_sidecar.beacon_block`, `block = signed_beacon_block.message`, `execution_payload = block.body.execution_payload`.
 - _[REJECT]_ The KZG commitments of the blobs are all correctly encoded compressed BLS G1 Points.
   -- i.e. `all(bls.KeyValidate(commitment) for commitment in block.body.blob_kzg_commitments)`
 - _[REJECT]_ The KZG commitments correspond to the versioned hashes in the transactions list.
   -- i.e. `verify_kzg_commitments_against_transactions(block.body.execution_payload.transactions, block.body.blob_kzg_commitments)`
 
-##### `blobs_sidecar`
-
-This topic is used to propagate data blobs included in any given beacon block.
-
-The following validations MUST pass before forwarding the `signed_blobs_sidecar` on the network;
-Alias `sidecar = signed_blobs_sidecar.message`.
+Alias `sidecar = signed_beacon_block_and_blobs_sidecar.blobs_sidecar.message`.
 - _[IGNORE]_ the `sidecar.beacon_block_slot` is for the current slot (with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance) -- i.e. `sidecar.beacon_block_slot == current_slot`.
 - _[REJECT]_ the `sidecar.blobs` are all well formatted, i.e. the `BLSFieldElement` in valid range (`x < BLS_MODULUS`).
 - _[REJECT]_ The KZG proof is a correctly encoded compressed BLS G1 Point -- i.e. `bls.KeyValidate(blobs_sidecar.kzg_aggregated_proof)`
@@ -113,10 +113,9 @@ Alias `sidecar = signed_blobs_sidecar.message`.
 - _[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 `sidecar.beacon_block_slot`
 
-Note that a sidecar may be propagated before or after the corresponding beacon block.
-
 Once both sidecar and beacon block are received, `validate_blobs_sidecar` can unlock the data-availability fork-choice dependency.
 
+
 ### Transitioning the gossip
 
 See gossip transition details found in the [Altair document](../altair/p2p-interface.md#transitioning-the-gossip) for