It is that time of the year in which I post about my personal interests, or rather wish lists, for Ethereum. I have already tried this topic before and will touch on that below, but before we get into the weeds of technicalities (actually I promised this post will be very short and to the point so there won’t be many) let’s get right to what this post is about:

The time Ethereum messages spend on the wire is wasted time.

We therefore want to spend the least amount of time broadcasting messages. The time we gain from communicating faster can be used in other ways:

  • We can communicate larger objects: more transactions per second, lower gas cost to transact, more blobs per second, even cheaper L2s, etc.
  • We can communicate more often: shorter slots, lower latency for inclusion, less price drift with other markets, etc.
  • We can be more resilient: less forkchoice split views, less missed slots, etc.

Whatever we decide to do with that time is up to us, but don’t be mistaken, whatever we do is better than wasting it. There is one tradeoff though and that is that attempts for faster propagation all come with more protocol complexity. This post is about the proposal with a minimal impact, which although I do not claim is small, it is a no-brainer that it is worth it.

Chunked broadcast and fucked up patents.

All approaches I know to propagate larger blocks in less time have something in common: break the object in pieces and broadcast each piece separately. Each piece will follow different paths to reach the same peer but the whole point is that they travel in parallel and they maximize bandwidth utilization, if you receive twice the same piece, well, you wasted that piece’s data over the wire, but only that piece, not the whole payload.

Chunked block broadcast

There is an optimal way of avoiding duplication of these chunks, and that is the one of randomly mixing them, this way, if you break the original payload in N chunks and each peer randomly mixes the chunks it has before rebroadcasting, peers are a) very unlikely to get twice the same chunk, or any useless chunk and b) after receiving any N of them they can recover the whole payload with a high degree of probability.

Unfortunately that field is covered by horrible patents that unfortunately prevent humanity from using classical literature or even linear algebra for a public good. Even though the original papers did not include additive commitments for origin validation as my post above did (I will credit Krohn and Freedman for an early appearance of additive hash functions for this, but surely someone will claim an earlier paper and after a few iterations we will fix this reference here. For example, I hope I don’t offend R. Gennaro, whose 1997 paper on Secure Distributed Storage and Retrieval already uses additive hashing for a slightly different purpose) lawyers are scared, companies do not want to deal with this, and ultimately, developers’ salaries have to come from places that aren’t afraid of going under a lawsuit.

So we could go with a very simple option, just chunk it and broadcast separately these chunks. As said above, this already shows quite some gains in broadcast time.

The complexity cost and erasure coding.

As soon as we decide to chunk the payload and broadcast many small pieces instead of a single large one, we already pay the complexity cost. The problem we have in Ethereum is that we need to be certain that any object traveling over the wire was a) sent by the rightful participant that was supposed to send a message and b) was not tampered over the wire. We can solve this in many ways,

  • Sign each chunk. The verifier needs to verify a signature and broadcast.
  • Use KZG commitments or any other type of commitment. The signer needs to produce proofs and the verifier just verifies the KZG proof which is faster than a signature.
  • Use Merkle proofs to a committed root. Verifier verifies a Merkle proof which is faster than the signature, sender needs to prepare the proofs which is faster than the KZG commitment, but depending on the number of chunks each chunk now comes with more data, the Merkle proof itself.

Whatever we do, it requires changing the way we verify payloads in the case at hand and how they are prepared and broadcast. There’s no way around it, this is the complexity cost. However, what we see is that we can then do more than chunking for free. We could apply any erasure coding technique, again I would have liked to use RLNC, but that ship has sailed. So let’s go with the second best option:

Let’s split the payload in k chunks, enlarge them to N > k chunks by Reed Solomon encoding, so that any k chunks from the group of N recovers the full payload, and use any of the verification systems above to broadcast the payload.

This way we start to really gain from better bandwidth utilization.

Subnets or not.

We already broadcast chunked objects in Ethereum. Data column sidecars are just parts of the whole data in the block. One can assemble the original blob data from just any 64 columns out of the 128. These messages travel in separate subnets. The existence of these subnets serves a purpose and comes with a separate tradeoff in itself. On the one hand, it reduces duplication, you know that you will not be getting useless columns if you register to some of them and aren’t listening on other subnets. It also helps in allowing clients to keep less data, validators do not need to custody all of the data in the block, as long as the chain collectively custodies the data, we satisfy the rollups’ safety mechanism. We thus allow validators to just listen to some and not all of the column subnets, and we split the subnets evenly to minimize bandwidth utilization.

On the other hand, the problem subnets come with is, again, complexity! Validators need to subscribe to these topics, need to find peers, administer them, rotate them, etc.

For the topic of the execution payload all validators need to get the whole data anyway, so subnets don’t serve the purpose above. We can simply broadcast the chunks on a single topic because everyone can and has to get every chunk needed to recover the full payload.

Subnets do serve a purpose though, and they can serve a purpose in the future too. Two examples that we can think of are

Mandatory proofs.

If in the future we don’t need the full payload to validate Ethereum, the payload in effect becomes just data, we need to make sure that the payload is available in the chain as a whole and thus we just need to treat it like blobs. Unfortunately, it was in this setting that EIP 8142 was originally proposed for Hegota. Hopefully there’s a tacit understanding that the EIP will change to something along the below lines.

BAL sidecars

Even without proofs, some clients may want to just take part of the payload and not all, this is the content of EIP 8146 which makes sure that BALs are broadcast separately, so that clients that want to keep the current state of Ethereum, without executing it, can. With subnets we could get this for free: just subscribe to the subnets that carry the BAL chunks instead of all subnets.

A more concrete proposal and the nuances of Ethereum politics.

The reason I am writing this post is because there is already a proposal to do the above. The problem is that the authors of that proposal, or perhaps the people that are pushing for chunked broadcast, aren’t really clear on this repurposing of the EIP, which looks less like block in blobs and looks more like Let’s fucking ship faster blocks for once!. So yes, this is my only appeal this fork to call your favorite core dev and tell them to get this EIP into Hegota. This is essentially my only priority this fork that already looks quite large and complex, so I’ll abstain from giving opinions on other EIPs, but this one is of a personal interest so just to keep it short let me describe the entire proposal in just some short direct points.

  • The builder splits the payload in k chunks.
  • Constructs N chunks with Reed Solomon, any k of them recover the payload.
  • Hashes each of the chunks and then constructs the Merkle tree of these hashes.
  • Commits the HTR of the above tree in the bid, no more blockHash. Fully compatible with delayed state root computation.
  • Adds a Merkle proof against that root to each chunk.
  • No subnets, no extra complexity, verifiers just verify the Merkle proof, no extra signature with the payload.

At the I* fork we can build upon this:

  • Add subnets and make sure that some chunks correspond to BAL. For nodes that only want to get BALs they won’t get erasure coding but can subscribe to just those subnets. There are smarter ways, changing the erasure code again, at the cost of complexity. But the point is that we get EIP 8146 for free, and this is the reason why I am against it in Hegota.
  • Add custody requirements and even data sampling if needed.