Alice: Thank you for being here today, Elias.
Elias: Thank you for having me. I'm very happy to be here.
AL: I'm wondering, Elias, if you can first start off by introducing yourself. Maybe share your story on how you got involved in both the Web3 space and specifically focused in ZK?
ET: Sure. After college, I studied math and political sciences. It was a double major because I didn't really know what to do, so I wanted to do a bit of everything. In my last year, I had an exchange in Singapore, where I met a friend who was a Bitcoin Maxi. We were chatting about crypto, and he got me to download Coinbase at the time. Around the same time, when I went back to France, my brother, who was a lawyer for crypto companies in Paris, also got me interested. When I discovered the new opportunities in the field, it made me want to learn development and get involved. That's how I got into crypto around 2019 or 2020.
I slowly converged towards Ethereum and rollups in particular. I remember a time when sending transactions from my wallet cost $20, and my friends and I joked about it during what felt like ‘DeFi Summer’. When I wanted to get more involved, there were only two zkRollups at the time - zkSync and Starknet. I was working as a full-stack engineer at a dev shop, and I asked to attend a StarkNet event. That's where I met the Starknet and StarkWare crew. We got along well, and I found not just colleagues but friends. That's how I ended up where I am today.
AL: I love that journey - starting from college, getting into crypto, and then finding your place in the Starknet community. Can you speak a little bit about your broad vision for the ZK space? Where do you see it going in the next few years? And what does the ‘ZK endgame’ mean for you?
ET: Sure. I'll try to keep it brief, as it's a broad topic and it's always tough to predict the future. But I think we're going to see a lot of infrastructure converge towards provable VMs, also known as zkVMs. Depending on the use cases, they might be adapted, but overall, I believe we'll see a shift from low-level circuits to zkVMs. There aren't many cryptographers available, and while you can expect engineers to have some notion of ZK concepts, you can't expect them to constantly write circuits. It’s not very maintainable or auditable.
If we want the entire internet of value - even outside of blockchain - to be verifiable through ZK, we need a lot more people contributing to ZK infrastructure. I think ZK will infuse the internet similarly to how security certificates did. This will help boost cooperation between actors who don't necessarily trust each other by default, all while maintaining verifiability and transparency.
AL: Absolutely, and I think that resonates a lot with the current debate about zkVM versus custom circuits. Some believe that as adoption increases, more people will want to use circuits, while others think zkVMs will prevail because of their lower entry barrier. Good to hear your take on that. What do you think are the most pressing challenges in the ZK space today, and what are you specifically focused on addressing?
ET: From a pragmatic perspective, we need to drive down the costs. ZK proving has to become something that operates in the background without the user thinking much about it. It needs to be fast, cheap, and nearly invisible - like a security check mark for integrity. Today, if you compare an OP Stack chain that isn't proven to a proven chain like Scroll or other zkRollups, you'll notice the cost is higher for ZK. Because of this, ZK is often seen as an annoying extra cost. The goal is to make ZK even cheaper than optimistic rollups in the next year or two so that it becomes a no-brainer in terms of UX, security, and interoperability.
AL: Totally agree. Now, focusing specifically on zkEVMs like Kakarot and the development of zkVMs, can you talk about some of the trade-offs, considerations, advantages, and disadvantages between these approaches?
ET: Sure. To provide a bit of context, a zkEVM is an environment that supports running Ethereum-like experiences - smart contracts written in Solidity - in a provable setting. So you can generate proofs for EVM-based transactions, like those involving Uniswap, Aave, and others. Kakarot, for instance, relies on the work StarkWare has done by using their core zkVM to achieve this.
I wouldn’t exactly oppose zkEVM versus zkVM, because in fact, the core engine of Kakarot - our provable EVM - is built on a zkVM. The VM is essentially the lower layer, and we have built the EVM on top to provide an Ethereum-like experience. There are some inherent overheads when it comes to this layered approach, but the architecture is designed to offer a secure, verifiable EVM that is tightly integrated with the capabilities of Cairo and Starknet.
AL: That makes a lot of sense. I like how you framed that - that the EVM is effectively an abstraction running on top of a secure, verifiable environment. Given the importance of balancing compatibility and scalability, what motivated you to start Kakarot? Did your vision evolve as the project grew?
ET: The story of Kakarot is really fun. About two years ago, in July, Shahar Papini, co-inventor of Cairo, had the idea for Kakarot. Back then, I wasn’t even in the StarkNet ecosystem yet. He tweeted about how it would be cool if you could write an EVM on top of the Cairo VM - a novel concept of layered abstraction. I found out about Kakarot through Abdel, who is the lead of the exploration team at StarkWare, while I was on an Only Dust mission.
Only Dust is an open-source contributor community that started with Starknet, and we took Shahar's idea and bootstrapped the community around it. It began as an open-source public good project on the Cairo stack. Later, as we saw potential, StarkWare greatly helped to accelerate and formalize Kakarot into a driven startup.
When we first started, I didn’t fully realize the scope of work required to write ZK circuits compared to ZK VMs, but it's become clear now. Our vision has evolved, especially as we see other projects like RISC Zero, Succinct, and Jolt expanding the zkVM space. Vitalik and Shahar were ahead of the curve in recognizing the value of using a zkVM for such tasks, and we're now catching up and evolving alongside others in the space.
AL: That evolution is exciting to hear about. You also mentioned your involvement with Only Dust - an open-source community. How important do you think open-source development is for the ZK space?
ET: Short answer - it's crucial. In my opinion, it doesn’t make much sense not to be open-source when developing ZK systems. Transparency is fundamental when we are talking about proof systems that secure networks of value. If people can’t access or verify your code, it raises significant concerns. Open-source also accelerates cryptographic advancement. ZK proofs existed 20 to 30 years ago but lacked the practical context and adoption they needed. With blockchain, cryptography has advanced ten years in just one, thanks to open collaboration and funding.
That said, I do understand why some projects may choose to remain closed source initially - to protect intellectual property and prevent competitors from forking before launching. But eventually, the push for open standards and transparency is strong. We've seen projects like StarkWare, RISC Zero, and others gradually open-source their tech under community pressure, and I think it's a positive development for the entire ecosystem.
AL: Back to Kakarot - I'm interested in the developer's journey. Can you share a bit about the stages a developer goes through in building ZK dApps on Kakarot and the challenges involved? How does Kakarot cater to developers and users?
ET: The experience of building on a zkEVM like Kakarot is intended to be very similar to building on a standard EVM. Developers write Solidity or Vyper, test, deploy, and interact with contracts through tools like MetaMask - ideally, it should all feel familiar. That said, there are current limitations - ZK still needs about another year to hit a performance level that feels truly seamless.
For instance, on chains like Base, you can execute more compute-heavy transactions compared to Scroll or Kakarot, due to proving overhead. These issues should be mitigated in time, as proving systems improve. The overall goal for Kakarot is for developers to feel the benefits of verifiability without facing UX penalties.
AL: Right, that makes sense. Given your deep involvement in this space, are there any ZK apps, infrastructure projects, or technologies that excite you besides Kakarot?
ET: Absolutely. One project I'm excited about is the work Gaga Labs is doing in the Cairo open-source community. They've created a way to verify Noir proofs on Cairo, allowing developers to write privacy-preserving dApps and verify them on Kakarot. I'm also intrigued by what's happening in the Rust and RISC-V space. Projects like RISC Zero, Succinct, and even POWDR - a framework for building zkVMs - are all very cool. There’s a lot of innovation around VMs, and it’s fun to see it all unfold.
I'm also starting to see the value in real-world assets on-chain - like tokenized T-bills - and I'm warming up to the idea of how traditional finance and crypto can merge in beneficial ways. And of course, privacy remains a huge gap that needs to be addressed, so I'm watching privacy-focused projects very closely as well.
AL: Those are some great insights, especially on the emerging ZK trends and your enthusiasm for privacy solutions. As we start wrapping up, what kind of announcements do you have for Kakarot, or how can developers and users further engage with your project?
ET: For developers, we're running a seed program that's like an accelerator or online hackathon. We believe that ecosystems grow around people who want to build cool stuff and take it to production, so we aim to support devs who have an entrepreneurial mindset. Our codebase is fully open-source, and we're always looking for adventurous contributors. You can find us on GitHub - just come by and make a pull request if you're interested.
For users, you can join our Discord and follow us on Twitter at @KakarotZkEvm. We’re currently in public testnet and aiming for mainnet by the end of the year - December. Once we launch, Starknet will officially be a multi-VM chain, and it will be the first ZK rollup to do so. We’re excited about the next few months and look forward to seeing people get involved.
AL: Thanks so much, Elias, for joining us today and sharing your insights. I really appreciate it.
ET: Thank you, Alice. I had a great time. Thanks for having me.
Keep up-to-date with Elias on Twitter: @ETazou
