Panel Discussion: Who Pays the Provers? moderated by Julian Ma, Ethereum Foundation

Transcript

Okay, so the final panel is going to be moderated by Julian Ma from RIG researcher on the robust incentives team uh robust incentives group at the EF. Uh and then the panelists, Lucian Stroy from Boundless, Leland Lee from Succinct, Alex Trust Michael from Ultrasound, Torston Barren from Galaxy Digital, and Jordy from ZISK. >> Do you want to be in the farthest? Say it or do you want to go? Yeah.

>> Yeah. Do you want to go? Ah, >> yeah. Should I go for the farthest? Sure. Thank you. All right. Do you hear me or is it good? Okay. Well, thank you everyone for being here on Saturday, last day of the night at 5:00 p.m. Uh, it's great to see that there's such a full audience still, and I guess that's a that's a big congrats to the organization. Um, so we're here to talk about who pays approvers, which I think is an important topic that's sometimes uh not as clear um in the room. I'd like to start out with just a round of introductions. Um, I'll go first and then we'll head to Jordy. I guess most of you will already know him by now and we'll go uh back here. So I'm Jillian. I'm a researcher at the EF within the robust incentives group. We

look at incentives within Ethereum very broadly. And I've been looking at prover incentives. Uh we've been looking at how should provers be integrated within Ethereum system. So if there's a slot, how much real-time proving time actually is there and how does the protocol architecture work? And then we've been looking at the incentives directly. So who should pay the provers and how much should they be paid? Um yeah I guess Jordy maybe if you want to have a word where you can immediately go at it. >> Um regarding who pays approvers I mean at the end who pays approvers is the it should be included in the transaction fee at the end is the users. I mean uh the value is uh in Ethereum is created by the users. So at the end of the chain it should be the users it will be the users who pay there. Okay. So the the

the question is okay what's the mechanism um for the money go from the users to the provers um in the right way I think this is the right the right quest I mean I the right the difficult part of uh to solve >> yeah that makes sense that makes sense we we'll dive into that uh just maybe Alex if you could introduce yourself as well >> Alex uh from Ultrasound uh we run one of the Ethereum relays, one of the bigger ones. Um, know somewhat about block building. I mean, I know we get a lot of blocks. We get thousands every slot. Um, and I guess by now we have done quite a bit of thinking about the economics of,

you know, how do we get paid, where's the value with transactions, and how does it flow through the entire pipeline. So, hope I can contribute a little bit from that perspective, even if I'm not a block builder myself. >> Cool. Thor, >> um, I'm with Galaxy Digital and also ETH staker. So, I have a bit of a leg in both um the professional staking world and the home and solo staking world. And I think here on this panel, the reason I'm on is to talk about local block builders and home and solo stakers and how that would impact them.

>> I'm Leelin from Succinct. I'm the ecosystem lead, which means I spend most of my time talking to early stage partners on what it's like to use SP1 or ZKVM, but also I talk to them a lot about like how do you actually pay for proving on the network. >> Hi, my name is Lucian. I'm with Boundless. Boundless is uh the first distributed um permissionless ZK marketplace and we're live. We launched about two months ago. So yeah, I'm going to talk about what it's like to actually have a onchain marketplace for ZK proofs.

>> Awesome. Okay, so the setup for the for the the setup for the panel would be is it is it good? [laughter] >> Yeah. Yeah. The setup for the panel would be we'll first go through the costs. So what does it actually take to create these proofs uh and look at the economics of that? So that would be the supply side. After that we go to the demand side. So where does the money come from and what mechanism routes the money to the provers? uh and later we'll zoom out a little and go into the L2 world and see moving away from real time proving how does the other markets for ZK affects our market. So looking at the cost structure um maybe um Lucian if you could start how would you see the cost for proving for Ethereum blocks and what is it composition is it mostly variable

is it mostly fixed costs >> yeah so background um is this okay so the background is boundless was actually incubated out of risk zero um doesn't seem to be working but >> like this >> it's been lovely still first if you >> thanks. Yeah, so Boundless was incubated out of Risk Zero, the first Risk 5 ZKVM. So we have quite a bit of time in production. Um our first product was a centralized uh GPU compute marketplace.

We called it Bonsai and it's centralized built on AWS and our architecture is essentially using AWS on demand uh to scale up to the proving needs of clusters. So I think the most important thing that we did at Boundless is create a open permissionless participation set and get the hell off AWS, right? And there's certain things that are necessary for us to like okay we're proving Ethereum and it is permissionless. It is principled and it matches the livveness guarantees of Ethereum itself. Because if proof requests essentially have a dependency on some kind of centralized entity and

that goes down, it's unacceptable to actually have Ethereum halt ever. >> That's that's very strong. I don't know if you have anything to add to that. >> Yeah, so when it comes to improving Ethereum, the costs really vary depending on which underlying ZKM you're using. As each ZKVM has a very [clears throat] different performance characteristics, I think our goal at Succinct is we want to make our ZKVM as performant as possible and to cater to home improvers. I think as time goes on and as the gas limit keeps on increasing, we want to maintain those same limits where as EF said under 100K of capex, under 10,000 kilowatt and so hopefully we can, you know, scale

the gas limit, you know, 10x, 100x while maintaining those limits as time goes on. >> Okay. Interesting. And and Thorson, could you maybe say a bit of what you think is acceptable cost toasts as well for proving? >> That's a that's an excellent question. Right. So, we're looking at 100,000 in capex right now. OPEX depends at 10 kilowatt. Of course, that's the max, not the average. You're eating anywhere between 7,000 and 25,000 a year just in power, depending on where in the world you are. Um, that's not going to work for homestakers, right? That's a hugely centralizing idea. Now, with your idea of we're going to shove that across, we're going to decentralize that and everybody gets a chunk to prove and then we'll have

redundancy. I think that can work. So, if a homestaker can just say, I'm putting a GPU in here, you know, something small. We're probably not getting away from Nvidia anytime soon. Um, and or we're getting specialized hardware. I think that's going to happen. We're not going to prove on GPU forever. You already have teams working on things that have like a little risk 5 CPU and a specialized chip and shared memory in between to speed all this up. We could get to the point where someone can spend I don't know 700 to a,000 bucks and be under a,000 watts and help proof. I think that would make it very decentralized.

>> Okay. Uh that's very interesting. Maybe I'll skip Alex for now and we ask Jordi. Do you think something like a,000 bucks would be reasonable? Well, uh I can tell exactly how much uh cost the Jirona cluster the one that you saw in the previous presentation. This is 16 16 normal gaming boxes. It's box each about 4K more or less. So all the cluster I mean I can tell you that all the cluster including the GPUs the server the hub the installation the air air condition the electrical installation uh the setup uh all together uh even the installing the installing cost of all that uh the budget it's uh below it's about 90 about

90k so a little bit less than uh 100k and uh regarding energy um I mean I have not paid the first bill and this of course depends on this that is this I mean this would depend a lot on the energy cost and you know this is depends a lot but I can tell you that the GPUs I mean when when you are doing blocks in that v of 6 seconds that means that the GPUs are only working around uh 40% 30 40% of the time um these GPUs are about 600k so you can do more or less the the numbers but I expect that it's going to be below 1K a month. Uh, definitively.

>> Okay. Okay. And do you think it's a problem that the GPU is only using 40% of the the time? >> I Well, it's what I say. I think that I mean I don't like the idea of of even clusters. This is the the meanless office clusters. I don't like this idea. I think that the nice thing of Ethereum is that Ethereum can run with u uh home home machines. Okay. uh they to lower lower the hardware required lower hardware and for me it's I would say it's lowering the hardware required but without having centralized um infrastructure and things for infrastructure I think they are not good I mean at least they are less uh

decentralized and they are not good and they are problematic uh at this point for example me mess and block builders are I think that are a little bit problematic for Ethereum because this is a central point uh on there and uh provers could be another u I mean provers could be another centralized uh point in there and if you if you join them together this is even worse uh uh but yeah we can talk about that. >> Do you want to say something? >> Yeah, I did and it was specifically with the the fact that we're optimizing for multiple things at once. Um we heard a lot of talks about real-time proving but the faster your proving cluster goes and it has to be a cluster colllocated uh to

go really really fast um you also have higher and higher underutilization of GPUs. So like you start having like 160 GPUs to like hit some benchmarks and you actually look at the utilization you're like I probably had 40% utilization that actually greatly contributes to cost and I think that the current um problem with ZK adoption currently like the types of customers that we have in production currently um the main bottleneck for further adoption is actually cost right now. Um, so it ends up actually uh being much more cost- effective to reduce latency uh requirements in the short

term. Um, but again, once we do optimize for all of these things, um, we're going to see that actually like, oh, if the latency requirements are a little bit lower, then we can actually get home provers faster. So, I actually participated with my gaming PC on our network as well. Um, my machine did not do more than one megahertz, so I'm not doing real-time proving of Ethereum, but I can do useful work and it could help rollups scale and transition from optimistic roll-ups to ZK roll-ups today. So the it's an incremental process and I think that um there's going to be some steps that we're going to take but we really need to solve the

cost problem and yeah the underutilization aspect of it is actually the reason that we had to shut down the AWS cluster like on demand resources on AWS the amount of time spent to like actually spin them down and to spin them back up actually just made it so infeasible that we priced out most use cases. So, we're extremely happy to be sunsetting that product at the end of the year. >> Wow, that's super interesting. That's good to know. Um, I guess Alex, maybe you could add a bit to uh like the engineering cost that would actually go into this. Um, if if you have any idea about that, I guess about running the provers.

>> Yeah, like exactly. Maybe what's interesting to add is like as I hear you speak, you say like the costs seem kind of high and I'm I'm thinking like actually they seem not that high to me. They seem like very reasonable. And if I would say anything like on some level I think it's going to be a trade-off of what we want like decentralization of course is very important but we also need people to be using the network right the other thing that we really want and I think the scaling the network is one of the most effective things we can do to bring more transactions on chain and if I very quickly think uh do some mental math and say like say that we can only we we increase the uh block space massively and we get just twice the amount of total transaction fee

volume then this like is way way way worth like running uh what is it K of N like K of these like instances all funded by these entities that are currently involved in the uh block building pipeline and in fact like my very next question would be like why are we holding it back as I understand from people today costs are going down um if they go down we would like to even push further and go for even bigger blocks and I would say in this case especially like we like yeah it'd be a profitable move to make right to say why not push even further, we're very very happy to pay more because yeah, economically this makes sense for us. But I I totally hear your concern >> and you can you can scale. I mean you have a centralized cluster and the

network grows probably have to add more I mean more more more workers there. But I like the idea of uh I mean if you have the the workers spread around the network and the incentives are aligned right uh then uh uh I mean if you have more demand uh you will you will have more supply because I mean you will have more incentive to put more more provers there and I think this is something that scales uh could scales better of course if the protocol is designed in the right way which probably is a difficult part here uh what we are talking about but it's model for me is decentralizing the the decentralizing the the the the provers I mean don't do not depend on a

single uh server or if you want a small set of uh server or clusters for building the proof >> person do you have any thoughts about that should we just increase throughput if we can >> I am torn right on the one hand um I love the idea of for livveness and for scaling we do density decentraliz ation here. I'd also want to say, you know, we always have to think why are we decentralizing? In this case, we wouldn't do it for censorship resistance. For censorship resistance, we already have decentralized the testers and we have Fossil. I'm assuming Fossil goes in. If there's somebody at the EF, please make that happen. Yeah, >> agree. Um, so that gives us our

censorship resistance. That's the the broadly set up home and solo stakers now and we still need them for that. Um, when we then say, "Okay, now put a GPU in there or use your gaming rig when you're not actually actively playing World of Warcraft and do some proofs at that point." On the one hand, that sounds really great. Um, maybe we can scale faster that way. On the other hand, we're now introducing latency. We're introducing complexity. So, the question is, is it necessary complexity? Can we survive these latencies? Does it does it constrain us in growth where a properly incentivized group of I don't know 10 20 50 provers or whatever can just scale that on an enterprise level

potentially much faster or in a more controlled way, right? We're not saying we hope we have enough GPUs online right now. We know we have enough GPUs online right now. So I'm I'm torn, you know, I want I want to advocate for home and solar sters to prove, but I'm also conscious of the technical difficulty to do so. >> Yeah, that makes sense. I think many of us are are thorn in that sense. Um, okay. So Luc, you spoke to it a bit already, but maybe we could hear some more. What do you think are the the vectors of competition among provers? So you spoke to it because you mentioned that the underutilization, for example, could be something that you need to improve on. Yeah, I think right now the state of ZKVM development uh requires large proving clusters and then it's

just a question of incentive and mechanism design to get the largest number online today. Um we also have a bit of a disadvantage right now because I think we do have a a floor. Um there's an opportunity cost because we're in the middle of like the craziest AI bubble and the optimal hardware actually matches the top-of-the-line GPUs. Um so like you had to go to Switzerland to get uh sources of GPUs and that was 16. And like yeah I mean we're really fortunate in the fact that like we're not actually trying to run infrastructure ourselves currently. Um we're actually just trying to make the incentives correct so that the people who have access to large uh

data centers with GPUs already and the lowest cost of electricity get online. So in terms of like driving down cost, I think that's the most important one. Um and then the next step is like what token is used to make the payment. The ticker is still ETH, right? [laughter] Yeah. So you make proof uh requests in ETH. um you do it on chain and you match the actual livveness guarantee of the chain that you request and once you have that proof request and you either have an option and I read u your uh paper that you sent over you have an option to either have a ton of people racing um and like have a prize pool or you have someone lock in and you only have one

person working on one proof request at a time. That's the option that we took because it's going to drive down costs. So if someone doesn't fill it in uh that proof request, then you need slashing and this is effectively like the design decisions that have gone into boundless and that are all live in production today. >> Okay, cool. Uh maybe Leland, you could tell us a bit about your system. >> Yeah, I think in our view the best way to reduce cost is just merely making your proof system more performant. So for example in May when we did realtime proving we used 160 GPUs which was tremendously expensive but come today we're only using 6T and the same as this and so when you get this like 10x improvement like your costs like go down like proportionally and so our view is

like we should ek out as much algorithmic improvements as possible along with like GPU improvements and try to use as min as little GPUs as possible and let's say let's say we want to double the block size or 10x the block size and we have to like 10x the GPUs. Sure, like 160 160 GPUs are expensive, but for context, Ethereum gives out like 4 billion in incentives every year, which seems like very poulry to let's say like a million dollars to build out a proving cluster. So if you have like a 100 proving clusters, say hundred million, it's very not it's like very little compared to 4 billion.

So maybe like it's actually okay to have lots of GPU, it's okay to really step on the gas pedal today. >> Okay. Okay. Okay. Okay. So in this part of the the the panel I wanted to sketch a bit so like what does it take to create these proofs and what is the supply side of the market. I think Jordi you've been aiming already at the demand side and I guess you guys have been talking about it some bits as well. Uh you guys are are envisioning the prover market model and I think Jordi you might be envisioning something different. How do you envision the the money actually going through to uh the provers? I mean the easiest part is I mean the same way that there is a budget assigned for validating uh it should be a budget assigned uh by the proverbs. This is one

way to do it. The other is uh maybe uh it could be a percentage of the gas. Uh that's another way of uh taking at that. I'm assuming here that the gas cost of the chain is more or less the same that the proving cost. Uh that's another way to look at it. But uh but I think that I I believe that needs to be embedded uh somehow in the protocol. So I think that the incentive needs to be uh set in the right way uh so that and the incentive needs to be for having for decentralizing the provers. I mean this

is the it's a matter of setting up the the so this is how you collect okay so you collect probably okay it's part of the gas is easy okay we already collect there okay but then it's how we distribute them well they distribute to the people that's doing the proof uh here we can play a game in the first come first serve but this is very inefficient probably I believe more in a okay you have a more prayign works maybe redundance uh some redundancy this is a little bit inefficient I mean in general Decentralization means uh some sort of inefficiency because you are buying other things. It also adds some sort of complexity. Uh I mean it's much difficult to run a chain that to run an

SQL server. We know that. But uh uh finding the right balance and understanding that the centralization is uh important and the centralization have a a cost uh uh it's okay. I mean I think we need to accept that and uh we need to set up the incentives in that direction. >> Okay. Okay. So what I hear is that at least the collecting money parts should either be transaction fees or I guess the pro school issuing some sort of of money. >> These are the I mean these are the two that comes to my mind but maybe there are others but for me it's like a variable cost or a fixed cost.

>> That makes sense. Um, so to to pose the the different perspective, I've heard that people say uh builders could run provers themselves and they could fund it, for example, out of MEV or or some other source. I don't know, Alex, if you have any insights into whether that would be viable. >> Yeah, I think that would be very reasonable. Um, in fact, like you still need the the block, right? There's already competition in Ethereum today for the transactions. They already flow through private pools. Um, and you know, you need something to prove. So uh if you have the transactions and they're coming from the builder I imagine there's already an economic relationship between the two like if there would be a lot of payment to the provers but you need the transactions to do it then already you would expect there'd be some kind of back and forth to find a balance

of what that split would be um I yeah I don't know where it would uh fall but also to the question of for example efficiency I imagine that yeah if you already have a fight between builders to figure out who has the most valuable block and that auction is uh won so to speak uh from there For a builder, it's you know very straightforward like you talk to all the provers you say hey I need this proof this is how much time I have what is it going to cost me and you get like a very standard market in which people can offer to uh to deliver the the proof of course it might get like more difficult with no you can imagine that even yeah networks plug in uh into that model just fine and maybe one more small addition like to the uh

decentralization question that yeah like we have fossil for censorship resistance if lifeeness is a big uh concern which I think is very fair I would sooner expect that there's some kind of like penalty of incentive to do something about that directly although yeah I I will recognize like it's it's a very tough question as well >> do you think builders will verticalize and how many builders are there in practice >> um yeah verticalize I [snorts] guess I haven't thought enough about like the benefits of verticalizing I can say that on a day-to-day basis as a relay it's very clear what the benefits would be of verticalizing um so I feel like that will come down to yeah what is your modes, what is your unique advantage, right? And if it's very copyable and if the chart for

hardware costs keep going down, then yeah, there's a point where I think builders will say, I think we can do the DevOps. We don't mind buying 16 CPUs. I actually know a guy who loves messing with CPUs. Actually did a bit of it myself way back in 2015. Uh, we'll figure it out. But yeah, this is my very like take it with a grain of salt. >> Eden, what do you think? Can builders just pay it out of me or do we need something? Uh yeah, I suppose builders can pay on a I mean I think what be more interesting as Jordy alluded to like today Ethereum has like execution layer rewards and consensus layer rewards. Uh because in the like ZK proving paradigm a tester no longer have to do as much work but they don't need to reexecute the entire block. In theory the

consensus layer rewards can be decreased and so if they're decrease like maybe that money should be shifted directly to the provers to incentivize a more decentralization. Uh the main reason why I don't like builders paying directly for proof generation is because I think it's very likely for builders to become verticalized. Like you'll reduce like latency and in practice there's only like three or four like builders that kind of dominate everything. And if our goal is to build a really robust system that's like always online like we want to have lots of provers and in order to have lots of provers we need to compensate them accordingly. And so having it as of an in protocol mechanism I think will establish like a floor of revenue to encourage all provers to participate.

>> Okay. And and this have you thought about that? >> I mean all of these proposals just sound like a ton more money into our marketplace. So absolutely no I mean realistically I prefer the idea of transaction fees primarily because um I want client side proving and I think that we can actually if we we can do client side proving easier if uh we do transaction fees based on zk. So if you start um a ZK computation um then you can potentially have less fees because it's less work for uh the prover clusters and yeah I mean there's like there's things that are great for boundless is bottom line right but then there's also just getting the right

mechanis mechanism design and mechanism design on L1 I think is really fragile. I'm actually concerned about the idea of ME and block builders um being the one who uh does proving primarily because ME becomes more valuable the more latency you add before you actually start proving. So you have this really perverse incentive in which it's like like okay maybe I'll start proving only after 6 seconds 7 seconds and then it just creates like a really kind of strange perverse incentive. It does create like an arms race to who can ZK prove things the fastest, but I'm I'm not necessarily like 100% sure that it's going to be free speed.

>> That makes sense. Uh Alex, I I see you. Okay, let's let's quickly dive into that, but we don't have much time. So maybe >> I I I mean probably it's the most natural I mean the most in the most natural way of uh I mean who has an incentive to build the uh the proof is the proof builder because I mean they want to I mean the idea here is if you generate the proof probably you will be able to build bigger proofs and and and then you have the incentive to I mean they are going to be validated. So maybe the validators have a limit on how much they can prove by themsel and they okay the the builder will generate bigger proof. So it can be bigger block. I mean this is h has a writing. I mean it it it's very easy uh and it's very natural

to go that direction. The problem is that this goes against uh the principle and uh I imagine at some point where block builders are removed uh maybe with because at privacy and then we still have the proof there. It's it's um I mean I don't like as a model but I understand that this is probably the the ones that have the incentives are the builders. So uh Maybe unfortunately this is the the easiest path. >> Okay. Um moving on from the me person, do you think that paying out of issuance would be um viable for provers?

>> Oh, I've been told I will get things thrown at me if we pay out of issuance. Um >> from [laughter] who? >> The audience. We will not be allowed to raise issuance. We could pay out of issuance if we reduce issuance for testers and then shovel that over to approvers. Can I briefly say something about me? Feel >> free. >> I fully agree with you that perverse incentives are a problem. I think the perverse incentives also apply to people like you. They apply to cordives, they apply to researchers because now we're enshrining the idea of MEV in the protocol is necessary to pay provers.

And then if we have the other push to say, but that's bad for users. We want to reduce ME particularly sandwiching toxic forms of ME. Now we have this force that says but we can't do that. than who pays the provers. Let's not go there. Yeah. Okay. So, out of issuance maybe I currently like your idea better to pay out of the transaction. >> It's an execution layer function. We're paying the execution layer right now from the TX fees. We're praying the consensus layer from issues issuance. So, why not keep paying the execution layer proving from transaction fees?

>> Yeah. Maybe if I can very quickly add to that because you're taking MV apart from transaction fees. But actually, I like the transaction fees idea too. I think today again not a block builder ourselves exploring that direction but even today that does pay a lot to block builders. Block builders are just concerned with building the most valuable block and one way they do it is by including as many transactions as possible and then there's you know complex mechanics between orderflow auctions and block builders and who gets exactly how much and what gets refunded to the the auction or maybe even the user through the wallet. But being paid from from uh uh transaction fees sounds uh great. But I do think we yeah might still have this interaction between the builder and the prover and who ends up with why.

>> Yeah. >> And also I just have to say from a principle if we're going all in on ZK like let's actually keep the zero knowledge. Let's do the research to actually have private mess and maybe do away with me entirely if we can. >> Okay. Okay. >> Crypto me pools are like it. >> Um Leland maybe you could tell us can we learn anything from how the L2s pay for DK proofs and does that inform how what we can do on the L1? >> Yeah that's a great question. So at succinct we have this library called op succinct. It basically turns a ops stack roll up into zk rollup. Uh we currently have three chains live on mainet. And so how these chains pay for uh proving is actually through transaction fees. Uh so we've upstream the change to opt called like a operator fee. And so every time

you send a transaction um some small slice of it goes directly to the prover. And so like yeah, if you look at prior literature, like yes, we could use um transaction fees directly, but I will caveat L2s are very different because L2s generally don't have inflation baked into their protocol. >> Okay, that makes sense. Um okay, I think we're going to have to round up, but I'd like to hear from each one of you. Is there any takeaway that you'd like the audience to have or any takeaway for yourself from the panel? And maybe we can start with you, Lucian. Um I mean I think the key takeaway is that there are certain principles um that you have to stick with even when we do a massive change in paradigm. You need to have the right to be able to run your

own prover. You need to have the right to be able to like actually just see the entire stack and have it be open source run the cryptography yourself and verify that it's correct. And uh the current state of ZKVMs and its relative maturity also requires at least a two of three verification system. And having worked on the operations side and worked with partners in production, we need to make this very clear. If you are running a production blockchain ZKVM system and you are enabling fast withdrawals from that verification and pro and your actual verifier is also permissionless,

you probably need a two of three proof system immediately. And it doesn't really matter because you can't just like go all in on one proof system to be like, oh, there won't be any bugs. Like we haven't figured that out yet. So we have to make sure that we have at least a two of three proof system and that we think about that going forward and how like we actually have the same thing of client diversity with ZKVM diversity is actually not a solved problem. Um do we set up a two or three base proof systems on a per client basis? I think that is actually like the best way to do this.

Um so I also want to put that out there. I think my view is like if you want to [snorts] if you want to optimize for g getting to giga gas as fast as possible we should throw as much money to provers as possible so that the ZQVMs become more and more performant. Hence direct direct incentives. >> Thirsten any final thoughts? >> Um first thank you for spending time with us here instead of at the music stage. I know that [laughter] we're not nearly as exciting. Um I've seen different numbers for where we're going. I've seen uh 100xing the gas.

I've also seen 540xing the gas to 24.3 gig I think it was. Um that's very exciting. I love that. And we need to make sure we keep our soul right while we're uh competing with other chains um that are in that kind of throughput. Can I say Solana? Um then [snorts] we must not lose what makes Ethereum Ethereum and that makes decentralization, right? And so we want to bring everyone along here and that means we need to stay decentralized even in parts where we say oh we can centralize this and we still have fossil right Len no let's try and keep proving decentralized as well let's make an effort.

>> Okay great Alex any final thoughts? >> Uh no I can like I think wholeheartedly like agree with that. Let's make sure we keep the properties but also let's scale Ethereum and let's scale it a lot. [laughter] My my thoughts is I mean ZK is really important for decentralizing Ethereum but uh for scaling Ethereum. Um today we unplug uh the first client I mean we were I mean we were using for first time uh ZK proof in northern in Ethereum somehow I mean this is I think historical uh thing today and what it means that this goes fast and now that's still early because I mean we just

unplug it there uh we are on time to set up the right uh incentives mechanism and to think in the right way. So I think that for me the takeaway is the importance of defining this protocol the having clarity in Ethereum. Um I think this is an important thing and this is part of a scaling Ethereum. Uh if we don't define uh the right uh incentive the right protocol for how the provers should be plugging in the network uh we risk in changing the values of the network. So I think this is important and it's the biggest takeaway that I'm taking from here.

>> Okay, awesome. Well, I think we could talk probably for hours and maybe we should actually. Uh, but yeah, I think we have to round it up here. So, thanks a lot to the panelists and thanks to the audience for being here on Saturday. [applause] >> Thank you all. >> All right, that concludes ETH proof day. We hope to see you all in CAN. Uh, there is a Devconnect happy hour happening right now. Um, hope to see you there, too. >> [applause] [music]

[music]