The zkWars | zkSync & Scroll

The zkWars are heating up. With 3 different teams recently announcing their zkEVM, we’re joined by Alex Gluchowski of zkSync and Ye Zhang of Scroll. Optimism’s Ben Jones cohosts as we explore why zkEVM is such a big deal, the respective roadmaps to mainnet, and of course… wen token? ------ 📣 Forta | Help Make Web3 a Safer Place https://bankless.cc/Forta ------ 🚀 SUBSCRIBE TO NEWSLETTER: https://newsletter.banklesshq.com/ 🎙️ SUBSCRIBE TO PODCAST: http://podcast.banklesshq.com/ ------ BANKLESS SPONSOR TOOLS: 🚀 ROCKET POOL | ETH STAKING https://bankless.cc/RocketPool ⚖️ ARBITRUM | SCALING ETHEREUM https://bankless.cc/Arbitrum ❎ ACROSS | BRIDGE TO LAYER 2 https://bankless.cc/Across 🦁 BRAVE | THE BROWSER NATIVE WALLET https://bankless.cc/Brave 🌴 MAKER DAO | DECENTRALIZED LENDING https://bankless.cc/MakerDAO 🔐 LEDGER | SECURE STAKING https://bankless.cc/Ledger ------ Topics Covered: 0:00 Intro 3:15 Crypto 101 10:00 Alex and Ye 13:25 zkSync 18:20 Scroll 22:30 What's Different about zkSync 31:10 What's Different about Scroll 37:15 zkProof Performance 41:30 Decentralizing Provers 46:30 Approaching Developers 57:07 Challenges to Upgrading 1:03:40 Vibe Check 1:09:20 Centralized Keys 1:17:45 Closing ------ Resources: Ben Jones https://twitter.com/ben_chain Alex Gluchowski https://twitter.com/gluk64 Ye Zhang https://twitter.com/yezhang1998 ----- Not financial or tax advice. This channel is strictly educational and is not investment advice or a solicitation to buy or sell any assets or to make any financial decisions. This video is not tax advice. Talk to your accountant. Do your own research. Disclosure. From time-to-time I may add links in this newsletter to products I use. I may receive commission if you make a purchase through one of these links. Additionally, the Bankless writers hold crypto assets. See our investment disclosures here: https://newsletter.banklesshq.com/p/bankless-disclosures

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:09Ryan Sean Adams?

  Hey, Bankless Nation. Welcome to another live edition of State of the Nation. Today, we're going to talk about the Zero Knowledge EVM, the ZK EVM. David guided us through, this is going to be formatted a little bit differently in that after the intro, I am actually stepping out. So who do we have on the show? How are we formatting this? And who is helping us out today?

• 0:32David Hoffman?

  Oh, we got my good friend Ben Jones from Optimism. And Ben is going to be our technical co-moderator here to help us unpack the ZK EVM. Ryan, you and I, I think we're pretty smart, but there's way smarter people in this industry. And there's way more technical things in this industry that we just kind of need some help unpacking. And so we're bringing in some extra help from the optimistic roll-up world to help us unpack the ZK side of things. So coming in, in the second half of the show, once we get there, we'll have Alex from ZK Sync and Yay from Scroll. And Ben is going to help us guide us through this conversation to understand a little bit more about the world of the ZK EVM.

• 1:12Ryan Sean Adams?

  It's a world that's heating up. I think the title of this episode is the ZK EVM Wars. And I think appropriately, it was like three weeks ago, all three ZK EVMs announced something big the exact same week. So the ZK wars are heating up. David, also got to tell them a little bit about our friends at Forta. And I think this is really important that we talk about tools like Forta right now. Because since, did you know, since 2021, 138 Web3 projects have been hacked? And that's cost victims a total of $2.3 billion. And of course, yesterday, David, we just saw the latest bridge hack, $190 million out of the Nomad Bridge.

• 1:56Ryan Sean Adams?

  And so we reset the clock. It's been, now it's been zero days since the last incident. Tell us a little bit about how Forta is trying to fix this.

• 2:07David Hoffman?

  Yeah, we can all do our best with smart contract audits and formal verification and blah, blah, blah, blah, blah. And everyone should be doing that. But you can also do an additional layer of protection, which is real time mempool monitoring. And so the way I like to explain this is there's that game in like the 90s where like asteroids were coming in and you would shoot the asteroids before they hit the earth. This is like that, but like smart contract exploits. So you like zap the malicious transactions before they actually execute. And this is what Forta provides for the world. Real time monitoring of your DeFi app, your NFT project, your DAO, your treasury, anything that's at risk, that's in the world of Ethereum. This is a missile defense system for your smart contract.

• 2:47Ryan Sean Adams?

  That's a cool analogy, David. Look who they're protecting here. $36 billion. Compound Balancer, Liquidity, Instap, Maker, Lido, all of these folks use Forta. So if you want to learn more, go check it out. The Forta Network at forta.org. There's a link in the show notes, banklist.cc/forta. All right. I'm going to ask you the question I ask before every state of the nation, David.

• 3:09David Hoffman?

  Wait, before we get there, Ryan, I want to talk about a little bit about just some intro stuff. Because we've got Ben here. And so before, there's going to be a bunch of questions that I think we don't actually necessarily have to ask every single participant here in this in this stream. So we're going to get some beginner questions out of the way. And Ben's going to going to help us with that here. So Ben, I want to start with this very first question, which is, what is the EVM? And why is it important? And then we'll get to what does it mean to zero knowledge EVM?

• 3:37Speaker 02

  Oh, good question. And thanks for having me on, y'all. Okay, what is the EVM?

• 3:44Speaker 02

  EVM is...

• 3:47Speaker 02

  What the heck does that mean? Okay, basically, it is a way to interpret Ethereum programs or Ethereum smart contracts. So basically, a virtual machine is this notion that you map a bunch of basically numbers, right? Everything in a computer's expressed as a number. And you map certain numbers to certain instructions. Instruction like add, or like divide, or like call, when you want to go and call another smart contract. This is the basis for how you construct smart contracts on Ethereum, in virtual. Right? Some solidity code happens behind the scenes is that's taken from text, goes through something called the compiler that turns into a bunch of numbers, which is all the instructions that implement the program That's the EVM.

• 4:32David Hoffman?

  Very important.

• 4:33Speaker 02

  Yes.

• 4:33David Hoffman?

  I would say crucially important.

• 4:35Speaker 02

  It is one of the things that makes Ethereum Ethereum.

• 4:38David Hoffman?

  Okay, and so we have that. That's what the Ethereum Layer One is. What does it mean for to have a ZK EVM? Why are so many people hyped on a ZK?

• 4:48Speaker 02

  Hmm, yes. So I think they're hyped for scalability. It's very interesting because ZK EVM, right? What is the ZK there? It's zero knowledge, right? And interestingly, it does use these things called zero knowledge proofs. Arguably, ZK isn't the most important part of the zero knowledge proof, right? So when you think of ZK snark, right? Might be this zero knowledge succinct, non-interactive argument of knowledge. A really key letter in that acronym is the S, is the succinct. Because the point of these proofs is that you can basically prove something in a very short manner. So a ZK EVM is about taking the EVM and converting it or running it inside a zero knowledge environment that lets you prove things succinct. So what does that mean? Basically, it means you can take the EVM

• 5:33Speaker 02

  and you can write a proof that says the result of these 10 transactions is state X, state Y, right? You prove the results of Ethereum virtual machine.

• 5:44Speaker 02

  But what's interesting about this is you could make that not 10 transactions, but 100 or 1,000, and still the proof size stays the same. So you can see why this might be very compelling.

• 5:55Ryan Sean Adams?

  Can I just bake this down into kind of layman's language here? So the EVM thing, that's the thing that turns Ethereum from a calculator into a computer. And the EVM thing is the thing that Bitcoin does not have and the reason it functions more like a calculator. You can't run programs on top of it, right? And then the ZK part makes the EVM thing, the computer part of Ethereum, much more scalable because it compresses it into this very tiny size.

• 6:28Speaker 02

  Yeah, I think that's a good way of thinking about it. There's a little more nuance in terms of like, you know, for example, if you're posting 10 transactions versus 1,000 transactions and you're still rolling those up, right? If we're talking about a ZK pull-up, right? Then there's still some cost there that fundamentally can't be compressed in quite the same way. You compress quite a bit, but it doesn't like disappear. There's more nuance, but that's absolutely.

• 6:52David Hoffman?

  What would you say, why are people so stoked on a ZK EVM? Why is this such an important thing to fight over? Why are there so many teams racing to mainnet?

• 7:02Speaker 02

  Right, yeah, I mean, so there's a few reasons. The core of it, though, is that the EVM is what powers Ethereum and it's what has all the network. So I'm a co-founder of Optimism, which is an optimistic rollup protocol. We spent a lot of time making the optimistic rollups work with the EVM. Why did we do that? It's because that's where all the applications and all the developers live, right? So to build a good scaling solution, we want to do that. And it's definitely been a limitation of ZK scaling solutions. They can't go ahead and take advantage of this. I think people are excited because there's potential with an EVM build on that network.

• 7:39David Hoffman?

  One last question before we get to the panelists. Ben, what are you hoping to get out of this conversation? What should listeners pay attention to listening to this? What are you also hoping to learn here?

• 7:50Speaker 02

  Good question. So it depends on who the listener is, right? I think that one of the things, obvious listeners would be like a user of these protocols, right? So I think you want to listen to what are the security properties like that you're interacting with? What is the roadmap of this thing that you're interacting with? I think if you're a developer, then really what you want to be thinking about is what does it actually mean in practice? Application.

• 8:17Speaker 02

  There's different ways that you can go about implementing. There's different levels of support for different things and aspects that you'll have access to. And so I think that's two bits of framing. As for what I want personally, oh, man, everything under the sun, really, I feel like, but including those questions. I'm secretly most excited to hear how we can integrate into. That's a whole nother.

• 8:40Ryan Sean Adams?

  Can you guys also go over, so I'm going to be grabbing the popcorn here and just watching as a bystander. But just throwing my one question in is can you guys talk a little bit about bridges? I know that's not typically like exclusive to ZK, but it's kind of like a rollup type technology. And I'm, I think a lot of people listening are probably. increasingly concerned about the security of bridges from one chain to another, or from mainnet to roll up from a mainnet to an alt L1. So I'd love to hear a bit more about that. And guys, we're going to get right to the episode. We're talking all about ZK EVMs. But before we do, we want to thank the sponsors that made this episode possible.

• 9:23David Hoffman?

  Rocketpool is your decentralized Ethereum staking protocol. You can stake your ETH in Rocketpool and get our ETH in return, allowing you to stake your ETH and use it in DeFi at the same time. You can get 4% on your ETH by staking it with Rocketpool, but you can get even more by running a node. Rocketpool is the only staking provider that allows anyone to permissionlessly join their network of validating Ethereum nodes. Setting up your Rocketpool node is easier than running a node solo, and you only need 16 ETH to get started. You get an extra 15% staking commission on the pooled ETH that uses your node to stake. You also get RPL token rewards on top. So if you're bullish ETH staking, you can boost your yield by adding your node to the decentralized Rocketpool network, which currently has over 1,000 independent node operators. It's yield farming, but with Ethereum nodes. You can get started at rocketpool.net,

• 10:08David Hoffman?

  and you can also join the Rocketpool community in their Discord. You can find me hanging out there sometimes in the chat, so I'll see you there. Arbitrum is an Ethereum Layer 2 scaling solution that is going to completely change how we use DeFi and NFTs. Some of the coolest new NFT collections have chosen Arbitrum as their home, while DeFi protocols continue to see increased liquidity and usage. You can now bridge straight into Arbitrum for more than 10 different exchanges, including Binance, FTX, Huobi, and Crypto.com. Once on Arbitrum, you'll enjoy fast transactions with cheap fees, allowing you to explore new frontiers of the crypto universe. New to Arbitrum, for a limited time, you can get Arbitrum NFTs designed by the famous artists Ratwell and Sugoi for joining the Arbitrum Odyssey. The Odyssey is an eight-week-long event where you complete on-chain activities and receive a free NFT as a reward.

• 10:50David Hoffman?

  Find out more by visiting the Discord at discord.gg/Arbitrum. You can also bridge your assets to Arbitrum at bridge.arbitrum.io and access all of Arbitrum's apps at portal.arbitrum.1 in order to experience DeFi and NFTs the way it was always meant to be: fast, cheap, secure, and fiction-free. MakerDAO is the OG DeFi protocol. The first DeFi protocol to ever exist, even before we called it DeFi. MakerDAO produces DAI, the industry's most battle-tested and resilient stablecoin. Using Maker, you don't need to sell your collateral if you need liquidity. Instead, you can spin up a Maker Vault and use your collateral to mince DAI directly. With Maker, the power to mince new money is in your hands. And there's something new in the MakerDAO ecosystem. Every time a new MakerDAO is opened, the owner can claim that PoW,

• 11:34David Hoffman?

  which contributes funds to One Tree Planted, an organization with ongoing global reforestation efforts, creating a world where digital participation and the health of our environment can live side by side. Soon, Maker will be present on all chains and Layer 2s, bringing the biggest and best DeFi credit facility to everywhere there is DeFi. So follow Maker on Twitter, @makerDAO, and learn from the oldest and most resilient DAO in existence. And we are back. I believe we fixed the audio issues, so chat, make sure, let me know if we have not. In the top right corner, we're talking to Alex Gluchowski from the ZK Sync Protocol. Alex, welcome to the show.

• 12:11David Hoffman?

  Cheers. And then in the bottom half in the middle, we got Yay from Scroll. Yay, welcome to the show.

• 12:19David Hoffman?

  So, beautiful. Before we get into some of the technical details of the project, I just want to kind of go through the context or the background, the genesis of each of your guys' respective teams. Alex, could you kind of just walk us through the history of ZK Sync? Where did it come from?

• 12:53Speaker 03

  Bitcoin, Ethereum, and all the schools.

• 12:55David Hoffman?

  Hang on, okay. I know, I know this is not audio issues. I just had you guys muted, so we're gonna start over again. Okay. In the top right corner, we got Alex Gluchowski from ZK Sync. Alex, welcome to the show.

• 13:09Speaker 03

  Hello, everyone. Very excited to be here.

• 13:11David Hoffman?

  And then in the bottom half, we got Yay from Scroll. Yay, welcome to Bankless.

• 13:16Speaker 04

  Hi, thanks for having me.

• 13:17David Hoffman?

  Okay, third time's the charm. Before we get into some of the technical details, I just want to go around into the background of each of your respective teams just to get a little bit of context about where each one came from. So Alex, we'll start with you. Where did ZK Sync come from? Like, what's the genesis story? What's the background? Can you kind of walk us through that?

• 13:35Speaker 03

  Absolutely, very habitus. So I'll start with my personal background. You might know that I was born in Soviet Ukraine and then grew up kind of like after the collapse of Soviet Union. And I was very impacted by the economic and social collapse and all the things that were going there. And it brought me to conclusion that there is nothing more impactful you can do in this world today than increase freedom, increase freedom of societies, increase individual freedom. And that is what brought me to crypto. Like, part of that is the, you know, the potential of crypto to enhance world's freedom, which I think is unparalleled with anything else. And the second part of my motivation was the technological challenges.

• 14:20Speaker 03

  And I have a software background, I was CTO for the last couple of years before moving into the space. And I just was looking at, like, it was three and a half years ago. Ethereum was just getting started, all the protocols were just being built, and there were a lot of issues around usability, insecurity, and like, everything was missing. Then I looked into kind of, what's going to be the end game? I was always interested in the end game, like, how do we get this thing in the hands of everyone in the world? And it was clear that all the problems that are very apparent are going to be solved very soon by some teams, except that, except scalability. That seemed like a really big black box. So I looked into what's going on in scalability space, and there was Plasma.

• 15:05Speaker 03

  And Ben, I know you are working on Plasma, my co-founder, Alex Lasso, was also working on that. So I met him at DefCon 3, I guess, in Prague. And we came, like, from, we both encountered the idea of zero knowledge proofs, of six-sim zero knowledge proofs. And we both had an immediate thought that, oh, you can apply that to Plasma and solve most of its issues, and actually get something that will work and bring us to the method of option. And back then, crypto protocols were not, like, ZK protocols were not as mature as they are today, but it was pretty clear that over the course of next

• 15:45Speaker 03

  Two, three, five years, we will get something that is workable in production, but we actually got there a lot sooner. A year later, Sonic appeared and two years later, we got Plonk. And that was something very, very useful. And Stark's appeared around the same time. And all the protocols are now getting converged towards like very, you know, like everything is going in the same direction. And we will have incredibly fast protocols, provers. You know, like all the mature tooling around that to get us to scale Ethereum with ZK in no time.

• 16:21David Hoffman?

  And before I hand it over to Yay from Scroll, Alex, the ZK Sync has been around Ethereum for a while. I remember using ZK Sync to like pay for Gitcoin grants in like 2020 or something. Can you just like speed run us through how ZK Sync has integrated itself into Ethereum over the last few years?

• 16:39Speaker 03

  Sure. So when we started out the project, we built the very first working ZK rollup on Ethereum. It was like, we called it back then Egnis, but we had to rename it to ZK Sync short afterwards because of the conflict. And it took us two more years to build the, like fully productive mainnet version for simple payments and swaps. It's live on mainnet for two, like, no, sorry, it took us one year and it's now live for two years. And after that, it was very clear that most people will need smart contracts. And simple application-specific ZK rollups or rollups or scalability systems are going to be very, very niche.

• 17:23Speaker 03

  And you really need this generic, you know, generic programmability with your incomplete programs. So we set out to build what is now known as ZK ABM, the Uh generic EVM compatible framework that is scalable under ZK conditions. Uh we launched the internal testnet over a year ago. We opened it to the public with Unisync for a Uniswap demo last fall. And the testnet is open to the uh like to everyone since over half a half a year. And we just announced a few weeks ago that we will be live on mainnet.

• 18:07Speaker 03

  Hundred days and it's now uh they um eighty seven days for me.

• 18:12David Hoffman?

  I'm sure Alex that you wake up every single morning and be like, there's eighty seven days left.

• 18:17Speaker 03

  We don't have a huge counter and it just goes.

• 18:21David Hoffman?

  All right, uh let's turn the conversation to to Yay from Scroll. Yay, can you explain a little bit about the the background behind Scroll? Because Scroll is newer on the scene. Uh and so this is uh something that's new for a lot of listeners and and including myself. Can you just explain a little bit about the background of Scroll? Where did Scroll come from?

• 18:36Speaker 04

  Yeah, yeah, sure, happy to. So Scroll started one and a half a year ago. We have three co-founders, including me, Hai Chen and Sandy. We were actually introduced by our mutual friend in the East Community. So before that, I was doing ZK research. It's pure about crypto and ZK stuff, about math and crypto not directly related to cryptocurrency. And I was working on the proving algorithms and hard work solution for the owner proof. Because years ago, the proving is the biggest bottleneck for using the owner proof in practice. So that's the the problem I work on, like how to make prover more practical and faster and how to support a larger circuit. And Hai Chen is an expert in building robust systems. He got his PhD from University of Washington.

• 19:19Speaker 04

  He has years of experience working Amazon, building very complicated systems. Like based on compilers, programming language and GPUs. So he has tons of experience of how to, you know, build a make a system more practical and run in real world. And Sandy is more, you know, like because three of us, like diverse a lot in our background. Sandy has been in the broader crypto space for many years. She has been doing investment in crypto since twenty seventeen. She has incubated many application level projects and also institutional facing product like products.

• 19:53Speaker 04

  She was attracted to Ethereum more strongly due to the rapidly growing community, the ethos of Ethereum, and also like innovations from dev developers. And when we met, it was, you know, instantly clear that we we shared the same vision on what was important. And there was nothing more exciting than us to, you know, scaling the basically our Ethereum and onboard the next billion of users for Ethereum. Because for a long time, it it wasn't very clear that whether the key event would even be technically possible. And previously, Zicker App can only support like payments for rather simple applications using some fixed circuit.

• 20:33Speaker 04

  But recent innovations, because we we are working on in this area, we know that recent innovations have make that finally possible. And we all want to build something which is truly impactful for the whole Ethereum community. And also, we were joined by our common vision to use this, you know, combining with Zicky Research, advanced technology, really solve the scalability issue of Ethereum. So that's basically the genesis of Scroll. And although like we are new, but we we have grown really fast. We have forty people in our team now, and thirty are engineers and researchers. So most are just strongly technical focused. And we have an incredibly strong technical team with mostly people has a strong math and crypto background.

• 21:17Speaker 04

  And this background is immensely useful for understanding the backbone of of the key VM, which highly relies on their own proof, basically all math and crypto stuff. And many of many members of our team had years of blockchain development experience and had been, you know, active contributor to a lot of open source reports like Foundry and stuff like that. And because our vision is aligned with Ethereum of being decentralized, many members of our team are also like, you know, quite global and decentralized. We we work remotely. We have people across Asia, US, and Europe, like including like China, Singapore, New York, Bay Area, Poland, Ukraine, Australia, a lot of other places.

• 21:59Speaker 04

  So I'm very proud of, you know, our, our current team and we are super focused on, on building like although we are, we are installs like previously and we want to be build the, the best like user and developer friendly ZKVM solution. And we work well together as a remote team. And also we, we have been very careful like in how we, we grow this team by bringing on the, the colleagues who are highly value aligned with a high integrity. And also the right motivation to work, work with us in this space.

• 22:29Speaker 02

  Nice. Yeah, beautiful. All right, David, I want to ask some questions. Can I get into it? Go for it. Okay, okay, okay, okay. So. All right, I think the first question that I would like to ask the both of you is. It's very clear that ZKBM, to your point in your intro questions to me, David, is like, you know, it's like been a problem on the horizon that we've been thinking about for a very long time. And like, when we first started the ZK scaling stuff, we did not start with the EVM, right? Cause it's a very, very hard problem. So obviously there's been huge strides made to your point earlier, Alex, and I have a suspicion. That there are different approaches being taken to solve this problem, right? Usually when there's a hard problem, you get a few different. Strategies. Strategies or ways, yeah.

• 23:12Speaker 02

  So what I'm really curious to hear from the, the folks on this panel are what do you think are the unique things about the approach that you take? What, and what are the things that are shared between the different approaches? And notably, right, we have two panelists here. There are a few other teams building ZK EVMs as well. So I'm really curious to hear from you guys, what you think the lay of the landscape is and what your strategy in particular is to tackle this in some unique way. And Alex, we'll start with you.

• 23:38Speaker 03

  Uh, sure. So. The approach we are taking goes back to how we think about the strategy of, of building ZK Sync and that goes back to the mission. Our mission is to accelerate the mass adoption of crypto for a personal sovereignty.

• 23:57Speaker 03

  Accelerate means move faster. We believe that it's coming, no matter what, but we wanted to arrive not in ten years, but in two years. And to move faster, you need to be very pragmatic. So what we learned from building the first version is that you're much better off launching something that works and then gradually iterating over it than like waiting for a perfect solution, trying to construct this abstract beauty in Bitcoin. So I have this picture, which you might know, like this is how we operate, right? With building gradually and not trying to get to fashion.

• 24:37Speaker 03

  And how it started, actually, we initially, there was no real way from the limitations of brewers and like from the protocols themselves to build a Turing-complete version of EVM. So we tried to build a non-Turing-complete version of smart contracts. And we had to construct a new language called ZIM. So we had to build a compiler team and we took Rust as a base, not the solidity, because we thought like if you have to learn a new language, which is going to have a lot of this internal limitations, it doesn't really matter, you need to learn from scratch, so let's take something that is more familiar to a broader audience.

• 25:19Speaker 03

  We quickly learned that it's going to be very problematic to force people to relearn the language and like to adopt the developer tools, everything like that, that's just going to be a mess for adoption. That's not what engineers want, on the one hand. On the other hand, there were some breakthroughs in the cryptography, like in Plong, recursive Plong, in improved efficiency for certain gadgets, for certain cryptographic functions that are required to build something like EVM, that we thought, okay, we're going to take on the challenge and actually build the full ZK EVM, something fully compatible with Ethereum, where you can take existing smart contracts, written in native solidity or Viper, and just take them and launch them on this thing.

• 26:04Speaker 03

  And we looked again, like what's going to be the fastest way to get there? So our head of engineering, Anthony Rose, is actually coming from SpaceX, used to be in charge of the satellite factory there. And we borrowed this concept of the critical path from SpaceX. Like, what's the shortest possible way for us to get to the goal? And it turned out that we can reuse our compiler skills and the and build something very similar to what we now know Stark was doing with Kyro, namely create a virtual machine that is optimized for probability under zero knowledge proofs, specifically

• 26:47Speaker 03

  optimized to be very efficient under Snacks. And then create this virtual machine with all the conventions of solidity and EVM. So that like all, all, all the calls, all the interactions, all, all the, you know, interfaces are exactly the same as EVM, but you just have a different set of public codes underneath. And then we can use the compiler to take the code written for EVM and, and bring it over here. And this is the approach we're taking. As far as I know, no other ZK EVM team is working in this direction. Stark, we're doing this for Kyro, but you have to relearn it, like the Kyro language. They have some, uh, to, to transpile code from solidity to Kyro called WARP, uh, but

• 27:32Speaker 03

  you actually have to maintain the code in Kyro. If there is no way for you to, to keep solidity as the source of truth as, as your basic code. And it would be very, very hard to keep the same code base between layer one and layer two, or between different layers. But that, that was something that was not acceptable to us. We wanted the code base to be exactly the same executable as well in mainnet as in, in any layer two. That's our approach. Uh, I'll pass over to you.

• 28:01David Hoffman?

  Ben, does that generate any follow-up questions or should we throw it to Yay?

• 28:05Speaker 02

  Um, okay, wait, let me just, okay, so let me just make sure I'm following right, Alex. So basically what we've said is we talked about in the intro of the show that we have this thing called the Ethereum virtual machine. It's how you interpret, um, you know, smart contracts in Ethereum mainnet. Basically what you've written is a virtual machine that's very similar, that's meant to be like very mappable and like close and related, that is optimized for ZK proving. And then you can basically relatively easily take solidity code that is meant to go to the EVM target and compile it instead to this other target. Is that right?

• 28:39Speaker 03

  That is correct. So we are actually not just, we, we don't have a native compiler from Solidity. We are using the Solidity compiler to produce the intermediate U representation of the code. Exactly. And then we're going from U to, uh, to our virtual machine, which is a lot easier to make that step. And in between, we're using L L V M as our compiler framework, which is a very mature, very well-tested, bottle-tested, uh, framework with a lot of tooling, a lot of optimizations. So our code is actually a lot more optimal than what Solidity compiler natively produces for EVM. We have three times less opcodes in the final, um, result.

• 29:24Speaker 03

  Uh, and yeah, so thi- this approach is the fastest to bring to, to, to production. Uh, and yeah, we, we, we started working on this for, like, since two years still. We, we have something that's very, very mature in, in compiler. It, it works in, like, you know, we are, we're covering all the tests from Ethereum, uh, test suits. And, uh, it's running in a very stable way on our test net, which is public. Like, a lot of teams are, are deploying there. We have hundreds of teams already working on test net. Everything works really, really well. Uh, but the, the, the most important thing is it will produce the, uh, uh, resulting virtual machine by codes that are very optimal.

• 30:09Speaker 03

  The, the, uh, execution, the proof generation for the, uh, Z K V M, for optimized Z K V M is going to be orders of magnitude less than approaches that try to mimic EVM at byte code level. So we are, we were talking about like very, very low cost per transactions, uh, if we can scale to both support the high load of DeFi, uh, N F Ts, but also like Very broad use cases, just gaming and like, oh, you know, all the new things that are coming to blockchain. Once we can actually support the scale of tens, hundreds of thousands of TPS. Uh, and in those cases, it really matters.

• 30:53Speaker 03

  Like, if your transaction costs like 10 cents or 0.1 cent, it matters a lot. You cannot just like, this is the quantitative step that unlocks qualitative difference. Uh, in what you can actually build and in an executed run on in these networks.

• 31:10David Hoffman?

  Beautiful. All right. Let's turn to Yay from Scroll. Yay. Can you talk about the competitive difference that Scroll is bringing to the table? How is the approach to the ZK EVM from Scroll side of things, unique from the others that you would find in the same landscape?

• 31:24Speaker 04

  Yeah, yeah, yeah, sure. I think technology wise, there are like mainly two, two differences. One is on the ZK EVM side and the other is on the infrastructure side. Um, firstly, on the ZK EVM side, so our goal is that we want to have the deepest level of compatibility with Ethereum. Down to the client implementation. So by saying that, like, we are not only being compatible with the solidity at a language level, like either you are you or like any R. We will like be compatible with EVM itself as a bytecode level, which means anything as far as you can use the existing compiler to compile down to the EVM bytecode. And we can prove that is correct.

• 32:04Speaker 04

  And also like by saying client implementation, we are reusing the existing Ethereum node implementation called Gas to generate our layer two blocks. So this is pretty similar to what Optimism is doing, like just try to reuse the implementation from Ethereum to inherit the, the performance, the security. And also like, you know, in the long upgrade, like we will be more aligned with, with Ethereum. So there is no compiling, there is no interpreting in between. So it brings us another level of compatibility, more than just the, the RPC interfaces. But it's a deeper level of, you know, like compatibility on the implementation side. And for users, it means they can do whatever they can on Ethereum using the same UI and UX. And for developers, they can reuse all the Ethereum toolings,

• 32:48Speaker 04

  even include some debug toolings like where you definitely need to down down to the by code level. Like for example, you need to like look up some some stack information and things like that. And they can migrate their code to scroll without any modification. And also, like, you know, this brings us another benefit, like where our implementation will be the most closest to the end goal of Ethereum where ZKVM can eventually be used to prove for layer one my net blocks. So in that sense, we are not only building for ourselves, we are not building like just for layer two purpose, but we are actually rebuilding this for the future of Ethereum. Because you know, it is very beneficial for Ethereum in the long term. So that's from the the compatibility and the ZKVM side.

• 33:32Speaker 04

  And another thing I want to mention is that on the infrastructure side, we have designed a decentralized proof our network. So there is both a a technical difference, like innovation there, and also a strategic difference. Because you know, a a big problem, we're mentioning like by maybe optimist they grow up or other other teams is that the the proving cost is large, because you know, generating proof is usually slow and considered to have, you know, very high, high, high cost, it's it's it's very expensive. But we can actually solve this problem by allowing many people who generally prove in parallel. And also this can drive the efficiency of of proving hardware to the to the extreme. And eventually even have the KASX to support the this proof generation, like anyone can just

• 34:14Speaker 04

  use this type of hardware or use general proper GPU or whatever they can to generate proof for us, for our platform. And it's very, you know, we we are prioritizing this because this is also like not only the technical like advantage, but also strategic differences, because you know, uh, more more immediately, especially with the ease merge, uh, miners could potentially just be be our provers. They can they can reuse their GPU machines to join provers and join our ecosystem if if they don't want to, you know, switch to another hardware work chain. So that's, you know, a both like technical innovation and also a strategic move for for us. So, yeah.

• 34:52Speaker 02

  Let me ask, okay, so I want to do the same thing and make sure that um following. So basically what Yes said, I think, correct me if I'm wrong, is that you uh effectively have a Program that is written is I would assume that's written in a that's running in some sort of lower level ZKVM, that is this Turing machine, Turing complete machine. And then you're running an EVM interpreter on top of that, basically, is that right?

• 35:19Speaker 04

  So we are not even having this, you know, middle layer, we are directly like so for example, if you you receive a transaction, you execute it on on gas and then you output some information like the execution trace, like which op code you are actually executing and then you use this trace as a witness like to feed into this circuit and prove that it's a valid trace using a very significant proof. And then this proof, like as far as you have this proof, it means, oh, this this trace is valid, so this, you know, like transaction is is correct. So there is no like middle step, you just reuse every information from the existing client implementation.

• 35:54Speaker 02

  Yeah, got it. And that circuit, I guess what I'm getting at is that circuit. So when you feed in, when you, okay, so it makes sense to me that you run the transaction on Geth, like vanilla thing. And Geth has a wonderful thing called a transaction trace, which will give you sort of

• 36:08Speaker 04

  Yes.

• 36:08Speaker 02

  step by step set of these instructions of the Ethereum virtual machine that we talked about, right? Geth will like break that down, instruction by instruction, it went here and then it went there and then it went there. So that all makes sense. But then what is actually running when that information is transferred to the prover, what is the circuit running? Is there some sort of Turing complete thing that is then running the EVM on top of it? Is it, have you actually written like an EVM like circuit for all this? What is that part of the stack?

• 36:36Speaker 04

  Yeah, yeah. So basically, what we are doing to handle this is that for each op code, we will implement some sub circuits to prove it's correct. For example, if if you add op code and we prove that this this number add to this number equal to this number. So we have a specialized sub circuits for each op code, it's a one to one mapping.

• 36:54Speaker 02

  Got it.

• 36:54Speaker 04

  And then like because and then like in EVM circuit, we compose those sub circuits together and then open or or like, you know, or or like using some selectors. We call that selector in in circuit, but basically if you meet with this op code, you open this certain constraints. And you, if you meet with the other op code, you open the next. And then like, you know, you prove that this is this is the correct.

• 37:14Speaker 02

  Yeah.

• 37:14Speaker 04

  And by constraining each op code.

• 37:17Speaker 02

  I'm interested, I'm really interested to hear from you, Alex, on this. Like, it's interesting. I know I've been on a panel with you and you love parallelized proof generation as well. I think all the ZKers do it. I totally do as well. But it also seemed like earlier you said you had a bit of a different approach for performance reasons. So I'm just curious, like, to hear what each other's perspective is on these things. Like, is the performance of ZK proofs an issue or not? I feel like I get conflating answers sometimes.

• 37:42Speaker 03

  That's a great question.

• 37:43Speaker 02

  Yeah.

• 37:44Speaker 03

  That's really a great question. So I don't see that we have different strategies here. Like, all ZK teams will eventually work towards decentralizing the prover. We are working on this definitely from, like, this is very important to us. We don't want to be any single point of failure. We don't want to run any operator that controls, like, the validation of the transactions going there to on or the generation. So it will be decentralized. We can reuse Ethereum miners indeed. We've been working on the GPU prover hardware for the last two years as well. And we have some pretty amazing results. Like, the GPU prover that we have on, that runs on ordinary consumer GPUs

• 38:29Speaker 03

  is something like 50 times faster than, like, 50 times cheaper than the proofs produced on CPUs. And for the product concept, it's really important to understand that whenever we talk about the prover efficiency, we always are talking about the amortized cost per transaction. Prover is always distributed, like, it's always done in parallel. No one is running a prover on a single machine. Like, if they do, it will take them hours to generate a single proof. Like, what we're doing, what probably other teams are doing as well is, like, we run it on as many machines as we need in parallel.

• 39:11Speaker 03

  And since the structure of the circuit is that we, kind of recursively combine many circuits together, our latency to generate proofs with GPUs is going to be, like, less than a minute. So we'll be able to, like, really... To to to get the blocks really fast. So what really matters at the end is like, what is the cost of this proof generation divided by the number of transactions? What is the cost per transaction? Uh, and that is where the differences will materialize very significantly with our approach. Or like what Stark was building versus uh what uh Scroll, like this very ambitious goal of Scroll to make E D M circuit, like circuit level compatibility. That is going to be like several orders of magnitude higher.

• 39:56Speaker 03

  Very curious to see what the numbers actually are, but that that is very complex and that is very complex also to maintain. So uh huge uh respect to the team uh who who are trying to make this like we we didn't trust ourselves. We we we want for much simpler approach because we know that the more complexity you add really like it it it grows non-linearly with the number of systems you add and with the number of layers you add to each system, which is like explodes at the end.

• 40:27David Hoffman?

  So I want to.

• 40:28Speaker 03

  So this is with regard to G P S.

• 40:30David Hoffman?

  Sorry, no, finish up the Alex and Alex my next question.

• 40:33Speaker 03

  Uh, so this is really garden to decentralizing the prover and G P S. And you just want to add that we decided explicitly not to reuse Gath uh as uh like not to rely on on standard nodes for uh a transaction uh for for the block building for for deciding what goes into transactions because Gath is known to have very strong limitations on throughput that it will bring with itself. And we decided like if we're just building a system that should be capable of running tens of thousands of transactions per second, we should redesign the node from scratch and we're writing it in Rust. Uh, it's highly optimized. We are, we also have very strong engineering team

• 41:13Speaker 03

  uh working on optimization of uh of the node because we don't want the node to be the the bottom.

• 41:21David Hoffman?

  I think Alex, you just opened up the conversation to the EVM compatibility versus EVM equivalence conversation, but before, I wanted to go back and just make sure we really knocked down the decentralizing the prover for the layman, because that part of the conversation made me feel like a dog driving a car. Can you, Ben, can you walk us through, why is, what does it mean to decentralize the prover? Like, why is that significant for just like the average user to pay attention to?

• 41:45Speaker 02

  Sure, so I'll talk about this, I'm not the ZK experts like these folks, but I have a rough sense. So basically, when you construct these zero knowledge proofs, right, that is an operation called proving, right? Unlike the operation called verifying, which is like in a ZK rollup, what the smart contract on chain does, what all the nodes do then downstream of that. So, in general, what you have to do, basically, when you produce a zero knowledge proof, is a bunch of extra cryptographic, moon mathy computation

• 42:11David Hoffman?

  Okay.

• 42:12Speaker 02

  that will give you some fancy numbers that allow the verifier in this succinct manner, right, in this short, you know, constant or logarithmic sized manner, to check whether or not the proof is valid, right? And so this is a computationally intensive operation. To do it in the zero knowledge succinct manner that we're talking about, you basically, if you want to prove something, it's kind of like, you don't just run the computation, because that's not a proof, that's just you doing it. You have to run the computation in some sort of circuit, zero knowledge math context that gives you some cryptographic steps along the way that you can sort of combine and aggregate and get this succinct proof.

• 42:48David Hoffman?

  Okay. I'm guessing that's the, doing the ZK stuff is like adding like an order of magnitude of difficulty upon a computation?

• 42:55Speaker 02

  Yeah, these guys can talk about those numbers much better than I can, but it adds overhead, for sure. For sure adds overhead.

• 43:01David Hoffman?

  And is that like the cost for like, when a transaction fee happens on like a ZK rollup, is that, is that the cost of this thing? Is that related? Are these related?

• 43:10Speaker 02

  So, it will be related, right? I think, I haven't looked into the details of either of these folks' fee markets, but that is, I think, what would be a very reasonable thing for a fee market to do, I think probably a requirement. There's additional costs, right, because even in a ZK rollup, you're still rolling up that data, right, which means you post it into Ethereum or whatever, right? I know at least Alex has like other more plasma type things that don't require that. So it's going to be a chunk of the cost, absolutely.

• 43:35David Hoffman?

  Okay. Okay, cool. Is there anything that Ben and I just said like stand out to you guys that you guys want to add on a comment to?

• 43:43Speaker 03

  That's good to me.

• 43:44David Hoffman?

  Cool. Yeah. All right, so we definitely got to talk about EVM compatibility and EVM equivalence, because I think that's really, Alex, you said that Geth is really just not optimized for some of this parallel proving magic, but yay, from what I've gathered, Scroll is really going after what Alex called like the very ambitious task of figuring out how to make Geth and a ZK roll up work together. So I think that's where we want to take this conversation next. But before we do that, we got to talk about some of these fantastic sponsors that make the show possible. There is a brand new staking feature in the Ledger Live app today. We all like staking the assets that we're bullish on, and now you can stake seven different coins inside the Ledger Live app. Cosmos, Polkadot, Tron, Algorian, Tezos, Solana, and of course Ethereum.

• 44:29David Hoffman?

  With Ledger Live, you can take money from your bank account, buy your most bullish crypto asset, and stake that asset to its network, all inside the Ledger Live app. Through a partnership with Figment, Ledger also lets you choose which validator you want to stake your assets with, and Ledger is running its own validating nodes, offering a convenient way to participate in network validation, and it even comes with slashing insurance. Ledger Live is truly becoming the battle station for the bankless world, so go download Ledger Live. If you have a Ledger already, you probably already have it, and get started securely staking your crypto assets. The Brave browser is the user-first browser for the Web3 internet with over 60 million monthly active users. And inside the Brave browser, you'll find the Brave Wallet, the secure, multi-chain crypto wallet built right into the browser. Web3 is freedom from

• 45:11David Hoffman?

  big tech and Wall Street. More control and better privacy, but there's a weak point in Web3: your crypto wallet. And most crypto wallets are browser extensions, which can easily be spoofed. But the Brave Wallet is different. No extensions are required, which gives Brave Browser an extra level of security versus other wallets. Brave Wallet is your secure passport for the possibilities of Web3 and supports multiple chains, including Ethereum and Solana. You can even buy crypto directly inside the wallet with Ramp. And of course, you can store, send, and swap your crypto assets, manage your NFTs, and connect to other wallets and DeFi apps. So whether you're new to crypto or you're a seasoned pro, it's time to ditch those risky extensions and it's time to switch to the Brave Wallet. Download Brave at brave.com/bankless and click the wallet icon to get started. The Layer 2 era Is upon us. Ethereum's Layer 2 ecosystem is growing every day,

• 45:55David Hoffman?

  and we need Layer 2 bridges to be fast and efficient in order to live a Layer 2 life. Across is the fastest, cheapest, and most secure cross-chain bridge. With Across, you don't have to worry about high fees or long wait times. Assets are bridged and available for use almost instantaneously. Across's bridges are powered by Ooma's Optimistic Oracle to securely transfer tokens between Layer 2s and Ethereum. Across is critical ecosystem infrastructure, and Across V2 has just launched. Their new version focuses on higher capital efficiency, Layer 2 to Layer 2 transfers, and a brand-new chain with Polygon, all while prioritizing high security and low fees. You can be a part of Across's story by joining their Discord and using Across for all of your Layer 2 transferring needs. So go to across.to to quickly and securely bridge your assets between Ethereum, Optimism, Polygon,

• 46:40David Hoffman?

  Arbitrum, or Boba Networks.

• 46:43Speaker 02

  Okay, welcome back, y'all. We're back in action. So, okay, we just had a really interesting discussion on, you know, some of the differences in these approaches. And one thing, to your point, David, that came up just before the break is understanding the role of, I think that... So I take some guilt for creating this term, which can be very confusing, but EVM equivalence is like a wonderful term that we use at Optimism to describe how we kind of try to move towards using Geth as much as possible. And this has been a matter of debate, and there are differences between our two panelists here and what they do. So I'm really curious to hear from you guys how you think about the developer experience. We talked a lot about the approaches sort of from a proving architectural cost GPU type of a perspective, but there's also the side of developers

• 47:28Speaker 02

  and what they're going to experience. So I'm curious to hear from you guys, from the panelists, what your different approaches to this developer experience are. What does it really look like for a developer to be implementing on one or the other? And how do you think about that long term? Is the other question. Are you at a place where you're comfortable? Are you trying to move in a specific direction? What's the take? So maybe we'll start with yeah.

• 47:57Speaker 04

  And developer experience, which means we will provide exactly the same execution environment as ECM layer one. So developers can pretty much reuse all the, you know, developer toolings around, like including the debugging toolings. Like if you want to go into the stack and look up some information, you can still use that. And because as far as I know, like many guest developers, uh, many, many even application level developers, they are very familiar with the gas implementation. So that is easier for them to debug and, uh, and like, you know, have some index security analysis. So I think we, we, we have some advantage on that because we are using a fork of gas to, to generate our blocks. And, uh, and also like, uh, because you, you are compatible with all the developer toolings.

• 48:41Speaker 04

  So developers are very comfortable with, you know, every toolings they use on, on layer one. They don't need even any extra plugins or any to link to any external compilers. They can just reuse whatever is there. So in the long term, I think it's more like secure, secure way because firstly, EVM has to test of time, like what? Like the, the, the, the design philosophy of each op code, this stack based virtual machine, it's, it's security has to test of time. If we, we just reuse everything from EVM, it's very easy to audit our code like because, uh, you know, our execution environment will make sure that the, the circuit will behave exactly the same as EVM. Like if you make a mistake there, then you, you, you can make mistakes here.

• 49:25Speaker 04

  So if, but if it's correct there, then like, you know, because they behave exactly the same. But I think that's, that's important, like in the long term, why you, you remaining this EVM, you couldn't say is important. And also secondly, as I mentioned, like if you, you are more aligned with this implementation for the further ECM upgrade, like. You like people are doing experiments over gas for EIPs for different improvements. You can directly use the same code base to improve your layer to design. And also like even sometimes give back. I think that's part of the motivations why optimism is is going into that that approach. So that's why like, you know, our our design philosophy for this part. And again, like, because we are actually giant, like, standing on on on top of the the the the giant.

• 50:09Speaker 04

  Because when when we appear like the the bricks already happen, we know like the the overhead is already affordable. So that's why we directly go into this by the code level, like compatible approach instead of building some some other virtual machines to to make the the proving or or had more manageable.

• 50:27Speaker 02

  I thought it was what's make sense. Yeah, let's hear from you, Alex.

• 50:31Speaker 03

  Uh, sure. So for uh, we are also on the mission to make the developer experience as easy and pleasant for developers as possible can uh have like. An absolute top um and uh it's important to see like what is the actual developer experience is like what what what you expect as a developer from from the environment. What you expect is that you don't have to modify your code and you can use the existing tooling. So you take your your whatever you have uh written in contracts and front end and test to test use etcetera and you port it and it just works. Just just work like one click, you know, stripe like experience where you don't have to to do any movements. That is exactly what we're gonna bring.

• 51:16Speaker 03

  We're not gonna bring it at the op code level, but we're gonna bring it at all the interfaces. Like your uh, the code does not need to change. You do not need to do any re audits. Your web three API works out of the box. Your all the coding conventions work, all the toolings on chain work. We have um the graph or changing uh a lot of other projects already integrating, already running on on our test net uh ready to to provide this experience. So things that will not work because the op codes are different are like low level debuggers.

• 51:52Speaker 03

  Uh, but those tools can just integrate. We can work with them. There are not many of them. You can work and make them be as compatible and then you you use the same. You have your tenderly experience, you have your remix, you have your common line based debuggers and they they provide the same output, the same experience to you. Like you as a developer do not need to to do anything. And like the surface of changes is is really minimal. Uh, but what is ultimately important to you as a developer is that your code works smoothly, that everything is fast. So the the the one way to think about ZK EVM equivalence versus CVM compatibility is like, what would be the analog of like the of of of these things in in in the real world? And in in in the normal computing.

• 52:35Speaker 03

  Imagine you have some some piece of software written for one operating system with specific architecture. I don't know, like a Photoshop running on Windows. Now you want to run this Photoshop on Mac with M one processor. Right? Uh, you have to options. Either you recompile the code for M one and it runs super fast and and you know, you you like the experience. Or you run a Windows simulator on your Mac. And then you run this Photoshop in the simulator. You can already sense like i- if you run uh just some uh some programs written for the older version of Mac. And then you try to run them on M one without without optimizations. You already feel the difference, right? Like it's huge.

• 53:18Speaker 03

  But if you run it in in an emulator, it's going to be a lot, lot slower. So your your developer experience is tightly coupled with your user experience as well. That is what matters. Yeah.

• 53:32Speaker 02

  Very, very, very interesting. Yeah. I I I want to take a careful spot here, David, to be your co-host because I'm very opinionated. As the as the folks like coined the term EVM equivalence, like I feel like I'm at an interesting position here. And I'll just say I'm very curious to see how it plays out. I definitely very much vibe with many of the um things that you said there, Alex. Some of them I became less of a fan of once I had to run a non-EVM equivalent system in practice. You guys are also building in a different space, right? You've got these ZK requirements. It's a little bit of a different world. So um, yeah, it'll be very interesting, David, to see how this plays out. I'm a huge fan of developer experience and I think that EVM equivalence is the way to go there, but we'll see.

• 54:14David Hoffman?

  Alex, any comments on that?

• 54:17David Hoffman?

  Or not?

• 54:18Speaker 03

  I'm also, I'm really happy that we have multiple approaches competing. We have our bet, like based on our analysis, how like, what's going to be the optimal for developers. Yeah, but it's like, it's really great that we have this race and let the thousand flowers blossom.

• 54:37David Hoffman?

  Yeah, any comment you want to add before I turn the conversation to something else?

• 54:42Speaker 04

  Yeah, yeah, I think it's, it will be just like, you know, we mean like, like eventually like all for all good for EVM, like different tries and like, you know, EVM equivalent environment or this compiler based one. And but I think, you know, in the long term, it's, you know, like, like if you have actual need for compiler, you have to also upgrade, like, you know, your compiler and both your compiler and your circuit at the same time, which actually adds the the overall complexity, because you you you need to, you know, those two parts are coupled together, and you need to upgrade like with with each upgrade. But for the key answer case, all the compiler stuff, you know, those can be reused and that those have been tested, you know, years of time. So that's why, like, you know, we, we want to handle this more complex stuff on the circuit side, but we don't need to handle like, you know, anything besides that.

• 55:27Speaker 03

  Oh, that's actually, I want to hear, I want to hear from Alex on that. Yeah, that's a really interesting point. I I wanted to add that in indeed, like the the what we're what we're building here is the future. And like, let's imagine, is EVM going to be ossified and be this standard that will be there forever and like will not undergo any modifications? Like, if you like, imagine that we we have the very first version of of PC with like 8086 architecture. Is this thing going to be like immutable and never change? Like, that is hardly imaginable, right? So like, we will have some evolution, in my opinion, like you, you might, you, you, you feel free to disagree.

• 56:05Speaker 03

  But with with the compiler, one thing that gives you, that the a separate compiler, specifically LVM based compiler, gives you is an option to have like developer experience beyond just CVM. You can port in any code written in all the modern languages that support LVM, like Rust, Golang, Python, you know, with C++ whatever.

• 56:30Speaker 03

  You take that, you compile it, even JavaScript. You compile it to LVM and then you can use it as libraries. Or we can also define some contract interfaces and then you eventually can write smart contracts in those languages. And I think that is going to be incredibly powerful because it just opens this massive code basis already written in this very expressive languages with generics, with all the cool stuff that is not yet possible in Solidity. And that have stood the test of time for like many more years before Solidity was even created. So I find that really, really fascinating.

• 57:07Speaker 02

  Okay, wait, Alex, I've got to dive into this more though. So I, okay, first of all, totally agree. If the reader has not heard of LVM, it is one of the modern marvels of like computer engineering, absolutely fascinating, go check it out. With that being said, there's a key, there's a key question here that I don't know if I heard an answer to, which I want to dive into, Alex, which is since you have developed a VM that is the ZK VM that like is like related to the EVM and maybe has some of the same semantics, but is different. How do you deal with upgrades, right? So like, I totally agree, we're going to like have upgrades to the L2 VMs. In this, are you basically, like, is implicitly there a commitment to this particular ZK VM that is the, that like your current compiler outputs?

• 57:52Speaker 02

  And like, is it your goal to maintain that going forward and just build more solid circuits around that? Or do you have the ability to improve that VM in the same capacity? So that question.

• 58:02Speaker 03

  That is a great question.

• 58:03Speaker 02

  Yeah.

• 58:04Speaker 03

  I, yeah, I think we will have iterations. So like in the initial versions of all the rollups, we'll have to work a lot on upgrades and do changes. It will be important to work with the source code and not with bytecode. I don't think we will have like a simplified bytecode in the near time. So eventually we will have a newer version and yes, you will need to redeploy your contracts there.

• 58:29Speaker 02

  Okay, I see. So you're basically going to enforce a requirement that you have source code accessible so that if you upgrade the underlying ZK VM that is not EVM, you can recompile and regenerate the bytecode for it.

• 58:43Speaker 03

  That would not be a hard requirement. So like, whatever you launch, like if, if, if, once we have a stable mainnet, we will guarantee that this mainnet will, will run for a long time. Uh, and then most likely you will, you will have a like, well, we, we, we need to say, I, I, I, I don't know exactly how this process will work. But like, yes, I believe that will, there will be progress in both the EVM world and CK VMs. And eventually we'll come, we, we will converge more and more with the world of generic computing. We'll reuse the tools like LVM, static analysis, uh, all the debuggers that, that, uh, the, uh, uh, traditional systems can bring. And I just think this process should be gradual and smooth.

• 59:27Speaker 03

  Should not be like a breaking change where you have to stop immediately and you cannot support the previous code. You can always emulate, like, it's, it's quite, um, quite easy for us to add bytecode compatibility in ZK sync. Because now, like, imagine we have the LVM compiler, we can do, we can write codes in Solidity and Rust. And it compiles to this very, very efficient, low-level virtual machine. We can just write a contract that executes native EVM bytecode. We write it in Solidity, or maybe we just compile our Rust implementation and we put it on, on ZK VM. You know, like, that, that, that will give you the same overhead, or maybe even slightly lower overhead than what Scroll or, or Hermes are building.

• 1:00:12Speaker 03

  Uh, but it's, it's a gradual process. You don't have to wait for this final step. You can already start using, porting your contracts to ZK sync written in Solidity because you recompile them. And the moment we have this contract live, you can just start porting your, your bytecode. If you're willing to take the, this massive overhead in, into account. If you want full efficiency, you just compile native to ZK VM.

• 1:00:39Speaker 02

  Fascinating.

• 1:00:40Speaker 04

  Oh.

• 1:00:41Speaker 03

  Can I add? That was we got.

• 1:00:43Speaker 04

  Yeah, yeah, can I add my more more comments on this like? You know, I I think there are two points firstly that I I agree that you know EVM may not be the the end goal like you know in maybe like one hundred years like we are not always stick to EVM model. But the reason why we firstly go into this EVM equivalent approach is that because we know that the the urgency for Ethereum is scaling, right? It's not for, you know, finding some new computational model as extension, but it's it's more for migrating all the existing apps securely to a layer two. So that the congested problem can be solved. So that's why we want to provide the EVM liquidity environment at the in the first place, because you know you have to handle with those problems and then you can think of the the further problem of a new VM or any any features.

• 1:01:29Speaker 04

  So that's one one thing like, you know, that's just our starting point and we will also definitely consider more like developer friendly, you know, VM or or or something like that. And the second thing is that to build this, um, so there are some arguments around like EVM versus VM, but they probably that uh, they I think the conclusion most likely that either you become you build a totally new virtual machine. Or like you you you just reuse this EVM and the true equivalency, because if you you modify part of that, it's nearly a new VM, but you you you can't just benefit from a totally new design from this virtual machine. So that's why like we are thinking of two approaches. One is that adding more feature to this EVM, for example, we can

• 1:02:07Speaker 04

  upgrade according to our community desire, like some new pre-compiles specifically to our layer two and using the existing EVM structure securely. And secondly, that we are in parallel, we can explore some more efficient VIKI VM to open this design space for more developers. So that's something like we are also exploring, but we we believe that that's also driven by the developers' needs instead of, you know, just reusing the compiler and just reusing the same virtual machine because it's fundamentally different. I think the last point is that. Using the LVM is very ideal like to support all the probing language. But you know, if you dive deeper into the LVM for very high level like language like Rust, Python, those touring complete language with many features,

• 1:02:50Speaker 04

  you will find that the LVM IR in the middle layer is very complicated. It's even much more complicated than building a ZK EVM, like adding support for all those opcodes. Because they have very complicated type, they have very advanced features. If you want to support all of them, you need to support a very complicated IR layer. It's not just the solidity or anything like, you know. Yeah, so I think, you know, even if you have this LVM, or it's still like, you know, take a very long way to go to support all the features of Rust. But if you only support the semantic of Rust, then I think it's, you know, still like less useful for developers because they still need to change a lot of code. And so that's, you know, like maybe three points from our perspective. So we are also exploring, but that's like why we went this as our first step.

• 1:03:36Speaker 03

  I'll take that challenge. Let's see how fast we can support Rust.

• 1:03:39Speaker 04

  All right. Yeah, yeah, yeah. Hey Ford.

• 1:03:43David Hoffman?

  Awesome, guys. Well, like I said earlier, I really like this metaphor. I feel like a dog trying to drive a car. So I'm going to zoom out this conversation and get something I think the users can understand, I think, a little bit better. And every single Layer 2 team has their sort of like vibe, if you will. Like it's their culture, it's their branding. And that's often really how users ultimately come to like determine whether they feel comfortable with a particular ecosystem or not. It's like, what are the values or the ethos that each team appears to exude, even though they can't really comprehend some of the very technical words that are being said? So I'd just like to get each of your guys' perspective as to like, what do you guys think about values or culture or vibes

• 1:04:24David Hoffman?

  when your guys' internal, like, just like communication as to how to build something? And maybe you can share that perspective with the broader world. Like, what is the vibe of your particular project? What's the, do you guys have like an ethos that you stand on? And yeah, I'll start with you.

• 1:04:41Speaker 04

  Sure, sure, sure. Yeah, that's that's actually a very important like aspect of Scroll. And you can check out more like on we have posted like articles talking about our vision, value, our technical principles. We want to up code when we are designing our whole architecture. But from the ethos and the, you know, like the the the vision side, we are more open. We are we are open. We have been building the open source way from day one. Like you, you know, the totally open source, the key and circus where anyone can run, anyone can and just, you know, even PR some code. And most parts of the ZKM circus are actually co-built in collaboration with a privacy and scaling exploration team at ECEM Foundation under permissionless license.

• 1:05:22Speaker 04

  So we are we are actually co-build together. We we like a lot of actually credit also come from this community. And because we have this permissionless license, which means anyone can use this repo and build things on top of that. And also, we encourage the broader community to do so because we firmly believe that, you know, building in this open source way leads to more secure and resilient code and help us to foster a broader community of developers. And they can check our progress in a very transparent way because, you know, there are some overclaims, right? They can just directly fact check our claims of, for example, like whether we have proofs or not.

• 1:06:01Speaker 04

  And in that perspective, we hold ourselves very, you know, to a very high standard that with with all our claims we we made. For example, we actually have live ZK proofs in our test net now can be checked. And we are focusing on on building and shipping shipping our shipping new features on our test net. And we are not doing endless PRs, but instead we are, you know, writing articles explaining what we are building and what our architecture look like and output more educational articles, which is beneficial for the whole space. It's it's not directly, you know, like. Finding each other, but but more like for educating people why this is important and what we are building. And I'm I'm glad that, you know, even if we we are still in a, you know, relatively stealth model.

• 1:06:44Speaker 04

  There is still a circle of of E's and Z K researchers who have recognized our work and given us credit where it's due. And we are actually finally ready to welcome a much broader community. And I'm happy to say that we have received over like twenty five K signups within two days of our pre offer test net announcement. And if you want to be the first batch of user, just sign up at sign up dot scroll dot I O. Yeah.

• 1:07:09David Hoffman?

  Beautiful. Thanks, Yay. And Alex, I'll say the same question to you. What's what's the overall value or vibe of Z K Sync?

• 1:07:16Speaker 03

  So Z K Sync is deeply mission driven project. So this this mission that I mentioned in the beginning to accelerate the adoption of crypto for self sovereignty is hugely important. And we we've written a lot about this. We have a team handbook that walks the new team members through through the values. We are extremely aligned with Ethereum on on the on the approach. Towards those goals and every technical decision we make is matched like we we i- is balanced against the the the principles of freedom, resilience, inclusivity.

• 1:07:54Speaker 03

  Like from escape hatches to the way we decentralize the prover to to the way we approach decentralization of the sequencer. To the way we we approach the standardization of of code bases. We are, we firmly believe in open source. Everything we do is going to be released under permissionless software license, just like we did for version one. With version one, we made some interesting experience that made us reconsider the approach to a complete openness. As we we opened, like we were leading the practical development completely in the open. And then there were people who just forked the code, made modifications that they did not understand. Took part, like they copied some, they fucked off some bugs. And they also changed things that led to more problems.

• 1:08:38Speaker 03

  And they tried to front out, or front run us with regard to the token. So like, there are powerful incentives for people to just rush with some unrated code and try to publish it. That's why we're taking like a more conservative approach now. So we're opening everything to independent researchers. We actually, next week, we will announce some people we opened it with who are highly credible in the space. And then we're going to gradually open it to more and more and more until we have all the audits and all the testimonials. Testimonials from the white hats where we feel comfortable that the code is safe. Then we're going to open source it.

• 1:09:18Speaker 02

  Beautiful. Thank you too. Yeah. Kumbaya. Crypto culture, baby. Okay, Alex, you did, you did just raise something that I really do want to get in before the end of this panel, which is a question for both of you. Okay. All of the ZK, I mean, realistically, almost all, pretty much all of the Layer 2 teams out there right now have upgrade keys, right? There's some set of small number of people that own a multi-sig that can be used to upgrade the system. And that includes upgrading it to something that is malicious and takes all of the money from the system. This is obviously not ideal. You know, I don't want to like rehash why that's necessary because I think we all agree that it is and we understand that it needs to happen.

• 1:10:00Speaker 02

  But my question is, at what point can we cast those upgrade keys into the fires of Mount Doom? Like, from both of your perspectives, what is the point in time in which, like, obviously, it makes sense that now for you to launch something, you can have some level of, you know, trust that it's at some level of productionization. But it's a big shift to say, okay, we're throwing away our upgrade keys. If someone comes to us with a bug in the future, we cannot solve that bug. So I'm really curious from your guys' perspective, like, what is the timeline and what is the, like, concretely the criteria that you think has to be fulfilled to be able to turn off your upgrade keys? And Alex, we'll start with you again.

• 1:10:41Speaker 03

  Sure, this is a huge problem. We're thinking a lot about we I I I published a tweet where we offered the bounty for the best design solution that that can help solve this problem. And for the broader context, the the the the problem here is very different in L2 space compared to L1s. Because if you have a problem with L1, you can always fork away. The decision to fork is ultimately with with the people who run the nodes. So you never depend on the honest majority. And that is the superpower of public blockchains, like like truly decentralized blockchains, like Bitcoin and Ethereum. And I can't really think of any other L1s that fall in this category. But Zee. But.

• 1:11:25Speaker 03

  You don't get this at Layer 2s. Because at Layer 2s, you you have all the funds of like are locked into this one contract on Layer 1 that someone needs to control. Someone needs to like this contract must objectively know. Like who is now like what what code is not canonical, like what what shall we execute? The solution we came up with was we have a team multi-sick that can initiate upgrades. And those upgrades are subject to a time lock period of multiple weeks. And then all the users who are disagreeing with with with those upgrades can exit. And we have permissionless mechanisms for exit, like scapehatches, like forced block proving, etc.

• 1:12:09Speaker 03

  But if there is a bug and we really need to accelerate, we need to act now and just fix an immediate problem. We must go and reach out to an external number of people who we call a security council. Those are highly prominent people from the Ethereum community, very reaching and famous. So like they they like it's very unlikely that they will all collude to to try to steal this funds. And they must approve an immediate upgrade. Now, this is this is not a perfect world. Because like we we don't want to to expose those people to like political struggles. And you know, to to to some like non-mater incentives that that might force them to to do things. Ultimately.

• 1:12:56Speaker 03

  What we can do is have multiple layers of protection in in our systems that like all of the checks must be made before they like a something happens. So the simple example would be if you we just have a second factor and we have a roll up running like a ZK roll up. Uh, and then we have number of validators appointed by by the users who have to approve transactions. Uh, and then you would have to break both the consensus of this validators like or or corrupt the stake and find a problem in in the ZK circuits to to to try to exploit.

• 1:13:38Speaker 03

  Uh, but that would compromise the liveness of the system if the proof of stake is or like this valid data set is compromised. Uh, so another option would be to have multiple implementations of rollups. Like maybe if you're ZK rollups or maybe optimistic plus ZK rollup. We combine those together and we put them uh on chain and then we we use governance only if they if they disagree and this is something that Vitalik posted last weekend uh on Twitter, which is a very interesting idea. Uh, but ultimately, we just need to wait for those systems to to become mature. Like if something is running for a few years with billions of dollars worth at stake and nothing has happened and those funds were not stolen.

• 1:14:23Speaker 03

  And you had honeypots running in the open with like much lower barrier, much lower threshold of uh capability. And those are also safe and those have had millions of doors uh stake in them that the attacker could just grab if they found like much, much easier hole to to penetrate than uh, I think then we can say, okay, we those systems are like plausibly secure and we can rely on them and we can remove them. But this is roughly how I think about it. Maybe there are some ways where we could rely on the governance of layer one. Maybe we could declare some rollups as like really important, like systematically important for Ethereum.

• 1:15:07Speaker 03

  And we can say like if something goes wrong in those systems, then we we would just rely on on the votes of of the general Ethereum community. Uh, and we actually, we don't need to declare them anything special. We just need governance mechanism that can rely on this external uh, voting power of, of broader theorem, maybe something like this. So like, all the ideas are, are really appreciated.

• 1:15:31David Hoffman?

  Yeah, you want to take the same question, just the overall security of Scroll and your guys' thoughts and plans around it?

• 1:15:37Speaker 04

  Yeah, yeah, yeah, sure. Uh, I, I think we do have like security plans and security definitely, you know, the, the first priority for, for Scroll because you know, like stakes are locked in smart contract. And for us, we, we do have security plan. And so there is no like antidote for repeated and more throughout auditing. But besides that, we are going to have an in-house security team. And the team will, you know, keep an eye on our code like all the time and also collaborate with external auditors for safety as well. And also like it's, it's, it's safe for now because all the transactions will be executed using this, you know, existing client implementation. We, we don't even implement a new ZK executor to execute our transaction.

• 1:16:22Speaker 04

  So it's very hard for any attacker to, to attack our system since they can't run this, you know, sequence of themselves. That's the first place. Secondly, that is existing implementation. And also they, they, they have no chance to generate fake proof or, or for this fake trace. Um, and, and that's, that's one, one aspect. And secondly, that as I mentioned, like, you know, there are definitely trade-offs be, be like between open source, like very early or very late. A scroll is built on an entirely open source foundation, even including the proving stack of, of Halo two, which is, you know, like many eyes are, are on that, including the Z cash. And for example, like community developer from Zero Park and even Falcon, you want to reuse the same like proving stack. And even like, you know, sometimes reuse the, the ZK even code base.

• 1:17:05Speaker 04

  So more broadly, we believe that using this community standards will be the most robust way to write security code and secure our whole code base and secure the, the system of our, the, the security of our, of like oral system. And for the upgrade case, uh, I think we will implement a sufficiently robust system before the sequencer is decentralized. Like some using some time delay like which makes sure that users will have enough time for you know before this smart contract upgrading. And even along run, we will progressively add this decentralization. And like more become more permissionless like it but it's it's in a long, long run like because you know decentralization is at different levels like first we decentralized prover and then we consider the overall system.

• 1:17:48David Hoffman?

  Well, gentlemen, thank you so much for all of your time. I know we've gone a little bit over. Ben, do you feel like you've got all of your questions answered?

• 1:17:54Speaker 02

  Oh, my goodness. I had all the questions answered. They spawn more as they always do, David, but I feel like a goodest place to pause is any.

• 1:18:01David Hoffman?

  Well, I think the the story of the ZK EVMs is going, we're just at the very, very beginning. So there will be plenty of ZK EVM content as the as the story progresses. So Alex, yay, thank you so much for joining me and and also Ben, my my technical co moderator here. To helping us unpack at the very start of this very long story of the ZK EVM. So thank you too.

• 1:18:25Speaker 03

  Thank you, David, Ben, and Yeh.

• 1:18:27Speaker 04

  Thanks for hosting. Thanks, Alex.

• 1:18:29David Hoffman?

  Of course.

• 1:18:29Speaker 03

  And see.

• 1:18:31David Hoffman?

  Go for it, Alex.

• 1:18:32Speaker 03

  Yeah, just wanted to say see you guys on mainnet in eighty seven days.

• 1:18:35David Hoffman?

  Oh, yeah, absolutely, absolutely. Well, actually, like before I I sign off, can we do a speed run through the roadmap for each of you? Alex, mainnet in eighty seven days. Is there anything else about your guys' roadmap that you want to talk about?

• 1:18:49Speaker 03

  Uh, we're now completely focused on on launching mainnet. Testnet is is up. If you want to be one of the first projects launching a mainnet, we're going to follow the fair launch policy. You should get on our test at now and start building. And for the next features that are coming, there are some really interesting things and I can't talk about them yet, but I will just say that. Layer three is a lot closer than many people think.

• 1:19:16David Hoffman?

  Well, I can see that very slight smile on your face. So that's getting me excited there, Alex. Yay. What about you and Scroll? What's the Scroll team's like high level roadmap? Can you speed run us through that?

• 1:19:26Speaker 04

  Yeah, yeah, yeah, sure. I think for our release philosophy, we are progressively releasing more functionality to test. So we can fix any bugs and any UX difficulties early and often towards a more robust, like, you know, infrastructure test of time. So currently, we are at the stage of pre-alpha testnet. It's running internally right now with real live ZK proofs. And we pre-deploy some applications like swap for user to interact with. They can see their transactions being processed on layer two and then finalized on layer one with a proof through an explorer. And if you want to be the first batch of users, again, like sign up our testnet at sign up dot scroll dot I O. And the next step will be a more permissionless alpha testnet where developers can deploy their smart contract.

• 1:20:11Speaker 04

  And anyone can interact with with applications on scroll. It doesn't need any sign up. You can directly use your mental mask to interact with scroll with using any interface you you like and you are familiar with. And we are testing our functionalities for now and it will be released soon. And also, like in in further release, like anyone, you will be able to run the proofers at home to to provide a computation power for us. And yeah, so that's roughly our our plan and.

• 1:20:38David Hoffman?

  Yeah, will there be a scroll token?

• 1:20:41Speaker 04

  Yeah, that's a that's a good question. So we are we are focused on building and we are thinking on long term scale and want to be extremely thoughtful about, you know, how to foster a sustainable community of user and developers. And I think, you know, we can learn a lot of license from Optimism and Polygon, which is the only two layer tools which, you know, already launched their tokens. But currently, we are still focusing on building the the best solution technically. Yeah.

• 1:21:07David Hoffman?

  Okay, and then Alex, same question to you. Is there going to be a ZK sync token?

• 1:21:11Speaker 03

  There might be a ZK sync token indeed.

• 1:21:14David Hoffman?

  I had an idea. Awesome. Thank you guys so much for joining me. Risk and disclaimers, of course. Crypto is risky, ETH is risky, Bitcoin is risky. Layer 2s are risky. We didn't get to the conversation of bridges, but bridges are also risky. But they're less risky if you go to a cryptographic bridge rather than a cross-chain bridge. But you could still lose what you put in. We are heading west. We're on the frontier. It's not for everyone, but we are glad you are with us on the Bankless Journey. Thanks a lot.