Overview

Context

The current PeerDAS design can potentially yield an 8x increase in blob capacity over Protodanksharding. It does so by introducing Reed-Solomon erasure coding with a 1:1 ratio, a matrix data layout consisting of 128 columns x # blob rows, partial deterministic custody requirements for every CL node, and sampling verification processes. If max blobs is 9, PeerDAS expands the capacity to 72 while keeping the storage requirements per node intact, in exchange for higher computational footprint for proposers, higher networking complexity, and additional synchronous checks for validators.

Risks

There are currently two bottlenecks and risks to achieving the full potential of PeerDAS to the desired scale:

1. EL mempool propagation: blobs continue to be fully propagated, resulting in a linear network traffic increase with an associated increase in bandwidth requirements (assuming lazy push gossip and ignoring the announcement overhead).
2. Additional synchronous computational and propagation work required by all participants within tight timing conditions (within the 4s propagation hot path).

Proposed changes

This proposal introduces two changes to the current PeerDAS design to pave the way for the targeted scale:

1. A sparse blobpool.
2. Cell staging ahead of time.

Goals

With these changes, we aim to:

1. Make EL mempool propagation sublinear while ensuring every node has access to the full blob payload at all times.
2. Offload the computational and distribution work from the critical path to derisk stability of block validation.

Proposal 1: Sparse blobpool