State of the Proving Infrastructure Landscape - 2024Q3

Nov 20, 2024

If you are thinking about building on Gevulot, register a key to get access to Devnet for free proof generation and verification. Or fill out this form if you are interested in joining the network as a prover node operator.

TL;DR

In our current report, we explore new projects and developments in the proving infra landscape, as well as the industry-wide collaborative efforts that are taking shape and have the potential to benefit the entire industry by making proof outsourcing seamless. In addition, we discuss workload allocation mechanisms, diving into the advantages and trade-offs of the different approaches, and the ongoing prover decentralization efforts in the L2 landscape.

Recap of Q2

In our latest report for Q2, we took a general outlook on how the concepts around prover decentralization evolved in 2023 and early 2024. We mapped the proving infrastructure landscape identifying around 20 projects, among which are several prover networks, proof markets, and centralized proof providers. We went on further analyzing them to better understand their architecture, specifics, and what they dominantly focus on within the proof supply chain.

We’ve learned that most prover networks are heavily centered around “in-house” products, such as zkVMs, and coprocessors, or around specific proof systems they support, and aim to serve the proof demand coming from the users of those. We have categorized them as demand-focused proof providers. One thing they have in common though is that they need to source compute from somewhere.

On the other hand, aggregators of proof demand also started to emerge, even though very few. Since they can generate proofs for any proof system across the board, they can efficiently supply compute to the demand-focused prover networks mentioned above, but serve any ZKP demand directly as well. Therefore we categorized them as supply-focused prover networks. Gevulot’s ZkCloud falls into the latter category: it is the first universal proving infrastructure for ZK.

Now let’s look at how the proving landscape evolved in Q3.

Decentralization efforts among validity and ZK-rollups

In the past months, multiple initiatives have been kicked off targeting prover decentralization of ZK- and validity rollups. In our view, these are real milestones for the entire L2 ecosystem.

Aztec’s ProverNet contest

In early August, Aztec announced a Request for Integration for provers, with the purpose of testing decentralized proof outsourcing. Projects interested in generating proofs for Aztec Network were invited to participate in ProverNet, a permissioned testnet for provers, incentivized through a contest. The contest took place in the early days of September with participation from around 15 teams.

Why is this important? All rollups are currently generating proofs in a centralized way, therefore prover decentralization is a key component for advancing the scalability, security, and decentralization of zk-rollups. Aztec has been committed to launching as a decentralized network from day one. Their ProverNet and the subsequent contest mark a very significant step for the entire L2 landscape, as this was the first live test of permissionless proof outsourcing.

Let’s go through the two tracks teams could participate in, and their outcomes:

Running an Aztec prover node as is: in this track the node automatically monitors unproven blocks, re-executes the transactions, internally orchestrates proof generation via the prover agents up to the final root proof, and submits it to L1. This track targeted all participants.
- Outcome: Gevulot won in proving speed, and tied in the number of proven blocks with three other teams. The tie occurred because these four teams managed to prove each Aztec block within the given time window, but Gevulot had the fastest average proving time per block:
  - Gevulot (avg time 419s),
  - Marlin (avg time 430s),
  - Lagrange (avg time 483s),
  - EmberStake (avg time 604s).
Building custom integration with existing prover infrastructure: this track focused on prover networks and proof markets to integrate the Aztec prover node with their infrastructure, through building custom interfaces between the orchestrator and the prover agents (the prover nodes of the prover network or marketplace), or building a custom implementation of the orchestrator interfacing with those prover agents.
- Outcome: Gevulot won the custom integration track.

We’ve released a detailed blog post on our journey related to Aztec’s first ProverNet, including challenges and lessons learned.

Prover decentralization of ZKsync Era

ZKsync announced a multi-phased decentralization process for its proof generation in June 2024. The initiative aims to create a more scalable and resilient network by opening the prover pipeline to any proof provider, reducing reliance on any single entity. However, this will not only benefit ZKsync Era but also any other chain building on the ZK Stack.

As of September 2024, ZKsync has launched the Prover API, allowing anyone to generate proofs and verify them against ZKsync through endpoints. This permissionless approach increases the security of ZKsync and contributes to a more decentralized proving ecosystem.

As per the initiative’s roadmap, participants start with integration, generating proofs for real batch inputs and verifying them against ZKsync via the endpoints. This is followed by real-time proof verification, and then live proving throughout a test period, after which successful proof providers become an integral part of ZKsync’s proving.

Both of these initiatives are significant advancements in prover decentralization. Building a decentralized network ourselves, at Gevulot, we are dedicated to supporting the decentralization efforts of any ZK-rollup in any ecosystem, providing fast, decentralized, and reliable proof generation.

New launches in Q3

Now, let’s look at some interesting developments and launches announced in Q3. We’ve listed the most notable ones below.

RISC Zero announced Boundless, their verifiable compute layer in September. Boundless enables verification of computations without re-execution across various blockchains. As opposed to Bonsai, where proofs are generated in a centralized manner, Boundless will include a decentralized prover network that can scale dynamically with demand and will be paired with a ZK-mining type of incentive mechanism. Boundless initially supports RISC Zero’s in-house zkVM and according to the announcement, alternative zkVMs may be supported later. Boundless is in an early testing phase, with the next step being the launch of a public testnet, however, the timeline has not been published yet.

Fermah exited stealth mode in September and announced building a prover network, and at the same time launching a permissioned devnet. As per their dashboard, the devnet had 16 AVS Operators that generated about 22K proofs at the time of writing. The network is backed by re-staked economic security through Eigenlayer. Fermah’s Matchmaker takes care of allocating proving jobs to Eigenlayer Operators. The workload allocation mechanism is simple: the Matchmaker runs through the list of available Operators and assigns a given task to the first one that has a compatible hardware configuration, even though it is not specified what defines the order of Operators in the list. The network aims to allow proof generation for any proof system and currently supports provers, such as SP1, Jolt, and RISC Zero zkVM. The minimum hardware specs needed for operators to join the devnet are 8 vCPUs, 16GB RAM, and at least 50 GB SSD.

Cysic Network launched its testnet in Q3, providing proof generation and verification for users. As per their whitepaper, various hardware owners can join the network as compute providers, from GPUs and ASICs to laptops and other consumer-grade hardware can contribute compute resources. Users can initiate proving tasks to the network by submitting a transaction on the underlying blockchain. Cysic Network, designed with a dual token model, is one of the very few prover networks (if not the only one) that incorporate proof-racing in some form: a certain number of provers are randomly selected to compete for the assigned task. However, the random selection in Cysic’s case also considers the number of tokens held by the prover nodes, allowing richer entities to have a higher probability of being selected to process proving tasks. According to the dashboard, 124 users (called projects) have submitted ~6K tasks since the launch of the testnet.

Polyhedra Network launched its proving service, Proof Cloud in July, in close collaboration with Google Cloud. The service exclusively uses Google’s infrastructure to generate proofs and supports multiple proof systems, including Polyhedra’s own Expander, as well as Plonky3 and Gnark. The permissioned beta version of the service is currently live, and based on the Proof Cloud explorer, it is dominantly generating proofs for deVirgo, the proof system used by Polyhedra’s zkBridge to prove Ethereum’s full consensus.

Gevulot has started onboarding prover node operators to its scalable, production-ready network, Firestarter. Gevulot is building ZkCloud, the first universal proving infrastructure for ZK. It supports any proof system and allows users to generate proofs at a fraction of the cost. Gevulot’s v network, the Devnet has been live since March 2024, and based on the dashboard it generated over 2.3 million proofs for various different prover programs but it was still lacking scalability. Firestarter has been designed to scale to hundreds or thousands of prover nodes dynamically as demand increases. It is the end-to-end implementation of ZkCloud, just running in a permissioned way: we are running all validator nodes ourselves at Gevulot. On the other hand, proof generation is already powered by a decentralized infrastructure, and prover node operators are incentivized to dedicate compute resources to Gevulot Firestarter.

Major collaboration in the proving landscape: ZkBoost

Competition is useful but fragmentation needs to be addressed. With more and more proof providers launching, it is equally important to strengthen the collaborative efforts that break down fragmentation, remove unnecessary complexities for users, and benefit the overall ZK and proving landscape. ZkBoost, an initiative kicked off by Gevulot in July, is a great example of industry players uniting for a common goal.

The ZkBoost Consortium launched in September 2024 with the aim to introduce a standardized API for zero-knowledge proof generation. The project, backed by 42 companies including the leading ZK-rollups in the space, focuses on abstracting away the complexity of outsourcing ZK-proving. The goal of this collaboration is to develop ZkBoost as a neutral, open-source software, and public good.

ZkBoost will function as a universal adapter, connecting various sources of proof demand (such as Layer 1 and Layer 2 solutions, co-processors, and ZK bridges) with proving services through a standardized interface. It also addresses fragmentation in the proving infrastructure landscape: by providing a single, standardized API for accessing all proving options, it can significantly reduce the technical overhead for developers by removing the need to manage various integrations. ZkBoost allows projects with ZKP demand to manage their proof supply chain through a single integration point, dynamically selecting proving services based on their priorities, be it redundancy, proving speed, or cost.

The forming of the ZkBoost Consortium and the collaborative effort of its members is a significant milestone in creating a more robust ZK ecosystem and improving the UX in sourcing proofs for any project in any ecosystem. In future editions of our report, we will follow how the collaboration around ZkBoost evolves.

Analysis of workload allocation mechanisms

The workload allocation mechanism of prover networks and marketplaces is a key protocol design component, and greatly affects other elements of their mechanisms. In this section, we provide a high-level overview of the most common workload distribution methods, with emphasis on how they impact decentralization. Centralization is not an issue on its own, but rather because it may introduce additional risks, and create an environment where it is very easy for any dominant entity to exercise censorship or control the cost structures of proof generation.

Auctions

Auctions are often considered the best-suited solution to drive down costs, but do they truly serve decentralization? The reality is more complex.

Auction-based workload allocation in decentralized proving seems to be a logical solution but it actually reveals significant centralization risks. While auctions can efficiently price proof generation services and theoretically reward the most cost-effective provers, they can easily devolve into destructive competitive dynamics.

Prover undercutting is real, and if provers engage in price wars, they can drive fees below sustainable levels. This creates a "race to the bottom" where only the most capitalized entities can survive extended periods of no profit, or even generate proofs at loss. Wealthy entities can strategically outbid competitors, creating proving monopolies, and leading to centralization. This also applies to complex mechanisms, such as double auctions, where the cost is still a dominant factor in the algorithm matching sellers to buyers.

The result is a mechanism that, while appearing competitive, might actually accelerate centralization as resource-rich entities leverage their capital advantages to dominate the prover network or marketplace.

Order book-based mechanisms

Order book-based workload allocation presents a market-driven approach with mixed implications. In short, in this mechanism, proof requesters indicate the amount they are willing to pay for a certain proof while provers for how much they are willing to generate the proof. However, the actual proving will only start if there is a match.

While this mechanism allows for transparent price discovery, in terms of centralization, order book-based workload distribution comes with very similar risks as auctions. Resourceful entities can effectively control the market by absorbing demand at any price point, creating artificial barriers to entry for smaller participants. The resulting market dynamics can lead to unhealthy competition and economics that favor concentration of power rather than distributed participation.

Proof racing

In the case of proof racing, all prover nodes compete to generate the proof, but only the fastest one gets rewarded. It introduces an element of competition that inherently favors entities with access to more advanced compute resources. This creates a natural monopolistic tendency where the most powerful entities consistently win races, effectively centralizing the network. Moreover, proof-racing introduces systemic waste: since multiple provers work on the same proofs simultaneously, significant computational resources are spent on redundant work.

Theoretically, this mechanism offers the lowest risk of liveness failure, however, the redundant (or wasted) computation required by racing, creates excess costs that must be absorbed in the network, typically leading to higher fees for end users.

Stake-based lottery

Stake-based lottery systems attempt to introduce fairness through randomization, but in this case, it is weighted by stake size. By randomly selecting provers with probability proportional to their staked tokens, it creates a somewhat fairer system that doesn't exclusively reward computational power or aggressive pricing strategies. This can encourage broader participation and reduce the intense competition seen in other mechanisms.

However, the fundamental advantage of wealthy entities remains: they can simply acquire more stake to increase their selection probability. While less direct than auction-based or compute power-based centralization, the end result may well be similar: entities with greater capital can effectively control a disproportionate share of proving opportunities, increasing centralization.

Random selection

Among all approaches, random selection emerges as perhaps the most neutral mechanism to maintain decentralization, though it presents its own set of trade-offs.

The primary advantage lies in its natural resistance to centralization pressures: by removing economic and computational advantages from the selection process entirely, neither capital nor computational power can directly influence selection probability. Additionally, the simplicity of random selection makes it more resistant to gaming or manipulation strategies that other mechanisms may be subject to.

However, the mechanism separates selection from performance capabilities. To ensure high performance in proof generation and to optimally allocate work to provers, the random selection must be paired up with design components that mitigate possible drawbacks, and allow it to maximize its efficiency. This may include establishing certain minimum hardware requirements across the board, to ensure any randomly selected prover node can meet the same performance standards, and efficiently generate proofs.

This is how we have designed ZkCloud at Gevulot: maximizing liveness, decentralization, and censorship resistance through random selection, while ensuring that all prover nodes in the active prover set meet and maintain the hardware requirements, and are constantly capable and available to generate proofs at the highest performance.

There is no solution to rule them all, but it is important that projects looking to outsource proof generation are aware of the different mechanisms and how they may impact other characteristics of the prover networks and marketplaces.

Summary and closing thoughts

The proving infrastructure landscape has shown a great evolution in Q3 2024, with developments across multiple fronts that signal the ecosystem's maturation.

New launches and announcements in the ecosystem

Several teams have made announcements and launches in Q3, including Risc Zero's Boundless, Fermah's devnet, Cysic Network's testnet, Polyhedra’s Proof Cloud powered by Google, or Gevulot’s node onboarding to Firestarter, which shows there is continuous development happening in the space. Each brings its own approach to the proving infrastructure, from ZK-mining incentives to stake-weighted selection mechanisms. The diversity of approaches provides great insights into different architectural and economic models.

Practical Decentralization taking shape

In Q3 we’ve seen significant practical progress in prover decentralization, moving beyond theoretical discussions to actual implementation. Aztec's ProverNet contest and ZKsync's multi-phased decentralization initiative represent crucial real-world advancements in permissionless proof outsourcing. These efforts are paving the way for other L2s and validity rollups to follow, potentially accelerating the industry's shift toward decentralized proving.

Workload allocation mechanisms

The analysis of workload allocation mechanisms reveals important considerations around decentralization that require further discussions and research in the industry. While mechanisms like auctions can drive market efficiency, the potential centralization risks suggest the need for careful protocol design that balances performance with maintaining a truly decentralized network of provers.

Industry consolidation through collaboration

The formation of the ZkBoost Consortium, bringing together 42 leading companies, marks a move toward collaborative standardization. The industry seems to recognize the need for common pieces of infrastructure and standards to drive adoption and improve user experience. The development of standardized APIs could significantly reduce integration complexity and accelerate the adoption of decentralized proving services and zero-knowledge in general.

It is reasonable to believe that the proving infrastructure landscape is moving from a period of initial experimentation to one of practical implementation and potential standardization.

Disclaimer:

The proving landscape is evolving day by day. If you feel we missed out on some important protocols or developments, or find any inaccuracies, please get in touch with Norbert from the Gevulot team, and we can make the necessary changes.

———

About Us:

Gevulot Blog

Discussion about this post