1. # Design notes for decoupled EIP4844

## WIP implementation

https://github.com/status-im/nimbus-eth2/pull/4550

## What this solves

The maximum block size is 1.8 MB - depending on who you ask, the blob adds another 128-1024kb on top of that. Data takes time to stream: 1mb on 10mbit = 1 s of streaming - we maintain a gossip mesh of ~8 peers, meaning that if we do nothing else, we need to both send and receive 8x the block+blob amount under time pressure, which is a lot to ask.

Core to the problem is that the block processing can be done independently of the blob - the situation is similar to how the execution processing can be done independently of the consensus processing.

Practically, it means that we can process the block, start gossiping it then process the blob, parallelizing utilization of both block and blob.

## Why 10 mbit

10mbit does not mean that the connection is limited to 10mbit: it means that with other things going on (such as sending the data to 8 peers), on the same connection (attestation traffic, transactions etc etc), 10mbit is a good conservative target.

## Advantages

4 main advantages:

* better utilisation of incoming / outgoing bandwith by "starting" the send earlier and overlapping sending one part while still receiving the other -> this lowers latency at every hop
* better utilisation of high-bandwidth peers due to non-overlapping meshes / separate topics -> fast peers can send "full" data to a more diverse set of peers more quickly -> lowers global latency, improves bandwidth usage
* parallelisation of signauture/commitment verification - less overlap for compute resource on each node -> faster "gossip ok" -> lowers latency
* better "lazy sending", where you don't "resend" data to peers that already sent the same data to you -> works better at smaller granularity due to timing effects between sending and receiving -> significantly lower bandwidth usage (even without episub)

## Future compatiblity / performance

the last points in terms of optimization opportunities we discussed with @proto are [](https://)amplified if instead of sending all blobs in a single sidecar, each blob is sent individually - this gives a "natural" way to grow the number of blobs / block, because we simply send on more topics and, this is the significant point, don't add to the serial "load" - they only add parallel load

## Architectural similarity / complexity

The architectural complexity resides in two places:

* adapting the optimistic sync mode to handle blobless blocks
* quarantine of blockless blobs (similar to block-less attestations)

We already have "similar" code in place: blocks are partially validated and gossiped "optmistically", attestations are "batched" for efficient signature verification meaning we have "delayed sending" and "overflow protection" in place, and have a one-way dependency on the block, etc - this adds very little "new" complexity to any current CL implementation

## Similarities with optimistic sync

A block without blob is semantically similar to a block without `VALID` execution payload.

* Similar head behavior - until sidecar has arrived, the block is essentially optimistic
* Need to keep track of last-know-good-head since the optimistic head while waiting for blob is short-lived
* REST API: report last-known-good if exists within reasonable time range (1 slot?) allowing validators to continue to operate as if the sidecar-less-block didn't exist

## Networking optimisations

* Protect the blobs by a proposer signature to prevent spam
* Include libp2p message ID early in stream to allow cancelling "in-flight streams" of blobs, should we already receive the same block/blob from someone else.

# Design notes

Past design notes: https://notes.ethereum.org/RLOGb1hYQ0aWt3hcVgzhgQ?

## One blob per sidecar

* more efficient propagation
* parallelized growth path when adding more blobs
* needs proposer signature on every blob
* Decouples by-root request to allow downloading individual blobs (without proposer signature)
* Turns sidecars into an almost-only additive proposal, in terms of having new requests and gossip topics for all functionality
* Potential network split: a proposer may send different sidecars to different peers - if we have a "seen-first" strategy, this may split the network
* How to fix: on block receipt, drop invalid blobs and clear seen flag so that the correct blob can propagate via gossip, alternatively request via `BlobSidecarsByRoot`

class BlobSidecar(Container):
    beacon_block_root: Root
    beacon_block_slot: Slot
    proposer_index: ValidatorIndex
    blob_index: uint64 # We need the index of the blob, otherwise we cannot do the gossip protections
    block_parent_root: Root
        ## For verifying the fork of the proposer_index
        ## TODO: dependent_root? Less information but also less sensitive to reorgs
    blob: Blob
    kzg_commitment: KZGCommitment
    kzg_proof: KZGProof # Allows for quick verification of kzg_commitment
        ## TODO: aggregation receiver-side?
        ## TODO: consider aggregate proof in first sidecar

class SignedBlobSidecar(Container):
    message: BlobSidecar
    signature: Signature

## P2P

* remove global sidecar topic

* Clients are expected to form a mesh for all sidecar topics, in addition to the regular `beacon_block` topic

### Topics and messages

Topics follow the same specification as in prior upgrades.

The new topics along with the type of the `data` field of a gossipsub message are given in this table:

| Name | Message Type |
| - | - |
| `blobs_sidecar_#` | `SignedBlobSidecar` (new) |

`#` denotes the index of the sidecar in the corresponding block

##### `blobs_sidecar`

This topic is used to propagate blobs sidecars to all nodes on the networks.

The following validations MUST pass before forwarding the `signed_sidecar` on the network.

Alias `sidecar = signed_sidecar.message`.
- _[IGNORE]_ the `sidecar.beacon_block_slot` is for the ~~current slot (with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance)~~ within 32 slots
- TODO: duplicate block condition / retention)
-- i.e. `sidecar.beacon_block_slot == block.slot`.
- _[IGNORE]_ the `sidecar.proposer_index` matches the expected proposer based on `sidecar.block_parent_root`
- TODO: dependent_root?
- TODO: skip this check completely? allows "not knowing" the fork if proposer_index matches local view, however penalises forking
- _[REJECT] Proposer signature doesn't match (TODO phrase same as block)
- _[IGNORE]_ the tuple `(sidecar.beacon_block_slot, sidecar.proposer_index, sidecar.blob_index)` has never been seen
- _[REJECT] `blob_index` matches topic (TODO phrase same as attestation)
- ~~_[REJECT]_ The KZG commitments in the block are valid against the provided blobs sidecar
-- i.e. `validate_blobs_sidecar(block.slot, hash_tree_root(block), block.body.blob_kzg_commitments, sidecar)`~~

#### BlobSidecarByRoot v1

**Protocol ID:** `/eth2/beacon_chain/req/blobs_sidecar_by_root/1/`

Request Content:

class BlobSidecarRequest(Container):
    beacon_block_root: Root
    blob_index: uint64
    

(
  List[BlobSidecarRequest, MAX_REQUEST_BLOCKS]
)

Response Content:

(
  List[BlobSidecar, MAX_REQUEST_BLOCKS]
)

Requests blobs by block root and blob index (= `hash_tree_root(SignedBeaconBlock.beacon_block.message)`).
The response is a list of `BlobSidecar` whose length is less than or equal to the number of requests.
It may be less in the case that the responding peer is missing sidecars.

No more than `MAX_REQUEST_BLOCKS` may be requested at a time.

`BeaconBlockAndBlobSidecarByRoot` is primarily used to recover recent sidecars (e.g. when receiving a sidecar that did not arrive on the sidecar gossip topic).

The response MUST consist of zero or more `response_chunk`.
Each _successful_ `response_chunk` MUST contain a single `BlobSidecar` payload.

Clients MUST support requesting blocks and sidecars since `minimum_request_epoch`, where `minimum_request_epoch = max(finalized_epoch, current_epoch - MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS, EIP4844_FORK_EPOCH)`. If any root in the request content references a block earlier than `minimum_request_epoch`, peers SHOULD respond with error code `3: ResourceUnavailable`.

Clients MUST respond with at least one block and sidecar, if they have it.
Clients MAY limit the number of blocks and sidecars in the response.

#### BlobsSidecarsByRange v1

**Protocol ID:** `/eth2/beacon_chain/req/blobs_sidecars_by_range/1/`

Request Content:

(
  start_slot: Slot
  count: uint64
)

Response Content:

class BlobSidecars(Container):
    sidecars: List[BlobSidecar, MAX_BLOBS_PER_BLOCK] # TODO verify constant name

(
  List[BlobSidecars, MAX_REQUEST_BLOBS_SIDECARS]
)