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 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/