New EIP Proposes Quantum-Resistant Overhaul of Ethereum's PeerDAS

A discussion thread posted to Ethereum Magicians on November 1, 2026 lays out EIP-9999, a draft proposal that rebuilds the data-availability layer behind Ethereum's PeerDAS design using cryptography intended to resist quantum computers rather than the elliptic-curve-based KZG commitments it uses today.

How EIP-9999 changes PeerDAS

PeerDAS is Ethereum's current approach to data-availability sampling, the mechanism that lets network nodes verify that blob data submitted on-chain is actually available without downloading the entire blob. In the present design, KZG polynomial commitments and cell proofs — built on elliptic-curve pairings — let nodes check sampled pieces of data against a commitment.

Per the Ethereum Magicians thread, EIP-9999 swaps that construction for Keccak-256 Merkle commitments paired with what the proposal calls a "LeanDA STARK," a zero-knowledge proof system that verifies both the Reed–Solomon encoding of the data and the correctness of the commitment derivation. STARKs rely on hash functions rather than elliptic-curve math, which is the property that makes them a candidate for post-quantum security, since a sufficiently powerful quantum computer running Shor's algorithm could in theory break the discrete-log assumptions that KZG depends on.

The thread states that sampled cells would be authenticated through Merkle authentication paths instead of KZG proofs, while the column-custody, sampling, subnet-allocation, and recovery mechanisms that already exist in PeerDAS are left unchanged. The proposal also widens blob sizing: it would permit power-of-two blob sizes ranging from 2 KiB to 512 KiB, while keeping the existing structure of 128 columns per blob.

What a quantum-resistant data-availability layer would mean for Ethereum

EIP-9999 is, at this stage, a discussion-forum draft rather than an accepted or scheduled upgrade. Ethereum Magicians threads are where the network's researchers and client teams propose and stress-test EIP ideas before they move toward formal Ethereum Improvement Proposal status, a client specification, and eventual inclusion in a hard fork — a process that typically spans months and includes community review, implementation across multiple client teams, and testnet activation before any mainnet deployment.

The proposal fits into a broader, multi-year conversation among Ethereum researchers about migrating cryptographic primitives away from elliptic-curve constructions that quantum computers could eventually undermine, toward hash-based and lattice-based alternatives presumed more resistant to such attacks. Because blobs underpin the data layer that Ethereum's rollups rely on for cheap transaction data, any change to how that data is committed and verified touches the Ethereum ecosystem's layer-2 scaling roadmap broadly, not just the base layer.

No timeline for client implementation, testnet deployment, or formal EIP status has been established in the thread as of this writing. Readers tracking Ethereum's protocol roadmap should watch for whether client teams pick up the proposal for prototyping and whether it advances through the EIP process toward a numbered, non-draft status.