Panel Discussion: Real-Time Proving moderated by Sophia Gold, Ethereum Foundation

Transcript

back to the presentation. So, um, if you could put the slide deck up, this just has kind of some names, but so the moderator is, and maybe you guys can come out and I'll just kind of introduce you. So, moderating the panel, this is a real-time proving panel. So, we're going to hear some uh firsthand war stories and and best practices and lessons learned from all the teams that were submitting proofs in the demo. So, uh moderating is Sophia Gold, the lead coordinator on the ZKVM team that's been just a a force of nature behind the scenes with all this. And then we've got the team leads from ZISK, Jordi Bina, uh Yei Sun from Axiom, Michael Dong from Brevis, uh Tamir Hemo from Succinct, and

Porter Adams from Matter Labs Airbender ZKYNC. >> So I think it's hard to overstate the significance of the demo we just saw. Uh ZKV EVMs are now at a point where we could launch them uh in a solo rollout on mainet in less than a year. And we've only reached this watershed moment. Sorry. [applause] Um, we've only reached this moment through incredible amount of work and a really world-class level of talent from all the ZK the ZKVM teams up on stage here. So, um, perhaps you can give them a round of applause. The the future of Ethereum. [applause] Um, so questions for the panelists. I

guess let's start out hot. Uh, in addition to the uh a tester client demo we just saw most of the teams up here, you've done your own real-time proving demonstrations uh throughout the past, you know, several months um on often different hardware targeting different levels of uh of main percentage of mainet blocks proven different levels of latency even. Uh, and so I'm going to ask something that I've been asked by many people in the community. Are real-time proving demos dishonest marketing or valuable proof of work that drives the needle forward for the future of Ethereum?

>> Yeah, I can. >> I guess I can start. >> Yeah. So we have not done such a demo but I would say my viewpoint is similar to the securities and exchange commission where in US equities what matters is not what you do but whether you disclose it. So I think that so long as all the demos are clearly disclosing the assumptions and security guarantees then it is helpful to see what teams deem to be the most interesting thing they can present. >> I think it's time now to probably we achieve uh I think real time proving is a reality. I think nobody discuses that.

We have seen in the demo but I mean internal teams we know that this is possible and now we need to have um need to find new challenges. I think that security of course is the first one. Putting all the things in production is maybe another one of course other more more technical things like uh improving sites verification time. I mean there is a lot of things that still probably still some optimizations but uh it's good that we change a little bit this challenge. I mean probably it's time to uh compete if you want but maybe compete with other parameters uh if this needs to be to follow and to continue improving the space.

>> Yeah. Just say one thing about marketing. In May, we did a demo for like the feasibility of real-time proving where we used a lot of GPUs to prove over 94% of blocks. And Ethereum is a community of people and I think it's good for the people to know what's happening and that this is a feasible thing. So if we convince all the validators to like switch to proving, I think they need to get guarantees that this is a good thing for them to do. Um and I also agree with Jordy that uh once we have a standard for what is secure and what is an acceptable real-time proof that will also be good. I think people are

optimizing for different things. For you it was like the bits of security for us in conjecture like there's all kinds of different things that are important to us. >> Yeah. Well, you know, I guess I can also answer to that marketing stone question. So uh you know uh in October we released uh uh the uh our prover that is capable of proving like 99.6% of the blogs in real time and uh that particular tweet uh got like 3 million views uh and a bunch of like tens of thousands of likes and kind of the community suddenly knows about us and uh people started think that okay you guys did a marketing stunt. Um so yeah I can kind of tell you kind of what's behind the scenes that how we got those kind of a numbers and uh you know what's the secret behind this and you know what's our view about

the marketing stunt. So first of all there's like no you know overstatement of numbers in any kind. So like our tweet was actually kind of extremely dry something like uh announcing pickle prism that we did uh you know let's see what's the tweet. Yeah so it's something like yeah announcing pickle prism that we we reached like 99.6% 6% of the uh you know we can prove Ethereum block 996% of Ethereum blocks under 12 seconds. This is like as plain as this. And uh you know accompanied with that tweet we have a fully reproducible step-by-step GitHub repo that allows you to reproduce the uh performance that we just show. And the numbers themselves are not also kind of a doctorred in any sense because like we ask Justin how can

we convince you that you know we reach real time proving just said don't do random sampling you just approve one single day of block every single block and we say which day Justin said September 1st. Okay we did that. Um so you know that's how we got those numbers. Um but you know in fact our marketing operation is kind of uh not really good because we didn't even go to any PR agency. We didn't even pay any PR agency to put this out to the PR media outlets. Uh what really happened was that you know uh Ethereum Foundation we basically just asked Ethereum Foundation to see okay we did this and we have all these kind of comprehensive result can you help us to retweet this and uh very gratefully you know Ethereum Foundation helped us do that. Justin did that too but Justin retweeted with like very long

post mentioning all these ZK VMs as well so that's what happened and uh you know we also work with numerous different partners so our partner amplified and somewhere along line Vatic also helped us to retweet and uh you know this whole thing got viral and got a kind of a 3 million views so it's there's really not no kind of a secretive marketing operation planning behind this this is just what happened and uh you know but I can understand people are surprised because we are probably the poorest the ZKVM team out there and we just announced like you know this thing less than a year ago and we we did this while we kind of launched like 35 different partners that using our product in uh live in production. So people say oh my god there must be something fishy about

this. Uh so you know we okay so I have a confession to make that we definitely cheated. This is how we cheated. Uh so our our team works 100 hour at least 100 hour per week for 300 days. No vacation, no national holiday, no weekends. This is how we did it. You you guys can learn from it basically. And [laughter] and uh yeah, you know, onto the topic of marketing. So like we uh you I have been building in this space for like 10 years now and uh you know, things has changed. The world has changed. Now we're in the age of attention like people kind of drive attention and uh you know kind of have influence that way. The a very unfortunate truth is that scammers and grifters they are so good at getting

attentions because that's all they do right so we got to do some real work ourselves um so I would say like in terms of marketing we as the Ethereum community builders should be like Jedis basically um you know we should not submit to the dark side of the force but we should know how the force works and uh you know whenever we we we did something that is amazing we should report this with high integrity But we should marketing stone the of this because it should be us, the builders, the innovators, developers, the Ethereum lovers who actually got the attention and get to influence where the entire industry is going instead of those scammers. Sorry, I got very emotional, but yeah, thank you.

[applause] >> I will just add quickly, I know that uh this is probably the biggest audience for ZKVMs we've had. There's a lot more interest now. You might be newer to ZKVM marketing than we are on stage. I would say benchmarking before this was much more contentious and there was a lot more that was kind of like hidden and hard to tell about the ZKVM announcements and benchmarks beforehand. I think Eve proofs is like by far the most clarity we've had and like it's a real world example that people can actually kind of see and measure and like understand. Uh so very happy with this.

>> Okay, let's um ask something a little more technical. So I'm curious, what changes did you have to make to achieve real-time latency with low GPU count? And also, what changes do you expect to have to make in the future to grow with Ethereum? So in other words, to prove higher gas limits, shorter slot durations or make your proof smaller. >> I guess the most impactful change that we made was to switch to ahead of time compilation for execution. Um, so we're now able to emulate risk 5 at about half of nav speed. Um, which was a pretty significant bottleneck in previous iterations of the system.

>> Yeah, I would add to that execution is definitely a bottleneck for latency because you can only prove what you can execute. Um, for us lowering the GPU count is basically cost. So building a new proof system that is built for the ZKVM workload was meaningful and I think what we have to do next is I mean it's a full stack optimization problem. So there's places to improve all around. Um and I think there's also new techniques that are going to come in. So I think in the in the next year we're going to see even better numbers or that's what I I foresee.

we have um I mean some pending optimizations uh say probably the the place where we having pushing less is the zone of the client side I mean what goes from the client to the executor I think there we are losing at least one two seconds easily uh on that side and we haven't probably go so deep in the client here we we I mean we we help that uh all the clients uh a good collaboration with the clients uh expect collaborations So we can improve this part of the proof that's important. Uh there is some in the can announce that we will have some good news for the kechak uh the kechak uh pre-ompile that I think these are good optimizations

there. uh but the main I would say that the main work in the upcoming month is going to be uh auditing internal auditing securing documenting putting the things uh uh in place uh if this needs to be done in in in in production and what I'm saying in production is holding millions if not billions of dollars uh uh that rely on the code that we write uh we need to Fritz the code stop uh go there clean the things put the things out the things and this is the this is the next challenge that at least we will face in

the in the team >> yeah so for us uh you know uh I think right now uh you know uh our emilation is definitely our bottleneck right now execution side of things and uh you know fortunately we got that recently uh solved as well it's just like we didn't get the servers in time to actually plug that in. Uh so uh but going forward I think there are several things we are exploring. Uh you know uh we are actually looking taking a very deep and hard look at GKR uh specifically and I think there's going to be a talk with J is giving a talk this afternoon. you know uh so we do think that there's something that is like very interesting on the GR side that we can do um to you know fundamentally kind of improve the

performance of the proving um uh so that's uh that's another direction we're exploring right now >> I would say like our focus on the entire stack of optimizations all the way down to the hardware like we really design everything with the hardware in mind and this will be what my talk's about like later today uh but it's like everything from the execution client the ZKVM the cryptography algorithms you use like all needs to be designed uh with the hardware in mind and going forward. There's actually like still so many optimizations we need to do. You probably just saw like our 2GPU announcement yesterday uh finally got ready just in time. Thank you to our engineers who've been working super hard to get that done in time and have not slept until right now probably. And so

yeah, there's there's still more optimizations to go when we also do need to work on like our security audits, proof of uh security bits, stuff like that. >> So many of you have mentioned security and um you know my view is the latency is just about good enough and that the next real-time proving will be provable security. I think we'll be hearing some uh alpha about that later this morning. But I want to ask all of you, how have your choices around security uh currently impacted your performance and how do you expect this to change with increasing your security in the future?

>> I think there's two dimensions in security. Usually it's the whether it's provable or relying on conjectures or the number of bits that are being targeted. Um I would say generally going from conjectural to provable security is more or less just engineering. um it's maybe a you know 50 to 100% uh impact on recursion which is a relatively smaller portion of the overall workload. So I'd expect that to be relatively fast to work out. Um on bits of security to get a larger number of bits as a target often it might require changing uh the field or doing some more fundamental changes to the system. And so it's definitely a bigger effort uh but I would say maybe not maybe double the um

effort on provable. >> Yeah, I think security actually has two faces to it. One is the cryptographic security which is kind of what you're alluding to is conjectures and bits of security. We prioritized the conjecture work and actually it does have it does come with um significant overhead and luckily our proof system is kind of made for that but but maturing our industry is and not relying on conjectures I think it's like a really important thing and on the other hand uh setting the bits of security to like the cryptographic standard is important but also um

innovating on the auditing and verification of the code itself that it actually does what it's supposed to do um is important. In our case uh we are we are in our case we are 128 bit security from the first day I think this is I mean it's the the industry standard so we don't want to go lower than that here is all these conjectures this is very recent and there is a lot of papers I mean we're we were waiting a little bit for the foundation recommendations there definitely will go into proven security uh for that this has some impact uh in the prover maybe something between 20% % uh penalty what we have to do of course mean we need to do the numbers there are

things that we are not doing right now we may consider to doing especially for the for the positive sides of all these papers like grinding and all these things like that so I think that overall when we put all the things together we probably will end up uh more or less in where we are but uh this is probably one of the works of the coming weeks >> yeah I think like cryptography uh security and also kind of a you know formal verification audits are you know of course like things are very important and all the panelists have mentioned uh I think another thing uh when when we look at like ZK uh EVM specifically is to think about how we actually operate this uh in the field like in the future

right so like once we have this live you know the entire Ethereum ecosystem is going to rely on these provers to actually generate proof and you know to be actually live and uh how does that work um you know what's the transition path to that uh you know operation wise like you know do we do like three out of five how do we pair you know different clients do we kind of have a different clients on the same VM different VM on the same clients so these kind of a consideration are actually very important when it comes to application use cases in this case it's a zik uh you know EVM and kind of a upgrading the consensus protocol itself so I think this is a kind of an area that is like right now getting less attention and this something that we want to

contribute in as well, >> right? Potentially hot tape, but I am not too concerned about like a two to the 80 cryptographic like attack uh in 12 seconds right now. I know Zika uh bits at the moment are a little bit lower than others on the stage, but this is like the the bugs that I'm worried about is more like what Tamir said, which is just like making sure that the code actually does what it's supposed to do. Uh that's why at zkync we're looking for like we want to have multiple execution clients uh multiple ZKVMs even besides just air bender. Airbender is so fast and cheap that we can probably just run a whole second CKVM and get security that way by not having any single dependency.

>> So just curious like you know have you guys tried to run things like risk uh in air bender and uh you know because you guys are using kind of a customized client program that is different from the rest of us right? So like uh you know what's your Yeah, just curious about that. >> Yes, I believe someone in the audience has been working on it. Um I'm not sure uh exactly what the benchmark comparison is between just regularly compiling ref and then using like our custom execution client, but I think it's like multiple times increase uh in performance by writing because the L1 execution clients are designed for normal computer programs. So they have like multi-threading like a lot of kind of stuff that you would use on a normal

processor but then when you're trying to prove things inside the ZKVM a lot of that stuff is like not too helpful and like kind of creates a lot of overhead. So writing like optimized code for ZKVMs is quite different and so like it's nice to just say like we'll just use a L1 client and we'll slap it together but uh there is a performance hit there. >> Yeah. So you know I think you know just kind of want to uh disagree on the approach here because like these kind of a clients you know that we are using has been running in production for years that has been security audit and everything. So like writing a customized uh you know client for uh you know Ethereum execution that is equivalent

that is supposedly equivalent to the the ones that has been battle tested in field for years will definitely add overhead. We'll have performance benefit granted but uh you know we'll definitely have overhead when it comes to security when it comes to how soon we can actually push this uh uh to live in production. Not sure what uh you know the rest of the panel thinks about that. >> Yeah, I think I actually want to emphasize this point too like there is a benefit and this is kind of the promise of ZKVMs is developers do not need to change anything and we will absorb it and we can do it. Now obviously up to a point there's clients are complicated so there are things that we can cooperate on but being able to run existing battle tested clients is really important to us

and I also think 80 bits is uh kind of risky. I wouldn't sleep well. >> I'll agree with you that I think 80 bits of conjectured security is not sufficient for the L1 especially when currently malicious provers can likely prepare soundness attacks ahead of time. >> Yeah. Um, so I I think we have about five minutes less left. I don't know if there are any questions from the audience. >> Here's all the Merkat questions if you want to. It's sorted by popularity, so feel free to ask what you would like.

>> Uh, okay. Um, the top voted question, why not open source from day one? Actually I myself was gonna ask what do you think are acceptable licenses for L1 CKVMs? >> MIT MIT uh patch from the first day. This is the this is [applause] [applause] >> so [laughter] I mean I appreciate Jord's commitment to MIT. I actually like I I like it in a way. However, I also think there is a big question about our ecosystem like

how do we make it sustainable? Doing these EKVMs took a lot of work for a lot of people that need to get paid somehow. And I think going too much on this like you have to be commoditized and open source is a little bit mean the incentive is aligned in a bad way because then I have to make money in another way, right? Um, so I think there's room to think about, okay, what can an L1 specific license look like or I think there's like the leave it to the business people to talk about, but I just want to emphasize like who pays the devs, who pays the prover devs as well is important. Yeah, >> Ethereum has been developed in the

open-source uh space and I mean I think that Ethereum has been very well developed and there are ways >> ways maybe they don't I can agree that maybe they don't maximize I mean and I know that launching a token and pumping it I mean this is good and it's good for for for and you get a lot of money but it's not the only way it's not the only way to um I mean to live from open source a lot of open source that are not even in crypto they survive uh quite well and if we are building common good we need to do common good on scratch I mean I don't want uh uh having an Ethereum where you have to pay a royalty every time that the block is mined and

uh I want to be open I want everything I don't want to look at your code and being afraid if I can use it I cannot use it if I'm getting I mean I just want to use open source We're literally open source. This is how the space has been built. >> Just grow or just to emphasize the VK ZKVM itself should be open source MIT and SP1 is MIT. The proving system itself is MIT. The prover code >> right now is under like a business license because you can write your own prover as well. There's nothing stopping.

>> Yeah. But it's what happen if the network is running your prover and your prover just stops. What about lightness? Uh >> there are other poofers as well the other teams I'm working with the develop proofers. >> Yeah but you should be able to uh uh built in common. I mean you are learning a lot from the open source uh projects. We are going you can take the code. I mean this is how we grow as ecosystem. I think it's not fair that there is uh [applause] [applause] I would say license aside. I do think licensing the prover and putting your monetization on proving actually creates kind of a negative incentive in that if

proving proving monetization is going to be cost plus. So as proving costs go down, you know, the the revenue opportunity goes down. So I I don't actually see a case where you know cost plus proving aligns incentives between ZK teams and applications. >> Yeah. >> I mean yeah >> I think I mean so for us like we care much less about the the entire VM stack licensing uh because like you know as mentioned for us like we build a general verifiable computing platform and ZKVM and Ethereum execution chain is one of that. uh the well you know again we were the poorest team here is like this guy have 100 million this like hundreds of millions but you know so we we need to kind of figure out

>> don't you guys have a token >> we don't we don't we don't we don't yeah so uh yeah so like soon DM >> you know so yeah so uh you know but we what we focus on is that we kind of try to build more use cases that can use verifiable computing like zkm is very important at the consensus layer but you can actually tap into the power of verifiable computing now in your application because you can offload some very complex computation into the ZKVM and into things like co-processors that you can generate proof and then use that proof back in your smart contract today. You can actually tap into that power now and this is the kind of thing that we build and this is where we want to monetize and not specifically kind of on the VM side. I know we're still kind of

in the business license side but we're kind of changing that pretty soon as well. Yeah, >> I think I mean there's a panel later on and who pays the provers one question. >> Okay. Uh okay. The next most voted one in which part of the stack say GPU implementation prover arithmetization compiler client do you expect the most gains going forward?

>> Let's take a look >> in which part of the stack do you expect the most gains going forward? >> I think the place that's been less pushed on because of the security risk as has been discussed is on the compiler side. Um there's a lot of room to optimize guest programs for ZK and for ZKVMs. Um but it is more dangerous to actually move on that front. Um so I think the natural velocity should be slower but it it strikes me that in 5 years we definitely will be in a world where co where we are co-optimizing the compiler and front end to the actual back end.

>> It's a balance. So I mean this is finding the balance between >> optimization and doing things very tricky and writing taking just the standard Ethereum clients that have been battle tested a lot and modifying minimally so that uh you keep the security and it's it's a balance and probably the right place some somewhere in the middle. >> I think the proving systems have not matured yet. Um this is a a problem that uh researchers have only been really thinking about for a few years and um I think there's a lot of promise there.

>> I think our our engineers have already maxed out our GPUs. They're at like near 100% utilization all the time. So there's not much more progress to make there. I think it is like in the cryptography algorithms like new proof systems like maybe multilinear is better stuff like that will be like the next big innovations. Okay, I think we're at time. The last thing I'll say is that we uh did a very similar panel on Thursday at the ZISK event with many of the same participants. I noticed that uh you guys are much better behaved and less controversial [laughter] at an event put on by the Ethereum Foundation. So that makes me quite hopeful at our ability to standardize uh ZVMs and which I think is what we'll hear about next.

>> Thank you. [applause] >> Thank you all. >> [applause]