Ethereum EIP-8479 Explained: Post-Quantum PeerDAS and Variable-Size Blobs

Ethereum EIP-8479 Explained: Post-Quantum PeerDAS and Variable-Size Blobs

Custom Image
What if Ethereum could make its data availability infrastructure more resistant to future quantum computers while giving Layer 2 networks greater flexibility over how they publish transaction data? A new proposal introduced by Ethereum Foundation researcher Francesco Risitano on November 1, 2026, explores exactly that possibility. The draft, originally numbered EIP-9999, proposes replacing KZG commitments in PeerDAS with Keccak-256 Merkle commitments and LeanDA STARK proofs. It also introduces variable-size blobs ranging from 2 KiB to 512 KiB, allowing rollups to select data capacity more closely aligned with their needs. The Ethereum Magicians discussion thread uses the EIP-8479 designation, making the numbering distinction important when following the proposal. Although the design remains at an early review stage, it connects three major Ethereum development priorities: post-quantum cryptography, data availability, and Layer 2 scalability. Its potential significance extends beyond protocol engineering, raising questions about rollup costs, Ethereum's infrastructure competitiveness, and ETH's longer-term ecosystem value.

Key Takeaways

  • A new post-quantum proposal: The draft explores replacing KZG-based PeerDAS commitments with Keccak-256 Merkle commitments and LeanDA STARK proofs.
  • Variable-size blobs: The design permits power-of-two blob sizes from 2 KiB to 512 KiB while retaining 128 columns per blob.
  • Layer 2 implications: Rollups could select data capacities more closely aligned with transaction batches, potentially improving data utilization.
  • Cryptographic changes: Merkle authentication paths would replace KZG cell proofs, while STARK proofs would verify Reed-Solomon encoding and commitment derivation.
  • Early development stage: The proposal remains a draft, with proof-system parameters, client integration, and performance benchmarks still requiring work.
  • ETH market relevance: The proposal may strengthen Ethereum's long-term infrastructure narrative, but it does not establish an immediate catalyst for ETH prices or guarantee lower transaction fees.

What Is Ethereum EIP-8479 and Why Was It Proposed?

The proposal addresses two connected challenges: the long-term cryptographic security of Ethereum's data availability layer and the need for more flexible data capacity for rollups. Its original specification is titled EIP-9999, with the November 1 discussion thread using the EIP-8479 title. It was authored by Francesco Risitano, Thomas Coratger, and Tom Wambsgans, and its initial draft was dated October 26, 2026. The proposal is a Core, Standards Track EIP and currently carries Draft status. It references several related proposals, including EIP-4844, EIP-7594, EIP-7892, EIP-8141, and EIP-8288.

Why Existing PeerDAS Needs a Different Cryptographic Approach

PeerDAS, or Peer Data Availability Sampling, allows Ethereum nodes to check whether blob data is available without downloading every byte of an entire blob. The mechanism distributes data into columns, assigns custody responsibilities to nodes, and allows participants to sample selected portions. This reduces the data requirements for ordinary validators while preserving a method for checking data availability.
 
The current design uses KZG commitments and cell proofs to authenticate sampled data. KZG relies on elliptic-curve pairing cryptography, which is vulnerable in principle to sufficiently capable fault-tolerant quantum computers running Shor's algorithm. Although practical quantum computers capable of breaking Ethereum's cryptographic assumptions are not currently available, protocol researchers are evaluating alternatives before such a threat becomes operational. EIP-8479's discussion therefore reflects a forward-looking security strategy rather than a response to an immediate quantum attack.

Why Blob Flexibility Matters to Ethereum

The second motivation concerns the way rollups purchase and publish data capacity. Fixed-size data structures can create inefficiencies when a rollup's transaction batch does not match the available capacity. A smaller batch may leave unused space, while waiting to accumulate a larger batch can introduce additional publication delays.
 
Variable-size blobs aim to give rollup operators more control over this trade-off. Instead of treating every submission as a fixed-capacity unit, the proposed design allows supported blob sizes to scale in powers of two. This could make data publication more adaptable to different transaction volumes and operating requirements.

How Does EIP-8479 Replace KZG With Post-Quantum STARKs?

The central cryptographic change is the replacement of KZG commitments and cell proofs with Keccak-256 Merkle commitments, Merkle authentication paths, and LeanDA STARK proofs. The design separates the task of authenticating individual data samples from the task of proving that the complete blob was encoded and committed correctly. This is intended to remove reliance on elliptic-curve pairing assumptions and eliminate the trusted setup required by the existing KZG construction.

Keccak-256 Merkle Commitments

A Merkle tree organizes data through repeated hashing. Individual data elements are first hashed into leaf nodes, after which pairs of hashes are combined to create higher-level nodes. The process continues until a single Merkle root represents the underlying data structure.
 
In the proposed PeerDAS design, each blob receives a Keccak-256-based Merkle commitment. When a node samples a particular data cell, it can receive the corresponding Merkle authentication path and independently verify that the cell belongs to the committed blob. This provides a way to authenticate sampled data without relying on KZG cell proofs.
 
Keccak-256 is particularly relevant because hash-based cryptographic constructions are generally considered more suitable for post-quantum security than schemes based on elliptic-curve discrete logarithms. Quantum search algorithms can still reduce the effective security of hash functions, so security parameters and implementation details remain important. The proposal should therefore be understood as a move toward quantum-resistant cryptographic assumptions, not a guarantee against every future quantum attack.

What Does LeanDA STARK Actually Verify?

Merkle authentication establishes that a sampled cell belongs to a particular committed data structure, but the protocol must also establish that the blob's data encoding and commitment generation are correct. This is where LeanDA STARK becomes important.
 
The proposed STARK proves two central properties: that the blob satisfies its Reed-Solomon encoding relationship and that the associated Merkle commitment has been derived correctly. Reed-Solomon coding introduces redundancy that allows missing data portions to be reconstructed when enough valid portions remain available. The proof allows the network to verify the relevant encoding and commitment relationships without requiring every verifier to repeat the entire computation independently.
 
The proposal also connects LeanDA proofs to EIP-8288, which provides a block-level recursive STARK aggregation framework. Rather than treating every proof as an isolated verification task, the design introduces data-availability dependency frames whose proofs can be folded into the broader block-level aggregate. This integration is technically significant because proof generation, aggregation, and verification costs will influence whether the design is practical for Ethereum clients.

How Do Variable-Size Blobs Change Ethereum Data Availability?

The proposal introduces blob sizes ranging from 2 KiB to 512 KiB, with supported byte lengths restricted to powers of two. Each blob retains 128 columns, meaning that the byte length of individual data units changes while the overall column structure remains consistent. This is a significant departure from the traditional fixed-size blob model used by Ethereum's existing data availability infrastructure.

From Fixed Capacity to Flexible Data Publication

Under the proposed design, a rollup could select a blob size that more closely matches the amount of data it needs to publish. A small transaction batch could use a smaller blob, while a larger batch could select a greater capacity. The objective is to reduce unnecessary padding and give rollups more flexibility in balancing data availability costs against publication frequency.
 
The following examples illustrate the proposed capacity range:
  • 2 KiB: A small data submission requiring limited capacity.
  • 8 KiB–64 KiB: Intermediate sizes for relatively compact transaction batches.
  • 128 KiB: A familiar reference point corresponding to the traditional blob capacity.
  • 256 KiB–512 KiB: Larger submissions requiring additional data capacity.
 
The proposal also specifies changes to blob-carrying transactions. Rather than relying solely on the existing versioned-hash representation, the proposed transaction structure uses a Merkle root and an explicit byte-length field. Blob-carrying transactions are represented using EIP-8141 frame transactions, linking the new data structure to the broader transaction-format design.

How Could Variable-Size Blobs Affect Gas Costs?

Flexible blob capacity could improve data utilization, but the relationship between blob size and fees is not as simple as choosing a smaller blob and automatically paying less. The proposal also changes networking requirements and gas accounting, including the costs associated with Merkle authentication and the new verification process.
 
For rollup operators, the relevant calculation involves more than raw data capacity. They must consider transaction batch sizes, blob publication frequency, proof-generation expenses, network propagation, and the market price of blob gas. A smaller blob may be more efficient for one workload, while a larger submission may be preferable for another.
 
The design therefore introduces an opportunity to optimize data publication rather than promising a universal fee reduction. Actual savings will depend on implementation benchmarks and how rollup developers adapt their batching strategies after the proposal undergoes further review.

What Could EIP-8479 Mean for Ethereum Layer 2 Networks?

The proposal could make Ethereum's data availability infrastructure more adaptable to the needs of Layer 2 networks, particularly rollups that publish transaction data in batches. Arbitrum, Optimism, and Base are examples of major Ethereum scaling ecosystems whose operators have an interest in efficient and predictable data publication. However, EIP-8479 does not directly change their execution environments or guarantee immediate reductions in user transaction fees.

Potential Benefits for Rollup Operators

Rollups must balance the frequency of transaction batch submissions with the cost of publishing data to Ethereum. Fixed-capacity blobs can create a mismatch between actual data requirements and the capacity purchased. Variable-size blobs could give operators more choices when designing batch sizes and publication schedules.
 
For example, a rollup experiencing relatively low transaction activity might prefer to publish smaller batches without waiting to accumulate enough data to fill a larger fixed-capacity structure. A high-volume rollup could instead use larger blobs to consolidate more data into each submission. These choices could improve operational flexibility and help developers optimize the relationship between data availability costs and transaction latency.
 
The benefit will not necessarily be identical across networks. Rollups differ in transaction volume, compression techniques, sequencing models, and data publication strategies. Consequently, developers will need to evaluate whether the additional flexibility outweighs the implementation and proof-generation costs.

Implications for Ethereum's Layer 2 Competition

Ethereum competes with alternative blockchain ecosystems that offer different approaches to execution, transaction settlement, and data availability. Improving the efficiency of its blob infrastructure could support Ethereum's position as a settlement and data availability layer for rollup-based applications.
 
However, network competitiveness depends on more than blob capacity. Developers and users also consider transaction fees, application performance, liquidity, interoperability, security, and ecosystem support. EIP-8479 addresses one important part of this broader equation: the cryptographic and data-availability infrastructure underlying rollup scaling.
 
Its potential contribution is therefore best evaluated as an infrastructure improvement that could strengthen Ethereum's Layer 2 development environment over time, rather than as an immediate competitive advantage that has already been demonstrated.

How Does EIP-8479 Fit Into Ethereum's Post-Quantum Roadmap?

EIP-8479 addresses the data availability component of Ethereum's wider post-quantum research agenda. It does not replace every cryptographic primitive used by the network, and it does not make Ethereum fully quantum-resistant. Consensus signatures, account authentication, and other cryptographic systems require their own migration strategies.

Three Cryptographic Areas Require Attention

Ethereum's cryptographic architecture includes several components with different security assumptions:
Consensus signatures: Ethereum validators use BLS signatures to participate in consensus and aggregate attestations. Because BLS depends on elliptic-curve pairing cryptography, researchers are exploring alternative signature systems that can offer stronger post-quantum security properties.
 
Account signatures: Standard externally owned accounts use ECDSA signatures. A sufficiently powerful quantum computer could theoretically use Shor's algorithm to derive private-key information from exposed public keys under the relevant elliptic-curve assumptions. Account abstraction and alternative signature verification mechanisms are among the approaches that could support future migration.
 
Data availability commitments: KZG commitments are the component directly targeted by this proposal. Replacing them with hash-based Merkle commitments and STARK proofs would address one specific part of the protocol's cryptographic exposure.
 
These areas are related, but they cannot be upgraded through a single change. Ethereum's post-quantum transition will require coordinated work across consensus, execution, networking, and application infrastructure.

Why STARK-Based Designs Matter

STARK systems use hash functions and transparent proof constructions rather than relying on elliptic-curve pairings and a conventional trusted setup. Their properties make them candidates for post-quantum applications, although proof size, verification performance, implementation complexity, and hash security parameters must still be evaluated.
 
EIP-8479 also demonstrates the importance of connecting cryptographic research with protocol engineering. A theoretically secure proof system is not sufficient on its own: it must work within Ethereum's block timing, bandwidth, validator resource, and client compatibility constraints. The proposal's integration with EIP-8288 reflects this requirement to consider proof verification at the wider block level.

What Is the Current Status of EIP-8479?

As of November 2, 2026, the proposal remains an early-stage draft rather than an approved Ethereum network upgrade. Its November 1 discussion and GitHub pull request invite feedback from rollup developers, consensus and execution client teams, networking contributors, and cryptography researchers. The specification explicitly identifies several unresolved issues, meaning that substantial design and implementation work remains before any mainnet deployment can be considered.

Outstanding Technical Challenges

The first issue is the completion of the LeanDA guest program and its verification-key hash. These components are important because they define the computation being proven and the parameters used by verifiers to check the resulting STARK proof.
 
The second issue is client implementation. The proposal requires coordinated changes across execution-layer, consensus-layer, and networking components. Developers must ensure that different clients interpret blob commitments, transaction fields, and data authentication procedures consistently.
 
The third issue concerns performance. Proof generation, recursive aggregation, Merkle authentication paths, and PeerDAS bandwidth must be benchmarked across different node configurations. A design that works in a controlled research environment must also remain practical for the broader validator network.
 
Finally, rollup operators need to confirm whether the proposed blob size distribution matches real-world demand. Feedback on preferred capacities will help determine whether variable-size blobs deliver meaningful benefits beyond additional protocol complexity.

What Should Developers and Investors Watch Next?

The most important developments will be progress on the specification, publication of a working prototype, independent cryptographic review, and performance results. Feedback from rollup teams will also help establish whether the proposed capacity range is useful for actual data publication workloads.
 
The status of related proposals matters as well. EIP-8288 provides the recursive proof aggregation framework referenced by LeanDA, while EIP-8141 supplies the proposed frame transaction structure. Their implementation progress could influence the integration path for the new design.
 
For investors, the distinction between a research proposal and a scheduled upgrade is essential. A Draft EIP can influence Ethereum's long-term development narrative, but it should not be treated as evidence that a specific feature will reach mainnet or produce a measurable change in ETH demand.

Could EIP-8479 Affect ETH Price and Ethereum Adoption?

EIP-8479 has potential long-term implications for Ethereum's infrastructure, but its immediate impact on ETH valuation is likely to be driven more by market expectations than by direct changes to network economics. The proposal has not been implemented, and there is no confirmed mainnet activation schedule. Consequently, it does not yet provide measurable evidence of lower rollup fees, increased blob utilization, or higher ETH transaction demand.
 
In the short term, traders and analysts are more likely to monitor ETH spot trading activity, derivatives positioning, ETF flows, and broader market conditions. News about the proposal may strengthen interest in Ethereum's technical roadmap, but a draft specification alone is not sufficient to establish a sustained price catalyst.
 
Over the longer term, successful implementation could support Ethereum's role as a secure data availability and settlement layer. More flexible blob capacity may help rollups manage data publication, while hash-based commitments and STARK proofs could contribute to the network's post-quantum transition. These improvements may strengthen developer confidence and ecosystem participation if they deliver practical performance benefits.
 
Nevertheless, ETH's broader valuation will continue to depend on network activity, staking, supply dynamics, application adoption, and competition from other blockchain ecosystems. EIP-8479 should therefore be viewed as one component of Ethereum's long-term infrastructure development rather than an independent investment thesis.

Conclusion

Ethereum's proposed post-quantum PeerDAS and variable-size blob design represents an important research direction for the network's data availability infrastructure. By replacing KZG commitments and cell proofs with Keccak-256 Merkle commitments and LeanDA STARK verification, the proposal explores a cryptographic architecture that is better aligned with long-term post-quantum security objectives. Its variable-size blob design, ranging from 2 KiB to 512 KiB, also introduces greater flexibility for rollups that need to publish different volumes of transaction data.
 
However, the proposal remains at an early draft stage. Its proof parameters, client integration, networking changes, and performance requirements still need to be addressed through technical review and implementation testing. For Ethereum, the significance of this development lies in the combination of cryptographic resilience and Layer 2 data efficiency. Whether it ultimately improves rollup economics or influences ETH adoption will depend on successful implementation and measurable ecosystem benefits. For now, EIP-8479 is best understood as a forward-looking infrastructure proposal within Ethereum's broader scaling and post-quantum research agenda.

FAQs

What Is the Difference Between an EIP and an ERC?

An Ethereum Improvement Proposal (EIP) describes proposed changes to Ethereum's protocol, standards, or development processes. An Ethereum Request for Comments (ERC) generally specifies application-layer standards, such as token interfaces and smart contract conventions. EIP-8479 is a Core proposal because it concerns fundamental data availability and protocol behavior.

What Does PeerDAS Stand For?

PeerDAS stands for Peer Data Availability Sampling. It is a mechanism that allows Ethereum nodes to sample portions of distributed blob data rather than downloading every data element. This approach helps reduce individual node data requirements while maintaining a way to verify data availability.

What Is Reed-Solomon Encoding?

Reed-Solomon encoding is an error-correcting code that adds redundancy to data. This allows missing portions to be reconstructed when sufficient valid portions remain available. It is relevant to PeerDAS because distributed data availability depends on the network's ability to recover the original data from sampled and distributed components.

What Is a Trusted Setup in Cryptography?

A trusted setup is an initialization process used by certain cryptographic systems to generate public parameters. If its secret information is not properly destroyed, it may create security risks. KZG commitments rely on a trusted setup, while the proposed STARK-based design aims to avoid this requirement through a transparent proof construction.

How Can Users Follow the Progress of an Ethereum Improvement Proposal?

Users can follow the Ethereum EIPs repository on GitHub, review technical discussions on Ethereum Magicians, and monitor updates from Ethereum developers. Important milestones include specification revisions, independent reviews, prototype implementations, client testing, and any formal decision about inclusion in a future network upgrade.
 
Disclaimer: This general market information, possibly from third-party, commercial, or sponsored sources, is provided for reference and educational purposes only and does not constitute financial or investment advice, an offer, solicitation, or guarantee. We disclaim liability for its accuracy, completeness, reliability, and any resulting losses. Investments/trading are risky; past performance doesn’t guarantee future results. Users should research, judge prudently, and take full responsibility. For further details, please consult KuCoin’s Terms of Use and Risk Disclosure.