Building the Ethereum endgame today

Transcript

All good set. So this is will be a talk about um how to build the Ethereum game today. Uh I'm wearing a beautifulance t-shirt which means zero knowledge in French and a lot of this thing will be circled around how to use your knowledge proofs. So I'm Silv. I'm the co-founder um of highly you can follow me on on the bird at sil chv. So the tlddr of this talk is that the blockchain endgame and specifically Ethereum's endgame is good but it could be faster. So how do we achieve that exactly? Um three points to the agenda. First of all a little recap

of what ZK is, how proofs work, etc. etc. What's the exact end game and how we can actually build it right now. First thing to know about proofs, um, I mean, if you've been around blockchain, show of hands quickly for the folks who just came in. Who knows about what what a ZK proof is? Show of hands. Okay. Who has already proved something? All right. All right. Pretty good. Who has built a ZKDSL from scratch? Nice. Um, so the one thing as you know most of you work in the IT industry or software development and as you know everything is late. So it's pretty cool to see when things are actually ahead of schedule and that was the case for ZK. We went

from a piece of technology that was very unusable 10 years ago. Uh it was taking ages to to prove a few hashes to now um real-time proving of EVM blocks is within reach and it is it just keeps on accelerating. The proving systems are getting faster. Um the tools are getting better. overall just really good. So, one big thing of something that happened recently is that proofs are getting actually good. Um, to the point that uh it's now become a meme that new ZKVM comes up every day. So, I had to update my slide just because this thing dropped this morning. Sorry to the ECC uh crowd.

The second thing that has really changed that really really helps feed into the hosk playbook is that there is a lot more digital signatures than before. Um you can now directly from your smartphone generate a knowledge proof of your identity of your nationality and as AI progresses there's going to be more and more of them and that's something that can directly feed into any ZKbased system. So that's really cool. Uh what happens if you have both? That's where we're going. People usually talk about ZK because it's really good for privacy scalability. Uh privacy that was the first use case with Zcash. You could do private cryptocurrency transfers. Really cool. Then we had roll-ups. It helped blockchain scale. But arguably one thing

ZK is actually really really good at when you combine digital signatures with proofs is distribution. It is now possible uh to send cryptocurrencies to someone's passport, first name and last name, to someone's email address and even to their credit card. This was a hackathon project from one of our builders last week um at ZK ZK Berlin. So cool. ZK is great. ZK is really really cool. Uh you can do a whole bunch of things. Now let's see what happens on the blockchain side uh of things. Mostly ZK was first introduced because of ZK EVMS.

Uh, and on the blockchain side of things for ZK, this does not spark joy. Blockchains are still super slow. UX is horrendous. Fragmentation is bad. I have like a couple more slides of these things, but I'm going to spare them. Um, and if you look at what this was all supposed to be, um, the Ethereum game is supposed to be this. First of all, everything should be on a rollup. rollups or specific execution environments, stuff happens, you send a proof somewhere. You use Ethereum for DA. You use proofs everywhere and you make sure that you can verify everything in a decentralized setting. That was the initial dream of the Ethereum game.

And now when you really look at how far we've gone, it's it's sort of feel lackluster um in a sense that so this is like the when the first bean chain was announced at Defcon, you had a whole slew of criticism on Twitter like does it really take 5 years to build all of this? It feels like everyone knows how to do the endgame, but it's actually taking so much time to deliver on it. So can you do it like right now? Can you build everything that we just talked about today without having to wait for anything? Um, this is a an article from Vitalic Vutarian on called the purge.

Uh, and this is like the last bit of the article. Uh, and it's called a more radical approach is oh actually we could just take Ethereum and just keep the beam chain remove everything about the EVM and just verify proofs. And that's basically what we've done at highly. We have built the more radical approach. So basically to build the endgame you just need three things. You need a scalable DA layer. You need native proof verification. And you need very fast consensus.

And that's it. That's all you need. These should not be three separate protocols. You can build all of them in one go. And that's what we've done at highly. So on highly it's very simple. Everything is a proof. We've got proofs everywhere and very very sweaty Steve Balmer memes. We have had to made some trade-offs. So for example, there is no storage. You just store a commitment of the data and you store it somewhere else. This is not our job. There is no execution environment. Whenever you update the state of your application, you just send the new state along with the proof and you're done. Execution happens elsewhere. And we go so far as to actually not even manage the account

states directly on the chain. So this is very opinionated architecture but actually is very desirable for many reasons. Um basically you must not dream to a little bit to dream a little bigger. Um, what this gives you is the ability for every single application on the network to operate as a based zk rollup. Sorry about this. It was supposed to be an animation but it got it got cropped. Um, you can use any programming language as long as you can prove it. So you can use solidity if you want because you can prove blocks. You can just use Rust. You can vip code an application in Rust use a ZKVM and you have a bonafide app chain that's already running in production. So the crux of

what we're doing is just you get to have your cake and eat it too. You can have a very scalable DA system. You can have very fast consensus and you can just use proofs everywhere without having to duct tape everything. Um can you actually build this without using highly? The answer is yes. Uh this is an example for example from a company called Hibachi. So these guys are building a provable order book or exchange. And the way they do it is that they do the DA on Celestia. They generate proofs of the exchange using Succent and they settle everything to Ethereum. So if you do the whole flow, you send your data to Celestia. You ZK proof Celestia's consensus back onto Ethereum. Then at the same time, you

prove the consensus of your exchange from wherever you are back to Ethereum. And then you hope that the two proofs can talk to each other in an atomic matter. This does not spark joy. Uh you can duct tape it. Uh but this is very aux coded. So we've just decided to build everything on highly in one very very opinionated stack. Again you get scalable DA fast consensus and native proverification. This was a good article by one guy at paradigm who was talking about what is the the ethos that you're fighting against. So for Solana for example, it was actually solo staking sucks. Uh it is okay to have a bit of

decentralization and that's the thing they run with. Our thesis at highly is that modularity sucks. If you need to solve a problem by adding three different protocols, you're probably not solving the right problem. You can duct tape things, but our thesis is that you can actually just build a very opinionated one-stop shop and a full stack solution. So, what is the trade-off in all these things? Like you hearing me talking about it, like you speedrun the Ethereum game, you just use proofs. Why haven't why hasn't anyone done this before?

Because it's actually really hard from a design standpoint. Like think of it, you have a blockchain, there is no execution environment, no state. How do you make sure for example that your contracts can talk to each other? Proofs take time to generate, sometimes even minutes. How do you solve for this? How do you even manage the fact that you can like generate two proofs for the same thing at the same time and that can um collide? And this has been all the work that we've done at highly over the past year. So to give you one example of the problems that you have when you work with proofs, let's say you have an auction system. The auction ends at 10:00 a.m. and your proofs take 1 minute to generate. So in effect, your auction ends at 9:59.

That's one problem that you have with proofs. Just generating them takes time. The second is let's take the example of the auction. Again, uh you have one user that's going to generate a proof and changes the state from green to blue. Then you have another user that's also going to generate a proof to send for the auction and generate a proof from green to red. Both of these state transitions are correct but they conflict as far as the network is concerned. So how do you solve this? That's actually one big problem that you have with most what we call proof chains uh like Mina for example. The way we've solved this is that we've introduced a concept called pipeline proving. What pipeline proving does is you it's like booking a table and then coming in to claim it. So in

the example that I gave you about the two users, both users will send transactions on Heidi and Heidi is going to sequence them on the DA layer. That's it. At that point in time, you're only sequencing, you're not proving anything. So now you have committed that it is first green to blue and then green to red. Then a prover, the user appro anyone is able to come in, look at the DA layer and say, "Oh, I'm actually going to prove things in that specific order." This gives you many many many advantages. First, you get instant fast finality because these transactions get sequenced in like less than a second.

Second, you can do parallelization. That's really really good. And overall, it completely removes proof generation from the critical path for your application. So, we really yet to see another uh network really use this design. But if you are to build proofs to build with proof, that's basically what you need to do. Think of it as anything is running as a based zk roll app. And the good thing is uh you can actually see it for yourself. For the past 10 months, we've been hard at work actually building a test net version of highly which you can experience over here. Uh so the QR code gets you to highly fun. You can use the codec and do it fast before the dev team kills me. Um and so we built so the network is

operating like we have eight nodes. We run the first implementation of the autoband consensus algorithm that's running and every single transaction that you're going to do on the network is a proof that is going to be proved either by the sinking proven network or by the boundless proven network using CKVMs and the wallet is built with more. So there's tons of good things that you can do over there. We really like you to experience it. Um and yeah that's about that. So to summarize what we believe in at high everything is going to be proved, signed and verified. You have to be very very opinionated because it is such a a radical change in computation that rather than try and cram proofs into blockchain, it is worth designing a

blockchain around the affordances of proofs. And overall, we do think it's not the end of the history for blockchains. That's it. Thank you for listening. Any questions? Do the people build ZKDSL have questions maybe? Yeah. Hi. Uh question about the password wallet. uh h how do you store the the

password on the blockchain when you use the password wallet? So the trick here is that we're not storing anything on highly like contracts are very very minimal. So it has a proof system in the concept in the context of this of the wallet for example it is built with noir it has what is called a program ID that helps you identify specific program within this proof system and then a let's say commitment like a hash of the state of the application. So everything is actually happening in your browser like whenever you're logging in on the highly using on highly using the wallet what you're doing is that you're generating a zero knowledge proof on your smartphone that you know your password and that's going to provision a session key in your browser that's good for like a couple of

days. So everything is happening like on your end. The ch the very weird thing when you get working with proofs is that like the network has zero ID what is going on. It's like yep this is the new state. it is correct. This is the correct proof and I'm I'm I'm executing upon it. But yeah, thank you. Um, how do you plan on achieving uh such uh an amount of proofs that you need to to verify to be sustainable?

So actually that's the easy part because um the one of the great things that blockchain have done in general is to create a massive massive research program for ZK. So and it was mostly let's say um it was supply side driven. Now we get to a point where you have risk five ZK VMs that just work. You have proven networks. So rather than how are you going to be able to generate so many proofs the question right now is rather who's who the hell is going to to consume all these proofs and that's basically what we do at highly highly sequences transactions verified proofs and has a very very fast consensus.

That's basically what we do. So we're currently one of the biggest proof consumers on the boundless networks. We've verified like 150,000 proofs in about 10 days. And the more the more proofs there are, the more we can consume them and the faster applications can get. The end goal for all of this is that like if we go back to this uh to theoop doesn't work. The end goal for users and even for developers is to not even have to think about proofs because right now let's say you want to build an app chain. You need to choose a stack. So you you need to call up like Mr. OP stack. You use the OP stack. Then you need to use a ZKVM to prove it. Okay, that works. um um you need to use a ZKVM to prove it,

then you need to maintain it um etc etc. The very cool thing with all of this is that you can just write your program in Rust, slap it in a ZKVM and that's it. You have a rollup. I think we've been very very sop into thinking that rollups have to be blockchains. They can just be servers. I almost uh understand nothing of the talk but is highly like um uh L1 or what and where does it derive its uh security

from? Is there a consensus mechanism with stakers and stuff like that? Yep. Okay. POS as God intended. Sorry. Proof of stake as God intended. Ah yes, perfect. Okay. Thank you. If your blockchain doesn't store state, how do you plan to track historical transactions and do analytics? I think this is a problem at the application level or if someone wants to provide that service like they can certainly do it. But if you look at Ethereum for example like they are archival nodes but this is not the job of the blockchain. What the blockchain

does is that it tells you the time it should sequence transaction and settle that's about it. Anything else can be provided as a service on top of it like we currently hosted on a carival node. And the very good thing with proofbased systems is that you do not need to have the whole history of transactions. You can just have a single backup and with a proof you can just check that it corresponds to the correct state. So it's very easy to build. Any last quick question? No. So thank you. Thank you. [Applause] [Music]