New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Economic security behind ZK proof generation

ETHBerlinMon, Jun 16, 2025, 03:30 PM · 11:35

The economic security behind zero-knowledge proof generation is quite an under-explored topic. Several prover networks and marketplaces have emerged in the past 12 months, most of them relying on a slashable financial bond, but more sophisticated design mechanisms ensuring security, accessibility and decentralization are yet to be seen.

Transcript

Hi, everyone. My name is Norbert. I'm from ZK Cloud, and I want to talk about the economic security behind ZK Proof Generation. So just quickly before we dive in, in the past one year, there's been quite a few prover networks, prover marketplaces that went live, and most of them simply use staking or some kind of financial commitment or financial bond as economic security. However, very often, this limits accessibility, and I think more nuanced and sophisticated mechanisms are needed to ensure accessibility, security, and decentralization of these marketplaces.

So let's dive in. The economic commitment of POS and POW, the Proof of Stake and Proof of Work networks. So basically, Proof of Stake networks need modest hardware. Because of that, validators basically need to stake, put up some mandatory stake to ensure security and liveness. However, for Proof of Work networks, as we know, you need much more powerful hardware to stay competitive, and redundancy is basically enshrined into the network to ensure security and liveness.

Redundancy means basically this, in another verb, basic computation is an inherent part of network security. While for proof generation, it's a little bit different type of animal, because you need substantial compute capacity to generate proof efficiently. Security comes from the underlying math, zero knowledge, and this is basically why do we need decentralization. It's for liveness, and for liveness, you can either do redundancy or economic security to ensure that proofs are delivered consistently. But both of them have trade-offs.

Redundancy means higher cost of proving, because at the end of the day, someone has to pay for the basic compute, while a mandatory stake increases the entry barrier for anyone who wants to join the network and contribute this compute power. So we need more nuanced approaches to balance between liveness guarantees and sufficiently low barrier of entry. Now, let's see proof mining versus Bitcoin mining a little bit. Both require substantial compute. We could even say that hardware is basically the form of economic commitment in this case, but this type of compute serves different purposes.

For Bitcoin mining, basically the compute power secures the network, and redundancy, as mentioned, is integral to network security. It's very similar to proof racing, where every prover races to complete the job, but only the fastest one gets rewarded. It includes a lot of basic compute. Proof racing includes also a lot of basic compute, so it can never be the cheapest option, actually. But proof mining serves a different purpose.

So basically, putting the privacy aspect aside, making data or computation verifiable without re-execution provides a lot of bandwidth for scalability and efficiency gains. But for that, basic compute increases the cost of proving a whole lot, and since the goal is to minimize the computing cost, basic compute conflicts this overall. And minimizing the compute cost is important because several use cases have not been economically viable because of the high cost of proving. Now, we are over that mostly, I think. It's sufficiently cheap, and proof systems are sufficiently performant, or are getting there.

So we need to remove basic compute. In order for removing that, the common answer was usually staking, and then let just one single prover generate the proof. Now, the purpose of economic security in the form of staking would be severe resistance, to ensure severe resistance, network liveness, and security. It means you lock up a certain stake, which creates a participation cost. It prevents spawning unlimited fake identities.

So basically, serves as severe resistance mechanism. Obviously, the stake has to be high enough and has to exceed malicious profit potential. But then, again, you can slash this collateral that's put up as a stake. It discourages dishonest behavior, and it could serve as a guarantee for timely proof delivery, especially if we consider that, for example, the finality of decay roll-ups or validity roll-ups depends on these proofs. Now, it also comes with some challenges, obviously.

There is a higher entry barrier because you have the high hardware costs for being able to generate the proof, plus you have the staking requirement. This favors more wealthy participants potentially and increases the risk of centralization. There is also an opportunity cost. Locked-up tokens cannot be used elsewhere, so it impacts profitability, and especially if we consider that there is a race to the bottom in proving costs. And also, there is some technical complexity there because the flashing logic is not necessarily trivial for universal prover networks.

And by universal prover networks, I mean a network like ZKCloud, where you can bring your own prover binary, deploy it to the network, and use the underlying prover nodes of the network to have proof generated for your binary. In this case, it's non-trivial to decide whether you posted a malicious binary, so we shouldn't punish the prover nodes, or it was the prover who didn't do the job correctly. But still, so these are some aspects to consider. Then there is, if not staking, then we could consider restaked economic security. However, for restaking, there is a tension between individual rational behavior and system security, because operators are incentivized to maximize their returns by restaking to as many AVS services as possible.

AVS mostly being used in eigenlayer, sorry, in eigenlayer, so these are actively validated services. And some of the prover networks or marketplaces have been building on eigenlayer as AVS is using restake security, so I think it's important to talk about this. There is a security dilution because operators are incentivized to maximize returns. It means each additional restaking commitment dilutes the economic security behind every single service that it supports. So individual optimizations actually may create systemic risks, and we can also quantify this dilution.

This is taken from last week from eigenlayer's dashboard. So the formula to quantify dilution would be to sum up the total TVL of each AVS that's running on eigenlayer and divide it by the total eigenlayer TVL. So currently there is a total TVL of $11 billion locked up in eigenlayer. It's used on 45 AVSs, but if you add up the total TVL of these AVSs individually, it comes to $150 billion. So it means 13.

2 AVSs are using the same single dollar value to back their assets. So when someone says, hey, I have $10 billion of restake security behind me, that's bullshit, basically. Divide it by 13.2, and that's the actual economic security there. And talking about cascading effects, if there is a slashing event and the horizontal shared security and the effects of such an event is a different topic.

It's just worth considering that whoever is looking to outsource, proving to some network built on using economic security, restaked economic security, it's just worth knowing about. So what are the alternatives to staking or restaking? And we've been thinking quite a lot about this, and I'm just throwing out ideas. We need more research on this. But basically, you could take hardware as economic commitment as the basis.

It could prevent CBLs in case of high network utilization, because then multiple CBLs cannot use the same hardware and still generate all the proof that they are assigned. But what if the network utilization is low? In that case, they could do that. So you need some mechanism to prevent that. And for that, we figured it could be a proof of capacity type of task.

Whenever they want to join the network, they are loaded with these tasks fully for an activation period. It could be several days. As soon as they have proven capacity, they can join the network. But then at times of low network utilization, you could fill up their bandwidth with these tasks to ensure that they can actually – they cannot spin up multiple CBLs and that they can still – you can still test that the capacity is there for each and every prover that's registered in the network. Failure to complete these would mean – would result in a forced exit from the network.

And then these two could further be combined with some reputation system, where ratings are performance-based and the reputation must be continuously proven and maintained. So the reputation score is basically kept to ensure fairness, because this would allow new joiners to reach same levels of reputation as old folks being already in the network. The max score should be reachable over a period of time. And then the score should be dynamically decreasing if performance drops. And off of this, you could even build a reward system, which, for example – which includes a reputation-based task allocation, meaning rewards would be dependent on reputation.

Poor performance directly means loss of potential revenue in this case. So definitely there are more – there's more research needed on this front, but combining the above elements, we do see that you could design a system that incentivizes honest behavior, ensures honest nodes can stay in the network long-term. It minimizes the time CBLs and malicious nodes can spend in the network. It forcibly removes non-delivering prover nodes or creates staying in the network sufficiently costly so that they would exit. It provides sufficient security and liveness guarantees, consistent proof delivery without the elevated entry barrier and systemic risks.

So, yeah, I think I'm just at time. Thank you very much. We released a full blog post about this. If you're curious about it, blog.vkcloud.

com. And thank you.

Automatic transcript — names and jargon may be misspelled.