DA Layers & Rollups Migration Playbook
A comprehensive guide for migrating data availability infrastructure and Layer-2 rollups to post-quantum cryptography. Covering KZG commitments, ZK proof systems, sequencer security, and modular blockchain architecture.
The Foundation Layer at Risk
Data availability layers and rollups form the scalability foundation of modern blockchain infrastructure. Ethereum’s EIP-4844 “proto-danksharding” uses KZG polynomial commitments—built on quantum-vulnerable BLS12-381 elliptic curves—to verify blob data. ZK-rollups using SNARKs rely on the same vulnerable pairings. A cryptographically relevant quantum computer could forge KZG proofs, corrupt data availability verification, and undermine the security guarantees that rollups inherit from their base layers. This playbook addresses the most complex migration challenge in the blockchain stack.
Why This Matters Now
The blockchain industry has committed heavily to rollup-centric scaling. Ethereum’s roadmap explicitly depends on data availability sampling (DAS) and KZG commitments. Layer-2 rollups collectively secure over $40 billion in total value locked (TVL). Modular blockchain projects like Celestia, EigenDA, and Avail are building specialized DA layers to support this architecture.
Every component of this stack has quantum vulnerabilities:
- KZG Commitments: Built on BLS12-381 elliptic curve pairings, broken by Shor’s algorithm
- BLS Validator Signatures: Over 1 million Ethereum validators use quantum-vulnerable BLS12-381
- SNARK Proof Systems: Groth16 and PLONK rely on elliptic curve pairings
- Sequencer Keys: Centralized sequencers use ECDSA for transaction ordering
- DA Layer Attestations: Validator signatures on data availability commitments
Vitalik Buterin has publicly stated there’s roughly a 20% chance of cryptographically relevant quantum computers (CRQCs) emerging before 2030. He has urged Ethereum to begin transitioning to quantum-resistant foundations within approximately 4 years. The complexity of DA layer and rollup migrations—involving proof system changes, commitment scheme replacements, and coordinated upgrades across multiple protocol layers—means migration must begin now.
KZG Commitments & Quantum Vulnerability
Kate-Zaverucha-Goldberg (KZG) polynomial commitments are the cryptographic foundation of Ethereum’s data availability solution. Implemented in EIP-4844 (Dencun upgrade, March 2024), KZG enables “blob” transactions that provide cheap data availability for rollups.
How KZG Works
KZG commitments allow a prover to commit to a polynomial and later prove evaluations at specific points without revealing the entire polynomial. The security relies on the hardness of the discrete logarithm problem on the BLS12-381 elliptic curve.
- Commitment: The prover computes C = g^p(s) where p(x) is the polynomial and s is from a trusted setup
- Evaluation Proof: To prove p(z) = y, the prover provides a witness w = g^q(s) where q(x) = (p(x) – y)/(x – z)
- Verification: The verifier checks e(C/g^y, g) = e(w, g^s/g^z) using bilinear pairings
The Quantum Attack
KZG Vulnerability Explained
KZG security assumes computing discrete logarithms on BLS12-381 is computationally infeasible. Shor’s algorithm solves discrete logarithms in polynomial time on quantum computers. With a sufficiently powerful CRQC:
- Extract Trusted Setup: Derive the secret s from any published g^s value
- Forge Commitments: Create valid-looking commitments to arbitrary polynomials
- Fake Evaluation Proofs: Generate proofs that pass verification for any claimed evaluation
- Corrupt Data Availability: Convince verifiers that invalid data is valid, breaking rollup security
Impact on Ethereum: EIP-4844 allows up to 6 blobs per block (targeting 3 average), each 128 KB. Rollups post transaction data to these blobs and rely on KZG proofs to verify data availability. If KZG proofs can be forged, rollups lose their data availability guarantee—the foundation of their security model.
The Trusted Setup Problem
Ethereum conducted a massive trusted setup ceremony in 2022-2023 with over 140,000 participants to generate the KZG parameters. The security assumption: at least one participant honestly deleted their contribution. This ceremony does NOT protect against quantum attacks—it only ensures no classical adversary knows the secret s. A quantum computer can derive s directly from the public parameters.
Data Availability Layer Architectures
Three major DA layer architectures have emerged, each with distinct quantum vulnerability profiles:
Celestia: Fraud Proof Model
Celestia uses a fraud-proof based data availability sampling (DAS) model. Validators produce blocks with erasure-coded data, and light clients sample random chunks to verify availability probabilistically. Celestia does not use KZG commitments.
| Component | Cryptography | Quantum Status |
|---|---|---|
| Consensus Signatures | Ed25519 (Tendermint) | Vulnerable—Shor’s algorithm |
| Data Commitments | Namespaced Merkle Trees (SHA-256) | Resistant—128-bit post-quantum |
| Erasure Coding | Reed-Solomon | Resistant—information-theoretic |
| Fraud Proofs | Merkle proofs | Resistant—hash-based |
Quantum assessment: Celestia’s data availability mechanism is largely quantum-resistant due to reliance on hash functions rather than pairings. The primary vulnerability is validator signatures (Ed25519), which affects consensus but not the DA verification itself.
EigenDA: Restaking Model
EigenDA leverages Ethereum’s restaking mechanism through EigenLayer. Operators stake ETH and run DA nodes, providing economic security. With over 4.3 million ETH restaked (billions in economic security), EigenDA offers 100MB/sec throughput.
| Component | Cryptography | Quantum Status |
|---|---|---|
| Operator Signatures | BLS12-381 | Vulnerable—Shor’s algorithm |
| Data Commitments | KZG on BLS12-381 | Vulnerable—Shor’s algorithm |
| Restaking Attestations | ECDSA/BLS | Vulnerable—Shor’s algorithm |
| Erasure Coding | Reed-Solomon | Resistant—information-theoretic |
Quantum assessment: EigenDA inherits Ethereum’s quantum vulnerabilities through its use of BLS signatures and KZG commitments. Both the economic security model (restaking attestations) and the DA verification (KZG proofs) are compromised under quantum attack.
Avail: KZG-Based Model
Avail (spun out from Polygon in July 2024) uses KZG commitments combined with erasure coding for data availability. It’s designed as a chain-agnostic DA layer supporting multiple rollup frameworks.
| Component | Cryptography | Quantum Status |
|---|---|---|
| Validator Signatures | BLS/ECDSA | Vulnerable—Shor’s algorithm |
| Data Commitments | KZG on BLS12-381 | Vulnerable—Shor’s algorithm |
| Data Availability Sampling | KZG proofs | Vulnerable—Shor’s algorithm |
| Erasure Coding | Reed-Solomon | Resistant—information-theoretic |
DA Layer Comparison
| DA Layer | Commitment Scheme | Throughput | Quantum DA Security |
|---|---|---|---|
| Celestia | Namespaced Merkle Trees | 8 MB/block (6s blocks) | Resistant—hash-based proofs |
| EigenDA | KZG Commitments | 100 MB/sec | Vulnerable—pairing-based |
| Avail | KZG Commitments | ~2 MB/block | Vulnerable—pairing-based |
| Ethereum (EIP-4844) | KZG Commitments | ~384 KB/block (3 blobs avg) | Vulnerable—pairing-based |
ZK Proof Systems: SNARKs vs STARKs
Zero-knowledge rollups use cryptographic proof systems to verify computation without revealing inputs. The two dominant approaches have fundamentally different quantum security profiles.
SNARKs (Succinct Non-Interactive Arguments of Knowledge)
SNARK systems like Groth16 and PLONK produce extremely compact proofs (128-288 bytes) with fast verification. They’re used by zkSync, Polygon zkEVM, Scroll, and most production ZK-rollups.
SNARK Quantum Vulnerability
SNARKs rely on bilinear pairings over elliptic curves (typically BLS12-381 or BN254). The security assumption is the hardness of the discrete logarithm problem in the pairing groups. Shor’s algorithm breaks this assumption entirely. A quantum attacker could:
- Forge proofs for invalid state transitions
- Create proofs claiming arbitrary withdrawals are valid
- Bypass all ZK-rollup security guarantees
| SNARK System | Proof Size | Verification Gas | Quantum Status |
|---|---|---|---|
| Groth16 | 128 bytes | ~200k gas | Vulnerable—pairing-based |
| PLONK | ~400 bytes | ~300k gas | Vulnerable—pairing-based |
| KZG-PLONK | ~288 bytes | ~250k gas | Vulnerable—KZG commitments |
STARKs (Scalable Transparent Arguments of Knowledge)
STARK systems, pioneered by StarkWare, use hash-based cryptography instead of elliptic curves. They produce larger proofs but require no trusted setup and are quantum-resistant by design.
STARK Quantum Resistance
STARKs rely only on collision-resistant hash functions (typically Pedersen or Poseidon hashes). Grover’s algorithm provides only a square-root speedup against hash functions, meaning 256-bit hashes retain 128-bit post-quantum security. STARKs are considered quantum-resistant and represent the path forward for ZK proof systems.
| STARK System | Proof Size | Verification | Quantum Status |
|---|---|---|---|
| Cairo/StarkNet | 40-200 KB | ~1M gas (with recursion) | Resistant—hash-based |
| STARK Recursion | ~100 KB compressed | Amortized across batches | Resistant—hash-based |
ZK-Rollup Quantum Status
| ZK-Rollup | Proof System | TVL | Quantum Status |
|---|---|---|---|
| StarkNet | STARKs (Cairo) | ~$200M | Resistant—hash-based proofs |
| zkSync Era | SNARKs (PLONK) | ~$800M | Vulnerable—pairing-based |
| Polygon zkEVM | SNARKs (PLONK) | ~$40M | Vulnerable—pairing-based |
| Scroll | SNARKs (KZG-PLONK) | ~$60M | Vulnerable—pairing-based |
| Linea | SNARKs | ~$700M | Vulnerable—pairing-based |
Optimistic Rollup Vulnerabilities
Optimistic rollups (Arbitrum, Optimism, Base) use a different security model: transactions are assumed valid unless challenged during a dispute period. While this avoids ZK proof system vulnerabilities, optimistic rollups face distinct quantum risks.
| Component | Cryptography | Quantum Status |
|---|---|---|
| Sequencer Transaction Signing | ECDSA (secp256k1) | Vulnerable—Shor’s algorithm |
| Fraud Proof Submissions | ECDSA signatures | Vulnerable—Shor’s algorithm |
| State Root Commitments | Merkle trees (Keccak-256) | Resistant—128-bit post-quantum |
| Dispute Resolution | Interactive bisection | Resistant—hash-based |
| DA Commitments (if using EIP-4844) | KZG | Vulnerable—pairing-based |
Key insight: Optimistic rollups’ fraud proof mechanism is quantum-resistant (hash-based), but the sequencer signing and DA layer (if using KZG blobs) remain vulnerable. A quantum attacker could impersonate the sequencer or corrupt data availability verification.
Sequencer Key Management
Most rollups today operate with centralized sequencers that order transactions and produce batches. The sequencer’s private key is a critical security component—if compromised, an attacker can reorder transactions for MEV extraction, censor users, or produce invalid batches (though fraud proofs eventually catch invalid state transitions).
Sequencer Quantum Risk
Sequencer keys typically use ECDSA on secp256k1. A quantum attacker could derive the sequencer private key from public keys exposed in batch submissions. This enables transaction reordering, censorship, and—for rollups without robust fraud proof systems—potentially invalid state transitions. While “based rollups” and decentralized sequencer networks are in development, most production rollups remain centralized.
| Rollup | Sequencer Model | Signing | Decentralization Plans |
|---|---|---|---|
| Arbitrum One | Centralized (Offchain Labs) | ECDSA | BOLD protocol for permissionless validation |
| Optimism | Centralized (Optimism Foundation) | ECDSA | Fault proofs enabled, sequencer decentralization planned |
| Base | Centralized (Coinbase) | ECDSA | Inherits Optimism’s roadmap |
| zkSync Era | Centralized (Matter Labs) | ECDSA | Shared sequencing research ongoing |
| StarkNet | Centralized (StarkWare) | ECDSA | Decentralized sequencing in development |
Migration Strategies
Migrating DA layers and rollups to post-quantum cryptography is the most complex challenge in the blockchain stack. Multiple interdependent components must be upgraded in coordination.
Strategy 1: Replace KZG with Hash-Based Commitments
The long-term solution is replacing KZG polynomial commitments with quantum-resistant alternatives:
- FRI-based Commitments: Used in STARKs, rely only on hash functions, quantum-resistant
- Merkle Tree Commitments: Traditional approach, larger proofs but fully hash-based
- Lattice-based Commitments: Newer constructions based on post-quantum lattice assumptions
Trade-off: Hash-based commitments produce significantly larger proofs. A KZG proof is 48 bytes; equivalent FRI proofs are 10-100 KB. This impacts on-chain verification costs and throughput.
Strategy 2: Migrate SNARKs to STARKs
ZK-rollups using SNARKs should plan migration to STARK-based proof systems:
- Circuit Redesign: Rewrite prover circuits in STARK-compatible languages (Cairo, Risc0)
- Verifier Contract Updates: Deploy new on-chain verifiers for STARK proofs
- Recursion Implementation: Use STARK recursion to compress proof sizes
- Hybrid Transition: Accept both SNARK and STARK proofs during migration period
Industry movement: Several SNARK-based rollups are researching STARK transitions. Polygon has announced “Polygon Miden” using STARKs. zkSync is exploring hybrid approaches. The availability of production-ready STARK infrastructure (StarkWare’s prover, Risc0) is accelerating this migration path.
Strategy 3: Sequencer Key Rotation to PQC
Sequencer keys should transition to post-quantum signatures:
- Phase 1: Generate PQC keys (ML-DSA) alongside existing ECDSA keys
- Phase 2: Include dual signatures in batch submissions
- Phase 3: Update L1 contracts to verify PQC signatures
- Phase 4: Deprecate ECDSA sequencer signatures
Strategy 4: DA Layer Selection
Rollups building new deployments should consider DA layer quantum posture:
- Celestia: Hash-based DA proofs, quantum-resistant data availability verification
- Ethereum (calldata): No KZG dependency, but higher costs
- Ethereum (blobs): KZG-dependent, quantum-vulnerable, but cheaper
- EigenDA/Avail: KZG-dependent, requires monitoring their PQC migration roadmaps
Migration Timeline
DA layer and rollup migrations are the most complex in the blockchain stack, requiring 24-36 months for comprehensive transition.
| Phase | Timeline | Key Activities | Deliverables |
|---|---|---|---|
| Phase 1: Assessment | Months 1-3 | Inventory cryptographic dependencies, benchmark PQC alternatives | Vulnerability map, PQC proof-of-concept, migration strategy |
| Phase 2: Research | Months 4-9 | Develop STARK circuits, implement PQC commitment schemes | STARK specifications, PQC libraries, verifier designs |
| Phase 3: Development | Months 10-18 | Build production prover, deploy testnet with PQC proofs | Testnet deployment, performance benchmarks, security audits |
| Phase 4: Mainnet Parallel | Months 19-27 | Enable PQC proofs alongside classical, monitor performance | Production PQC proofs, monitoring dashboards |
| Phase 5: PQC Primary | Months 28-33 | Require PQC verification, deprecate classical proofs | PQC-required verification, deprecated classical infrastructure |
| Phase 6: Classical Sunset | Months 34-36 | Remove classical proof acceptance, complete DA migration | PQC-only infrastructure, documentation |
Migration Checklist
Use this checklist to track migration progress:
Assessment & Planning
Proof System Migration (if using SNARKs)
DA Layer Migration
Sequencer Security
Testing & Deployment
QRC Scoring Integration
DA layer and rollup characteristics directly impact QRC scores:
| QRC Dimension | Weight | DA/Rollup Impact |
|---|---|---|
| Signature Resistance | 35% | Sequencer keys, validator attestations use quantum-vulnerable ECDSA/BLS |
| Pairing-Free Status | 8% | KZG commitments and SNARKs use quantum-vulnerable pairings |
| Crypto-Agility | 12% | Ability to upgrade proof systems, DA commitments without hard fork |
| Operational Mitigations | 7% | Active STARK migration plans, PQC sequencer key roadmaps |
| Dependency Multiplier | Amplifier | L2s inherit the lower of their own security OR base layer security |
Scoring note: Rollups using STARKs receive higher scores in Pairing-Free Status. Rollups using quantum-resistant DA layers receive credit in Operational Mitigations. Currently 49 cryptocurrencies are tracked, with Layer-2 dependencies factored into final scores.
Related Playbooks
- Oracles & Bridges Playbook → Cross-chain messaging, oracle attestations
- Exchange & Custody Playbook → HSM upgrades, MPC infrastructure
- Layer-1 Protocol Playbook → Validator key rotation, consensus upgrades
- Migration Playbooks Overview → Complete playbook index
Assess Your Rollup
See how Layer-2 rollups and their base layers score for quantum resistance.
Last updated: December 4, 2025 | Scoring Engine V5.1