Ethereum Draft Targets Quantum Risk With 512 KiB Blobs

PeerDAS draft replaces KZG proofs

Risitano described the submission in the primary pull request as an early architectural draft for review. It remained open and unmerged when checked at 20:01 UTC, with no activation date established.

PeerDAS lets nodes check that blob data is available by downloading samples rather than every blob in full. The existing specification authenticates those samples using KZG commitments, cryptographic fingerprints that connect individual pieces to the original data.

The new design would replace those commitments with hash-based Merkle trees. A node would check a piece of data by following a chain of hashes back to the blob’s root, while a LeanDA STARK proof would establish correct encoding and commitment construction.

The distinction is consequential: the STARK proves that data was encoded correctly, not that it remains available. Custody, sampling, reconstruction and networking would still carry that responsibility. The draft preserves the existing column assignments and recovery thresholds.

The document is dated October 26, preceding the November 1 public submission. It turns one part of Ethereum’s broader quantum and scaling roadmap into a specific design for review, without establishing an agreed network upgrade.

Variable blobs change Ethereum fee accounting

Under the proposed specification, blob lengths could range from 2,048 to 524,288 bytes in powers of two. That is 2 to 512 KiB, with each blob still divided into 128 cells.

The smallest permitted blob would therefore contain 16-byte cells; the largest would contain 4,096-byte cells. A transaction could reference at most six blobs, with their combined byte length capped at 786,432. Six maximum-size blobs would exceed that separate limit.

The motivation is to reduce the choice between paying for unused capacity and waiting to accumulate enough data for a larger batch. Rollups publish transaction data to Ethereum, so the size and price of that publication can influence their operating costs and submission timing.

However, the proposed charge is not simply the number of bytes a sender chooses. Each blob would incur one gas unit per byte plus 4,064 units representing its Merkle tree’s internal nodes. A minimum-size blob would therefore consume 6,112 blob-gas units under the draft formula.

That fixed allowance is an accounting convention, rather than an exact measure of every peer’s transmitted data. Smaller packets could reduce unused capacity, but the design alone cannot establish a particular fee saving in dollars or guarantee lower end-user charges.

The proposal also depends on frame transactions and recursive proof aggregation. It connects to the broader transaction-verification redesign, rather than offering a standalone switch that applications can activate today.

Ethereum fork would require migration and testing

The draft explicitly describes a consensus-breaking change. After a future activation, legacy KZG blob transactions would become ineligible for new blocks, while historical blocks would remain valid under their original rules.

Applications submitting blobs would need to migrate their transaction format. Client teams would also need new networking and data-exchange handling, alongside tests covering serialization, fees, malformed proofs and the boundary between old and new fork rules.

The security tradeoff is not absent. The draft warns that Merkle authentication paths increase bandwidth and denial-of-service exposure relative to KZG proofs. It makes its post-quantum claim conditional on the hash function, STARK system, guest program and recursive verification path meeting a coordinated security target.

This work concerns data commitments, not the authorization of ordinary ETH transfers. Separate work such as Ethereum’s post-quantum key registry proposal addresses a different part of the migration problem. Publication of this draft does not establish a wallet compromise or a completed quantum-safe network.

Alternative.me’s Fear & Greed Index read 34, or Fear, on November 1, compared with 30 the previous day. It measures broad crypto sentiment rather than technical readiness for the proposal.

The next concrete milestones are review revisions, implementation evidence, proof-generation and networking benchmarks, and any decision to include the design in a fork. Until those emerge, the verified development is a detailed research proposal with migration requirements and unresolved performance work.