Faster block/blob propagation in Ethereum

In general, any mechanism we settle on to propagate blocks faster should aim to: (a) saturate all mesh paths in parallel, (b) utilize all available bandwidth, (c) maximize efficiency by transmitting unique information, (d) ensure we only handle authenticated chunks.

At a network level, we should favour packets sized below path MTU to prevent IP fragmentation. Because we now deal with smaller propagation units and built-in data erasure coding redundancy, we can use QUIC (unreliable) datagrams with larger fanouts experimenting with various routing strategies (e.g. chaotic/random, latency-centric, etc.) to enable burstier parallel transmission (up to the bandwidth limits in EIP-7870). We can also leverage QUIC session resumption to “warm up” connections with a large set of peers ahead of time, to later dispatch packets rapidly with 0-RTT under a reestablished secure channel.

Unfortunately, using large fields with RLNC to enable commitments narrows down the parameter space significantly, to the extent that none of the above is possible due to coefficient overhead.

There are other directions in the design space I’m keen to explore. Here are a few that seem conceptually promising and worthwhile.

  1. Rateless/fountain codes like RaptorQ (RFC6330) with source-authenticated packets carrying signatures over the index + packet. The key problem is knowing when producers should stop seeding packets. We have a built-in feedback loop: attestation arrival. Valid attestations indicate peers successfully reconstructed the original payload, and can assist others in converging. We could set dynamic % thresholds over the expected attestations on subscribed subnets. Though CL clients attest at different times, efforts exist to normalize this to “as soon as a valid block is seen”.

  2. Traditional/systematic Reed-Solomon with source-authenticated packets, opportunistically piggybacking availability bitmaps for pair-wise set reconciliation. This prevents duplicate transfers at the cost of bitmap overhead (reducible with RLE/Roaring compression). The main challenge is parameter optimization, concretely balancing RS redundancy, bitmap overhead, peer parallelism, and set reconciliation behavior.

  3. Rateless IBLTs for mempool-aware block propagation. This reconciles incoming blocks against local mempool contents, transmitting only missing transactions. Given ~60% public transactions in blocks, this method could achieve 1.35x communication overhead relative to private/missing transactions (40%), potentially reducing block propagation bandwidth considerably. A peer could likely reuse the local symbol set across all its peers, though we need extra research on parallelization across peers. That said, there is a privacy consideration. While devp2p announces txs that may be dropped later, this algorithm could reveal current mempool state, which adversaries could theoretically exploit. However, the bandwidth and latency improvements may justify this tradeoff.

We’re working on prototyping (1) and (2) in the p2p networking team at the EF – we’ll have more to share in the coming weeks!

3 Likes