00:00.028 --> 00:02.849
Hey Bankless Nation, I'm very excited about the episode today.
00:02.849 --> 00:09.692
David is out, and this episode gets technical at times, so I have ETH researcher Justin Drake, whom I'm sure many of you know.
00:09.692 --> 00:12.054
He's co-hosting with me today.
00:12.054 --> 00:14.515
Some context as we get into this episode.
00:14.515 --> 00:19.357
So we did a previous episode a few weeks ago called The Sci-Fi Roadmap to Ethereum.
00:19.357 --> 00:23.179
And in that episode, Justin Drake described the endgame for Ethereum.
00:23.179 --> 00:25.280
And he said this, we snarkify everything.
00:26.240 --> 00:30.105
In today's episode, we explore exactly what that means and how we do it.
00:30.105 --> 00:32.187
How do we snarkify everything?
00:32.187 --> 00:33.629
Our guest today is Brian Redford.
00:33.629 --> 00:39.016
He is the co-founder of what might be the world's first Type 1 ZK EVM.
00:39.016 --> 00:40.538
And if you don't know what that means, that's fine.
00:40.538 --> 00:42.300
Neither did I, as we were getting into this episode.
00:42.680 --> 00:51.633
And it turns out that building a type one ZK EVM is an important part of delivering what Justin Drake called an enshrined rollup inside of Ethereum.
00:51.633 --> 00:52.695
More on that in just a minute.
00:52.695 --> 00:57.762
But before we get in, just want to mention something quick from our friends and sponsors over at SAFE.
00:57.942 --> 01:00.583
SAFE is the multi-sig wallet we recommend for crypto.
01:00.583 --> 01:06.046
And you've heard us talk about smart contract wallets many times, how they're going to 10X the crypto wallet experience.
01:06.046 --> 01:07.506
We definitely believe that's true.
01:07.506 --> 01:18.151
And SAFE recently proposed their modular open source SAFE core protocol as a standard for the industry so that we can all move forward and transition to the smart contract wallet future.
01:18.151 --> 01:19.431
And they want you to check it out.
01:19.431 --> 01:22.033
So there's a link for the devs in the show notes.
01:22.033 --> 01:27.535
SAFE really believes this is an opportunity to create a unified standard to catapult smart contract accounts
01:28.035 --> 01:29.256
onto the EVM.
01:29.256 --> 01:35.959
The standard itself is unopinionated and vendor agnostic and maintains interoperability and smart contract diversity.
01:35.959 --> 01:36.819
So go check it out.
01:36.819 --> 01:44.203
And also to check out, SAFE is organizing the first ever conference dedicated to smart contract wallets and account abstraction.
01:44.203 --> 01:46.204
That happens the second week of December.
01:46.204 --> 01:49.325
There'll be a link in the show notes to go register for that as well.
01:49.325 --> 01:51.226
So thanks to SAFE for building into the frontier.
01:51.806 --> 01:55.608
All right, speaking of frontier, back to Ethereum enshrined rollups.
01:55.608 --> 01:57.709
So why are we having this conversation and why now?
01:57.709 --> 02:02.451
The compute era scaled with Moore's law, but the blockchain era scales with something differently.
02:02.451 --> 02:07.394
It scales with cryptography, specifically cryptographic breakthroughs like ZK Snarks,
02:07.894 --> 02:15.142
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.
02:15.142 --> 02:26.014
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.
02:26.875 --> 02:28.997
What kinds of things could this unlock in the future?
02:28.997 --> 02:30.078
Why is this important?
02:30.078 --> 02:33.202
Well, what if we could convert an optimistic roll-up to a ZK roll-up?
02:33.202 --> 02:41.990
What if we could upgrade Ethereum's Layer 1 from a single-threaded EVM model to a multi-threaded EVM, so that compute was virtually limitless and free?
02:42.931 --> 02:48.256
What if ETH validators themselves had the ability to run from something as small as a smartwatch?
02:48.256 --> 02:51.318
All of these are possible unlocks with this technology.
02:51.318 --> 02:53.200
This is crazy cool, deep stuff.
02:53.200 --> 02:58.004
Down the crypto rabbit hole we go, and it gets technical at times, but it's absolutely worth holding on for the ride.
02:58.004 --> 03:04.930
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.
03:05.510 --> 03:09.216
because this is key to understanding how blockchains actually work and how they scale.
03:09.216 --> 03:14.363
And in so understanding, I think this type of thing can help you avoid bad investments and dead ends.
03:14.363 --> 03:16.226
And there are a lot of those out in the space as well.
03:16.527 --> 03:19.028
We're going to get right to the episode with Brian and Justin.
03:19.028 --> 03:27.371
But before we do, I want to thank the sponsors that made this possible, including our number one recommended crypto exchange for 2023, Kraken.
03:27.371 --> 03:28.152
Go check them out.
03:28.152 --> 03:31.993
Kraken Pro has easily become the best crypto trading platform in the industry.
03:31.993 --> 03:36.215
The place I use to check the charts and the crypto prices, even when I'm not looking to place a trade.
03:36.355 --> 03:44.338
On Kraken 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.
03:44.338 --> 03:49.441
Kraken's new customizable modular layout lets you tailor your trading experience to suit your needs.
03:49.441 --> 03:53.022
Pick and choose your favorite modules and place them anywhere you want in your screen.
03:53.022 --> 03:54.963
With Kraken Pro, you have that power.
03:54.963 --> 04:01.566
Whether you are a seasoned pro or just starting out, join thousands of traders who trust Kraken Pro for their crypto trading needs.
04:01.566 --> 04:04.187
Visit pro.kraken.com to get started today.
04:04.707 --> 04:21.342
Mantle, formerly known as BitDAO, is the first DAO-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.
04:21.342 --> 04:29.129
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.
04:29.309 --> 04:36.976
The Mantle Treasury is one of the biggest DAO-owned treasuries, which is seeding an ecosystem of projects from all around the Web3 space for Mantle.
04:36.976 --> 04:44.343
Mantle already has sub-communities from around Web3 onboarded, like Game7 for Web3 gaming and Bybit for TVL and liquidity and on-rails.
04:44.563 --> 04:54.089
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.
04:54.089 --> 05:02.374
If you want to get started working with the first DAO-led Layer 2 ecosystem, check out Mantle at mantle.xyz and follow them on Twitter at 0xMantle.
05:02.374 --> 05:07.077
Arbitrum is accelerating the Web3 landscape with a suite of secure Ethereum scaling solutions.
05:07.537 --> 05:12.522
Hundreds of projects have already deployed on Arbitrum One, with flourishing DeFi and NFT ecosystems.
05:12.522 --> 05:18.649
Arbitrum Nova is quickly becoming a Web3 gaming hub, and social dApps like Reddit are also calling Arbitrum home.
05:18.649 --> 05:28.839
And now, Arbitrum Orbit allows you to use Arbitrum's secure scaling technology to build your own Layer 3, giving you access to interoperable, customizable permissions with dedicated throughput.
05:29.059 --> 05:34.522
Whether you are a developer, enterprise, or a user, Arbitrum Orbit lets you take your project to new heights.
05:34.522 --> 05:43.488
All of these technologies leverage the security and decentralization of Ethereum and provide a builder experience that's intuitive, familiar, and fully EVM compatible.
05:43.488 --> 05:46.430
Faster transaction speeds and significantly lower gas fees.
05:46.650 --> 05:54.335
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.
05:54.335 --> 05:57.117
Experience web three development the way it was always meant to be.
05:57.117 --> 05:59.879
Secure, fast, cheap, and friction-free.
05:59.879 --> 06:00.640
Bankless Nation.
06:00.640 --> 06:03.021
I am super excited to introduce you to Brian Redford.
06:03.021 --> 06:09.786
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.
06:09.786 --> 06:11.547
Brian, welcome to Bankless.
06:11.547 --> 06:11.948
Thanks.
06:11.948 --> 06:12.548
Glad to be here.
06:13.417 --> 06:16.978
Also excited to be joined yet again on Bankless by Justin Drake.
06:16.978 --> 06:20.299
He's an Ethereum researcher and repeat Bankless guest.
06:20.299 --> 06:22.059
Justin, how you doing?
06:22.059 --> 06:22.779
I'm doing great.
06:22.779 --> 06:23.719
Thanks for having me again.
06:23.719 --> 06:27.400
But I guess this time, maybe as a host asking some technical questions.
06:27.400 --> 06:27.600
Yeah.
06:27.600 --> 06:28.141
How's it feel?
06:28.141 --> 06:29.121
The tables have turned.
06:29.121 --> 06:32.241
So Justin, I'm going to tap you in as my co-host today.
06:32.241 --> 06:38.283
So David is out and we're going to talk about this, the next generation ZK EVMs.
06:38.283 --> 06:42.324
So I think we're talking to Brian about the world's first
06:42.884 --> 06:46.827
maybe ZK EVM, that's a type one ZK EVM.
06:46.827 --> 06:50.050
And I'm not even sure the words that I'm saying or what they mean.
06:50.050 --> 06:52.692
So we'll absolutely need to define that.
06:52.692 --> 06:54.734
But David's out right now.
06:54.734 --> 06:57.136
So Justin, you're going to tap in and help me with this.
06:57.136 --> 07:03.041
I feel like this is a continuation, though, of a conversation that you had with him on ETHCC.
07:03.041 --> 07:11.288
And I think bankless listeners may have listened to an episode entitled Ethereum's Sci-Fi Roadmap or the Sci-Fi Roadmap to Ethereum.
07:11.868 --> 07:13.529
in which there was this really interesting part.
07:13.529 --> 07:26.657
And I love that episode, by the way, where you were describing the ability of us in the future of Ethereum to snarkify the EVM on mainnet, on the base layer.
07:26.657 --> 07:29.099
And that sounded really interesting to me.
07:29.099 --> 07:32.241
And I think that ties into the conversation that we're about to have.
07:32.241 --> 07:36.864
So tee this up for us, if you will, Justin, as a continuation on that conversation.
07:36.864 --> 07:39.886
I know we're talking about sci-fi Ethereum, future stuff.
07:40.646 --> 07:44.289
But what does it mean to snarkify the EVM?
07:44.289 --> 07:47.631
And how does that tie into the conversation we're about to have with Brian today?
07:47.631 --> 07:48.032
Right.
07:48.032 --> 07:51.874
So big picture, we're actually going to snarkify all of Ethereum.
07:51.874 --> 07:55.657
And there's two big components that need to be snarkified.
07:55.657 --> 08:00.581
One is the EVM, which is this virtual machine which processes Ethereum transactions.
08:00.581 --> 08:03.303
And then the other part is the beacon chain.
08:03.303 --> 08:05.665
Now, once we've snarkified these two things,
08:06.385 --> 08:12.612
will be in a position where compute won't ever be a bottleneck for Ethereum.
08:12.612 --> 08:18.798
So it means that, for example, as a validator, you won't have to really have beefy CPUs.
08:18.798 --> 08:21.881
So you'll be able to be a validator on your smartwatch.
08:23.262 --> 08:36.033
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.
08:36.033 --> 08:45.161
It also has implications for like clients, for what we call enshrined rollups, which are super high security rollups.
08:45.161 --> 08:48.364
And when the words type one
08:49.565 --> 09:02.611
EVM come to mind, Type 1 ZKVM, it really kind of gets me excited as a researcher, because it was a kind of a piece of sci-fi engineering that was thought to be, you know, five to ten years into the future.
09:02.611 --> 09:05.473
But it looks like, well, there's several teams working on them.
09:05.473 --> 09:10.295
There's, for example, Tyco, and there's RISC-0 now, and
09:13.096 --> 09:15.737
it looks like the engineering will just be ready so much sooner.
09:15.737 --> 09:28.922
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 2, but also what I'm excited about, which is the Layer 1.
09:29.682 --> 09:33.307
So what you just described here, Justin, is kind of the Holy Grail.
09:33.307 --> 09:43.720
And I still want to spend some more time with you right here, just fleshing this out and making sure that we understand this going into the episode, because it sets the context for the rest of the conversation with Brian and Risk Zero here.
09:43.720 --> 09:48.126
So the light at the end of the tunnel, or what I just referred to as the Holy Grail,
09:48.746 --> 09:50.467
snarkifying all of Ethereum.
09:50.467 --> 10:01.373
What this means is we get to use the spooky math, the crypto magic ZK math that you've described so eloquently many times on the Bankless episode.
10:01.373 --> 10:14.760
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.
10:15.440 --> 10:18.083
So, okay, is that really what we're talking about?
10:18.083 --> 10:27.933
So of course, one of the end goals and the end goal, the entire purpose of Ethereum is for it to remain decentralized.
10:27.933 --> 10:33.699
And that means ideally, anybody with a basic consumer level computer
10:34.440 --> 10:38.343
can validate transactions on the Ethereum mainnet.
10:38.343 --> 10:44.207
And right now the requirements for doing that are somewhat higher than just a smartphone or a smartwatch.
10:44.207 --> 10:53.774
But this will decrease the requirements, the hardware profile, in order to validate transactions on the Ethereum mainnet and also to stake.
10:53.774 --> 10:54.494
Is that what you're saying?
10:55.675 --> 10:56.356
That's correct.
10:56.356 --> 11:06.383
So anytime you have a human that ends up wanting to interact with Ethereum, they need to interface through a full node.
11:06.383 --> 11:13.709
And there's some complications here because running a full node is not something that you can necessarily easily do on your phone.
11:13.709 --> 11:17.732
And it's not something that the average individual would want to do.
11:18.312 --> 11:23.036
and it's something that every single validator has to do if they want to become a validator.
11:23.036 --> 11:36.805
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.
11:36.805 --> 11:38.867
So for example, if you're using MetaMask,
11:39.567 --> 11:46.034
you're going to be connecting to Infura nodes that are kind of running the full nodes on your behalf.
11:46.034 --> 11:50.298
And so there's some amount of trust that you as a user are placing into MetaMask.
11:51.980 --> 12:04.784
So once we have a Type 1 ZKVM, once we've snockified the VM 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.
12:04.784 --> 12:16.847
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.
12:18.510 --> 12:21.395
Does this imply anything for a bandwidth as well?
12:21.395 --> 12:26.105
Will this decrease the bandwidth requirements or will bandwidth kind of become the constraint here now?
12:27.917 --> 12:28.858
Right, great question.
12:28.858 --> 12:33.401
So consensus kind of solves two problems.
12:33.401 --> 12:37.423
One of them is execution and the other one is data availability.
12:37.423 --> 12:45.669
Snarks is kind of this magic technology that removes computation as a bottleneck within the context of consensus.
12:45.669 --> 12:52.513
And it turns out we have another magic technology for data availability called data availability sampling.
12:52.513 --> 12:54.815
Neither of these are really in production right now.
12:55.535 --> 13:05.846
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.
13:05.846 --> 13:08.990
So you won't even need to download the Ethereum blocks.
13:08.990 --> 13:17.479
All you 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.
13:17.859 --> 13:20.421
So data availability sampling as well.
13:20.421 --> 13:24.424
That's a core upgrade of what I think people are calling Dank Sharding as well.
13:24.424 --> 13:29.247
Not Proto Dank Sharding, as I recall, but Dank Sharding, which could occur later in the future.
13:29.247 --> 13:32.289
Exactly right.
13:32.289 --> 13:44.477
So we're looking at technologies, you know, two, three, maybe four or five years into the future, which in a way will transform accessibility of Ethereum for users.
13:44.477 --> 13:45.278
And in the endgame,
13:46.875 --> 13:50.878
accessing Ethereum will be just as easy as accessing any other website.
13:50.878 --> 13:55.582
And you'll have guarantees, just like on the website today, you have this cap lock.
13:55.582 --> 13:57.504
Sorry, this, this lock.
13:57.504 --> 14:02.508
And HTTPS, you'll have a similar lock saying you're really connected to the real Ethereum.
14:02.508 --> 14:05.150
And you'll have to have done almost no work.
14:05.150 --> 14:08.854
And you'll have have to download it, download almost no data.
14:08.854 --> 14:14.018
And ZK... Trust nobody also, unlike the current kind of lock where you actually have to trust the sort of
14:14.578 --> 14:17.462
signature issues.
14:17.462 --> 14:21.186
ZK technology is the thing that makes this all possible.
14:21.186 --> 14:29.956
What's very interesting is I know there are people who talk about compute scaling in blockchains via Moore's law, and that's true.
14:29.956 --> 14:31.658
But where we really get the massive
14:33.720 --> 14:37.561
scalability is more with like cryptography breakthroughs.
14:37.561 --> 14:52.765
That is something I've learned as part of like exploring the roadmaps and 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.
14:52.765 --> 15:00.627
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.
15:00.627 --> 15:01.828
What does this imply for
15:02.688 --> 15:06.813
maybe scalability on Ethereum mainnet.
15:06.813 --> 15:12.239
So we talked about lowering the compute requirements to be a validator, which is fantastic.
15:12.239 --> 15:15.822
That is a further decentralization unlock.
15:15.822 --> 15:20.668
How about transactions per second on the Ethereum layer one mainnet?
15:20.668 --> 15:22.690
Does this have any impact on that as well?
15:24.059 --> 15:24.980
Fantastic question.
15:24.980 --> 15:37.707
So once we've snarkified 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.
15:37.707 --> 15:43.351
And the reason is that the gas limit is an anti-denial-of-service vector whereby
15:44.251 --> 15:50.933
When you receive a block, you want to be able to fully verify that the block is valid on the order of one second.
15:50.933 --> 15:56.655
And so if there's too many transactions in that block, then it's going to take more than one second to validate.
15:56.655 --> 16:02.557
But the magical thing about snarks is that the verification time of a snark is on the order of one millisecond.
16:03.455 --> 16:16.483
And so you can take a block that's kind of arbitrarily large with arbitrarily many transactions and arbitrarily much execution and know that the execution is correct within a constant amount of time, which is only one millisecond.
16:17.582 --> 16:19.283
So what does that imply then?
16:19.283 --> 16:25.366
So if Ethereum right now supports like 16 transactions per second, and we're scaling that out via rollups.
16:25.366 --> 16:34.290
And last time I checked on L2B, if you count all of the kind of rollups combined in that, we're about 5X 16 transactions per second, something like that.
16:34.290 --> 16:36.692
And that's the entirety of Ethereum right now.
16:36.692 --> 16:36.952
We're not
16:37.432 --> 16:42.019
We're not handling visa level throughput at this point in time, it's safe to say.
16:42.019 --> 16:53.435
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?
16:55.022 --> 16:59.105
Right, so what it means is that there's going to be a partial comeback of the Layer 1.
16:59.105 --> 17:16.296
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 1 is really going to be lagging because we're extremely conservative and, you know, we're frankly kind of slow for good reasons.
17:18.177 --> 17:28.425
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.
17:28.425 --> 17:34.110
And so the L1 will, to an extent, be able to scale out.
17:34.110 --> 17:43.177
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.
17:44.237 --> 18:00.943
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 opcode within the EVM which allows you to verify validity proofs, snarks, of EVM blocks itself.
18:00.943 --> 18:07.565
So kind of the EVM is aware of itself and knows when another EVM block is valid.
18:07.565 --> 18:12.127
And what this allows us to do is have multiple instances of the EVM.
18:12.607 --> 18:19.833
Because ultimately, you can think of the EVM as being this single-threaded CPU or virtual machine.
18:19.833 --> 18:22.856
So it can only run on one core, just to simplify.
18:22.856 --> 18:28.641
And so there's this inherently sequential computation that's going on, which is a bottleneck for scalability.
18:28.641 --> 18:35.748
The EVM will never be able, most likely, to do a million transactions per second, just because we have this inherent bottleneck.
18:36.268 --> 18:45.578
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.
18:45.578 --> 18:50.082
So this is going to be EVM 0, and then EVM 1, EVM 2.
18:50.082 --> 18:57.610
And the cool thing is that once we have this opcode, anyone can programmatically create a new instance of the EVM.
18:58.766 --> 19:07.893
Wow, so this would become kind of Ethereum mainnet, the layer one, kind of our multi-core moment then?
19:07.893 --> 19:09.254
What's kind of the analog?
19:09.254 --> 19:12.756
Is it from 486 to Pentium?
19:12.756 --> 19:13.657
I don't know what we're doing here.
19:14.949 --> 19:16.390
Yeah, I think that's a good analogy.
19:16.390 --> 19:17.231
We're going multi-core.
19:17.231 --> 19:21.754
So for a very, very long time, we've had the CPUs, which were just one core.
19:21.754 --> 19:25.817
And then what we did is we ramped up the frequency of the CPUs.
19:25.817 --> 19:30.360
So it was like hundreds of megahertz and then one gigahertz and then 1.5, two.
19:30.360 --> 19:36.444
And then we, you know, nowadays we have, I don't know, three gigahertz CPUs and you can't do like 30 gigahertz.
19:36.444 --> 19:40.167
And the reason is that the transistors just don't turn on and off fast enough.
19:40.447 --> 19:42.369
So there's this sequential bottleneck.
19:42.369 --> 19:53.441
And so the way that you scale is by scaling out horizontally by having multiple cores working in parallel.
19:53.441 --> 19:57.185
And this is exactly what we can do once we have this upcode.
19:57.185 --> 20:00.508
And the term that I like to use is enshrined rollup.
20:00.508 --> 20:02.010
So once we've snarkified
20:02.670 --> 20:08.276
the canonical instance of the EVM that we have today, we're going to have one enshrined rolled up.
20:08.276 --> 20:14.722
Then once we add this opcode, we'll allow anyone to create as many enshrined rolled up as they want.
20:14.722 --> 20:23.690
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.
20:23.690 --> 20:26.133
And I think that you are working on that.
20:26.533 --> 20:46.204
Now, you're not working on that within the bounds of sort of 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.
20:46.204 --> 20:48.946
So, Brian, I'm wondering if you could tell us
20:49.746 --> 20:56.171
Maybe first, I would love to get your reaction to what Justin just said and anything that that maybe triggers in your mind.
20:56.171 --> 21:03.837
And then we'll talk about what you're building out at Risk Zero and this platform that you're calling Zeth right now.
21:03.837 --> 21:06.959
But first of all, any reaction to what Justin just said?
21:06.959 --> 21:14.105
Yeah, I mean, it's pretty clear that with all of the advances that we're making in cryptography, as you said, that
21:14.886 --> 21:25.174
you know, the capabilities of a theory and we're just going to continue to compound and compound and probably much faster than we would have seen or thought of even possible.
21:25.174 --> 21:32.219
So I think the future is very bright, given all of the, you know, advances that are being made across the entire space.
21:32.219 --> 21:35.381
And this is just a, you know, one key in a very large puzzle.
21:35.381 --> 21:36.222
So it's very exciting.
21:36.733 --> 21:50.305
Okay, well, so tell us what you're building then on out on the frontier, which again, is 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.
21:50.305 --> 21:53.869
So you, your company is called risk zero.
21:53.869 --> 22:00.575
And you've got, I believe, this this platform called Zeth, and we describe this as a type one zk EVM.
22:00.575 --> 22:01.756
And this goes kind of
22:02.376 --> 22:04.517
beyond what I even know I'm describing.
22:04.517 --> 22:09.318
So what is Zeth and what is a Type 1 ZK EVM?
22:09.318 --> 22:18.060
Yeah, so Zeth is an EVM implementation that's actually based on REST, which is, like Geth, an implementation of the EVM.
22:18.060 --> 22:20.601
However, it's one that's built using Rust.
22:22.038 --> 22:39.467
And a type one ZAEVM is simply one that can actually process the full nature of Ethereum in 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
22:40.708 --> 22:56.065
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 succinctly verifies that the EVM computation was run correctly.
22:56.932 --> 23:15.236
So the other ZK EVMs that we've talked about many times before, the ones that Polygon are building, the ones that MatterLab is building, the one that Scroll is building, you differentiate that and you'd say, that's not a type one EVM because it's a little bit different in some way.
23:15.236 --> 23:15.917
Is that correct?
23:15.917 --> 23:17.217
And how is it different exactly?
23:18.625 --> 23:19.727
They're all different in different ways.
23:19.727 --> 23:27.622
And they, you know, they often change exactly how things get marginalized, how states stored and they generally tend to implement all the outputs.
23:27.622 --> 23:29.686
I don't know, Justin, do you want to expound upon that?
23:32.390 --> 23:40.156
Generally speaking, what will happen is that they will want a Solidity developer and Solidity code to be reused.
23:40.156 --> 23:42.697
That's one of the main goals.
23:42.697 --> 23:54.846
They're going to reimplement every single opcode, but under the hood, under the bonnet, they're going to be taking some shortcuts to optimize things.
23:54.846 --> 23:58.829
One of the prime shortcuts is to change the way that the...
23:59.509 --> 24:01.451
the storage is Merkleized.
24:01.451 --> 24:07.476
So today we have what's called a Patricia Merkle tree, which is using this Ketchak hash function.
24:07.476 --> 24:14.802
There's all sorts of technical terms just to say that the way that we handle storage is very much non-SNOC friendly.
24:14.802 --> 24:23.288
And so what these teams have done is they've just taken a completely different approach to authenticate and Merkleize the state.
24:23.288 --> 24:28.272
Another possible difference is changing the gas schedule.
24:29.193 --> 24:35.315
because the EVM gas was designed from the perspective of CPUs.
24:35.315 --> 24:46.397
If a certain operation takes 100 nanoseconds and another one takes 10 nanoseconds, then the first one should be roughly 10 times more expensive from a gas perspective.
24:46.397 --> 24:51.499
But the gas schedules don't translate very well to Snark land.
24:51.499 --> 24:55.940
So you could have a very, very cheap instruction on the CPU, for example,
24:56.840 --> 25:02.607
you know, doing a hash like Ketchak, that's extremely fast on the CPU.
25:02.607 --> 25:06.132
But if you were to do it in Snark land, it's extremely expensive.
25:06.132 --> 25:15.303
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
25:16.832 --> 25:23.436
mount a denial of service attack on a specific rollup, they've adjusted the gas schedule.
25:23.436 --> 25:29.560
So it's not exactly compatible with the EVM that we have today on mainnet at layer one.
25:29.560 --> 25:31.962
So because of those changes, because of those
25:33.042 --> 25:36.965
you know, I guess optimizations or differences.
25:36.965 --> 25:44.011
These type two ZK EVMs are not candidates to become an enshrined rollup, at least in their existing form.
25:44.011 --> 25:44.891
Is that correct?
25:44.891 --> 25:51.676
And this, a type one ZK EVM is closer to a candidate to becoming an enshrined rollup.
25:51.676 --> 25:53.778
Am I making that connection correctly?
25:56.439 --> 25:58.441
Yeah, that's exactly right.
25:58.441 --> 26:02.043
But what I'll say is that oftentimes, these are journeys.
26:02.043 --> 26:08.668
They start somewhere, and then they incrementally become more and more compliant with the EVM.
26:08.668 --> 26:11.570
I mean, this even happened with optimistic rollups.
26:11.570 --> 26:21.298
At first, they had these small modifications relative to the EVM opcodes, and then they said, no, we want it to be exactly equivalent with the EVM opcodes.
26:22.959 --> 26:29.343
And this journey is going to happen for the ZK-EVM rollout implementations, I believe.
26:29.343 --> 26:37.589
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.
26:37.589 --> 26:41.993
But the trade-off here is that it's much, much harder from a technical standpoint.
26:42.693 --> 26:51.057
But what's happening, and it's kind of magical to see in front of our eyes, is that the technology is improving at an extremely fast pace.
26:51.057 --> 26:56.399
We kind of have an equivalent of Moore's law for snark improvements.
26:56.399 --> 27:02.741
And I don't know what it is, but it's something like, I don't know, improving by 4x every single year.
27:02.741 --> 27:03.882
So give it a few more years.
27:03.882 --> 27:05.042
Is this Drake's Law?
27:05.042 --> 27:06.883
Can we make it Drake's Law here, please?
27:06.883 --> 27:09.224
I want to laugh.
27:09.224 --> 27:11.285
It's a Moore's law with another Moore's law on top of it.
27:13.539 --> 27:13.863
Right.
27:15.508 --> 27:16.568
Um, yeah.
27:16.568 --> 27:16.908
Okay.
27:16.908 --> 27:17.429
Okay.
27:17.429 --> 27:22.270
Um, so this is, uh, about the limit of my technical proficiency here.
27:22.270 --> 27:30.312
And I'm, I'm wondering, uh, Justin, if you could sort of, like, what questions do you have for, for Brian here actually about how this works.
27:30.312 --> 27:33.752
So we're talking about this type one ZK EVM.
27:33.752 --> 27:40.874
We've, 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, on bridges.
27:40.874 --> 27:43.655
Uh, we talked about enshrined rollups, multi provers.
27:44.335 --> 27:50.378
You know, there's the performance conversation, security, licensing type of conversation.
27:50.378 --> 27:58.302
Why don't you take some of the technical details here and maybe I'll come back and ask the dumb questions as they arise in my mind.
27:58.302 --> 27:58.702
Perfect.
27:58.702 --> 28:00.343
Sounds great.
28:00.343 --> 28:09.968
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.
28:10.308 --> 28:14.953
for a relatively long amount of time, maybe a year or two.
28:14.953 --> 28:22.722
And a few days ago, when you made the announcement, Vitalik was messaging me and was like, who are these risk zero people?
28:22.722 --> 28:25.785
Are they doing good work?
28:25.785 --> 28:26.606
Can they be trusted?
28:26.606 --> 28:27.947
Et cetera, et cetera.
28:27.947 --> 28:28.067
And
28:29.249 --> 28:34.172
If Vitalik is not aware of you guys, maybe the listener is also not aware of you guys.
28:34.172 --> 28:41.378
And so, I guess my question is, what prompted you in the first place to build a ZKVM?
28:41.378 --> 28:49.745
Normally, when you build a ZKVM, it's because you're aiming towards a roll-up, but my understanding is that you're not aiming towards a roll-up.
28:49.745 --> 28:50.866
So what is the background here?
28:52.215 --> 29:01.905
Yeah, I mean, so RISC-Zero got started with this idea of building out general purpose ZK capabilities, sort of the ability to actually prove any computation.
29:01.905 --> 29:12.075
So not just the EVM, like an existing game, you could prove Doom, you could prove Linux, people are actually using this to prove execution of Linux.
29:12.075 --> 29:12.115
So,
29:14.243 --> 29:34.559
ECC, not this past one, but two years ago, or two ECCs ago, I was talking about the fact that, you know, in my mind, the best way to build a ZK EVM was to actually just take the code that people have already written 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.
29:34.559 --> 29:42.606
So basically reduces the amount of capital required to actually run an EVM and produces a world where the proofs that you're creating
29:43.006 --> 29:46.389
are very much in line with the clients that created them.
29:46.389 --> 29:52.414
So, yeah, I would say we've been thinking about doing this for a long time.
29:52.414 --> 29:59.420
It's just getting the sort of technical requirement, getting the technical capabilities over the line to the point where we could do this.
29:59.420 --> 30:02.222
We really just got there like two months ago.
30:02.222 --> 30:06.606
So then as soon as that happened, we're like, OK, now we have to actually try to make the EVM real.
30:07.472 --> 30:20.066
The type one medium, and it turns out like it was, you know, fairly straightforward once we got the, you know, extra year of engineering done to get to get the sort of continuations and long running proof feature to work.
30:20.488 --> 30:29.213
And Brian, this is maybe the flash of lightning that Justin is referring to, because Resero just came across my radar last week as well.
30:29.213 --> 30:31.294
And David was like, hey, I'm going to be out.
30:31.294 --> 30:32.495
He's that burning man, actually.
30:32.495 --> 30:34.756
So I'm going to be out next week.
30:34.756 --> 30:39.139
Ryan, you should go talk to these people and see what's going on.
30:39.139 --> 30:44.902
And this is the tweet, introducing Zeth, a fully open source Type 0 ZK EVM,
30:45.402 --> 30:59.946
built on the RISC-Zero, ZK, EVM, and Bonsai is that there's a performant, upgradable, and scalable way for developers to ZK-proof any Ethereum block, ushering in the next generation of ZK and EVM.
30:59.946 --> 31:05.248
So pretty big tweet thread to splash in the world.
31:05.248 --> 31:07.669
And yeah, that's part of the context for this conversation.
31:07.669 --> 31:11.410
All plus one Justin is like, we want to find out what you guys are doing.
31:11.410 --> 31:12.150
What's going on here?
31:12.805 --> 31:15.186
Yeah, so the type 0 thing is definitely a joke.
31:15.186 --> 31:21.449
I might have brought some people the wrong way, but the idea of like it's a type 1 EVM, but you didn't have to do.
31:21.449 --> 31:29.012
You did zero work to make it work, because we just utilized all the hard work of of everyone else in the space to create this platform.
31:29.012 --> 31:30.153
It's not entirely true.
31:30.153 --> 31:38.036
We had to change some of the ways like the Merkle Patricia tree works to make sure it's like more snark friendly or stark friendly.
31:38.036 --> 31:41.338
And then we also had to modify a bit of the database back end.
31:41.887 --> 31:48.855
So definitely required some brilliant work by some amazing engineers, but like a month and three people to get this over the line.
31:48.855 --> 31:53.641
Now, you know, there's tons of room to increase the performance of the system and all kinds of things like that.
31:53.641 --> 32:01.170
But we really have gotten to this kind of base level of now we can actually ZK proof Ethereum exactly as is.
32:02.927 --> 32:15.374
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.
32:15.374 --> 32:22.578
And you have this really interesting approach, which I guess we should dig into, very interesting technical approach.
32:23.298 --> 32:33.883
But in our pre-call yesterday, one of the things you mentioned was that there was some sort of partnership maybe with another rolled up projects, maybe the Optimism project.
32:33.883 --> 32:46.570
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.
32:47.812 --> 32:57.757
Yeah, I mean, we've been talking to OP like on and off for a while because this idea that you can take ZK and sort of create fraud proofs.
32:57.757 --> 33:03.300
As soon as you can ZK prove something, you can also ZK prove that something is different than what other people said it is.
33:03.300 --> 33:10.003
So you have this kind of ability to automatically create a fraud proof if you have a ZK provable system.
33:10.003 --> 33:12.164
So we've been chatting with Optimism for a while.
33:12.164 --> 33:13.605
They eventually decided they were going to
33:14.665 --> 33:22.087
send out this like RFP or mission for people to actually zkify the OP stack.
33:22.087 --> 33:25.207
And us and Mina and a couple other teams all applied.
33:25.207 --> 33:30.449
And our solution was very much based on the preliminary work we'd done on Zeph.
33:30.449 --> 33:40.851
We realized rather than, you know, taking this very complex fraud-proofing system, which is an amazing work of engineering, but kind of sidestepped it and said, let's just take the OP ref, like
33:41.267 --> 34:00.851
in development libraries and just create a way to CK prove those, which effectively provides a broad proof mechanism, because now you can prove, well, once it's done, which will be, you know, near future, you'll be able to prove that an optimism block is or is not a different from what the chain actually agreed on.
34:00.851 --> 34:06.692
So we're going to actually see, I think, in the near future through this partnership with optimism, the ability to get, you know,
34:07.511 --> 34:11.337
liquidity much faster than seven days, remove your assets around and access your money.
34:11.337 --> 34:22.695
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 fractally hyperscale, however you want to say that.
34:23.013 --> 34:23.393
Right.
34:23.393 --> 34:35.181
So I think what is partially going on is that Optimism as a project, which is an optimistic roll-up, is thinking down the line of upgrading to a ZK roll-up.
34:35.181 --> 34:44.348
And they submitted this request for proposal where they're saying, okay, anyone in the world, if you can help us snarkify Optimism, we're going to give you money.
34:45.088 --> 34:53.415
Now, I had a look at the grant, the request for proposal, and it was 250,000 OP tokens, which at current price is about $375,000.
34:53.415 --> 34:55.777
Now, the reason I mentioned this is because
35:02.682 --> 35:19.685
If you had asked us, you know, two years ago to come up with a prototype, a proof of concept for a 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.
35:19.685 --> 35:28.487
And for now, for half of a million dollars, you know, we have this new team coming forward and providing, you know, technology.
35:28.487 --> 35:28.867
And I think
35:30.047 --> 35:35.590
one of the key tools used here is abstraction, right?
35:35.590 --> 35:38.492
There's this kind of this massive shortcut that was taken.
35:38.492 --> 35:43.014
And so there's kind of various pieces of the puzzle.
35:43.014 --> 35:47.677
And the way that I think about it is that there's three steps.
35:47.677 --> 35:53.320
You start with an existing Ephem client, in this case, Ref.
35:53.320 --> 35:55.201
And then there's this new intermediate step
35:56.027 --> 36:01.591
uh, which is RISC-V, which I guess it would be good for you to describe what exactly is RISC-V.
36:01.591 --> 36:07.475
And then there's kind of this final step towards getting a, a, a snark.
36:07.475 --> 36:15.760
And it, it, it seems like actually that there isn't much work going from the client to RISC-V, almost no work.
36:15.760 --> 36:19.303
And then same thing for going from RISC-V to the snark.
36:19.303 --> 36:23.766
So can you describe these three steps and the work involved in getting one?
36:24.426 --> 36:26.026
And really quick, RISC-V.
36:26.026 --> 36:27.167
What is RISC-V?
36:27.167 --> 36:28.187
We know what RISC-0 is.
36:28.187 --> 36:29.347
It's a company.
36:29.347 --> 36:29.987
Right.
36:29.987 --> 36:31.948
So RISC-0's name comes from RISC-V.
36:31.948 --> 36:38.790
And RISC-V is an open source instruction set architecture for actual microprocessors.
36:38.790 --> 36:48.432
So people familiar with the Apple M2 or ARM or x86 or MIPS, these are actually instruction sets.
36:48.432 --> 36:52.193
So similar to the EVM, they have opcodes that tend to be
36:53.427 --> 36:58.071
There are opcodes that can actually be reified in a hardware in a reasonable manner.
36:58.071 --> 37:01.595
So, x86 has, you know, hundreds thousands of them.
37:01.595 --> 37:13.066
So it's a complex instruction set architecture, but then you've seen the shift towards ARM and MIPS is very old but RISC-V is kind of the spiritual successor to MIPS in a way, it's a very small set.
37:14.780 --> 37:18.241
Has a couple different like dialects, but you can boil it down to about.
37:18.241 --> 37:28.244
I think only 40 something off codes at its core, so so what we've done is created a ZK VM, so it's not an EVM.
37:28.244 --> 37:35.426
It's the same idea except what it does is process these much lower level instructions, so there's not really pre compiles or anything like that.
37:35.426 --> 37:40.768
There are escape patches that you can use, but so there's this core very.
37:42.032 --> 37:47.753
minimal set of computing instructions that RISC-V sort of publishes.
37:47.753 --> 37:56.975
And people can actually take Sci-5, the company that invented it, you can just get a spec from them and you can put RISC-V cores into whatever project you're doing.
37:56.975 --> 38:05.417
So almost every computer that's shipping now does have some number of RISC-V cores somewhere in the sort of bigger chip.
38:05.417 --> 38:08.678
So most chips, anything people think of as a CPU or a
38:09.475 --> 38:13.881
anything like that is really a system and I should probably has 20 different cores in it.
38:13.881 --> 38:24.675
So, anyway, by doing all 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.
38:26.620 --> 38:41.845
The reason that sort of going, so going from a RISC-V to a ZK proving a RISC-V was something we, you know, surprised the ZK world with at least about a year and a half ago when we released this.
38:41.845 --> 38:52.008
I think, you know, at the time Ellie had said that he, Ellie Vincentson from Starkwire thought that, you know, general purpose ZK VM was at least five years out.
38:52.008 --> 38:54.329
So this is another example of ZK kind of just,
38:57.184 --> 38:59.706
happening much faster than people would otherwise expect.
38:59.706 --> 39:06.212
So by focusing on this minimal set of instructions, we're able to create a very performant ZKVM.
39:06.212 --> 39:14.959
And most of the work to translate from anything else into RISC-V has already been done by the RISC-V development community and by the LLVM compiler community.
39:14.959 --> 39:24.947
So we're really just leveraging the network effects of open source software to take, as Justin said, a massive shortcut to get to ZK-proof.
39:26.474 --> 39:32.396
So basically, there's two translation steps or kind of compilation steps that need to happen.
39:32.396 --> 39:43.778
And it turns out that the Rust programming language, by default today, already allows you to compile to various CPUs.
39:43.778 --> 39:49.920
So when you have a Rust program, you can compile it to x86, which is, you know, a lot of Intel machines run on this.
39:50.300 --> 39:56.167
you could compile it to ARM, which is a lot of the new Macs and a lot of phones run on ARM.
39:56.167 --> 40:06.398
But you can also compile it to this more arcane but still popular enough to be supported instruction set, which is called RISC-V.
40:07.539 --> 40:18.905
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 RISC-V.
40:18.905 --> 40:27.069
And then there's this one-time step that needs to be done to go from RISC-V to a SNOC.
40:27.069 --> 40:32.152
And this is the heavy lifting that Brian and his team have done, but it's a one-time thing.
40:32.812 --> 40:40.398
And so now we can kind of take any Rust program that we want and kind of reap the benefits of abstraction.
40:40.398 --> 40:53.308
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?
40:53.308 --> 40:56.870
You have a program that you want to snarkify and you're going to kind of
40:57.991 --> 41:11.645
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.
41:12.546 --> 41:22.436
But 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.
41:22.436 --> 41:26.861
And Rust is an extremely kind of high level and friendly programming language.
41:26.861 --> 41:30.364
And within the blockchain space specifically, it's extremely popular.
41:32.243 --> 41:42.912
And in combination, we're finding all sorts of optimizations, both kind of at the software, the hardware level, to make this palatable.
41:42.912 --> 41:53.261
Maybe we should move to performance, which is that back then, we could have said, yes, you can go ahead and do it, but it will take days to produce a proof for an Ethereum block.
41:53.261 --> 41:57.945
What kind of performance do you guys have and how did you get there?
41:59.053 --> 42:05.879
Yeah, so the performance varies based on which kind of hardware actual hardware target you're running the ZKVM on.
42:05.879 --> 42:13.186
So we support CPUs, we support the M2 GPU and we support NVIDIA GPUs as well.
42:15.897 --> 42:33.797
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 set a subset of us 532 bit instructions that is because it lets us operate in the sort of smaller prime field.
42:34.853 --> 42:38.134
which is much more amenable to being accelerated on GPUs.
42:38.134 --> 42:48.458
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.
42:48.458 --> 42:54.460
You can actually do ZK proofs using like a 16 gigabyte desktop GPU.
42:54.460 --> 43:00.622
So that actually, so we built a proof system that could run in these really small kind of consumer grade cards.
43:01.066 --> 43:05.448
However, then that had some other kind of downsides, like you couldn't run giant programs.
43:05.448 --> 43:10.249
So we built this system called continuations, which is like folding, you've mentioned a bunch.
43:10.249 --> 43:21.793
So it's a way to take a proof and split it up into 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.
43:21.793 --> 43:26.555
So getting to this level of performance, we had to optimize the recursion circuits, because taking
43:28.032 --> 43:34.755
1024 proofs and rolling it down into one proof, you know, takes 10 vertical steps of recursion.
43:34.755 --> 43:44.219
And then beyond that, we have this ability to actually run the proving computation itself, as I mentioned, on a GPU rather than a CPU.
43:44.219 --> 43:53.963
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,
43:54.391 --> 44:00.095
let's do the general purpose thing, let people actually prove something, and then we can focus on the performance where it matters.
44:00.095 --> 44:02.236
So yeah, it's been a combination.
44:03.113 --> 44:15.820
On that performance, so I'm just in kind of like the intros, we're exploring this throughout the possibility that someday we could run an Ethereum, a snarkified Ethereum validator from our smartwatch.
44:15.820 --> 44:21.043
It sounds like there are a lot of performance steps necessary to get there.
44:21.043 --> 44:22.944
And I'm curious, how close are we?
44:22.944 --> 44:28.868
So is what you're saying, Brian, that right now we could run what you've developed, which is this
44:29.888 --> 44:36.272
ZK Type 1 EVM on a home consumer laptop.
44:36.272 --> 44:38.653
It's a pretty beefy laptop.
44:38.653 --> 44:42.495
And then how many steps away are we from getting that to like a smartwatch?
44:43.197 --> 44:51.963
Well, so proving, I don't think you're going to, when you end up in this sort of enshrined roll-up world, you're not going to have the proving be done on the smartwatch.
44:51.963 --> 44:57.006
The proving will be done by these machines off in the cloud, or in this decentralized network.
44:57.006 --> 45:06.112
And then the verification, like, because your SNARK or STARK, like they're really small, the SNARK especially, and, you know, it takes literally fractions of a millisecond.
45:06.112 --> 45:07.893
So the computing power to verify the SNARK is
45:08.428 --> 45:08.848
there.
45:08.848 --> 45:15.534
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 network.
45:15.534 --> 45:18.196
So you can have a very light pipeline.
45:18.196 --> 45:22.739
So then why does performance matter so much?
45:22.739 --> 45:25.902
Oh, performance of the proving system?
45:25.902 --> 45:26.082
Yeah.
45:26.747 --> 45:31.091
I mean, effectively, it gets down to how quickly you can make these sort of EVM blocks, right?
45:31.091 --> 45:37.336
Like, right now, it takes us, if we use 64 of these off-the-shelf machines, it takes about 50 minutes.
45:37.336 --> 45:39.898
And I think there's probably an easy 10x there.
45:39.898 --> 45:43.561
But if you use even more machines, we can get down to 12 minutes.
45:43.561 --> 45:47.705
But realistically, if you want this sort of enshrined roll-up, you need to, what did you say, Justin?
45:47.705 --> 45:48.085
Two seconds.
45:48.225 --> 45:58.232
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.
45:58.232 --> 46:05.336
Basically, the latency, the proof latency, the time it takes to generate the proof should be on the order of one second.
46:05.336 --> 46:07.057
And today, we're not there yet.
46:07.057 --> 46:13.582
We're maybe 100 to 1,000x, so let's say 2.5 orders of magnitude away from getting there.
46:14.362 --> 46:18.026
And so performance matters for two key reasons.
46:18.026 --> 46:26.495
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.
46:27.998 --> 46:32.342
And the other reason is just diminishing the size of the prover.
46:32.342 --> 46:42.510
So nowadays, if you want to be a prover, more likely than not, you're going to rent out a rig of GPUs on AWS.
46:42.510 --> 46:47.134
Brian was talking about 64 GPUs, I believe, on AWS.
46:47.134 --> 46:51.298
And that's not super friendly to a decentralized proving network.
46:52.078 --> 46:53.320
of people at home.
46:53.320 --> 46:59.807
And so what we partially want to do as well is kind of shrink all these 64 GPUs into like a small box.
46:59.807 --> 47:07.395
And the way to get there, in my opinion, I'd be curious what your opinion is, Brian, is to have snark acceleration.
47:07.395 --> 47:14.362
So we went from CPUs to GPUs, and then the endgame is to go from GPUs to ASICs.
47:15.862 --> 47:33.515
Yeah, I mean, I think, 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 approvers, maybe these ASICs are even in people's phones, you're still going to end up splitting, you know, proving an entire each block, probably up over, you know, hundreds or thousands of nodes.
47:33.515 --> 47:38.499
So I think parallelism is critically important, no matter what, but the ability
47:39.550 --> 47:48.880
Now that we've 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.
47:48.880 --> 47:58.030
I was pretty bearish on hardware for the first year of the company's existence because I didn't think that people were going to be able to do better than NVIDIA.
47:58.030 --> 48:00.993
It's really hard to do better than NVIDIA with their sort of GPU performance.
48:01.593 --> 48:20.803
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, sorry, gigahertz level ZK proving through ASICs in the, you know, five year timeframe, let's say, three to five years.
48:23.692 --> 48:35.638
Okay, so if I were to try and summarize 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.
48:35.638 --> 48:38.019
It comes from three different types of tricks.
48:38.019 --> 48:48.044
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.
48:48.044 --> 48:50.225
You've leveraged the GPUs,
48:51.245 --> 49:00.769
which, as you said, NVIDIA does a great job with their GPUs, which are used for AI, but can also be used for SNOCs, which are also extremely compute-intensive.
49:00.769 --> 49:19.716
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 reassemble all the pieces of the puzzle, and all of that can be parallelized and distributed.
49:19.996 --> 49:20.436
Well said.
49:20.436 --> 49:21.777
Are you a Metamask user?
49:21.777 --> 49:23.958
Well, you're listening to Bankless, so of course you are.
49:23.958 --> 49:26.960
The wallet you know and love just got a whole lot better.
49:26.960 --> 49:31.482
Metamask Portfolio is the ultimate one-stop shop for all of your crypto needs.
49:31.482 --> 49:37.085
It gives you a holistic view of your crypto portfolio across multiple chains and multiple addresses all at once.
49:37.085 --> 49:43.488
You can easily view and manage all your coins, tokens, and NFTs in one convenient place just by connecting your wallet.
49:43.568 --> 49:46.911
Metamask Portfolio goes beyond just viewing your portfolio, though.
49:46.911 --> 49:51.315
Inside the portfolio, you can do all the incredible money verbs that make DeFi so powerful.
49:51.315 --> 49:54.918
You can buy, swap, bridge, and stake your crypto assets with ease.
49:54.918 --> 49:59.002
It's like having a powerful battle station for all your DeFi moves right at your fingertips.
49:59.002 --> 50:03.306
So if you're looking to do more in Web3 your way, Metamask Portfolio is the answer.
50:03.306 --> 50:07.109
I already know that you have a Metamask wallet, so go check out your Metamask Portfolio.
50:07.109 --> 50:10.092
Learn more at metamask.io slash portfolio.
50:11.230 --> 50:13.272
Introducing ETHX from Stator.
50:13.272 --> 50:17.836
ETHX is a liquid staking token designed to maximize rewards all while securing Ethereum.
50:17.836 --> 50:25.764
With Stator, you can run an Ethereum node with just four ETH, which is 85% lower capital and 35% higher returns versus just solo staking.
50:25.764 --> 50:32.690
Stator has a multi-pool architecture with both permissionless and permission node operators to enable decentralization and scalability.
50:32.890 --> 50:41.117
Stater has extensive experience in building liquid staking solutions on six proof-of-stake blockchains and is trusted by over 70,000 stakers.
50:41.117 --> 50:47.262
Stater has partnered with over 40 leading protocols on these chains to bring DeFi utility to their liquid staking tokens.
50:47.262 --> 50:53.807
Stater is actively building integrations and partnerships across Ethereum to bring the same great DeFi utility to the ETHX token.
50:53.847 --> 51:01.830
While smart contract bugs are always a risk in DeFi, the ETHX smart contract has received three independent audits and has a million dollar bug bounty with ImmuneFi.
51:01.830 --> 51:06.552
Go to statorlabs.com slash eth slash stake to access the Stator Staking Protocol today.
51:06.552 --> 51:13.175
You know Uniswap, it's the world's largest decentralized exchange with over $1.4 trillion in trading volume.
51:13.175 --> 51:15.596
You know this because we talk about it endlessly on Bankless.
51:15.596 --> 51:18.537
It's Uniswap, but Uniswap is becoming so much more.
51:18.537 --> 51:21.098
Uniswap Labs just released the Uniswap Mobile Wallet,
51:21.318 --> 51:24.599
for iOS, the newest, easiest way to trade tokens on the go.
51:24.599 --> 51:36.184
With a 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 mainnet, polygon, arbitrum, and optimism.
51:36.364 --> 51:47.973
On the Uniswap Mobile Wallet, you can store and display your beautiful NFTs, 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.
51:47.973 --> 51:51.115
So you can now go directly to DeFi with the Uniswap Mobile Wallet.
51:51.115 --> 51:54.618
Safe, simple custody from the most trusted team in DeFi.
51:54.618 --> 51:56.579
Download the Uniswap Wallet today on iOS.
51:56.579 --> 51:57.480
There is a link in the show notes.
51:57.785 --> 52:07.416
Now, I guess the next big topic in my mind as an Ethereum researcher and thinking of Type 1 ZKE AVMs is security, right?
52:07.416 --> 52:07.796
We have
52:08.764 --> 52:12.366
Traditionally, a lot of complexity going on here.
52:12.366 --> 52:15.087
And the likelihood for bugs is very, very high.
52:15.087 --> 52:26.132
And I have this saying, which is maybe, I guess, a little arrogant, but I believe that every single ZKVM has multiple critical vulnerabilities today.
52:26.132 --> 52:34.476
And so we need to be prepared as a community to either have mitigations to these bugs, and there's a lot of very good ideas,
52:35.536 --> 52:41.018
And we also, unfortunately, need to be prepared to rollups getting hacked.
52:41.018 --> 52:56.745
So just like we've had a bunch of fairly large rollup hacks, sorry, 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 rollup space.
52:56.745 --> 53:00.526
And so I'm curious, how do you think of security?
53:00.526 --> 53:04.288
And how do you think of removing every single bug from the system?
53:05.127 --> 53:07.790
Yeah, so obviously a huge topic.
53:07.790 --> 53:09.572
So me and my co-founders actually know each other.
53:09.572 --> 53:13.175
We met 23 years ago in the Seattle InfoSec scene.
53:13.175 --> 53:15.918
So we were all like hackers back in the day.
53:15.918 --> 53:20.763
So we have a pretty deep set of sort of experience and knowledge in this space.
53:20.763 --> 53:23.266
And that's part of the reason we chose RISC-V also.
53:23.266 --> 53:27.150
It actually has a full formal specification for it.
53:27.150 --> 53:27.991
You actually can
53:28.885 --> 53:33.427
prove that certain systems, formally prove that certain systems implement RISC-V.
53:33.427 --> 53:38.630
We haven't gotten to that level of sort of formal verification with what we're doing yet.
53:38.630 --> 53:49.295
You can imagine getting to the place where you have very strong guarantees that the ZK system itself is proving RISC-V and only RISC-V and that
53:51.992 --> 54:00.385
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.
54:00.385 --> 54:04.872
So there's a lot of work on the mathematical side to sort of prove that the crypto system itself is
54:05.558 --> 54:08.281
like the proving system is actually doing what it's supposed to.
54:08.281 --> 54:26.018
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 RISC-V instruction set 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.
54:26.438 --> 54:36.082
it still doesn't increase the audit surface of the ZK part to the same degree that doing ZK EVM from scratch would.
54:36.082 --> 54:44.906
Now, you're also, I think as you pointed out in the pre-call, by doing this, you are potentially onboarding a few more security considerations.
54:44.906 --> 54:48.167
For instance, you're trusting the Rust compiler and you're trusting LLVM.
54:48.167 --> 54:51.329
Now, these things, and there are often bugs in LLVM.
54:51.329 --> 54:52.089
I think we just found
54:53.048 --> 54:54.769
one the other day.
54:54.769 --> 54:58.711
So, you know, compilers, especially for new architectures, aren't perfect.
54:58.711 --> 55:02.953
But this is one of the reasons, again, why we chose an existing architecture.
55:02.953 --> 55:08.135
I don't think ARM or something older or more mature would have really fit in a ZK circuit.
55:08.135 --> 55:15.278
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.
55:15.719 --> 55:16.179
Gotcha.
55:16.179 --> 55:28.726
So if I were to summarize this kind of this final step where we go from RISC-V to a SNARK, which is actually fairly digestible because RISC-V is relatively simple.
55:28.726 --> 55:31.327
Actually, this reminds me of Cairo from Stockware.
55:31.327 --> 55:37.530
They have an even more kind of reduced instruction set, which is super simple.
55:37.530 --> 55:42.813
And what they've been able to do is apply some formal verification tools to prove that, you know,
55:44.146 --> 55:46.008
things are working properly there.
55:46.008 --> 55:55.918
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.
55:55.918 --> 56:07.669
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 RISC-V.
56:08.810 --> 56:14.595
And it's possible that there's bugs, generally speaking, in the Rust compiler.
56:14.595 --> 56:24.724
But it's also possible that there's bugs specific to compiling to RISC-V, because RISC-V is one of the more niche instruction sets that you can compile to.
56:24.724 --> 56:33.191
But what might happen is that we're going to start building these rollups, which are securing billions and billions of dollars, and then Lindy starts to kick in.
56:34.132 --> 56:37.334
And we might have bug bounty programs.
56:37.334 --> 56:44.959
And it's kind of interesting where, in a way, the blockchain space might make a huge contribution to compiler security.
56:44.959 --> 56:45.499
Absolutely.
56:45.499 --> 56:47.100
Because there will be way more eyes.
56:47.100 --> 56:53.505
We recently had this bug right in the Viper compiler, and that caused a bunch of bugs.
56:54.785 --> 57:13.392
And it would be great if we could apply similar tools like formal verification to compilers like Rust compilers, 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.
57:13.392 --> 57:13.652
Yeah.
57:13.652 --> 57:20.975
I mean, people have done this for C, and if you're going to do formal verification for C, then Rust is probably also within
57:21.770 --> 57:23.631
the bounds of what's possible.
57:23.631 --> 57:26.732
But these efforts take decades, or a really long time.
57:26.732 --> 57:30.033
But blockchain accelerates everything, to an obscene degree.
57:30.033 --> 57:36.995
ZK would still be a niche academic pursuit, I think, if it weren't for blockchain needing it so badly.
57:36.995 --> 57:38.736
Okay, great.
57:38.736 --> 57:44.278
So I guess the final kind of semi-technical topic that I have is around licensing.
57:45.758 --> 57:57.644
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.
57:57.644 --> 58:06.369
And I guess the kind of favorite types of licenses that we have might be Apache 2.0 and the MIT license.
58:06.369 --> 58:10.631
Can you discuss what have you open sourced and under which licenses?
58:11.303 --> 58:21.507
Yeah, so the sort of core is RISC-0 ZKVM, so the RISC-V proving engine, that's licensed under the Apache 2 license right now, always has been.
58:21.507 --> 58:25.668
And then ZESS itself will probably be Apache 2 slash MIT licensed.
58:25.668 --> 58:32.870
We might also end up dual licensing everything, because that's kind of the standard in the Rust community.
58:32.870 --> 58:34.911
And OP is a fan of MIT.
58:34.911 --> 58:39.913
So that's for the system that produces
58:40.892 --> 58:45.634
it takes the EVM program and chunks it up into a bunch of little proofs and then proves all of those.
58:45.634 --> 58:52.517
The parts we haven't yet open sourced or released is the part that actually takes all those proofs and recurses them down into a single proof.
58:52.517 --> 58:56.278
And then also this thing that converts the Stark that we use into a Stark.
58:56.278 --> 58:59.480
So there are two kind of aspects of this that we haven't launched.
58:59.480 --> 59:03.601
And effectively, we're waiting for these things to get through security audits.
59:03.601 --> 59:03.821
It's a
59:06.184 --> 59:11.586
With the current system as is, you can't really, the proof is much too large to put on chain.
59:11.586 --> 59:16.107
So it's kind of hard to get wrecked because you can't actually use stuff on chain as readily.
59:16.107 --> 59:22.689
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.
59:22.689 --> 59:30.071
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
59:31.718 --> 59:33.999
it wrecked soon because of the ZK system.
59:33.999 --> 59:35.019
Okay, understood.
59:35.019 --> 59:48.162
So you've open sourced like several key components on the 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.
59:48.162 --> 01:00:00.905
And like part of the prover is already open source, but maybe some of the final things involving the recursion and kind of the wrapping it into a tiny, tiny proof so that it can be consumed on chain, that's not yet open source.
01:00:03.015 --> 01:00:09.419
Brian, Risk Zero seems to have come out of nowhere.
01:00:09.419 --> 01:00:16.204
It's super incredible how fast all this is coming to bear here.
01:00:16.204 --> 01:00:26.771
Open source working, it sounds like first to snarkify our favorite L2s out there, like working with Optimism and others.
01:00:26.771 --> 01:00:27.191
I imagine
01:00:27.852 --> 01:00:32.317
That's going to be a bulk of the work at first.
01:00:32.317 --> 01:00:34.801
What are you guys planning to do here?
01:00:34.801 --> 01:00:38.265
What's the business model for risk zero?
01:00:38.265 --> 01:00:44.934
It almost sounds like what you're producing is a public good, and here, Justin and I and the rest of the Bankless community are kind of cheering you on.
01:00:45.574 --> 01:00:47.596
But I'm sure you have investors.
01:00:47.596 --> 01:00:59.704
I'm sure you have VCs here that have 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 yet, it sounds like.
01:00:59.704 --> 01:01:01.705
So, or maybe you will.
01:01:01.705 --> 01:01:05.388
So yeah, tell us what Risk Zeroes is put on earth to do.
01:01:05.388 --> 01:01:07.989
What are you planning to do in this space?
01:01:07.989 --> 01:01:12.592
Yeah, in this space, we're really focused on this Bonsai ZK application development platform.
01:01:12.592 --> 01:01:14.274
So there's something we've been working on for a while.
01:01:15.548 --> 01:01:18.410
because you can use zk for all kinds of things.
01:01:18.410 --> 01:01:31.177
I don't know how if you've talked to like many of the zk coprocessing teams, but you can use bonsai effectively the zk coprocessor, which lets you run a bunch of complex logic off chain and then just attest to it on chain.
01:01:31.177 --> 01:01:31.317
So we
01:01:32.308 --> 01:01:45.631
like Denver, I talked about a like a one club effectively running an order book on Ethereum directly at Uniswap, you can achieve roughly Uniswap level pricing by doing all the order book matching off chain.
01:01:45.631 --> 01:01:58.274
So you have your orders, the orders get placed on chain, and then bonds, I sort of just reads those orders does all the matching in zk just on one machine, some ran any random corner of the internet or AWS, wherever you want it to be.
01:01:58.274 --> 01:01:58.494
And then
01:01:59.338 --> 01:02:03.462
says, okay, here's proof that these are the orders that got matched at this price.
01:02:03.462 --> 01:02:05.204
So, so there's the Bonsai.
01:02:05.204 --> 01:02:11.350
Bonsai is kind of a platform for ZK snarkifying apps, maybe, let's call it.
01:02:11.350 --> 01:02:13.932
Apps and rollups, anything really.
01:02:13.932 --> 01:02:23.141
So we expect, right now it's a centralized SaaS offering and we think there's long-term value in sort of providing an enterprise sort of open core
01:02:24.177 --> 01:02:28.639
model there, but we will definitely be building a decentralized network around that as well.
01:02:28.639 --> 01:02:31.000
Exactly what that looks like, who knows?
01:02:31.000 --> 01:02:38.863
It's going to be very focused on the sort of core accounting for proving tasks.
01:02:38.863 --> 01:02:45.525
So, kind of like a proof marketplace, but we expect that it will add interesting features for application developers over time.
01:02:45.525 --> 01:02:49.147
There's this ability with continuations to do sort of zk docker.
01:02:49.147 --> 01:02:49.327
You can
01:02:49.884 --> 01:02:54.988
prove something up to a certain point, you can suspend the thing, and then you can just keep going on later.
01:02:54.988 --> 01:03:04.415
So you can kind of imagine having a ready-to-go EVM image, where people can just resume it, and they have full access to the Ethereum state.
01:03:04.415 --> 01:03:14.002
Is this like a sort of an AWS for ZK proofs kind of thing, or it's just like a marketplace here, and you're looking to try to make it as decentralized as possible?
01:03:14.002 --> 01:03:15.163
That could be a future here?
01:03:15.163 --> 01:03:16.244
Definitely.
01:03:16.244 --> 01:03:18.426
I mean, this is like when we got into
01:03:19.854 --> 01:03:32.982
Jeremy, our chief 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
01:03:34.035 --> 01:03:41.223
let people who are building infrastructure and applications not need to rely on, you know, Facebook, Amazon, Microsoft, Google for everything.
01:03:41.223 --> 01:03:53.355
So this 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 what this technology is capable of.
01:03:53.355 --> 01:03:56.378
So I think Bonsai is going to be a platform that helps people do that.
01:03:57.306 --> 01:04:00.108
Brian, what do you think happens next in the roadmap?
01:04:00.108 --> 01:04:05.771
All of this seems to be happening faster than we all thought it would, which is so incredibly exciting.
01:04:05.771 --> 01:04:12.835
The level of investment in the space and the level of talent and brains now being focused on crypto is just absolutely astounding.
01:04:12.835 --> 01:04:22.280
We almost ended the episode with one of the last parts, which I think is, of course, the public good that is Ethereum mainnet.
01:04:23.240 --> 01:04:29.743
that will upgrade to a fully snarkified enshrined ZK EVM probably last.
01:04:29.743 --> 01:04:35.726
We're going to want this fully proved out in all sorts of ways across crypto before we get to that stage.
01:04:35.726 --> 01:04:43.990
So I'm wondering, what do you think will happen in the interim over the next six months, over the next one to two years?
01:04:43.990 --> 01:04:48.932
How do you think the tech that you're building will start to impact the crypto landscape?
01:04:48.932 --> 01:04:49.473
Will we just see
01:04:50.173 --> 01:04:57.798
you know, ZK snark snarkified layer two, should we expect to see this technology applied mainly in rollups?
01:04:57.798 --> 01:05:01.121
Are there apps that you see this being applied?
01:05:01.121 --> 01:05:03.182
Or will it take a few years?
01:05:03.182 --> 01:05:04.263
Yeah.
01:05:04.263 --> 01:05:04.803
All of the above.
01:05:04.803 --> 01:05:13.049
We're definitely working with, you know, L2s, L3s, rollout frameworks, however you want to think about all of that space.
01:05:13.049 --> 01:05:18.072
And also, you know, we're working with people on DeFi projects, and eventually gaming is going to be a big part of this.
01:05:18.072 --> 01:05:18.653
The way I see this
01:05:19.419 --> 01:05:25.984
playing out is, you know, just like friend.tech kind of surprised everybody with how much better the crypto onboarding experience has become.
01:05:25.984 --> 01:05:28.426
And sure, there's still a lot of room to go.
01:05:28.426 --> 01:05:32.509
I think the, the head like that,
01:05:33.404 --> 01:05:45.809
headway that people have 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.
01:05:45.809 --> 01:05:55.933
So I think we'll see the cave playing 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.
01:05:55.933 --> 01:05:59.935
So the sort of zk coprocessing architecture is going to be a huge unlock for applications.
01:05:59.935 --> 01:06:02.556
Yeah, for Web3 applications.
01:06:03.586 --> 01:06:04.667
This has been great.
01:06:04.667 --> 01:06:10.990
Justin, do you have any other questions for Brian, or should we start to close this out here?
01:06:10.990 --> 01:06:17.573
I think I have one final question, which is around your alignment with Ethereum.
01:06:17.573 --> 01:06:18.734
I think we had a
01:06:20.208 --> 01:06:26.490
you know, during the prequel, it sounded like as an individual as a as a person, you were in this space for quite a long time.
01:06:26.490 --> 01:06:29.670
And you know, you have a certain set of beliefs.
01:06:29.670 --> 01:06:37.792
And I'm curious what those are, but also how this translates into the culture of the company.
01:06:37.792 --> 01:06:44.674
Yeah, I mean, our sort of core three core values are like integrity, transparency and agency.
01:06:44.674 --> 01:06:49.695
And I think, you know, if those aren't like a theorem aligned, I'm not really sure what that
01:06:50.044 --> 01:06:51.124
sort of even means.
01:06:51.124 --> 01:07:02.549
So coming out of the hacker culture that, you know, the founders came from, it just seems like a very natural sort of fit to the to the sort of ethos of Ethereum.
01:07:02.549 --> 01:07:14.134
So I think value wise, yeah, we're really the vision of the sort of hyper structure world of the future is very much something we all resonate, like very deeply resonates with all of us.
01:07:14.134 --> 01:07:16.175
Brian, what first brought you down the crypto rabbit hole?
01:07:19.134 --> 01:07:21.276
You know, buying supplies for Burning Man.
01:07:21.276 --> 01:07:25.680
That's funny as my co-host is literally at Burning Man right now.
01:07:25.680 --> 01:07:30.204
Fantastic.
01:07:30.204 --> 01:07:34.428
No, but it's been a crazy journey and so it's really fun to get more and more into the space.
01:07:35.364 --> 01:07:37.205
Yeah, well, very good.
01:07:37.205 --> 01:07:43.550
And maybe my last question is kind of the high level to Justin.
01:07:43.550 --> 01:07:54.637
So this idea of hyperscaling Ethereum using kind of like fractal crypto proofs, ZK proofs on top of ZK proofs.
01:07:54.637 --> 01:07:58.320
I mean, has this always been part of the plan or is this just happenstance?
01:07:59.120 --> 01:08:08.028
Yeah, I guess when you think of the term hyperscaling, how do you envision Ethereum looking five years from now?
01:08:08.028 --> 01:08:10.810
Is all of this stuff just kind of working?
01:08:10.810 --> 01:08:13.252
And what's the total transactions per second?
01:08:13.252 --> 01:08:14.253
I don't know.
01:08:14.253 --> 01:08:17.816
What's the sci-fi Ethereum with this tech applied?
01:08:17.816 --> 01:08:18.977
How does that look, Justin?
01:08:18.977 --> 01:08:19.437
Right.
01:08:19.437 --> 01:08:23.521
So, I mean, if you want to think in terms of end games and fundamentals,
01:08:24.521 --> 01:08:30.285
you go back to these fundamental resources, computation, that's just not going to be a problem of consensus.
01:08:30.285 --> 01:08:39.110
And the way that I think about it is that consensus is this very flexible tool that can solve all sorts of problems.
01:08:39.110 --> 01:08:50.196
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.
01:08:51.496 --> 01:08:59.740
And historically, actually, one of the big breakthroughs for consensus was simple message authentication and signatures.
01:08:59.740 --> 01:09:10.645
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 signed and authenticated.
01:09:10.645 --> 01:09:15.627
And so the model was, what can you do with consensus given signatures?
01:09:15.627 --> 01:09:16.708
And now we kind of have
01:09:18.253 --> 01:09:26.160
this new tool, which is much more powerful from a cryptographic standpoint, which is, what can you do with consensus, with snarks?
01:09:26.160 --> 01:09:32.865
And it turns out that the things that it needs to solve are data availability and finality.
01:09:32.865 --> 01:09:38.911
And it turns out that data availability is something that we can solve with data sampling, as I mentioned.
01:09:40.141 --> 01:09:45.483
And then there's this other thing, finality, which I only discovered recently.
01:09:45.483 --> 01:09:57.706
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.
01:09:57.706 --> 01:10:04.449
And so then you can ask ourselves, okay, what is consensus used for if, you know, cryptography solves all these things?
01:10:04.449 --> 01:10:08.870
Well, it turns out that the last thing that's still not solved is this concept of liveness.
01:10:09.940 --> 01:10:15.965
How do you make sure that the chain just keeps on going even if validators just...
01:10:17.133 --> 01:10:23.615
don't show up, for example, if there's World War III and 90% of the population has gone.
01:10:23.615 --> 01:10:36.659
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.
01:10:36.659 --> 01:10:41.420
It's a very long journey to get the one-shot signatures because we need these quantum computers.
01:10:42.916 --> 01:10:50.161
But in the meantime, we're going to enjoy the spoils of snarks, which are extremely significant.
01:10:50.161 --> 01:10:54.244
Well, it seems like we have entered the snark era for sure.
01:10:54.244 --> 01:10:57.806
And there's going to be a lot of that applied to crypto in the future.
01:10:57.806 --> 01:11:01.709
So Brian, Justin, thank you so much for guiding us on the tour today.
01:11:01.709 --> 01:11:02.830
It's been much appreciated.
01:11:02.830 --> 01:11:04.771
Thank you.
01:11:04.771 --> 01:11:05.051
Thank you.
01:11:06.169 --> 01:11:08.610
Bankless Nation, risks and disclaimers.
01:11:08.610 --> 01:11:11.712
Got to let you know, of course, none of this has been financial advice.
01:11:11.712 --> 01:11:15.293
I don't even think we talked price in this whole episode, so obviously not.
01:11:15.293 --> 01:11:18.295
Crypto is risky, so are compilers, so are new layer twos.
01:11:18.295 --> 01:11:20.896
You could lose what you put in, but we are headed west.
01:11:20.896 --> 01:11:21.896
This is the frontier.
01:11:21.896 --> 01:11:25.238
It's not for everyone, but we're glad you're with us on the bankless journey.
01:11:25.238 --> 01:11:25.698
Thanks a lot.