EIP-8142 Block-in-Blobs (Block-in-Blobs (BiB))
Hegota Proposed for Inclusion · Scaling & data · EIP status Draft · created 2026-01-29
A proposal to put transactions and the block access list into blobs and carry them in the same beacon block, so that execution data is always published even in an era when blocks are verified with zkEVM proofs.
Why it is needed
Today, when a validator checks a block, it downloads the execution payload, re-executes it, and compares the result with the header. This process meant that block data was guaranteed to be published without any extra mechanism. Once zkEVM is introduced, however, validators only need to receive and check a proof and a header instead of the payload. The problem is that the implicit requirement to download the data disappears. A malicious or selfish block producer could publish only a valid proof and withhold the transaction data itself. Then only that producer could build the next block. RPC providers and indexers, which cannot operate on proofs alone and must re-execute the data, would halt. This proposal forces the execution payload data to be placed in blobs and carried in the same beacon block, so the data is always published even in the proof era.
What changes
Today
- Validators download the payload and re-execute it, so data publication is guaranteed automatically
- With zkEVM proofs alone, a producer can publish the proof and withhold the data
- If the data is withheld, only that builder can build the next block, and RPC providers and indexers halt
After EIP-8142
- Transactions and the block access list (BAL) are put in blobs and are always published in the same beacon block
- The front part of the beacon block's blob commitment list is reserved for payload blobs
- The existing blob sampling (PeerDAS) also guarantees publication of the payload data as is
Who is affected
- Client teams: A payload_blob_count field is added to the execution header, and getPayload and newPayload in the Engine API change. A hard fork is required, and nodes that have not implemented it cannot validate blocks after activation.
- Block builders: When building a block, the payload data must be encoded into blobs and the KZG commitments and proofs must be computed. Payload blobs are not pre-propagated in the mempool, so the bandwidth burden can grow.
- Rollups and blob users: Payload blobs consume blob gas, so they compete with transaction blobs for capacity and affect blob congestion and the base fee.
- RPC providers and indexers: Even after proof verification becomes mandatory, the execution payload can be recovered from blobs, so services based on re-execution can keep running.
In depth
What goes into blobs: transactions and the BAL
The ExecutionPayloadData placed in blobs consists of two items: blockAccessList (the BAL from EIP-7928, RLP-encoded) and transactions. Transactions are included because they are the only data that cannot be derived from other components of the payload and is not provided by the consensus layer. The BAL is originally an execution output and could be recomputed, but once zkEVM proofs are mandatory, validators no longer execute, so a builder could submit only the proof and withhold the BAL; it is therefore included as well. Withdrawals, on the other hand, are excluded because they can be derived from the consensus layer, and execution requests are excluded because they can be recomputed from transactions and are already needed for consensus layer validation. The header holds payload_blob_count, and since this value depends on the number of blobs, putting the header in blobs would create a circular dependency, so it is excluded.
Encoding rules: 31 bytes per field element and an 8-byte header
Each 32-byte field element in a blob keeps its first byte (MSB) at 0 and uses only the remaining 31 bytes (USABLE_BYTES_PER_FIELD_ELEMENT = 31). This ensures that every element value is a canonical field element smaller than BLS_MODULUS. The usable capacity of one blob is FIELD_ELEMENTS_PER_BLOB (4096) × 31 bytes. An 8-byte header [4-byte BAL length][4-byte transactions length] in big-endian is prepended to the data so that the BAL can be extracted on its own without parsing the transactions. When decoding, everything after the declared lengths must be zero padding, and extra data is not allowed. The invariant holds that the encoding function execution_payload_data_to_blobs and the decoding function blobs_to_execution_payload_data are inverses of each other. For simplicity, serialization uses RLP, and it is recommended not to use compression for the time being.
The payload_blob_count field and commitment order
A new payload_blob_count (uint64) field is added to the execution header and the consensus layer ExecutionPayload. In the blob_kzg_commitments list referenced by the beacon block, the first payload_blob_count entries are payload blob commitments and the rest are commitments of type 3 (EIP-4844 blob-carrying) transactions. The total number of blobs cannot exceed MAX_BLOBS_PER_BLOCK set by EIP-7892, so a builder must account for payload blob usage when selecting type 3 transactions. The consensus layer uses this field only to interpret the commitment order. It adds no new validation rules for payload blobs and treats them the same as other blobs for availability and networking.
Two Engine API variants: native and zkEVM-optimized
Two equivalent approaches are given for newPayload and getPayload. The native variant computes the payload blob commitments directly with blob_to_kzg_commitment and verifies payload_blob_count and the versioned hashes. It suits implementations before proofs become mandatory. The zkEVM-optimized variant takes into account that the multi-scalar multiplication (MSM) needed to compute commitments is expensive to prove inside a zkEVM circuit, so it batch-verifies polynomial opening proofs with verify_blob_kzg_proof_batch instead. For this, a payload_kzg_proofs field is added to BlobsBundle. This list contains only random-point KZG proofs for payload blobs, and its length equals payload_blob_count. In the circuit, the payload, the commitments, and the KZG proofs are private inputs, while the versioned hashes and the payload header are public inputs. The validity conditions of the two variants are identical, so a block valid in one is also valid in the other.
Fees: a cost the protocol absorbs
Payload blobs do not come from user transactions, so unlike type 3 blobs they are not charged a per-blob fee. Instead, the protocol accepts them as a cost required to keep data available. However, they consume blob gas, so they directly affect blob congestion and the blob base fee. An attack in which a builder deliberately creates a large payload to inflate blob gas is economically constrained. To enlarge the payload, the builder must add transactions containing calldata, and calldata consumes execution gas, so inflating the payload solely to manipulate blob fees does not pay off. Explicit protocol-level pricing for payload blobs remains an open problem.
Networking: gossip fallback and bridge nodes
Blob propagation uses the existing mechanisms as is. Once proofs are mandatory, a separate path for receiving the full payload is needed, and the execution_payload gossip topic introduced by EIP-7732 can be used. However, if an overwhelming majority of stake is zk validators that listen only to the header topic, a malicious builder could put the payload only in blobs and not gossip it on the execution_payload topic. In that case zk validators attest, but nodes that need the full payload stall. As a countermeasure, a fallback can be added in which a node that fails to receive the payload from the topic reconstructs it from the first payload_blob_count blobs and supplies it to the topic itself. This makes every node act as a bridge node whenever needed. Also, unlike most type 3 blobs, payload blobs are not propagated before the block is built, so the builder's bandwidth requirements can grow.
Status and fork discussion: champion withdrawal and replacement
This EIP is in Draft status, so the specification may still change, and the test cases and reference implementation are not yet written (TODO). According to the call records, it was accepted as a Hegota candidate (PFI) at 08.06 ACDC #184. Later, at 09.21 ACDT #97, it was announced that the champion withdrew EIP-8142 and proposed EIP-8411 (Fast Execution Payload Broadcast) as a replacement. No decision was made on that call, and the CL teams were asked to rate it before the next ACDC.