Ethereum Foundation Researcher Drafts Quantum-Resistant PeerDAS, 524,288-Byte Blobs

Foundation Researcher Targets the KZG Dependency

An Ethereum (ETH) Foundation researcher has published a draft EIP that would rebuild data verification under PeerDAS on quantum-resistant cryptography and give the Ethereum (ETH) network variable blob sizes. The proposal comes from Francesco Risitano and was circulated for public review on 1 November. Its first pillar replaces the KZG commitments and proofs that currently secure PeerDAS with per-blob Keccak-256 Merkle commitments checked through authentication paths. The draft text states that this removes the trusted setup procedure behind KZG and raises quantum resistance across the data availability layer. PeerDAS, the peer-to-peer data availability sampling scheme behind Ethereum's scaling plans, lets nodes confirm that blob data exists by sampling fragments rather than downloading every blob in full. Sampling keeps node hardware light because a node verifies availability probabilistically instead of storing every rollup's data. Under the current design, a KZG proof confirms that a sampled fragment belongs to its original blob. Those proofs rest on a structured reference string produced in a one-time multi-party ceremony, a parameter set whose integrity participants must trust rather than recompute themselves. A Merkle commitment works differently: a verifier shows the branch of hashes connecting one fragment to a single fixed root, so membership can be checked without any ceremony output. Quantum resistance, in this context, means the scheme should hold even if large-scale quantum machines eventually break today's pairing-based assumptions. The second pillar reaches into blob economics: blobs are the dedicated data space that Layer 2 rollups use to post transaction data back to the chain, and the draft lets each blob be configured anywhere from 2,048 to 524,288 bytes. Both changes share one aim: reworking how the Ethereum network commits, transmits and prices blob data. No activation schedule or fork accompanies the text, which sits at the public comment stage.

Merkle Verification and Gas Rules

The mechanics of the replacement run in two steps. Authentication paths first confirm each sampled fragment against the blob's Merkle root. STARK proofs from LeanDA then recompute that root, letting a node verify the Reed-Solomon encoding relationship and the consistency between the posted data and its commitment. The two checks together confirm that the fragment, the encoding and the commitment all match. The sizing rules carry their own constraints. Every blob must be a power of two in bytes and must divide evenly into 128 data units. The draft keeps the unit count fixed at 128 and scales each unit's size to the chosen blob, so a 524,288-byte blob holds 128 units of 4,096 bytes while a 2,048-byte blob holds 128 units of 16. The arithmetic stays uniform because every permitted size is a multiple of the smallest one, which keeps fragment indexing predictable across the range. That preserves the sampling design PeerDAS was built around while letting a blob's footprint move with demand. Transmission and pricing follow the sizes. On the execution layer, transactions would carry a Merkle root and the byte length of the blob instead of the versioned hash used today, which means client software that reads versioned hashes would track a different field. The draft also places network transmission rules for blob exchange under adjustment, since fragments of very different sizes move differently across the peer-to-peer layer. The proposal puts gas calculation on the adjustment list alongside them, and gas fee pricing for blobs would move with the redefined parameters. For validators, the practical work sits in the sampling path: code that verifies KZG proofs today would verify Merkle branches and recomputed roots instead, a change every client that participates in data availability sampling would carry. None of this touches consensus tomorrow; the text is a draft open for comment, with no activation block or fork named in it.

Why the Trusted Setup Matters

The trusted setup removal is the load-bearing change in this draft. Every KZG commitment in production today traces back to a ceremony whose participants are assumed, never proven, to have destroyed their secret contributions, and the Merkle scheme eliminates that assumption at the source. Variable blob sizing, meanwhile, pulls blob pricing toward the amount of data actually posted, which matters as rollup throughput grows. For readers tracking the Ethereum price, this is a protocol story rather than a trading one: the draft carries no activation date, and it will need public review and testnet rehearsal before anything reaches a hard fork, the staged path the network followed through the Ethereum 2.0 upgrade.