P2P.org Joins Monad as a Validator

<h3 id="introduction-how-l2s-think-about-zk-proof-generation-decentralization">Introduction: how L2s think about ZK proof generation decentralization</h3><p>The goal of this blog post is to add infrastructure providers’ point of view to the discussion of different methods on ZK proof generation decentralization. We found that this point of view is missing or misinterpreted by researchers and L2/ZK protocol creators. Since the decentralization mechanics are usually game-theoretic to some extent, the misconception of infrastructure providers’ behavior could lead to wrong conclusions, thus making the project not reaching its goal - proper reliable, censorship resistant and trustless system that we cherish so much in web3 (cherish less in recent years with surge of centralized L2s, but nevertheless, all of them <em>promise</em> to be properly decentralized one day and we <em>trust</em> them in our <em>trustless</em> industry).</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2025/04/Staking---ZK-proof-generation-2.png" class="kg-image" alt loading="lazy" width="904" height="174" srcset="https://p2p.org/economy/content/images/size/w600/2025/04/Staking---ZK-proof-generation-2.png 600w, https://p2p.org/economy/content/images/2025/04/Staking---ZK-proof-generation-2.png 904w" sizes="(min-width: 720px) 720px"></figure><p>It is hard to separate ZK proof generation decentralization from sequencer decentralization as both those parts of the stack should participate in the same tokenomics. But since we have shared sequencer protocols like Espresso, Astria, Radius and others, plus possible reluctance of L2 protocols to decentralize the sequencers, we will describe only separate decentralization of ZK proof generation.</p><p>We will present 3 articles regarding decentralization in ZK and experiments on proof generation parallelization. In the first one we will review staking tokenomics and its bad connectivity with the nature of the ZK proving process. The second article will focus on parallelization of proof generation tasks on different hardware. In the third article we will discuss the concept of idle GPUs that many protocols use as the cornerstone of their proof marketplace designs and the aggregation of aggregators problem in ZK space.</p><p>This article will not provide a definite answer to highlighted problems. The goal is to give additional data missing from other articles regarding this topic, combine them and emphasize on the fact that everything should be battletested and should not be presented as the best final solution while being only on paper. We encourage all protocols not to be afraid to change in the search of the perfect concept.</p><h3 id="taiko%E2%80%99s-numerous-experiments">Taiko’s numerous experiments</h3><p>The biggest practical research of this issue was done by the Taiko team that decided to make the 1st permissionless fully decentralized L2. For more than 1 year they have tested multiple setups: proof generation race, stake-based option, bond-based option and finally arrived at the stage with both proposer and prover role handled by the same entity. Let’s make a quick recap of all those tests and how they ended up with the current mainnet.</p><p><strong>Proof generation race.</strong></p><p>As the 1st step, Taiko started with the easiest solution. But due to the deterministic nature of ZK proof generation the race ended up with the clear single winner that took almost all of the proofs, so, the result was almost as centralized as current L2 solutions with 1 dominant player<strong>.</strong> Others were formally “on backup”, but in fact not present at all. It happened because the cost of running the operations is not compensated if you do not actively contribute to the chain's progress.</p><p>The stats from this testnet may show it otherwise with heavy centralization for Proposers and too beautiful pictures for Provers. We don’t want to get into conspiracy theories, we will just say that we were able to generate ZK proofs mostly at night, during the weekend, and by the end of the testnet when 3 main provers were not active. Nonetheless, the Taiko team made a good decision to test other methods since the community in discord was furious with this model.</p><figure class="kg-card kg-image-card kg-width-wide"><img src="https://p2p.org/economy/content/images/2025/04/Staking---ZK-proof-generation--1--1.png" class="kg-image" alt loading="lazy" width="927" height="527" srcset="https://p2p.org/economy/content/images/size/w600/2025/04/Staking---ZK-proof-generation--1--1.png 600w, https://p2p.org/economy/content/images/2025/04/Staking---ZK-proof-generation--1--1.png 927w"></figure><p><strong>Stake-based solution.</strong></p><p>The next attempt was a stake-based option with the active set of 32 provers and others beyond those 32 on backup. Usually Proof-of-Stake validator’s probability to produce the next block is equal to its share of the stake. But in Proof-of-Stake it is relatively easy to produce the next block, so validators do not have a scaling problem because of the number of blocks to produce (there is a scaling problem with constantly growing blockchain size overall, but it’s another one).</p><p>On the contrary, ZK proof generation is very demanding in computational power to generate a single proof, and if the prover's stake is growing, it should keep increasing the hardware capacities, otherwise it starts to get slashed. This is what happened in this testnet, and the amount of slashing was so big, that the best position was to be the 33rd prover (the 1st in non-active set) to receive blocks to prove and do the job without the fear of getting slashed. <strong>But then the stake grew (or others’ stake was slashed), prover ended up in the active set, got slashed, fell back, and it was a never ending cycle.</strong> As you can see, the system was enormously unstable, so Taiko decided to switch to other solutions.</p><p><strong>Proposer “buys” proofs.</strong></p><p>The idea is “if protocol can not handle it, let the invisible hand of the market do its magic”. <strong>In this solution each proposer can decide on where it can get the proof.</strong> At least this was for the first three weeks since mainnet was decentralized. But then the foundation announced “If you are proposing Taiko blocks, ensure you also prove your own blocks, or your liveness bond will be forfeited” also explaining this with “This change removes hook calls from the protocol for gas optimization and simplicity, as hooks are expensive”. Technically, it still can be two separate entities, but in fact the prover does not need the proposer and will always prove on its own.</p><p>Key aspects why Taiko permissionless decentralization works without both high congestion for proof submission:</p><ol><li>150 TAIKO tokens per each proof that are locked for 4 hours to dispute - a single entity needs a lot of TAIKO and ETH to proof all blocks in a day (<em>the numbers change with every network update</em>)</li><li>SGX proving - relatively complex technology which is hard to access and manage. This organically reduces the number of participants and prevents gas wars to submit the proof</li></ol><p>Nevertheless, from a community and tokenomics perspective there is a significant drawback to the model. With the current parameters 4 hours to return the bond and on average 2 proofs per minute only 72000 TAIKO tokens are being actively used for system functioning. In other words, 99.92% of circulating supply has no utility, apart from being used within DeFi and governance.</p><h3 id="other-protocols-discussions">Other protocols discussions</h3><p>In 2023 Starknet was actively discussing proposals on decentralization of their protocol on forum, so, let’s address the summary of the discussion. The Starknet protocol is divided into four layers: leader/proposer elections, consensus, proving, and L1 state updates. Starknet will use a variant of Tendermint. Starknet plans to use the chained proof protocol which is based on Mina’s design. It requires every block proposal to include a proof of a previous block.</p><p>Aztec’s testnet is underway, and in their initial series of blog posts they have created a design for stake-based sequencer decentralization protocol, while ZK proof generation will be outsourced. Sequencers are allowed to get the proof on external markets of their choice. They hope that the open market will provide the best quality and price.</p><p>Before the airdrop ZkSync also dropped a news bomb with a blog post and corresponding article about their thoughts on ZK proof generation decentralization. On a high level within the Prooφ described in the article corresponding to the post both staking and auction-based mechanisms are included, where staking is needed to slash provers if they send incorrect proofs. As for the auction part, a prover with the best bet (=lowest cost) wins, but gets paid the costs of the second price determined by the auction. At the same time the fee should always cover the cost of the proof generation for an auction to work.</p><h3 id="stake-based-solutions">Stake-based solutions</h3><p>We have described before how Taiko experimented with staking and went into mainnet with bonds instead. Overall, it makes some sense, but it also reduces the number of people that can use TAIKO as utility token, thus reducing its attractiveness to institutions and retail, since only a selected few can launch SGX prover and meaningfully utilize the token. Tokens are not only a financial or technological phenomenon, but also a social one, and engagement from as many participants as possible is crucial for project success, so, we will focus on a stake-based model of decentralization.</p><p>Sudden spikes of stake will not be possible to avoid, even by creating a hard cap on maximum stake, because the cap will not safe from the situation where several other provers lose their delegation, thus “promoting” the weak prover to get more proofs to generate while it does not have the required capacity. Some might argue “so slash them if they are not capable”, but constant slashing is exactly the reason why Taiko abandoned staking: this is bad delegators’ experience, and they will simply use other more safe protocols, for example Solana, where they don’t have slashing.</p><p>Let’s draw some possible scenarios</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2025/04/table1.png" class="kg-image" alt loading="lazy" width="2000" height="459" srcset="https://p2p.org/economy/content/images/size/w600/2025/04/table1.png 600w, https://p2p.org/economy/content/images/size/w1000/2025/04/table1.png 1000w, https://p2p.org/economy/content/images/size/w1600/2025/04/table1.png 1600w, https://p2p.org/economy/content/images/2025/04/table1.png 2000w" sizes="(min-width: 720px) 720px"></figure><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2025/04/table2.png" class="kg-image" alt loading="lazy" width="2000" height="563" srcset="https://p2p.org/economy/content/images/size/w600/2025/04/table2.png 600w, https://p2p.org/economy/content/images/size/w1000/2025/04/table2.png 1000w, https://p2p.org/economy/content/images/size/w1600/2025/04/table2.png 1600w, https://p2p.org/economy/content/images/2025/04/table2.png 2000w" sizes="(min-width: 720px) 720px"></figure><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2025/04/table3.png" class="kg-image" alt loading="lazy" width="2000" height="459" srcset="https://p2p.org/economy/content/images/size/w600/2025/04/table3.png 600w, https://p2p.org/economy/content/images/size/w1000/2025/04/table3.png 1000w, https://p2p.org/economy/content/images/size/w1600/2025/04/table3.png 1600w, https://p2p.org/economy/content/images/2025/04/table3.png 2000w" sizes="(min-width: 720px) 720px"></figure><p>Some suggestions might be:</p><ul><li>Slash only Operators - then Delegator will have to unbond, wait for N days, delegate again to another operator, possibly repeating the situation.</li><li>Even if there’s no unbond period, still, delegator will have to monitor the activity precisely, so, either the rewards should be good (and not absorbed by sequencer), or a delegator will find better opportunities elsewhere</li><li>“Buying” proofs elsewhere including from A &amp; B. Although A &amp; B benefit from C getting slashed, but buying elsewhere requires business details negotiations, setting up provers elsewhere, possibly syncing with the network - it might take a long time, not all operators might have everything setup</li><li>Decoupling leader selection from staking</li></ul><p>The idea in general should be like in the bonding schema: if the prover knows that it can’t make another proof in time, it should not be forced to do it by leader election mechanism. Nevertheless, with a big stake comes great responsibility, and this should be reflected in the user-related metrics, for example in APR. ZkSync’s “Proof” partially solves the issues, but several months later another whitepaper also addressed the problem using another auction method.</p><p>Succinct’s proof contest is an interesting approach that helps to internalize the competition between provers and free them from gas wars on Ethereum for their respective proofs to be accepted on-chain. The staked collateral will be used not only for potential slashing, but also in the reverse auction to win proofs. Provers will use a part of staked collateral to pay for a chance to win the next proof. To prevent payment wars, the size of the payment only determines the probability to win, but not the one with the highest payment wins.</p><p>Overall, this model seems like a fascinating approach that definitely should be tried within the Web3 industry to test how it can be potentially gamed. As we’ve seen before with numerous Taiko experiments, there were a lot of ideas that seemed to work well on paper, but in the end turned out as a disaster, so we only wish for protocols to be flexible in the new environment and evolve to new challenges.</p><h3 id="conclusion">Conclusion</h3><p>Taiko has tested many different decentralization setups for more than 1 year before coming to the current solution. Whatever design other protocols might choose - it is better to test it properly and figure out all mistakes before mainnet. Hopefully, when most of the rollups achieve stage 2 decentralization, stage 3 will appear with decentralized parts of the stack for censorship resistance, so that everyone could have the same access to the ecosystem as everyone else, and not by forcing transactions from L1.</p><p>Overall, we wanted to thank the Taiko team for enormous work on the forefront of L2 decentralization and we encourage other protocols to follow their steps. We also want to thank the Starknet and Aztec teams for taking an active discussion with the community about decentralization designs, and the ZkSync team for their paper and blog post on future decentralization steps. Also we want to reference some of Figment's related blog posts on L2 decentralization. They have similar thoughts, but we tried to make our contribution as well and make a research based on new data from 2024.</p><h3 id="references">References:</h3><p>Taiko vision (and impressions on them):</p><ul><li>Taiko changing complaints (twitter): <a href="https://x.com/bkiepuszewski/status/1798987014047670565?ref=p2p.org"><u>https://x.com/bkiepuszewski/status/1798987014047670565</u></a></li><li>Taiko proposer must be the prover as well:<a href="https://x.com/taikoxyz/status/1803838265046491409?ref=p2p.org"><u>https://x.com/taikoxyz/status/1803838265046491409</u></a>&nbsp;</li><li>Impressions on P2P’s participation in Taiko’s testnet №3 on Starknet forum <a href="https://community.starknet.io/t/starknet-decentralized-protocol-iv-proofs-in-the-protocol/6030/18?ref=p2p.org"><u>https://community.starknet.io/t/starknet-decentralized-protocol-iv-proofs-in-the-protocol/6030/18</u></a></li><li><a href="https://taiko.mirror.xyz/qvZV19UrPOPbWwJ3hwdppNlnqn4nM_LXoS1uztKs6DE?ref=p2p.org"><u>https://taiko.mirror.xyz/qvZV19UrPOPbWwJ3hwdppNlnqn4nM_LXoS1uztKs6DE</u></a>&nbsp;</li><li>The update where prover &amp; proposer were united <a href="https://taiko.mirror.xyz/Od8CVUstKAr6bvuHac5DHuv9jdePOhW6pb5pNOr3VX0?ref=p2p.org"><u>https://taiko.mirror.xyz/Od8CVUstKAr6bvuHac5DHuv9jdePOhW6pb5pNOr3VX0</u></a>&nbsp;</li><li>Proof generation race stats from ZKPool <a href="https://data.zkpool.io/public/dashboards/Aebs8y0nZ9w20wokJeFlIjWsi9DQcTVOzmBDpQXe?ref=p2p.org"><u>https://data.zkpool.io/public/dashboards/Aebs8y0nZ9w20wokJeFlIjWsi9DQcTVOzmBDpQXe</u></a>&nbsp;</li><li>Taiko governance <a href="https://taiko.mirror.xyz/9lW3JdFnMJGtoPbmXqFS32XNxf_iK0VDx0vGWk2K7Eo?ref=p2p.org"><u>https://taiko.mirror.xyz/9lW3JdFnMJGtoPbmXqFS32XNxf_iK0VDx0vGWk2K7Eo</u></a>&nbsp;</li></ul><p>Starknet vision:</p><ul><li>Overview <a href="https://community.starknet.io/t/starknet-decentralized-protocol-i-introduction/2671?ref=p2p.org"><u>https://community.starknet.io/t/starknet-decentralized-protocol-i-introduction/2671</u></a></li><li>Leader election <a href="https://community.starknet.io/t/starknet-decentralized-protocol-ii-candidate-for-leader-elections/4751?ref=p2p.org"><u>https://community.starknet.io/t/starknet-decentralized-protocol-ii-candidate-for-leader-elections/4751</u></a>&nbsp;</li><li>Consensus <a href="https://community.starknet.io/t/starknet-decentralized-protocol-iii-consensus/5386?ref=p2p.org"><u>https://community.starknet.io/t/starknet-decentralized-protocol-iii-consensus/5386</u></a>&nbsp;</li><li>Prover decentralization <a href="https://community.starknet.io/t/starknet-decentralized-protocol-iv-proofs-in-the-protocol/6030?ref=p2p.org"><u>https://community.starknet.io/t/starknet-decentralized-protocol-iv-proofs-in-the-protocol/6030</u></a>&nbsp;</li><li>Checkpoints for fast finality <a href="https://community.starknet.io/t/starknet-decentralized-protocol-v-checkpoints-for-fast-finality/6032?ref=p2p.org"><u>https://community.starknet.io/t/starknet-decentralized-protocol-v-checkpoints-for-fast-finality/6032</u></a></li><li>Chained proof protocols <a href="https://community.starknet.io/t/starknet-decentralized-protocol-vii-chained-proof-protocols-braiding/18831?ref=p2p.org"><u>https://community.starknet.io/t/starknet-decentralized-protocol-vii-chained-proof-protocols-braiding/18831</u></a>&nbsp;</li><li>Tendermint for Starknet <a href="https://community.starknet.io/t/tendermint-for-starknet/98248?ref=p2p.org"><u>https://community.starknet.io/t/tendermint-for-starknet/98248</u></a></li><li>Summary <a href="https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693?ref=p2p.org"><u>https://community.starknet.io/t/simple-decentralized-protocol-proposal/99693</u></a>&nbsp;</li></ul><p>ZkSync vision:</p><ul><li><a href="https://zksync.mirror.xyz/z3GvALZwgxN5CrU2kvHV1LuPf14GHc2Ul5dGDC8AZzs?ref=p2p.org"><u>https://zksync.mirror.xyz/z3GvALZwgxN5CrU2kvHV1LuPf14GHc2Ul5dGDC8AZzs</u></a>&nbsp;</li><li><a href="https://arxiv.org/search/cs?searchtype=author&query=Wang%2C+W&ref=p2p.org">Wenhao Wang</a>, <a href="https://arxiv.org/search/cs?searchtype=author&query=Zhou%2C+L&ref=p2p.org">Lulu Zhou</a>, <a href="https://arxiv.org/search/cs?searchtype=author&query=Yaish%2C+A&ref=p2p.org">Aviv Yaish</a>, <a href="https://arxiv.org/search/cs?searchtype=author&query=Zhang%2C+F&ref=p2p.org">Fan Zhang</a>, <a href="https://arxiv.org/search/cs?searchtype=author&query=Fisch%2C+B&ref=p2p.org">Ben Fisch</a>, <a href="https://arxiv.org/search/cs?searchtype=author&query=Livshits%2C+B&ref=p2p.org">Benjamin Livshits</a> Mechanism Design for ZK-Rollup Prover Markets <a href="https://arxiv.org/abs/2404.06495?ref=p2p.org"><u>https://arxiv.org/abs/2404.06495</u></a>&nbsp;</li></ul><p>Aztec vision:</p><ul><li><a href="https://forum.aztec.network/t/on-proving-marketplaces/5218/5?ref=p2p.org"><u>https://forum.aztec.network/t/on-proving-marketplaces/5218/5</u></a>&nbsp;</li></ul><p>Figment vision:</p><ul><li>Proof supply chain <a href="https://figmentcapital.medium.com/the-proof-supply-chain-be6a6a884eff?ref=p2p.org"><u>https://figmentcapital.medium.com/the-proof-supply-chain-be6a6a884eff</u></a>&nbsp;</li><li>Decentralized Proving, Proof Markets, and ZK Infrastructure <a href="https://figmentcapital.medium.com/decentralized-proving-proof-markets-and-zk-infrastructure-f4cce2c58596?ref=p2p.org"><u>https://figmentcapital.medium.com/decentralized-proving-proof-markets-and-zk-infrastructure-f4cce2c58596</u></a> </li></ul>