Fast payload propagation, splitting a large block into 64 pieces to send

Strawmap Hegotá (2027) · fast payload broadcast

The execution payload a builder produces is spread as 64 pieces instead of being sent as one lump. Each piece can be verified separately, so even as blocks grow, they reach the network quickly.

Why it is needed

With EIP-7732 the gas limit can be raised, and the execution payload (the bundle of transactions in a block) grows accordingly. The current method sends the payload as a single message. A node passes it on to the next node only after receiving all of it, so transmission time accumulates with the number of hops. The same data also arrives again by other routes at nodes that already have it, wasting bandwidth. If the Payload Timeliness Committee (PTC) does not receive it by the deadline, even a perfectly valid payload is treated as missing. Splitting it into 64 pieces lets a node forward each piece as soon as it receives it, so delivery overlaps and no large duplication arises. It reached the Hegotá Considered for Inclusion (CFI) stage at ACDC #190 in October 2026. Which fork it goes into is the Strawmap's estimate and is not yet confirmed.

How it works

  1. The builder puts the root of the pieces into the bid The builder converts the payload to bytes, cuts it into 64 pieces, hashes each piece and combines the hashes into a single Merkle root. It puts this root in the bid and spreads it across the network before the block.
  2. Send the pieces one at a time A piece message contains the piece index, the data, a Merkle inclusion proof, and slot and block root hints. The hints are for quickly filtering pieces and finding the block, and are not treated as authenticated values.
  3. The receiving node verifies each piece and forwards it immediately The bid signature is checked only once, and each piece is checked against the bid's root with its inclusion proof. A node passes a piece to the next node as soon as it receives it, without waiting for the block.
  4. Join the 64 pieces to restore the payload The pieces are joined in order starting from index 0 to restore the original payload. At the end the node must check that the result matches the payload hash committed in the beacon block.

Related EIPs

← Roadmap