We are excited to finally introduce Gevulot - a fully permissionless and programmable layer 1 blockchain for deploying proof systems as on-chain programs. It’s designed with the end-user in mind and comes with high liveness guarantees, predictable fees and performance to match centralised provers. Gevulot is built by a team from Equilibrium Group where the members of the team have previously worked closely with industry leaders such as Aleo, Starknet and Avail.
This blog post serves as an introduction to the Gevulot network and how it works, why we decided to build it and who it’s designed for. To demonstrate the capabilities and enable wider testing, we are also releasing the following on Github:
- A demo of Starkware STARK, Filecoin SNARK, Marlin and Ed25519 provers running in the Gevulot environment, as well as verifier programs for testing.
- The Gevulot environment, which is a Nanos unikernel configuration, and instructions for how to compile and run a prover locally or on Google Cloud.
This is only the first step in the development of Gevulot and we’ll be sharing more information on timelines and future plans later on. Make sure to follow us on X/Twitter to keep up to date.
Why Are We Building Gevulot?
Zero-knowledge-proof technology is being leveraged in blockchains for succinctness (recursive blockchains), scaling (validity rollups, bridges, off-chain compute…) and privacy (Aleo, Aztec, Zcash…). As these applications get more usage, the demand for proof generation will increase rapidly.
Today, almost all proving infrastructure is permissioned and many applications rely on a single prover. While the centralised solution is less complex, decentralising the proving architecture brings several benefits. One key benefit comes in the form of liveness guarantees which are crucial for applications that depend on frequent proof generation. Users also benefit from higher censorship resistance as well as lower fees driven by competition and sharing the workload amongst multiple provers.
Applications that want to decentralise the role of provers can either choose to bootstrap an internal proof network (multiple provers, single application) or outsource the proving to an external proof market (multiple provers, multiple applications).
However, getting the right incentives and mechanism design is difficult. Internal proof network designs tend to be inefficient, in that they only ever use a small amount of total proving capacity for their single application. They also create unnecessary complexity for provers who due to the inefficiency will be participating in many proof networks and must navigate each network's interfaces & incentives. Proof markets, on the other hand, cannot provide liveness guarantees, making them a poor choice for mission-critical applications. They also suffer from unpredictable pricing and the complexity of bidding logic. Finally, they do not offer deployment or smooth upgrade paths, meaning a tight integration is required for each application.
Gevulot takes a fundamentally different approach by aiming to serve as a fully permissionless and general-purpose proof network for any system that requires zero-knowledge proofs to operate.
What Is Gevulot?
Gevulot is a permissionless and programmable layer 1 blockchain for deploying proof systems as on-chain programs. It’s designed specifically for applications that require cheap and fast proof generation, with high liveness guarantees.
Similar to other PoS blockchains, Gevulot has balances, transfers, staking with the native token, as well as, proof system deployment, which resembles smart contract deployment. However, the two main differences to most other blockchains are that Gevulot lacks traditional smart contract state and verification of computation is done through validating ZKPs rather than re-execution. Provers run deployed prover programs and the proofs are verified by the network, after which they get added to blocks. Blocks on Gevulot contain financial transactions and proofs, rather than smart contract state transitions.
Users can deploy programs permissionlessly on Gevulot and benefit from proving speed that matches centralised providers. The two types of programs on Gevulot - provers and verifiers - can either be deployed as a pair (“proof system”) or just as a standalone verifier program for validating proofs produced outside the Gevulot network. Interacting with the proof program is as simple as interacting with a smart contract.
For provers, Gevulot aggregates proving workloads across many
different applications maximizing both hardware utilisation and
financial return. Gevulot also provides a compelling target for both
software and hardware optimisation given its broad applicability.
Key Benefits Of Gevulot
1. Performance That Competes With Centralised Provers
Gevulot uses unikernels, which are very lightweight operating systems designed to run only a single process. Unikernels offer a compelling mix of performance and security, allowing Gevulot programs to match centralised prover implementations in speed while ensuring effective sandboxing of the software. More specifically, Gevulot utilises the Nanos unikernel running in a KVM hypervisor or on Google Cloud, which provides benefits such as multi-threading, GPU support and efficient orchestration.
In addition, the proving workload is distributed to a small group of provers using a Verifiable Random Function (VRF). This limits the amount of wasted computation (only a small subset of the provers run the computation rather than the entire network) and allows for parallelisation of proving workloads across the network.
2. Easy and Permissionless Program Deployment
Gevulot is a layer 1 blockchain, which means that anyone can deploy programs in a permissionless manner. Nanos supports x86_64 Linux ELF binaries, which means programs can be written in C, C++, Go, Java, Node.js, Python, Rust, Ruby, PHP and more. The program is compiled down to a unikernel image which requires minimal to no modification for most open-source prover implementations today.
3. High Liveness and Predictable Fees
Distributing the proving workload to small groups of provers using a VRF (rather than choosing a single prover per task) ensures liveness as long as at least one of the provers in the group is able to generate the proof within the specified time. To further incentivise liveness, slashing is used to punish nodes that don’t respond to a proving workload.
Given that proving fees are a significant cost for many applications that rely on ZKPs, we have designed the fee structure in Gevulot to be both stable and predictable. The maximum fee is set by the user depending on how many cycles they want the program to run for (more below). This helps teams forecast their costs and in turn, enables them to give a better experience to their end users. In addition, limiting the amount of wasted computation across the network leads to cheaper proving fees since the fee doesn’t need to reflect the work of an entire network.
Fees and Prover Rewards
To determine fees in Gevulot we introduce the concept of cycles: A cycle is a fixed amount of blocks and functions as an objective measure of a program’s running time. The user sets a maximum fee by paying for the number of cycles that they estimate it will take to run the program and generate the proof.
If the user doesn’t pay for enough cycles, the program will not complete (nodes will return a fail) and the fee is burned. If the user pays for excessive cycles, the nodes will return the output as soon as the program completes due to competitive dynamics in prover incentives. The user only pays for the number of cycles that it takes the fastest prover to generate the proof and the unused fee is refunded. Therefore, the user is incentivised to set their max fee slightly higher than their estimate to make sure that the proof gets generated.
Provers are rewarded by both the Gevulot network and through fees paid by the user who requests the proof. Both payments are in the network’s native token:
- The network reward is paid to all provers who complete the workload within the given timeframe that’s defined by the user (number of cycles). However, the amount each prover gets is determined by speed, with the first node to return an output receiving the majority of the reward, the second a smaller portion, the third an even smaller portion and so on.
- Fees paid by the user are shared equally amongst all provers who successfully generated the proof within the given timeframe. Given that fees are estimated to be very low, the network reward is going to be significantly more important for provers, while the fee is primarily to prevent users from DDoSing the network.
Example: Calling A Prover On A Validity Rollup
- Users on the rollup generate transactions, which the sequencer gathers and orders.
- Rather than generating the proof itself, the sequencer sends the data to the proof system deployed on Gevulot (either by running a full node or being connected to an RPC provider).
- The proof request is added to the mempool and gets allocated to a small group of provers using a VRF.
- The provers in the group run the program and attempt to generate the proof within the number of cycles that the sequencer node has specified.
- The fastest prover in the group to generate the proof wins.
- Once the proof is in the mempool, the sequencer’s full node or RPC provider can immediately verify the proof and get a deterministic guarantee of finality. If valid, the sequencer can post the proof on their settlement layer (such as Ethereum).
- The winning proof is verified by a subset of validators on Gevulot until the verification threshold is reached (a subset of the network), after which it is included in a block and the provers get rewarded.
Who Is Gevulot For?
Gevulot can be utilised for any application or network that relies on zero-knowledge proofs (except for those that require privacy guarantees). While the future may bring new use cases, some examples today include:
- Validity Rollups: ZK proofs are used to verify correct execution in validity rollups. The proof generation can be outsourced to Gevulot by simply deploying a proof system program, which avoids projects having to bootstrap their own prover networks or relying on their sequencers to manage heavy computational loads.
- Privacy Rollups: While Gevulot can’t be used for privacy-preserving proof generation as that would require sharing private inputs, it can be used for aggregation of private proofs. Many privacy rollups need to aggregate a large number of private proofs into one aggregate proof, or in Aztec’s case many sub-aggregation proofs that make up the proof tree. Gevulot could handle the aggregation, while still retaining the desired privacy guarantees for users.
- ZkVMs: There are already tens of zkVM implementations including CairoVM, Risc0, zkWASM, zkBPF and zkEVMs. Any such zkVM implementation can be deployed on Gevulot and used as a standalone environment.
- Bridges: ZK-bridges such as Succinct Labs' Telepathy rely on Proof-of-Consensus, which can also be deployed to Gevulot as a proof system leading to minimal additional hardware needing to be run.
- ZK Mining: Gevulot could be used to compute the coinbase puzzle for Aleo or Filecoin Storage provider SNARKs.
Summary
We believe that zero-knowledge proofs will be part of most applications in the future. However, proof generation as it stands today is centralised and many projects rely on just a single prover. Bootstrapping a proving network requires a lot of thought and consideration to get the incentives right, which is an additional burden for projects. It also leads to more complexity from the provers’ perspective (often involved in multiple networks with different interfaces & incentives). Proof markets on the other hand cannot provide the liveness guarantees needed for many applications.
Gevulot takes a fundamentally different approach by providing a layer 1 blockchain that enables decentralised proving in a permissionless manner and performance to match centralised provers. We have designed Gevulot with the end user in mind which is reflected in high liveness, fast proving, predictable fees and easy program deployment across multiple different languages. Users can simply deploy a proof system on Gevulot and interact with it as easily as they would with a smart contract.
You can find more information about the technical implementation on our GitHub. We are excited to share this with the wider community and start contributing more actively to the conversation around decentralising provers. Follow us on X/Twitter for further updates.
Thanks to Omer from Ingonyama, Kelly from Supranational, Rami from Fabric Cryptography, Cooper from Aztec Protocol, and Jesse and Alana from Variant, for discussions and insights into the design process.