Open Proofs: Ethereum’s Verifiable and Post-Quantum Future
Devcon 8 India: Community Hub Proposal
Submitted by: zkBankai
Summary
Open Proofs is a community hub covering Ethereum’s post-quantum transition and the proving work connected to it. It is a working space for protocol engineers, cryptographers, zkVM teams, researchers and anyone trying to follow what is happening across post-quantum cryptography, real-time proving, L1 zkEVMs and open-source protocol research.
Motivation and Rationale
How would this Community Hub enhance the attendee experience?
Ethereum is changing how the protocol is verified.
ZK proofs are moving closer to Ethereum L1. Multiple zkVM teams are already proving Ethereum blocks in real time. Ethereum is exploring a future where validators can verify proofs of execution instead of every validator re-executing every transaction. In parallel, work around lean Ethereum and post-quantum cryptography is looking at how Ethereum’s consensus, execution and data layers can become simpler, more verifiable and resilient to future cryptographic threats.
A lot of this work is happening in the open, but following it still requires jumping between research posts, specifications, repositories, benchmarks, protocol calls and different research communities.
We want a room at Devcon where that work sits in one place.
Someone should be able to walk into the hub knowing very little about zkVMs or post-quantum cryptography and leave understanding:
- what an Ethereum block proof is
- why Ethereum wants real-time proving
- what Ethproofs is measuring
- which cryptographic assumptions Ethereum depends on today
- what researchers are trying to change
For people already working in the space, the same hub should support deeper conversations about proof systems, zkVM architectures, formal verification, proving hardware, post-quantum signatures, signature aggregation, leanVM and protocol design.
We want people to leave able to inspect, question and contribute to this work, rather than having heard it described.
How would it complement Devcon 8 India?
Devcon already brings together many of the people working on different parts of this transition: zkVM engineers, Ethereum client developers, protocol researchers, cryptographers, hardware teams, wallet developers, ZK researchers, students and open-source contributors.
The interesting part is increasingly the intersection between these communities.
Real-time proving is not only a ZK problem. It touches Ethereum execution, hardware, client architecture, networking, decentralization and protocol security.
Post-quantum Ethereum is not only a cryptography problem either. It touches accounts, wallets, account abstraction, validator signatures, proof aggregation, data availability, formal verification and protocol migration.
India is also particularly relevant here. There is already a strong community of ZK, cryptography and protocol engineers in India, but the path from being interested in ZK to contributing to Ethereum protocol research can still feel unclear. We want the hub to help close that gap.
Why a Community Hub rather than a one-time talk or workshop?
There is no single finished system here to present. The work is moving quickly and a lot is still open:
- How should Ethereum introduce proof-based execution verification?
- What does zkVM diversity look like when these systems become protocol infrastructure?
- How do we compare different provers beyond a single benchmark number?
- Can real-time proving remain accessible enough to avoid unnecessary prover centralization?
- How should Ethereum move away from cryptographic assumptions that are not post-quantum secure?
- How do we aggregate post-quantum signatures efficiently?
- What does formal verification look like when proof systems become part of Ethereum’s critical infrastructure?
These are better explored as conversations and working sessions than as a sequence of presentations.
A talk can explain how a zkVM works. A hub can let someone look at a real Ethereum block on Ethproofs, compare proofs generated by different zkVMs, understand the architectures behind them, and then sit with an engineer working on one of those systems.
A talk can explain why quantum computing affects elliptic-curve cryptography. A hub can map where ECDSA, BLS and KZG appear across Ethereum and then explore the work being done around account abstraction, hash-based signatures, leanXMSS, leanVM and post-quantum blobs.
How would the hub support builders of a free, open, private and verifiable future?
Ethereum’s ability to remain verifiable should not depend on increasingly powerful hardware being available to every validator. This is one reason proof-based verification is interesting: instead of asking every validator to independently perform the same computation, a prover can generate a cryptographic proof of correct execution and other participants can cheaply verify it.
At the same time, verifiability needs to survive changes in the cryptographic assumptions Ethereum relies on. Preparing for post-quantum cryptography is part of that longer-term responsibility.
What connects these efforts is open-source cryptography. The infrastructure that Ethereum may eventually depend on should be inspectable, benchmarkable, reproducible and open to competing implementations.
The hub would put attendees in front of that work and show them where they can contribute.
Past Experience
Have you organized a Community Hub at a past Devcon edition?
zkBankai has not previously organized an official Devcon Community Hub, but we have organized technical residencies, workshops, research sessions and whiteboard spaces around Devcon and the broader ZK ecosystem.
zkBankai Hacker house (Bengaluru, ETHIndia week 2023)
A seven-day ZK hacker residency bringing together around 30 ZK hackers, researchers and builders. The format was intentionally small and collaborative, giving participants time to work together rather than structuring the entire week around presentations. One of the projects that came out of that residency was uZumaKi, an open-source effort exploring benchmarking across ZK systems, including zkVMs, proving systems, DSLs and hardware.
PlonkCafE (Devcon 2024, Bangkok)
Run as part of the Aggregation Cave: a multi-hour academic and whiteboard session focused on understanding the mathematics behind PLONK and Plonkish systems. The format was deliberately simple: bring people interested in the same technical problem into a room, give them whiteboards and enough uninterrupted time to actually work through it.
Whiteboarding sessions at ETH Taipei, plus open-source development programs across Plonky3 and Circom.
Noir Christmas Camp (with Aztec)
A three-session program progressing from Noir and Barretenberg fundamentals, to building applications with NoirJS, to circuit security and production readiness.
What would we carry forward?
The main thing we have learned from these formats is that people pick up cryptography much faster when they have time to sit with it.
People need somewhere they can ask the question they did not want to ask during a conference talk, draw something on a whiteboard, open the implementation on their laptop and work through it with someone else.
For Devcon, we want to keep that technical depth while making it easier to walk in cold. Someone should not need to already be a cryptographer to participate in the hub.
Implementation
We want the space to feel closer to an open protocol and cryptography lab than a project booth.
Space and equipment
Most of what we need is relatively simple:
- Whiteboards
- Large display or TV
- Tables suitable for laptops and small working groups
- Chairs and some flexible seating
- Reliable internet
- Power outlets
- Space for physical research and contribution boards
Persistent installations
We would like to create a few persistent pieces inside the hub.
1. Ethereum Proofs Wall
A visual explanation of how Ethereum works today and how proof-based verification changes that model.
The display can also surface live or recent Ethproofs data, so attendees can see Ethereum blocks being proven by different zkVM implementations and compare metrics such as proving time, latency, cost and proof size.
2. Ethereum Cryptography Map
A second map showing where cryptography exists across Ethereum today:
| Layer | Primitive |
|---|---|
| Accounts | ECDSA |
| Consensus | BLS |
| Data availability | KZG |
| Execution | zkVMs / proof systems |
From there, attendees can explore where post-quantum considerations appear and which research directions are being explored.
3. Open Problems Board
Researchers and participating teams can continuously add problems, questions and contribution opportunities, ranging from beginner-friendly engineering tasks to open research questions.
Areas of Interest
We would rather describe the areas we want the hub to hold than commit to a fixed set of tracks. The underlying work is moving quickly, these areas overlap heavily, and the overlap is usually the interesting part.
Most of the weight sits on Ethereum’s post-quantum transition. Proving is covered as part of how that transition happens rather than as a separate subject.
Ethereum’s post-quantum transition
We want to avoid treating quantum computing as an imminent catastrophe. The interesting engineering problem is how a decentralized protocol can gradually change foundational cryptographic primitives without introducing greater risks in the process. That question breaks down into several distinct areas of work.
What actually breaks
- What does quantum computing actually break, and what does it leave intact?
- Ethereum’s current cryptographic assumptions, layer by layer
- ECDSA and user accounts
- BLS and validator signatures
- KZG and data availability
Post-quantum signatures and aggregation
- Hash-based signatures as a foundation
- Why post-quantum signatures are difficult to aggregate
- leanXMSS and leanSig
- leanVM and proof-based signature aggregation
- What aggregation costs at validator-set scale
Accounts, wallets and authentication
- Account abstraction and quantum-safe authentication
- Post-quantum transaction migration
- What changes for users, wallets and existing keys
Data availability
- Post-quantum blobs
- What replaces or supplements KZG commitments
Migration and cryptographic agility
- What should Ethereum migrate first?
- What does a realistic migration path look like?
- Designing for cryptographic agility rather than one-time replacement
- How a migration is validated before it is relied on
Where proving and post-quantum work meet
These two directions are usually presented separately, and we think the connection between them deserves dedicated space in the hub.
- Hash-based proof systems are already post-quantum, which makes proof-system choice part of the post-quantum question rather than adjacent to it
- Proof-based signature aggregation turns a cryptographic problem into a zkVM problem
- Protocol snarkification is one of the mechanisms by which a post-quantum migration becomes practical
- What assumptions a proof system inherits, and which of those survive a quantum adversary
Proving Ethereum
- What does it mean to prove an Ethereum block?
- From re-execution to proof verification
- L1 zkEVM architecture and Type-1 zkEVMs
- Anatomy of a zkVM
- Real-time proving and home proving
- Proving hardware and acceleration
- Proof size, latency, cost and security
- Multi-prover architectures and zkVM diversity
- What happens when zkVMs become part of validator infrastructure
Ethproofs, benchmarking and reproducibility
Ethproofs gives us real data to work from. Instead of discussing zkVM performance abstractly, attendees can inspect proofs generated for actual Ethereum blocks.
- Reading Ethproofs
- Comparing zkVM architectures
- What makes a useful proving benchmark?
- Beyond proving speed: security, proof size and operational constraints
- Reproducing an Ethereum block proof
- How should Ethereum evaluate zkVMs?
- Open-source benchmarking and reproducibility
We would like to invite engineers from zkVM teams currently participating in the broader Ethereum proving ecosystem, subject to availability.
Verification, open source and contribution
- What formal verification looks like when proof systems and new primitives become critical infrastructure
- Inspecting, reproducing and comparing implementations
- Where new contributors can actually start
Possible Speakers and Contributors
The speaker list should stay flexible and be put together with the relevant communities. We would like to reach out to contributors from:
Ethereum Foundation Protocol. Researchers and engineers working across zkEVMs, protocol snarkification, post-quantum Ethereum, lean consensus, account abstraction and protocol security.
lean Ethereum / Post-Quantum Ethereum. Researchers working on leanXMSS, leanSig, leanVM, post-quantum consensus and cryptographic agility.
Ethproofs. Contributors working on Ethereum block-proof collection, benchmarking and proof verification.
zkVM teams. Engineers from different proving systems currently working toward real-time Ethereum proving.
Ethereum client teams. To bring the perspective of the software that actually implements and validates the protocol.
Academia and independent cryptographers. Particularly researchers working on proof systems, hash-based cryptography, post-quantum signatures, formal verification and cryptographic security.
The final programming would be developed with these communities rather than treating the initial proposal as a fixed conference schedule.
Sample Program
The exact program will be developed with participating researchers, teams and contributors closer to Devcon. A typical day could look like:
| Time | Session |
|---|---|
| 09:00 to 10:30 | Open Hub, onboarding and whiteboard discussions |
| 10:30 to 12:30 | Technical talks and research discussions |
| 12:30 to 14:00 | Open Hub and office hours |
| 14:00 to 16:00 | Workshops, code walkthroughs and demos |
| 16:00 to 18:00 | Open research sessions, working groups and contributor hours |
Across the four days, programming would move across these areas, weighted toward Ethereum’s post-quantum transition, with proving, benchmarking and contribution work running alongside it.
The schedule is intentionally flexible. We would develop the final program collaboratively with participating teams and researchers closer to Devcon.
Supporting Ethereum’s Core Properties, Open-Source Ethos and Community Bridge-Building
Post-quantum research asks whether Ethereum can preserve its security guarantees even when some of today’s cryptographic assumptions eventually stop being safe.
Open-source development matters to all of this. If zkVMs, proof systems and new cryptographic primitives become critical Ethereum infrastructure, developers should be able to inspect them, reproduce results, compare implementations and participate in their development.
The hub also creates a bridge between communities that can otherwise remain fairly separated:
- protocol developers ↔ ZK engineers
- cryptographers ↔ client developers
- hardware engineers ↔ proof-system researchers
- researchers ↔ new contributors
- global protocol teams ↔ India’s Ethereum and cryptography community
Audience
The hub is aimed at the people building and studying Ethereum’s protocol layer: protocol and client developers, ZK and zkVM engineers, cryptographers, security and formal verification researchers, wallet and account abstraction developers, and the hardware teams working on proving infrastructure. It is equally for students, academic researchers, open-source contributors and anyone who wants to understand where this work is heading and how to take part in it.
No prior knowledge of post-quantum cryptography or zkVM internals should be required.
