Bankless - Scaling Ethereum To The Next Level with zkEVM

Episode Date: August 30, 2023

Joining us today for this deeply technical conversation is RiscZero CEO Brian Retford and Justin Drake. RiscZero is attempting to create a zkEVM for Ethereum that will require such low compute requirements that validators could be run on smart watches and mobile phones. Moderated by Justin Drake, we take a look at the implications this tech can have on the future of Ethereum. ----- 🏹 Airdrop Hunter is HERE, join your first HUNT today https://bankless.cc/JoinYourFirstHUNT  ------ 📣 SAFE CORE | Smart Wallet Infrastructure https://safe.global/core  ------ BANKLESS SPONSOR TOOLS: 🐙KRAKEN | MOST-TRUSTED CRYPTO EXCHANGE https://k.xyz/bankless-pod-q2   ⁠ 🦊METAMASK PORTFOLIO | MANAGE YOUR WEB3 EVERYTHING https://bankless.cc/MetaMask  ⚖️ ARBITRUM | SCALING ETHEREUM https://bankless.cc/Arbitrum  ⁠ 🛞MANTLE | MODULAR LAYER 2 NETWORK https://bankless.cc/Mantle  ⁠  🦄UNISWAP | ON-CHAIN MARKETPLACE ⁠https://bankless.cc/uniswap   👾STADER LABS | ETHX LIQUID STAKING https://bankless.cc/Stader  ----- TIMESTAMPS  0:00 Intro 7:47 Validator On Your Smartwatch 12:16 Bandwith Requirements 15:00 Implications for mainnet scaling 18:57 Is This Our Multi-Core Moment? 21:35 What is RiscZero? 27:57 Why Build a zkEVM? 32:00 TLDR Summary 35:42 The 3 Steps To Snarks 41:40 Performance Unlocks 43:59 How close are we to all this? 51:54 How Secure is This? 57:34 Licensing this Tech 59:59 RiscZero Business Model? 1:03:53 What’s Next on The Roadmap? 1:06:15 Core Values of RiscZero 1:07:54 How Does Ethereum Look in 5 Years? ---------- Resources: The Sci-Fi roadmap to Ethereum: https://www.youtube.com/watch?v=6_NXxcGe7Ts  Brian: https://twitter.com/BrianRetford  Justin: https://twitter.com/drakefjustin  ------ Not financial or tax advice. See our investment disclosures here: https://www.bankless.com/disclosures⁠ 

Hey, Bankless Nation, I'm very excited about the episode today. David is out, and this episode gets technical at time. So I have ETH researcher, Justin Drake, whom I'm sure many of you know, he's co-hosting with me today. Some context as we get into this episode. So we did a previous episode a few weeks ago called the sci-fi roadmap to Ethereum. And in that episode, Justin Drake described the end game for Ethereum. And he said this, we snorkeify everything. In today's episode, we explore exactly what that means and how we do it. it. How do we snarkify everything? Our guest today is Brian Redford. He is the co-founder of what might be the world's first type 1 ZKEVM. And if you don't know what that means, that's fine. Neither did I, as we're getting into this episode. And it turns out that building a type 1 ZK. Evm is an important part of delivering what Justin Drake called an enshrined roll-up inside of Ethereum. More on that in just a minute. But before we get in, just want to mention something quick from our friends and sponsors over at SAFE. Safe is the multi-sig wallet. We recommend. for crypto and you've heard us talk about smart contract wallace many times how they're going to 10x

the crypto wallet experience we definitely believe that's true and safe recently proposed their modular open source safe core protocol as a standard for the industries that we can all move forward and transition to the smart contract wallet future and they want you to check it out so there's a link for the devs in the show notes safe really believes this is an opportunity to create a unified standard to catapult smart contract accounts onto the ebm the standard the standard itself is unopinionated and vendor agnostic and maintains interoperability and smart contract diversity. So go check it out. And also to check out, SAFE is organizing the first ever conference dedicated to smart contract

wallets and account abstraction. That happens the second week of December. There'll be a link in the show notes to go register for that as well. So thanks to SAFE for building into the frontier. All right. Speaking of the frontier, back to Ethereum enshrined roll-ups. So why are we having this conversation and why now? The compute era scaled with Moore's law.

but the blockchain era scales with something differently. It scales with cryptography. Specifically, cryptographic breakthroughs like ZK Snarks and all of this ZK Snark stuff, the snarkifying of the EVM, it's all happening a lot faster than any of us previously thought. It's happening so fast that a project called Risk Zero just came on our radar last week and they've already produced a working version of the world's first ZK snarkified Type 1 EVM. What kinds of things could this unlock in the future? Why is this important? Well, what if we could convert an optimistic roll-up to a ZK roll-up? What if we could upgrade Ethereum's layer one from a single-threaded EVM model to a multi-threaded

EVMs so that compute was virtually limitless and free? What if ETH validators themselves had the ability to run from something as small as a smartwatch? All of these are possible unlocks with this technology. This is crazy cool, deep stuff. Down the crypto rabbit hole, we go, and it gets technical at times, but it's absolutely worth holding on for the ride. This is crazy cool stuff, and we're going deep down the rabbit hole today. And this gets technical at times, but I think it's absolutely worth it to hold on for the ride.

Because this is key to understanding how blockchains actually work and how they scale. And in so understanding, I think this type of thing can help you avoid bad investments and dead ends. And there are a lot of those out in the space as well. We're going to get right to the episode with Brian and Justin. But before we do, I want to thank the sponsors that made this possible, including our number one recommended crypto exchange for 2023. Cracken, go check them out. Cracken Pro has easily become the best crypto trading platform in the industry.

The place I use to check the charts and the crypto prices, even when I'm not looking to place a trade. On Cracken Pro, you'll have access to advanced charting tools, real-time market data, and lightning fast trade execution, all inside their spiffy new modular interface. Cracken's new customizable modular layout lets you tailor your trading experience to suit your needs. Pick and choose your favorite modules

and place them anywhere you want in your screen. With Cracken Pro, you have that power. Whether you are a seasoned pro, or just starting out, join thousands of traders who trust Cracken Pro for their crypto trading needs. Visit pro.crakken.com to get started today. Mantle, formerly known as BitDow, is the first Dow-led Web3 ecosystem, all built on top of Mantle's first core product, the Mantle Network, a brand new high-performance Ethereum Layer 2 built using the OP stack, but uses Eigenlayer's data availability solution instead

of the expensive Ethereum Layer 1. Not only does this reduce Mantle Network's gas fees by 80%, but it also reduces gas fee volatility, providing a more stable foundation for Mantle's applications. The Mantle treasury is one of the biggest Dow-owned treasuries, which is seeding an ecosystem of projects from all around the Web-Free space for Mantle.

Mantle already has sub-communities from around Web3 onboarded, like Game 7 for Web Free Gaming and Buy Bit for TVL and liquidity and on-rance. So if you want to build on the Mantle Network, Mantle is offering a grants program that provides milestone-based funding to promising projects

that help expand, secure, and decentralize Mantle. If you want to get started working with the first Dow-led layer 2 ecosystem, check out Mantle at mantle.xyZ and follow them on Twitter at ZeroX Mantle. Arbitrum is accelerating the Web3 landscape with a suite of secure Ethereum scaling solutions. Hundreds of projects have already deployed on Arbitrum 1 with flourishing defy and NFT ecosystems. Arbitram Nova is quickly becoming a Web3 gaming hub and social adapts like Reddit are also calling Arbitrum home.

And now Arbitrum orbit from secure scaling technology to build your own latest. 3, giving you access to interoperable, customizable permissions with dedicated throughput. Whether you are a developer, enterprise, or user, Arbitrum orbit, lets you take your project to new heights. All of these technologies leverage the security and decentralization of Ethereum, and provide a builder experience that's intuitive, familiar, and fully EBM compatible, faster transaction speeds, and significantly lower gas fees. So visit Arbitrum.io, where you can join the community, dive into the developer docs,

bridge your assets, and start building your first app with Arbitrum. Experience Web3 development the way it was always meant to be. Secure, fast, cheap, and friction-free. Bankless Nation, I am super excited to introduce you to Brian Redford. He's the co-founder of a ZK. EVM project that we're going to find out a bit more about on today's episode called Risk Zero. Brian, welcome to Bankless. Thanks. Glad to be here. Also excited to be joined yet again on Bankless by Justin Drake. He's an Ethereum, researcher, and repeat Bankless guest. Justin, how you doing?

I'm doing great. Thanks for having me again. But I guess this is this is a time maybe as a host asking some technical questions. Yeah, how's it feel? The tables have turned. So, Justin, I'm going to tap you in as my co-host today. So David is out, and we're going to talk about this, the next generation, ZK EVMs. So I think we're talking to Brian about the world's first maybe ZK EVM. That's a type 1 ZK EVM. And I'm not even sure the words that I'm saying or what they mean. So we'll absolutely need to define that. But, you know, David's out. right now. So Justin, you're going to tap it and help me with this. I feel like this is a continuation, though, of a conversation that you had with him on ETHC. And I think bankless listeners may have listened

to an episode entitled Ethereum's sci-fi roadmap or the sci-fi roadmap to Ethereum in which there was this really interesting part. And I love that episode, by the way, where you were describing this, the ability of us in the future of Ethereum to snarkify the EVM on, on, on, kind of mainnet, on the base layer. And that sounded really interesting to me. And I think that ties into the conversation that we're about to have. So teat this up for us, if you will, Justin, is a continuation on that conversation. I know this, we're talking about sci-fi Ethereum, future stuff. But what does it mean to snarkify the EVM? And how does that tie into the conversation we're about to have with Brian today? Right. So big picture, we're actually going to snarkify

all of Ethereum. And there's two big components that need to be. snarkified. One is the EVM, which is this virtual machine which processes Ethereum transactions, and then the other part is the beacon chain. Now, once we've snarkified these two things, we'll be in a position where compute won't ever be a bottleneck for Ethereum. So it means that, for example, as a validator, you won't have to really have BFD CPUs. So you'll be able to be a validator on your smartwatch. If you're building bridges between L1s, you'll be able to have another L1,

verify the state of Ethereum without having to redo all the computations themselves. It also has implications for like clients, for what we call enshrine roll-ups, which are super high-security roll-ups. And when the words type 1 EVM, come to mind, type 1 ZKVM, it really kind of gets me excited

as a researcher because it was kind of a piece of sci-fi engineering that was thought to be five to ten years into the future. But it looks like, well, there's several teams working on them. There's, for example, Tyco and there's risk zero now.

And it looks like the engineering will just be ready so much sooner. So we're starting to see the light at the end of the tunnel. And that has some big implications in terms of applications for Ethereum, both at layer two, but also what I'm excited about, which is the layer one. So what you just described here, Justin, is kind of the Holy Grail. And I still want to spend some more time with you right here, just flushing this out

and making sure that we understand this going to the episode because it sets the context for the rest of the conversation with Brian and Risk Zero here. So the light at the end of the tunnel, or what I just referred to as the Holy Grail, snarkifying all of Ethereum. What this means is we get to use the spooky math, you know, the crypto magic ZK math that you've described so eloquently many times on the bankless episode. And what we get, the prize that's held out to us is the ability, first of all, you said, to validate, be a validator on something as small as like a smartphone or an Apple Watch. So, okay, is that really what we're talking about?

of course, one of the end goals and the end goal, the entire purpose of Ethereum, is for it to maintain, for it to remain decentralized. And that means, ideally, anybody with a basic consumer level computer can validate transactions on the Ethereum mainnet. And right now, the requirements for doing that are somewhat higher than just a smartphone or a smart watch. But this will decrease the requirements, the hardware profile in order to validate transactions on the Ethereum mainnet and also to stake. Is that what you're saying? That's correct. So anytime you have a human that ends up wanting to interact with Ethereum, they need to interface through a full node. And there's some complications here because

running a full node is not something that you can necessarily easily do on your phone. and it's not something that the average individual we want to do. And it's something that every single validator has to do if they want to become a validator. So there's this barrier to entry. And more often than not today, for the vast majority of users, we end up patching this technical barrier to entry with some level of centralization. So for example, if you're using Metamask, you're going to be connecting to Infura nodes that are kind of running the full nodes on your behalf.

And so there's some amount of trust that you as a user are placing into Metamask. So once we have a Type 1 ZKVM, once we've snarkify DVM and all of Ethereum, we're going to be in a position where the user will be able to interact with Ethereum with much, much, much less hardware. Like a phone or a smartwatch

will be able to get best in class access with best in class security, best in class latency, all with very, very little hardware. Does this imply anything for a bandwidth as well? Will this decrease the bandwidth requirements, or will bandwidth kind of become the constraint here now? Right, great question. So consensus kind of solves two problems. One of them is execution, and the other one is data availability. Snarks is kind of this magic technology that removes computation as a bottleneck within the context of consensus. And it turns out we have another magic technology for data availability called

data availability sampling. Neither of these are really in production right now. But once we have both in production, you won't have to pay the cost of computation and you will have to pay a very, very minimal cost from the bandwidth perspective. So you won't even need to download the Ethereum blocks. All you'll have to do is make these small queries. for chunks of blocks, and that's going to be enough to guarantee that you're on the canonical Ethereum chain.

So data availability sampling as well, that's a core upgrade of what I think people are calling dank sharding as well, not proto-dank sharding, as I recall, but dank sharding, which could occur later in the future. Exactly right. So we're looking at technologies, you know, two, three, maybe four or five years into the future, which in a way will transform access. of Ethereum for users. And in the endgame,

accessing Ethereum will be just as easy as accessing any other website. And you'll have guarantees, just like on the website today, you have this cap lock, sorry, this lock and HTTP. You'll have a similar lock saying you're really connected to the real Ethereum and you'll have

to have done almost no work and you'll have to download almost no data. And ZK. Trust nobody also. unlike the current kind of law where you actually have to trust the sort of signature verifiers or those signature issues. ZK technology is the thing that makes this all possible. What's very interesting is I know there are people who talk about kind of like compute

scaling in blockchains via Moore's law. And that's true. But where we really get the like kind of the massive scalability is more with like cryptography breakthroughs. That is something I've learned as part of like exploring the roadmaps. being in this industry for many years now, is these cryptographic breakthroughs are the key sort of step function breakthroughs that allow us to actually scale this technology. One other quick question for you, Justin, before we get to Brian to kind of describe what

he's actually working on, what we're doing here. What does this imply for maybe scalability on Ethereum main net? So we talked about lowering the compute requirements to be a validator, which is fantastic. That is a further decentralization unlock. How about transactions per second on the Ethereum layer one main net? Does this have any impact on that as well? Fantastic question. So once we've snorkeified the EVM, we'll be in a position where we can greatly increase the gas limit

and potentially even remove the gas limit for computation, specifically. And the reason is that the gas limit is an anti-denal of service vector, whereby when you receive a block, you want to be able to fully verify that the block is valid on the order of one second. And so if there's too many transactions in that block, then it's going to take more than one second to validate. But the magical thing about snarks is that the verification time of a snark is on the order of one millisecond. And so you can take a block that's kind of arbitrarily large with arbitrarily many transactions and arbitrary much transaction execution and know that the execution are correct within a constant amount of time, which is only one millisecond.

So what does that imply then? So if Ethereum right now supports like 16 transactions per second, and we're scaling that out via roll-ups. And last time I checked on L2B, we're about, if you count all of the kind of roll-ups combined in that, we're about 5x, 16 transactions per second, something like that. And that's the entirety of Ethereum right now. We're not handling a visa level throughput at this point in time. It's safe to say. But what you just said about kind of finality or confirmation times, the millisecond level validation verification here,

what does that imply for main net throughput, Justin? Right. So what it means is that there's going to be a partial comeback of the layer one. So I think the spotlight is going to shift to L2s for the next few years. and there's going to be a lot of experimentation, a lot of innovation. And the layer one is really going to be lagging because we're extremely conservative and, you know, we're frankly kind of slow for good reasons. But once we are able to catch up from a technological standpoint with the L2s,

well, the L1s will also have some of the similar powers that the L2s provide. And so the L1 will, to an extent, be able to scale out. one of the superpowers will mean that we can increase the gas limit and there's something that's kind of explicitly put in Vitalik's roadmap diagram. But another thing that we can do, and I think this is something that Vitalik will add in maybe the next iteration of the diagram, is that we can have an upcode within the EVM,

which allows you to verify validity proofs, snarks, of EVM blocks itself. So kind of the EVM is aware of it, itself and knows when another EVM block is valid. And what this allows us to do is have multiple instances of the EVM. Because ultimately, you can think of the EVM as being this single-threaded CPU or virtual machine. So it can only run on one core just to simplify.

And so there's this inherently sequential computation that's going on, which is a bottleneck for scalability. The EVM will never be able, most likely, to do a million transactions per second. just because we have this inherent bottleneck. And so the way that we scale out, once we've reached all the gains by increasing the gas limit, is by having multiple instances of the EVM. So this is going to be EVM 0 and then EVM1, EVM2.

And the cool thing is that once we have this upcode, anyone can programmatically kind of create a new instance of the EVM. Wow. So this would become kind of Ethereum, Maynett, the layer one kind of our multi-core moment then? What's kind of the analog? Is it from 486 to Pentium? I don't know what we're doing here.

Yeah, I think that's a good analogy. We're going multi-core. So for a very, very long time, we've had these CPUs, which were just one core. And then what we did is we ramped up the frequency of the CPUs. So it was like hundreds of megahertz, and then one gigahertz, and then 1.5, 2. and then we, you know, nowadays we have, I know, 3 gigahertz.

And you can't do like 30 gigahertz. And the reason is that the transistors just don't turn on enough fast enough. So there's this sequential bottleneck. And so the way that you scale is by scaling out vertically, so horizontally, by having multiple cores working in parallel. And this is exactly what we can do once we have this upcode. And the term that I like to use is enshrined roll up. So once we've snorkeified the canonical instance of the EVM that we have today, we're going to have one enshrined world up.

And then once we add this upcode, we'll allow anyone to create as many enshrine rolled up as they want. Okay. Well, Brian, you've been sitting here waiting very patiently as Justin eloquently described the light at the end of the tunnel, this kind of holy grail. And I think that you are working on that. Now, you're not working on that within the bounds of sort of the, the, the, Ethereum Foundation and applying that to Ethereum Mainnet. But you've got this project called Risk Zero that is actually pursuing the technology that is required to get us to the promised land and everything that Justin just described.

So, Brian, I'm wondering if you could tell us, maybe first, I would love to get your kind of your reaction to what Justin just said and anything that that may be triggers in your mind. And then we'll talk about what you're building out at Risk Zero and this platform that you're calling Zeth right now. But first of all, any reaction to what Justin just said? Yeah, I mean, it's pretty clear that with all of the advances that we're making in cryptography, as you said, that, you know, the capabilities of Ethereum are just going to continue to compound and compound and probably much faster than we would have seen or thought of even possible. So I think the future is very bright, given all of the advances that are being made across the entire space. And this is just one key in a very large puzzle. So it's very exciting.

Okay. Well, so tell us what you're building then out on the frontier, which again looks a little sci-fi from our perspective, but seems to be at the same time also happening faster than many would have imagined at least many years ago. So your company is called Risk Zero. and you've got, I believe, this platform called Zeth, and we describe this as a type 1 ZK EVM. And this goes kind of beyond what I even know I'm describing. So, like, what is Zeth and what is a type 1 ZK EVM? Yeah, so Zeth is an EVM implementation that's actually based on Reth,

which is like Geth, a new implementation of the EVM. However, it's one that's built using Rust. And a type 1, the AVM is simply one that can actually process the full nature of Ethereum an entire block and prove, effectively snarkify an actual Ethereum block, as opposed to some of the other L2s that you have out there that have made various compromises in order to, in order to create a more provable EVM. Type 1, EVM makes no compromises and sticks to the original Ethereum specification, but still produces this snark. that that succinctly verifies that the EVM computation was run correctly. So the other ZK EVMs that we've talked about many times before, the ones that Polygon are building, the ones that Matter Lab is building,

the one that scroll is building, you differentiate that and you'd say that's not a type 1 EVM because it's a little bit different in some way? Is that correct? And how is it different exactly? They're all different in different ways. And they often change exactly how things get mercilized, how states stored. And they generally tend to implement all the op-hids.

I don't know, Justin, you want to expound upon that? Yeah, so generally speaking, what will happen is that they will want a solidity developer and solidity code to be reused. That's kind of one of the main goals. And so they're going to re-implement every single upcode. But in, you know, be under the hood, under the bonnet, they're going to be making some, some taking some shortcuts to optimize things. And one of the prime kind of shortcuts is to change the way that the storage is Merkleized.

So today we have what's called a Patricia Merkel tree, which is using this Ketchak hash function. There's all sorts of technical terms just to say that the way that we handle storage is very much non-snock-friendly. And so what these teams have done is they've just taken a completely different approach to authenticate and Merkley. the state. Another possible difference is changing the gas schedule, right? Because the EVM gas was designed from the perspective of CPUs. If a certain operation takes, you know, 100 nanoseconds, and another one takes 10 nanoseconds, then, you know, the first one should be kind of roughly 10 times more expensive

from a gas perspective. But the gas schedules don't translate very well to Snockland. So you could have a very, very cheap instruction on the CPU. For example, you know, doing a hash like Ketchak. That's extremely fast on the CPU. But if you were to do it in Snockland, it's extremely expensive. And so in order to protect themselves from these denial of service attacks where someone can craft a block with lots and lots of Ketchak and basically mount a denial of service attack on a specific roll-up,

they've adjusted the gas schedule. So it's not exactly compatible with the EVM that we have today on Mainnet at layer 1. So because of those changes, because of those, you know, I guess optimizations or differences, these type 2 ZK EVMs are not candidates to become an enshrined roll-up, at least in their existing form. Is that correct? And this, a type 1 ZK EVM is closer to a candidate to be. becoming an enshrined roll-up. Am I making that connection correctly?

Yeah, that's exactly right. But what I'll say is that oftentimes, like, these are journeys, right? They start somewhere and then they incrementally become more and more compliant with the EVM. I mean, this even happened with optimistic roll-ups, right? At first, they had these small modifications relative to the EVM upcodes. And then they said, no, we want to be exactly equivalent with the EVM upcodes. And this journey is going to happen for the ZK EVM roll-up implementations, I believe. And part of the reason is that you get to benefit from a lot of tooling, from a lot of standards, from a lot of network effects.

But the trade-off here is that it's much, much harder from a technical standpoint. But what's happening and is kind of magical to see in front of our eyes is that the technology is improving at an extremely fast pace. we kind of have an equivalent of Moore's law for snark improvements. And I don't know what it is, but something like, I don't know, improving by 4x every single year. So give it a few more years. Can we make a Drake's law here, please? I want a law. Like, it's a Moore's Law with another Moore's Law on top of it.

Okay. Right. Yeah. Okay. Okay. So this is about the limit of my tech. technical proficiency here. And I'm wondering, Justin, if you could sort of, what questions do you have for for Brian here, actually, about how this works? So we're talking about this type 1 ZK.

We've fleshed out the rough contours of what this actually is. But I think this has an impact on a lot of things on bridges. We talked about enshrined roll-ups, multi-provers. You know, there's the performance conversation, security licensing type of conversation. Why don't you you take some of the technical details here and maybe, you know, I'll come back and ask the dumb questions as they arise in my mind. Perfect. Sounds great. But I guess I do have one non-technical question, which is a little bit about context setting, which is that it seems like you guys were in stealth mode for a relatively long amount of time, maybe, you know, a year or two. And, you know, a few days ago when you made the announcement, Vitalik was messaging me and it's like,

Who are these risk zero people? You know, are they doing good work? Can they be trusted, et cetera, et cetera? And, you know, if Vitalik is not aware of you guys, maybe the listener is also not aware of you guys. And so I guess my question is, what prompted you in the first place to build a ZKVM? Normally when you build ZKVM

is because you're aiming towards a roll-up, but my understanding is that you're not aiming towards a roll-up. what is the background here? Yeah, I mean, so risk zero got started with this idea of building out general purpose ZK capabilities, the ability to actually prove any computation. So not just the EVM, like an existing game. You could prove Doom. You could prove Linux.

People are actually using this to prove the execution of Linux. So, ECC, not this past one, but two years ago, or two ECCs ago, I was talking about the that, you know, in my mind, the best way to build the ZK.EBM was to actually just take the code that people already read and then run it in this sort of general purpose context because you don't actually need to then engineer all these hundreds of circuits. So basically reduces the amount of capital required to actually run an EVM and produces a world where the proofs that you're creating are very much in line with the clients that created them. So, yeah, I would say we've I've been thinking about doing this for a long time.

It's just getting the sort of technical requirement, getting the technical capabilities over the line to the point where we could do this. We really just got there like two months ago. So then as soon as that happened, we're like, okay, now we have to actually try to make the EVM real, the type 1 EVM. And it turns out like it was, you know, fairly straightforward once we got the, you know, an extra year of engineering done to get the sort of continuations and long-running proof future to work. And Brian, this is maybe the flash of lightning that Justin is referring to because

Rissera just came across my radar last week as well. And David was like, hey, I'm going to be out. He's at Burning Man, actually. So I'm going to be out next week. Ryan, you should go talk to these people and see what's going on. And this is the tweet, introducing Zeth, a fully open source type zero ZK EVM built on the Risk Zero ZK EVM and Bonsize. Zeth is a performance. performant, upgradable, and scalable way for developers to ZK prove any Ethereum block ushering in the next generation of ZK and EVM. So pretty big tweet thread to splash in the world. And yeah, that's part of the context for this conversation.

All plus one, Justin is like, we want to find out what you guys are doing. What's going on here? Yeah. So the type zero thing is definitely a joke. I might have brought some people the wrong way. But the idea, like, it's a type 1 EVM, but we didn't have to do, you did zero work to make it work. Because we just utilized all the hard work of everyone else in the space to create this platform. It's not entirely true.

We had to change some of the ways like the Merkel Patricia She works to make sure it's like more snark friendly or stark friendly. And then we also had to modify a bit of the database backend. So it definitely required some brilliant work by some amazing engineers, but like a month and three people. to get this over the line. Now, you know, there's tons of room to increase the performance of the system and all kinds of things like that. But we really have gotten to this kind of base level

of now we can actually ZK-proof Ethereum exactly as is. So if I were to summarize, it sounds like you guys started off very much as a technology company, focused squarely on snarks and snarkifying the world. And you have this really interesting

approach, which I guess, you know, we should, we should dig into, very interesting technical approach. But in our, in our pre-call yesterday, one of the things you mentioned was that there was some sort of partnership maybe with another role that projects, maybe the optimism project. And that little piece of nugget was kind of interesting to me because it kind of what created the bridge between the technology company and more so like the crypto or the Ethereum company. Yeah, I mean, we've been talking to OPE like on and off for a while because this idea that you can take ZK and sort of create fraud proofs. As soon as you can ZK prove something, you can also ZK prove that something is different than what other people said it is.

So you have this kind of ability to automatically create a fraud proof if you have a ZK provable system. So we've been chatting with optimism for a while. They eventually decided they were going to send out this like RFP or mission. for people to actually ZKFI the OP stack. And us and Mina and a couple other teams all applied. And our solution was very much based on the preliminary work we'd done on Zeth. We realized rather than taking this very complex fraud-proving system, which is an amazing work of engineering,

but kind of sidestepped it and said, let's just take the OPE-Rath in development libraries and just create a way to ZK-prove those, which effectively provides a fraud-proof mechanism because now you can prove, well, once it's done, which will be in, you know, near future, you'll be able to prove that an optimism blog user is not a different, different from what the chain actually agreed on. So we're going to actually see, I think, in the near future, through this partnership with optimism, the ability to get, you know, liquidity much faster than seven days, remove your assets around and access your money. So yeah.

And this gets to sort of what you were saying about the magic of Snarks and being able to, you know, in the distant future, have Ethereum itself be factually hyperscale, however you want to say that. Right. So I think what is partially going on is that optimism as a project, which is, you know, an optimistic roll-up is thinking down the line of upgrading to ZK roll-up. And they submitted this request for proposal where they're saying, okay, anyone in the world, if you can, help us snockify optimism, we're going to give you money. Now, I had a look at the grant, kind of the request for proposal, and it was 250,000 OP tokens, which at current price is about $375,000. Now, the reason I mentioned this is because if you had asked us, you know, two years ago to come up with a prototype, a proof of concept for type 1 ZKVM, with open source code running in, you know, on the cluster of GPUs,

that would have cost millions, if not tens of millions of dollars. And for now, for half of a million dollars, you know, we have this new team coming forward and providing, you know, technology. And I think one of the key tools used here is abstraction. Right. There's this kind of this massive shortcut that was taken. And so there's this kind of various pieces of the puzzle. And the way that I think about it is that there's three steps.

You start with an existing FM client, in this case, RFF. And then there's this new intermediate step, which is Risk 5, which I guess it would be good for you to describe what exactly is Risk 5. And then there's kind of this final step towards getting a snark. and it seems like actually that there isn't much work going from the client to Risk 5, almost no work, and then same thing for going from Risk 5 to the Snok. So can you describe these three steps and the work involved in getting one? And really quick, Risk 5. What is Risk 5?

We know what Risk 5 is. It's a company. Right. So Risk 0 name comes from Risk 5, and Risk 5 is an open source instruction set architecture, for actual microprocessors. So people familiar with like the Apple M2 or Arm or X86 or MIPs, you know, these are actually instruction sets. So similar to the EVM, they have op codes that tend to be, you know, there are op codes that can actually be reified in a hardware in a reasonable manner. So X86 has, you know, hundreds, thousands of them.

So it's a complex instruction set architecture. But then you've seen the shift towards arm. And MIPS is very old. The Risk Five is kind of the spiritual successor to MIPS in a way. So it's a very small set. Well, it has a couple different dialects, but you can boil it down to about,

I think only 40 something off codes at its core. So what we've done is created a ZKVM. So it's not an EVM. It's the same idea, except for what it does, is process these much lower level instructions. So there's not really pre-compiles or anything like that. are escape patches that you can use. But so there's this core, very minimal set of computing instructions that that Risk

5 sort of publishes. And people can actually take Sci5, the company that invented it. You can just get a spec from them and you can put Risk 5 cores into whatever project you're doing. So almost every computer that's shipping now does have some number of Risk 5 cores somewhere in the sort of bigger chip. most chips, anything people think of as a CPU or anything like that is really a system on a chip that probably has 20 different cores in it. So anyway, by doing all of this,

we've taken the ability to ZK prove something and said, we're going to be able to ZK prove anything you could run on a normal processor. So the reason that sort of going, so going from risk five to a ZK proving of risk five was something we, um, you know, surprise the ZK world with at least about a year and a half ago when we, when we released this, I think, you know, the time Ellie had said that he, Ellie been song from Starkware thought that, you know, general purpose ZKVM was at least five years out. So this is another example of ZK kind of just happening much faster than people would otherwise expect. So by focusing on this minimal set of instructions, we were able to create a very performant ZKVM. And most of the work to translate from anything else into Risk 5 has already been done by the Risk 5 development community and by the LVM compiler community. So we're really just leveraging the network effects of open source software to take as just instead a massive shortcut to get to ZK proof of Ethereum. So basically there's this two translation steps or kind of compilation steps that need to happen.

and it turns out that the Rust programming language, by default, today, already allows you to compile to various CPUs. So when you have a Rust program, you can compile it to X86, which is a lot of Intel machines run on this. You could compile it to Arm, which is a lot of the new Macs and a lot of phones run on Arm. But you can also compile it to this more arcane but still kind of popular enough. to be supported instruction set, which is called Risk 5. And so there's basically all the work has been done to go from Rust, which is, for example, ref, which is written in Rust, to Risk 5. And then there's this one-time step that needs to be done to go from Risk 5 to a Snock.

And this is the heavy lifting that Brian and his team have done. but it's a one-time thing. And so now we can kind of take any rush program that we want and kind of reap the benefits of abstraction. So now what the normal, the current, I guess the traditional paradigm for snarkifying things is to work very, very close to the metal, very, very low level, right?

You have a program that you want to snarkify and you're going to kind of jump through lots of hoops and kind of work with these polynomials and very low-level programming languages, partly because there isn't much tooling, but also partly because you need the performance of these really low-level optimizations. One of the things that's happening

is that we're getting more and more powerful abstractions, which means that as a developer, you can work with higher- and higher-level programming languages, and Russ is an extremely kind of high-level and friendly programming language. And within the blockchain space specifically, it's extremely popular. And in combination, we're finding all sorts of optimizations,

both kind of at the software, at the hardware level, to make this palatable. Like, maybe we should move to performance, which is that back then, you know, we could have said, yes, you can go ahead and do it, but it will take, I know, days to produce a proof for an inferior block. What kind of performance do you guys have, and how did you get there?

Yeah, so the performance varies based on which kind of hardware, actual hardware target you're running the ZKVM on. So we support CPUs, we support the M2 GPUs, and we support Nvidia GPUs as well. So getting to this level of performance has been a multi-stage journey. And honestly, there's a lot of room for us to get even more performance out of it. But one of the early choices, the reason we use this particular subset of a 35-32-bit instructions set is because it lets us operate in the sort of smaller prime field, which is much more amenable to being accelerated on GPUs. And specifically, I think interesting to the sort of Ethereum space and blockchain in general, you know, this smaller field means you don't need these massive crazy ZK proving rigs anymore. You can actually do ZK proofs using like a 16-gabyte desktop GPU. So that actually, so we built a proof system that could run in these really small kind of consumer grade cards.

However, then that had some other kind of downside, like you couldn't run giant programs. So we built this system called Continuations, which uses, it's like folding you've mentioned a bunch. So it's a way to take proof and split it up and do a bunch of small proofs and then let a bunch of different parties effectively prove bits of them and roll them back up into one single proof. So getting to this level of performance, we had to opt up. It might as the recursion circuits because taking that 1,024 proofs and rolling it down into one proof, you know, takes 10 vertical steps of recursion. And then beyond that, we have this ability to actually run the proving computation itself. Yeah, as I mentioned, on a GPU rather than a CPU. And we see pretty significant gains for that, but there's, we're just really kind of scratching the surface because we haven't.

We focused on enabling everything, which is kind of our core thesis. Let's do the general purpose thing, let people actually prove something, and then we can focus on the performance where it matters. So, yeah, it's been a combination. On that performance, so I'm Justin kind of like the intros we're exploring this throughout the possibility that someday we could run an Ethereum, a sarcified Ethereum validator from our smart watch. It sounds like there are a lot of performance steps necessary to get there. And I'm curious, like, how close are we? So is what you're saying, Brian, that right now we could run what you've developed, which is this ZK type 1 EVM on a home consumer laptop.

This is a pretty beefy laptop. And then how many steps away are we from getting that to like a smart watch? Well, so proving, I don't think you're going to, when you end up in this sort of enshrined to roll up world, you're not going to have the proving be done on the smart watch. The proving was done by these machines off in the cloud or in this decentralized network. And then the verification, because your snark or stark, like, they're really small, the snarks especially. And, you know, it takes literally fractions of a millisecond.

So the computing power to verify the snark is there. And then once you have data availability sampling, you know, you really just don't need that much information to actually participate fully in the networks. You can have a very light, light line. So then why does performance matter so much? Oh, performance of the proving system? Yeah. Effectively, it gets down to how quickly you can make these sort of EVM blocks, right?

Like right now it takes us, if we use 64 of these off-the-shelf machines, it takes about 50 minutes, and I think there's probably an easy 10x there. But if you use even more machines, we can get down to 12 minutes. But realistically, if you want this sort of enshrined roll up, you need to, what did you say, Justin? If you want to, if the use case specifically is being a validator, then when a new block comes in, you want to know that it's valid a second later. Basically the latency, the proof latency,

the time it takes to generate the proof should be on the order of one second. And today we're not there yet. We're maybe 100 to 1,000 X. So let's say 2.5 orders of magnitude away from getting there. And so performance matters for two key reasons. One is this proof latency that we,

you know, for some use cases, we don't really need the low latency, but for other use cases, we do need the low latency. And the other reason is just diminishing the size of the prover. So nowadays, if you want to be a prover, more likely than not,

you're going to rent out a rig of GPUs on ABLEUS. You know, Brian was talking about 64 GPUs, I believe, on A2U.S. And that's not super friendly to a decentralized proving network of people at home. And so what we partially want to do as well

is kind of shrink all these 64 GPUs into like a small box. And the way to get there in my opinion, I'd be curious what your opinion is, Brian, is to have snark acceleration. So we went from CPUs to GPUs. And then the end game

is to go from GPUs to ASICs. Yeah. I mean, I still think even when you get to the ASIC level, you're still going to end up, like, And you have a huge decentralized network of Provers, maybe these A6-3 even in people's phones, you're still going to end up splitting, you know, proving an entire ETH block probably up over, you know, hundreds or thousands of nodes.

So I think parallelism is critically important no matter what. But the ability, now that we sort of shrunk the requirements of the Prover down to where it is, I think the ability of hardware acceleration to really make a difference is actually there. I was pretty bearish on hardware for the first year of the company's existence because I didn't think, I didn't think people were going to be able to do better than Nvidia. It's really hard to do better than Nvidia with their sort of GPU performance. But the stuff I've seen coming out of several hardware teams recently is really, I think there's going to be, yeah, the ability to get to, you know, gigahertz level GPU. you, sorry, gigahertz level ZK proving through A6 in the, you know, five-year time frame, let's say, three to five years, yeah.

Okay, so if I were to try and summarize, you know, where does this performance come from, which is just to recap, it's like a 10 minute, roughly speaking, 10 minutes to one hour, proof latency comes from three different types of tricks. One is on the proof system itself, where you move to this different type of, so-called finite field, which is 32 bits as opposed to something larger. You've leveraged the GPUs, which, you know, as you said, Enviso there's a great job with the GPUs, which are used for AI, but can also be used for snarks, which are also extremely compute-intensive. And then there's this final really beautiful trick, which is basically recursion, where you

take a big chunk of computation, you cut it up into much smaller chunks, and then you do the proving for each small chunk in parallel and then you kind of reassemble all the pieces of the puzzle and all of that can be parallelized and distributed. Very well said. Are you a Metamask user? Well, you're listening to Bankless. So of course you are. The wallet you know and love just got a whole lot better. Metamask portfolio is the ultimate one-stop shop for all of your crypto needs. It gives you a holistic view of your crypto portfolio across multiple chains and multiple addresses all at once. You can easily view and manage all your coins, tokens, and NFTs in one convenient place, just by connecting your wallet.

Metamask portfolio goes beyond just viewing your portfolio, though. Inside the portfolio, you can do all the incredible money verbs that make defy so powerful. You can buy, swap, bridge, and stake your crypto assets with ease. It's like having a powerful battle station for all your defy moves right at your fingertips. So if you're looking to do more in Web3, your way, Metamask portfolio is the answer. I already know that you have Metamask wallet, so go check out your Metamask portfolio. Learn more at metamask.io slash portfolio. Introducing ETHX from Stater.

ETHX is a liquid staking token designed to maximize rewards, all while securing Ethereum. With Stater, you can run an Ethereum node with just 4Eath, which is 85% lower capital and 35% higher returns versus just solo staking. Stater has a multi-pool architecture with both permissionless and permission node operators to enable decentralization and scalability. Stater has extensive experience in building liquid staking solutions on six proof-of-stake blockchains and is trusted by over 70,000. Stater has partnered with over 40 leading protocols on these chains to bring Defi utility to their liquid staking tokens. Stater is actively building integrations and partnerships across Ethereum to bring the same great defi utility to the ETHX token.

While smart contract bugs are always a risk in defy, the ETHX smart contract has received three independent audits and has a million dollar bug bounty with Immunify. Go to Staterlabs.com slash ETH slash stake to access the Stater staking protocol today. You know Uniswap. It's the world's largest decentralized exchange with over $1.4 trillion in trading volume. You know this because we talk about it endlessly on bank lists. It's Uniswap.

But Uniswap is becoming so much more. Uniswap Labs just released the Uniswop mobile wallet for iOS. The newest, easiest way to trade tokens on the go. With the Uniswap wallet, you can easily create or import a new wallet, buy crypto on any available exchange with your debit card, with extremely low fiat on-ramp fees, and you can seamlessly swap on main net, polygon, arbitram, and optimism. On the Uniswap mobile wallet, you can store and display your beautiful NFTA.

And you can also explore Web3 with the in-app search features, market leaderboards, and price charts. Or use Wallet Connect to connect to any Web3 application. So you can now go directly to DFI with the Uniswot mobile wallet, safe, simple custody from the most trusted team in D5. Download the Uniswap wallet today on iOS. There is a link in the showdowns. Now I guess the next big topic in my mind as an Ethereum researcher and thinking of type 1 Ziki AVMs is security. Right. we have traditionally a lot of complexity going on here.

And the likelihood for bugs is very, very high. And I have this saying, you know, which is maybe I guess a little arrogant. But I believe that every single ZKVM has multiple critical vulnerabilities today. And so we need to be prepared as a community to either have like mitigations to these bugs. And there's a lot of very good ideas. and we also unfortunately need to be prepared to roll-ups getting hacked. So just like we've had a bunch of fairly large roll-up hacks, or so bridge hacks on the order of hundreds of millions of dollars,

maybe close to a billion dollars, we could have multi-billion dollar hacks in the ZK roll-up space. And so I'm curious, how do you think of security and how do you think of removing every single bug from the system? Yeah, so obviously a huge topic. So me and my co-founders actually know each other. We met 23 years ago in the Seattle like infosec scene. So we were all like hackers back in the day. So we have a pretty deep set of sort of experience and knowledge in this space. And that's part of the reason we chose risk five also. It is actually has like there's a full formal formal specification for it. You actually can prove that certain systems formally prove that certain systems implement risk five. We haven't gotten to that. level of sort of formal verification with what we're doing yet. You can imagine getting to the place where you have very strong guarantees that the ZK system itself is proving risk five and only risk five and that and that the sort of conjectured amount of security, the number of bits of security

is actually, you know, is actually what we think it is. So there's a lot of work on the mathematical side to sort of prove that the crypto system itself is like the proving system is actually doing what it's supposed to. Separately, you then need to audit, as you mentioned, the actual ZK circuits. And I think that's an area where this approach really shines is that because the risk five instructions at itself is small, it means there's much less surface area to audit. Although we do have these sort of acceleration circuits that one can add on to the system, it still doesn't increase the sort of audit surface of the ZK part to the same. degree that, you know, doing a ZKVM from scratch wood. Now, you're also, I think as you pointed out,

the pre-call, by doing this, you're, you are potentially onboarding a few more, like, security considerations. For instance, you're trusting the Rust compiler and you're trusting LLVM. Now, these things, and there are often, you know, bugs in LLVM. I think we just found one the other day. So, you know, compilers, especially for new architectures aren't perfect, but this is one of the reasons, again, why we chose an existing architecture. I don't think ARM or something older or more mature would have really fit in a ZK circuit. But by choosing an existing architecture, we get to leverage all of the billions of dollars of investment that's gone into the security of this existing ecosystem.

Gotcha. So if I were to summarize this kind of this final step where we go from Risk Five to a Snock, which is actually fairly digestible because Risk Five is relatively simple. Actually, this reminds me of Cairo from stockware. They have an even more kind of reduced instruction set, which is super simple. And what they've been able to do is apply some of formal verification tools to prove that, you know, things are working properly there. And the hope is that this one-time investment, we can really drill down with powerful tools like formal verification and prove that it's correct. And then we kind of have the rest of the can of worms, which is kind of this fairly complex compiler to go from Rust to Risk 5.

And it's possible that there's bugs, generally speaking, in the Rust compiler. But it's also possible that there's bugs specific to compiling to Risk 5 because Risk 5 is one of the more niche instruction sets that you can compile to. but what might happen is that we're going to start building these roll-ups, you know, which are securing billions and billions of dollars, and then Lindy starts to kick in. And, you know, we might have bug bounty programs. And it's kind of interesting where in a way the blockchain space might make a huge contribution to compiler security. It's going to be way more eyes.

We recently had this bug, right, in the Viper compiler, and that caused a bunch of bugs. and it would be great if we could apply kind of similar tools like formal verification to compilers, like Russ complies, which today sounds very grandiose, but maybe the blockchain use case is so security critical that we're going to try and move forward partially in that direction. Yeah. I mean, people have done this for C and if you're going to make, if you're going to do formal verification proceed, then, you know, Rust is probably also within the bounds of what's

possible. But these efforts take decades for a really long time. But blockchain accelerates everything even if it seemed to agree. You know, ZK would still be like a niche academic pursuit, I think, if it weren't for blockchain needing it so badly. Yeah. Okay, great. So I guess the final kind of semi-technical topic that I have is around licensing. So if we are going to be using a piece of code at layer one, really for it to be kind of palatable, socially palatable, I guess, the licensing needs to be good. And I guess the kind of favorite types of licenses that we have might be Apache 2.0 and the MIT license.

Can you discuss what have you open sourced and under which licenses? Yeah, so the sort of core Risk Zero ZKVM, so the Risk 5 proving engine, that's a license or the Apache 2 license right now always has been. And then Zath itself will probably be Apache 2 slash MIT licensed. We might also end up, I do the licensing everything because that's kind of the standard in the Rust community. And OPE is a fan of MIT. So that's for the system that produces, takes the EVM program and chunks it up into a bunch

of little proofs and then proves all of those. The parts we haven't yet open source to release is the part that actually takes all those proofs and recurses them down into a single proof. And then also this thing that converts the stark that we use into a stark. So there are two kind of aspects of this that we haven't launched. And effectively, we're waiting for these things to get through security audits. With the current system as is, you can't really, the proof's much too large to put on chain. So it's kind of hard to get wrecked because you can't actually use stuff on chain as readily. So right now, if people want to use the system, we have to get an API key from us.

But that's definitely not the direction we're headed. We're very much committed to fully open sourcing the entire system. But we want to make sure we have a high confidence that people are not going to get wrecked soon because of the ZK system. Okay, understood. So you've open sourced several key components under a very attractive license, Apache 2.0. And you're thinking of dual licensing it maybe with MIT. so you can choose which license you want when you start using the code. And part of the prover is already open source,

but maybe some of the final things involving the recursion and kind of wrapping it into a tiny, tiny proof so that it can be consumed on chain. That's not yet open source. Yeah, exactly. So, Brian, Risk Zero seems to have come out of nowhere. And, you know, it's super incredible how fast all this is coming to be, to, to, um, bear here. And like open source working, it sounds like first to kind of snarkify our favorite L2s out there, like working with optimism and others. So I imagine that's going to be a bulk of the

work at first. What are you guys planning to do here? Like what's the business model for risk zero? It almost sounds like what you're producing is a public good. And here, you're Justin and I and the rest of the bankless community are kind of, you know, cheering you on. But I'm sure you have investors. I'm sure you have VCs here that have, you know, put you put some money in, and they're going to expect some kind of return. Yet you're not building a layer to yourself as of as of yet, it sounds like. So, or maybe you will. So yeah, tell us what risk zero is put on earth to do. What do you, what do you planning to do in this space? Yeah, in this space We're really focused on this Bonsai ZK application development platform.

So there's something we've been working on for a while. Because you can use ZK for all kinds of things. I don't know how if you've talked to many of the ZK co-processing teams. But you can use Bonsai effectively the ZK co-processor, which lets you run a bunch of complex logic off-chain and then just attest to it on chain. So we like in Denver, I talked about like a L1 club, effectively running an order book on Ethereum directly. uniswap. You can achieve roughly uniswap level pricing by doing all of the order book matching

off chain. So you have your orders. The orders get placed on chain. And then Bonsai sort of just reads those orders, does all the matching in ZK just on one machine, some and ran any random corner at the internet or AWS wherever you want it to be. And then says, okay, here's proof that these are the orders that got matched at this price. So this thing, Bonsai is kind of a platform for ZK snarkifying apps, maybe, let's call it. Apps and the roll-ups, anything really. So we expect right now it's a centralized SaaS offering, and we think there's long-term value

and sort of providing an enterprise sort of open-core model there, but we will definitely be building a decentralized network around that as well, exactly what that looks like. Who knows? It's going to be very focused on the sort of core accounting for, approving tasks. So kind of like a proof marketplace, but we expect that it will add interesting features for application developers over time. This is the ability with continuations to do sort of ZK Docker. You can prove something up to a certain point. You can suspend the thing and then you can

just keep going on later. So you can kind of imagine having a ready-to-go EVM image versus people can just resume it and they have like full access to the Ethereum state. Is this like a sort of an AWS for ZK proofs kind of thing. It's just like a marketplace here. And you're looking to try to make it as decentralized as possible. That could be a future here. Definitely. I mean, this is like when we got into,

I mean, Jeremy, or she scientist is just always into AI and ZK and all of these things. But when we started really thinking about what we're going to do with it, I think that really got me excited was the potential of this technology to kind of let people who are building infrastructure and applications. not need to rely on, you know, Facebook, Amazon, Microsoft, Google for everything. So this is the idea that we could actually fully decentralize the sort of infrastructure that goes into many of the applications we use has always been really appealing part of, like what this technology is capable of. So I think Bonsai is going to be a platform that

helps people do that. So Brian, what do you think happens next in kind of the roadmap? So all of this seems to be happening faster than we all thought it would, which is so incredibly exciting, the level of investment in the space and the level of talent in, you know, brains now being focused on crypto is just absolutely astounding. We almost ended the episode with kind of the one of the last, you know, parts, which I think is, of course, the public good that is Ethereum mainnet, kind of that will upgrade to a fully snarkified, enshrined ZK. EVM, probably last. We're going to want this fully proved out in all sorts of ways across crypto before we get to that stage. So I'm wondering what do you think will happen in the interim

over the next six months, over the next, you know, one to two years. How do you think the tech that you're building will start to impact the crypto landscape? Will we just see, you know, ZK snarkified layer two should be expected to see this technology applied mainly in rollups? Are there apps that you see this being applied? Or will it take a few years? Yeah. All of the above. We're definitely working with, you know, L2's L3's rollout frameworks, however you want to think about all of that space. And also, you know, we're working with people on DFI projects and eventually gaming is going to be a big part of this. The way I see this playing out is, you know, just like friend. Dot Tech kind of surprised everybody with how much better the crypto onboarding experience has become. And be sure, there's still a lot of room to go. I think the head way that people been making and making crypto applications easier for people to use is going to then also increase demand for the capabilities of these systems to be, you know, to be able to do more and more interesting things. So I think we'll see ZK planning a critical part in all of this by enabling

people to do whatever computations they want off-chain and readily attest to them on-chain. So the sort of ZK co-processing architecture is going to be a huge unlock for applications built. Yeah, for Web3 applications. Well, this has been great. Justin, do you have any other questions for Brian, or should we start to close this out here? I think I have one final question, which is around your alignment with Ethereum. I think we had a, you know, during the pre-co, it sounded like as an individual, as a person, you were in this space for quite a long time. And, you know, you have a certain set of beliefs.

and I'm curious what those are, but also how this translates into the culture of the company. Yeah, I mean, our sort of core, three core values are like integrity, transparency, and agency. And I think, you know, if those aren't like Ethereum aligned, I'm not really sure what that sort of even means. So coming out of the, you know, the founders came from, it just seems like. like a very natural sort of fit to the sort of ethos of Ethereum. So I think value-wise, yeah, we're really, the vision of the sort of hyperstructure world of the future is very much something we all resonate, like very deeply resonates with all of us. Brian, what first brought you down the crypto rabbit hole?

You know, buying supplies for Burning Man. That's funny. As my co-host is literally at Burning Man right now. Fantastic. No, but it's been a crazy journey. And so it's really fun to get more and more into the space. Yeah. Well, very good.

And maybe my last question is kind of the high level to Justin. So this idea of hyperscaling Ethereum using kind of like fractal, you know, crypto proofs, on top of ZK proofs, I mean, has this always been part of the plan? or is this just happenstance? And I guess when you think of the term hyper-scaling, how do you envision Ethereum looking five years from now? Is all of this stuff just kind of working? And what's the total transactions per second?

I don't know. What's the sci-fi Ethereum with this tech applied? How does that look, Justin? Right. So, I mean, if you want to think in terms of end games and fundamentals, you go back to these fundamental resources, computation that's just not going to be a problem of consensus. And the way that I think about it is that consensus is this very flexible tool that can solve

all sorts of problems. And then cryptography, what it does, it gives you a few superpowers that allows you to reduce the scope of consensus and basically have more and more crypto and less and less economics, if you will. And historically, actually, one of the big breakthroughs for consensus was simple message authentication and signatures. That kind of changed the model where you had these messages that could be intercepted and modified, but that didn't really matter because they were kind of sign and authenticated.

And so the model was, what can you do with consensus given signatures? And now we kind of have this new tool, which is much more powerful from a cryptographic standpoint, which is what can you do with consensus with SNOCs? And it turns out that the things that needs to solve are data availability and finality. And it turns out that data availability is something that we can solve with data data sampling, as I mentioned. And then there's this other thing, finality, which I only discovered recently, you can also solve with cryptography, with these really, really sophisticated pieces of cryptography called

one-shot signatures, which actually marry quantum mechanics and cryptography. And so then you can ask ourselves, okay, what is consensus useful if, you know, cryptography solves all these things? But it turns out that the last thing that's still not solved is this concept of lightness. Like, how do you make sure that the chain just keeps on going, even if, like, validators just, you know, don't show up. For example, if there's World War III and 90% of the population has. has gone. And this is kind of cool because we're reducing and reducing and reducing the scope of

consensus and we're kind of hardening the rest with pure cryptography and physics and mathematics. It's a very long journey to get the one-shot signatures because we need these quantum computers. But in the meantime, we're going to enjoy the spoils of snarks, which are extremely significant. Well, it seems like we have entered the SNARC era for sure, and there's going to be a lot of that applied to crypto in the future. So Brian, Justin, thank you so much for guiding us on the tour today. It's been much appreciated. Thank you. Thank you.

Bankless Nation, risk and disclaimers. Got to let you know, of course, none of this has been financial advice. I don't even think we talked price in this whole episode, so obviously not. Crypto is risky, so are compilers, so are new layer twos. You could lose what you put in, but we are headed west. This is the frontier. It's not for everyone, but we're glad you're with us on the bankless journey. Thanks a lot.