Subscribe to Zeeve
Zeeve is an enterprise-grade low-code Blockchain Infrastructure-as-a-Service platform, compliant with ISO, SOC2 Type II, and GDPR. As the leading provider of Rollups-as-a-Service, dedicated node infrastructure, and hosted subgraphs, Zeeve ensures 24x7 monitoring, Enterprise SLA, 99.9% uptime, and management dashboards for a secure and scalable web3 infrastructure.
<100 subscribers
Share Dialog
Blockchains have evolved faster since 2022, when it became easy to launch modular rollups using popular open-source frameworks. However, the issue of scalability and security still lingers, which is why modular, layer-2 solutions like ZKSync Elastic Chains were developed to leverage ZK proofs.
As the need increases for ZK chains to become more “elastic” (adapting dynamically to transaction loads and security needs), the underlying ZK proof generation infrastructure, which is called the prover, must evolve too. But what exactly are provers? Are Decentralized ZKsync Provers for Elastic Chains really the best approach? This article breaks down the pros and cons.
A Prover is that component of a ZK chain that actually generates Zero-Knowledge proofs. The Prover aggregates multiple transactions into a batch off-chain and then computes the proof for the batch. This proof mathematically shows all the included transactions within that batch are valid and follow the rules of the blockchain (i.e., correct balance checks, no double spending) with minimal to no reveal of transaction data.
So, provers are like advanced auditors that confirm each exchange or calculation on the blockchain. They permit validators and clients to affirm the trustworthiness of tasks without seeing the delicate subtleties. This fastens verification as well as reinforces security.
To make sense of this critical component, here is how it assembles with other layers:
Users submit transactions to the rollup network, which are received by the Sequencer.
⬇️
Sequencer Aggregates and orders transactions from users into batches.
⬇️
Batched transactions are then received by Off-chain ZKVM of the Rollup for Execution and state transitions computation.
⬇️
Transaction data/commitment to the data is posted to a DA layer, if needed.
⬇️
Prover takes the executed transactions and generates a zero-knowledge proof.
⬇️
The proof, along with necessary data or commitments, is submitted to the Final Settlement Layer
Throughout this process, a Decentralized ZKsync Provers for Elastic Chains can offer unique advantages by distributing proof generation more broadly rather than leaving it centralized.
Let’s come back to ZKsync now.
ZKsync has become well known by emphatically expanding transaction throughput while lowering expenses and the provers assume a vital part in this cycle. Right now, ZKsync and ZK stack chains are run in a semi-concentrated way. This means that while the protocol benefits from the proficiency of zero-knowledge proofs, the prover model is still controlled by a single entity or a group of entities. In ZKsync’s case, this is ‘Matter Labs.’
They currently use Boojum Prover which is based on the STARK technology that reduces hardware footprint and cost of ZK proving (also optimized for future decentralization). Though Boojum generates STARK proofs, for the final proof submitted to Ethereum, a SNARK proof is used for its succinctness. Recursive proofs here come into play. Recursive means proof of proof. Multiple STARK proofs that are generated from batches are recursively converted into a single proof, which is then converted into SNARK for final verification on Ethereum.
This centralization, while efficient, comes with the following trade-offs:
During times of high network demand, a centralized prover setup may create potential bottlenecks as transaction volume increases, even with Boojum.
If the central prover is compromised, the entire network might be at risk.
Centralized systems may also stifle experimentation with new protocols and technologies that could further enhance performance or security.
In light of these issues, many are looking at ways to implement Decentralized ZKsync Provers for Elastic Chains as the next phase in scaling and securing ZK-based networks. After the recent ZK Stack’s prover decentralization effort, Fede Intern, a popular blockchain analyst on X, criticized ZKstack for its previous difficulty of running a prover or delegating the prover to another entity in his tweet.
So, what does decentralizing ZKsync provers mean? In essence, Decentralized ZKsync Provers for Elastic Chains involves distributing the proof generation process across a network of independent nodes rather than relying on a single entity or a small group of centralized networks. One way to decentralize is to set up a network where multiple independent nodes are responsible for generating proofs. Each node can work on different parts of the overall computation, and together, they contribute to the final verification process.
Below are the two ways possible in 2025 to decentralize proving for ZKsync Elastic Chains.
1. ZK Stack x Lagrange
Recently ZKsync and Lagrange partnered for the first ever decentralized implementation of ZKsync prover.
Lagrange Labs is known for its Zero-knowledge proving infrastructure, and this partnership with ZKsync is introducing a decentralized prover network into the ZKsync/ Elastic Chain ecosystem. Now, ideally, multiple entities will be able to run their prover nodes for generating ZK proofs for transactions across the ZKsync network of Elastic chains.
Here’s How it will work with any rollup Elastic chain:
First, transactions are batched on the ZK stack rollup and then processed by an LPN-optimized proxy prover for efficient submission.
Second, the proxy prover sends these transaction bundles to the LPN instead of the centralized ZK stack prover.
Within LPN, operators bid through an auction system managed by the Lagrange Gateway to process these transactions.
Winning operators generate valid ZKPs—bringing Decentralized ZKsync Provers for Elastic Chains to life by replacing a central bottleneck.
More details on it can be found here.
The Hardware requirement to run a prover node is also gonna be consumer-grade, which will again reduce participation barrier. That’s a feature of Boojum Prover btw, and it can run on GPUs with 16GB of RAM. On Eigen Layer, where the Lagrange network is actually deployed, node runners can ‘restake’ their ETH to act as provers.
The proof generation and verification will be a two-step process on a broad level:
Commit Phase: When a batch of transactions is ready, provers commit to generating proof for this batch. This usually involves submitting a hash of the proof they intend to generate or a unique identifier. This prevents race conditions and ensures only one prover will ultimately be rewarded for proving it.
Verification Phase: After the commit phase, there’s a waiting period to allow all commitments to be made. Once this period ends, provers submit their full proofs. These proofs are then checked by the smart contract on Ethereum, and if they are valid, the state is updated accordingly on L1. The prover is rewarded.
The prover decentralization is already underway. But ZKsync also has a plan to decentralize validation as well. Potentially, these could include community governance or a voting mechanism on who can validate the proofs. It’s going to support multiple proof types in the coming days, catering to different chain needs. Also, there could be self-registration for the provers in the coming days. As this develops, Decentralized ZKsync Provers for Elastic Chains might become the standard for future ZK rollup deployments.
Chances are, the Lagrange network will be integrated with ZK Stack natively for developers to choose them at the time of deployment. If this is done, it will be the first of its kind for any big rollup framework to decentralize their proving in practice.
Fermah is a universal proof market capable of generating proofs for any proof system, chain or VM, including those used by ZKsync Elastic chains.
Users can send proof requests to Fermah, which then distributes these requests to its network of provers. And as they follow a marketplace model, the proof generation cost is cheap.
But unlike Lagrange, which utilizes a bidding system, Fermah acts as an intermediary and distributes proof requests across its network without necessarily involving in the auction.
Fermah also uses EigenLayer operators to kickstart its network of prover nodes. These operators already have a stake in Ethereum, which gives an initial trust layer.
Both the two methodologies to decentralize provers has a reward system to urge more people to participate in proof generation, making Decentralized ZKsync Provers for Elastic Chains more accessible. Rewards include transaction fees, tokens, or other economic incentives.
Opting for Decentralized ZKsync Provers for Elastic Chains could bring several key benefits, such as:
A decentralized protocol is innately stronger and less prone to hacks. By dispersing the proof generation to multiple validators, the framework limits the risks related to a single point of failure. Multiple provers with geographic distribution introduce redundancy. This make sure if one prover fail, others can continue operations.
Elastic chains, by design, need to accommodate changing transaction volumes. A decentralized prover has parallel processing and elastic scalability, hence it can adapt to the varying loads more effectively by adding more nodes as demand increases or reducing the nodes when demand diminishes. This dynamism is necessary for efficiency and productivity without sacrificing security.
As a decentralized prover network is designed to work with multiple protocols/ chains, it enhances interoperability without central coordination. Plus, this decentralization effort often lead to standardization in proof generation.
A decentralized market of provers can lead to competitive pricing for proof generation. This can drive down costs and make overall cost per transaction cheaper for end users.
While Decentrakized ZKsync Provers for Elastic Chains offer clear benefits, it’s fundamental to understand that it probably won’t be the best answer for each elastic chain. The context, first of all, is fundamental. Only one out of every odd blockchain application requires a similar degree of decentralization. For certain networks, especially those dealing with less complex transactions or working in a controlled ecosystem, a semi-concentrated prover framework might get the job done. The above decentralization could present pointless intricacy and cost where more straightforward arrangements could work similarly as well.
Furthermore, decentralization incurs some costs. There are expanded coordination difficulties and potential execution compromises. At times, the additional inactivity from organizing numerous nodes could counterbalance the advantages of decentralized security. Each network should gauge the advantages of decentralization against its one-of-a-kind functional prerequisites and requirements.
In initial stages where a centralized prover will simplify development, testing, etc for quicker iterations and easy management. This could be cost effective also.
Private/ permissioned use cases where trust is established among known entities. Here public verifiability is less critical. Hence Decentralized ZKsync Provers for Elastic Chains might be unnecessary.
Projects might start with a centralized prover and transition to a decentralized model as it matures. If you see, ZKsync’s effort with Lagrange and Fermah’s integration with ZK Stac are examples of this transition.
Zeeve Rollups-as-a-Service introduces the necessary tooling and support that you need to deploy your own ZKsync Elastic Chain and integrate provers using the ZK Stack. Launch your testnet in couple of clicks and then move into mainnet when you are ready. Zeeve RaaS offers over 45+ additional integrations for every elastic chain launched on the platform. With ongoing management, 24/7 monitoring, analytics, and strict security and data compliance laws in place, you are always game for the big rally.
Zeeve
