Ethereum draft proposes variable-size blobs and new verification for PeerDAS

A submission without a final number or adoption

Francesco Risitano opened a proposed change in the Ethereum EIPs repository on November 1 at 03:51 UTC. His text, “Post-Quantum PeerDAS and Variable-Size Blobs,” describes a different way to verify blob-related data. At this publication’s check, pull request 12604 is open, marked as a draft and unmerged. That number identifies the GitHub request; it is not the final number of an Ethereum standard.

The file carries an internal creation date of October 26, distinct from its November 1 public submission. It presents an architecture for discussion, with several technical dependencies and elements still to be defined. The EIP process specifically distinguishes a design document from its implementation. Neither the submission nor its draft label means Ethereum clients have adopted the proposed rules or that mainnet activation has been decided.

Changing proofs while retaining sampling

The project would replace KZG blob commitments with Keccak-256-based Merkle commitments. Each sampled fragment would be authenticated through a path of hashes leading to its blob’s root. A LeanDA STARK proof would verify the Reed–Solomon encoding relation and correct derivation of the commitments. However, the text retains PeerDAS column custody, sampling mechanisms and reconstruction thresholds; it does not propose removing them.

The stated objective is to move away from elliptic-curve security assumptions and the trusted-setup ceremony associated with KZG. The author nevertheless specifies that post-quantum resistance depends on the security of the entire construction, including hashing, the proof and its aggregation. He also distinguishes two functions: proving correct encoding and commitments does not, by itself, prove that the data remains available across the network.

Adjustable sizes, with costs still to be tested

Blobs could range from 2,048 to 524,288 bytes, using permitted power-of-two sizes. Each blob would retain 128 cells; the byte length of each cell would vary. The project seeks to avoid making senders with little data pay for unused capacity or wait until they have assembled a larger batch. That rationale is not a measurement of lower fees already observed: the new rules have not been deployed.

The proposed accounting adds the blob’s byte length and a fixed charge corresponding to its Merkle tree’s internal nodes. It would be accompanied by changes to transactions, network exchanges and interfaces between clients. The document describes a transition requiring a consensus change, testing and performance benchmarks. It also notes that authentication paths increase bandwidth and denial-of-service exposure compared with KZG proofs. These trade-offs remain to be assessed before any integration decision.