Alice Liu: Hi Justin, thank you so much for taking the time to sit down with me. It’s a pleasure to have you here. We’re very excited to dive into your work and hear your thoughts on Ethereum and the evolution of ZK.
Justin Drake: Absolutely, Alice. Thanks for having me. ZK is such a fascinating topic, and it’s one of the key areas that got me into Ethereum. It’s close to my heart.
Alice: That’s great to hear. Could you start by sharing a bit about your background? How did you first get involved with ZK, Ethereum, and the broader Web3 ecosystem?
Justin: Sure. My journey into crypto started with Bitcoin back in 2013. It was actually Dankrad Feist (@dankrad) - of Danksharding fame - who introduced me to Bitcoin. Together, we started the Bitcoin ATM, and eventually, I co-founded a Bitcoin startup. Unfortunately, that startup didn’t take off, but it gave me time to explore the cryptographic space more deeply. I became fascinated with SNARKs, this “dark magic” of cryptography.
Dankrad and I both studied mathematics in Cambridge, so I already had some grounding in finite fields and other necessary concepts. During those early days of @Zcash, I wrote a blog post exploring how SNARKs could be applied to @Ethereum. I called it “ZEthereum”, essentially envisioning an Ethereum version with a precompile to verify SNARKs. This idea was very similar to what we now call native rollups.@EliBenSasson saw my post and invited me to a conference at the Technion in Israel, where I met key figures like @Zooko, @VitalikButerin, and early members of what later became @StarkWareLtd. That’s how I got fully immersed in ZK. When I joined the @EthereumFndn, I initially worked on sharding and later on the Beacon Chain, but the vision of ZEthereum has always lingered in the back of my mind.
Alice: That’s such a rich journey, starting with Bitcoin and later diving into SNARKs during Zcash’s early days. You’ve seen ZK evolve significantly over the years. You mentioned recent performance breakthroughs in ZK—what excites you most about those developments?
Justin: The pace of improvement is remarkable. Every year, we’re seeing 5-10x advancements in performance. One major catalyst for this progress is SNARK ASICs - custom silicon for accelerating SNARK proving. This is something I’m particularly excited about. At the ZK Summit in Athens, I gave a talk about this concept.
The Ethereum Foundation is also spearheading initiatives to accelerate ZK. For instance, we have a $20 million bug bounty program to formally verify RISC-V ZKVMs, and there’s ongoing work to harden Poseidon as a hash function. Poseidon’s been around for five years now, and our goal is to ensure it’s secure enough for Layer 1 use within the next three years. It’s interesting to note that Satoshi’s choice of SHA-256 for Bitcoin and Vitalik’s choice of Keccak for Ethereum both came after roughly eight years of maturity for those functions. By 2027, Poseidon should hit that same milestone.
We’re also launching “ethproofs.org”, a platform for benchmarking ZKVMs. It’ll showcase proofs, costs, and performance metrics for various ZKVMs, fostering friendly competition and innovation. And finally, there’s potential funding for SNARK ASIC development, which could push us closer to real-time proving.
Alice: Those are huge strides. Despite these advancements, mainstream adoption of ZK still faces challenges. What do you see as the biggest obstacles right now, and where should we focus our efforts to overcome them?
Justin: The good news is that proving costs are no longer the bottleneck they once were. For example, SP1 reports that proving a typical EVM transaction now costs a tenth of a cent - far less than the data availability costs. However, we still have work to do on latency. Many use cases are bottlenecked by the time it takes to generate proofs, which can range from seconds to minutes. Real-time proving, where proofs are generated within a slot time, is critical for unlocking trustless, synchronous composability between rollups.
Security is another key issue. ZK systems are immensely complex, and critical bugs remain a risk. Client diversity and formal verification are two solutions we’re pursuing. With ZKVMs, we now have a single system to audit instead of individual circuits for each application, which simplifies security efforts. Additionally, lookup tables and other techniques are making circuits easier to analyze.
Alice: It’s encouraging to hear that the community is addressing these challenges methodically. You’ve mentioned ZKVMs several times. How do they fit into Ethereum’s long-term vision?
Justin: ZKVMs are foundational to the idea of a fully snarkified Ethereum, or what I call “ZKEthereum”. They’ll be integral at all three layers - consensus, data, and execution.
For the consensus layer, ZKVMs can enable subslot proving, ensuring validators can quickly verify block validity. For the execution layer, native rollups could leverage ZKVMs as precompiles, making it easier for developers to build EVM-equivalent systems without additional overhead. This eliminates divergence issues and ensures seamless governance updates. And for the data layer, SNARKs can secure erasure coding and provide post-quantum security.
Alice: Let’s talk about Beam Chain, your proposed redesign for Ethereum’s consensus layer. How does it align with Ethereum’s broader roadmap?
Justin: Beam Chain doesn’t change the content of Ethereum’s roadmap but rethinks how it’s tackled. The roadmap often focuses on incremental upgrades - the merge, the surge, etc. Beam Chain slices the problem differently, focusing on the consensus layer as a standalone area for innovation.
One of its goals is to simplify the Beacon Chain’s design. The Beacon Chain, as it exists today, is needlessly complex and slow to upgrade. Beam Chain proposes writing a new spec from scratch, incorporating all the latest ideas, and implementing it as a single major upgrade rather than a series of incremental changes.
Alice: Why is now the right time for Beam Chain? What developments make it feasible today?
Justin: Two key developments come to mind. First, MEV has become a massive factor since the Beacon Chain’s design was finalized over five years ago. We now have better mechanisms to mitigate MEV-related issues. Second, SNARK performance has reached a point where it’s viable for Layer 1 use. ZKVMs and other advancements have also made it easier to integrate SNARKs safely and effectively.
Alice: What’s needed to make Beam Chain a reality? Are there specific technical prerequisites?
Justin: Security is the biggest prerequisite, which we’re addressing through client diversity and ZKVMs. Real-time proving is another critical factor. For this, the consensus layer needs to become SNARK-friendly, starting with replacing Keccak with Poseidon as the hash function. Other changes include making the serialization and merkelization of data SNARK-friendly.
Alice: As we near the end of our conversation, how can others get involved with Beam Chain? Any advice for those who want to contribute?
Justin: We’ve set up an email address - beam.chain@ethereum.org - for anyone interested in contributing. The response has been incredible so far, with around 12 teams and 50 individuals expressing interest. For 2025, the focus will primarily be on speccing and prototyping, so it’s a great time for researchers and developers to engage. Peer-to-peer networking experts and those with experience in cryptography are especially encouraged to reach out.
Alice: Thank you so much, Justin. This has been an insightful discussion. It’s exciting to hear about the progress being made toward Beam Chain and Ethereum’s broader vision. We look forward to seeing these ideas come to life.
Justin: Thank you, Alice. It’s been a pleasure to share these thoughts with you.
For up-to-date insights on the latest from Justin and the Ethereum Foundation, follow @drakefjustin and @ethereumfndn on X.
