Sidecar Prover Coordination & Gevulot
We on the Gevulot(.com) team wholeheartedly agree with Cooper’s. It is impossible to control where proving actually takes place. In any prover network nodes could simply be using the same centralized API in the backend. Simultaneously reliance on any single solution, enshrined or external, is risky. Given this dynamic, we support Cooper’s proposal to not attempt to dictate how proof generation happens but rather create economic incentives and disincentives for participants to generate proofs as they see fit.
We would also encourage providing reasonable default options to ensure minimal cognitive overhead for sequencers and propose Gevulot as one such option (but it should not be the only one).
In the rest of this post, we’ll dive into what Gevulot is, how it can provide cheap and performant decentralized proving for Aztec, and our timelines going forward.
What is Gevulot?
Gevulot is a generic decentralized prover network. More specifically it is a new L1, which allows users to permissionlessly deploy arbitrary provers and verifiers as on-chain programs and run them to complete proving workloads, while still being cost-effective and performant enough to genuinely compete with centralized options.
In Gevulot, prover programs are only executed by a small, configurable subset of prover nodes and later verified by a subset of validators (primarily for the purpose of distributing rewards). The programs themselves are ELF binaries and run in a unikernel. More specifically Gevulot uses the Nanos unikernel, which supports 8+ languages (incl. Rust & C++), multithreading, CPU & GPU (support for new hardware such as FPGAs or ASICs can be added later), all in a highly performant sandboxed environment.
You can read more about the network design and find instructions for compiling and running a prover in Nanos here. We provide example provers for Marlin, Ed25519 and Filecoin SNARKs.
Gevulot Roadmap
Q1 2024 - Permissioned Devnet
Coinciding with Aztec’s plans to have decentralized sequencing on testnet by Q1, we will be launching a permissioned devnet for Gevulot. The devnet will operate with 4-5 nodes run by prominent ZK acceleration teams, validators, and the Gevulot core team.
The purpose of the testnet is to:
a) Facilitate testing of the core functionality, including proving, verifying, networking, orchestration, etc.
b) Allow external teams and projects to begin integration and testing.
c) Benchmark and optimize performance.
The devnet will allow users to:
- Deploy arbitrary provers and verifiers.
- Run proving workloads to generate proofs.
- Track workload status, cancel and retrieve outputs via an API.
- Store proofs.
Q3-Q4 2024 - Permissionless Testnet
We are aiming to launch a permissionless testnet during the second half of 2024, which will include all core functionality for validation, proving, and the incentives therein, in permissionless form. You can refer to the gevulot-overview.md document on our github regarding the planned scope for testnet.
TBD 2025 - Mainnet
We are targeting a mainnet launch in 2025.
Gevulot & Aztec
The first step to integrating into the Aztec network will be to deploy the finalized Aztec prover on Gevulot’s devnet, followed by granting permissions to sequencers.
Generating proofs for Aztec requires both network data and a financial stake. Gevulot simply generates proofs with the delivered inputs, so outsourcing proof generation to Gevulot can manifest in two primary ways:
- The sequencers themselves stake, outsource the proof generation to Gevulot and then post the completed proof to L1.
- An intermediary entity operates a proxy, which offers the outsourcing of proof generation to Gevulot and then posts the completed proof to L1.
We recommend the first option, where outsourcing to Gevulot could eventually be an option implemented directly in the sequencer node along with other options. However, the inherent permissionless structure of our system means that the community can also choose to embrace the second option and deploy proxy nodes for this purpose. If this is the direction the community wants to go, we are happy to help in implementing such a proxy node.
Incentives and Slashing
Gevulot does not affect Aztec incentives and those can be configured independently by the Aztec Network.
From the perspective of Aztec, the party taking responsibility for proving would be the sequencer or the proxy node (who can be slashed and rewarded), who in turn is relying on Gevulot’s incentives, which are described below.
Gevulot prover nodes will be staked and we employ a number of incentive mechanisms to ensure nodes perform their tasks in a timely manner:
-
Slashing for liveness failures: In Gevulot, users define the maximum running time of a program. If the program does not produce a proof during that running time, the provers get no reward and fees are burned, but they do not get slashed. They only get slashed if they do not respond at all.
-
Rewards for completing proofs: In Gevulot provers are always rewarded if they complete a proof in the running time specified by the user, both via network rewards as well as user fees. In executing a proving workload the user defines the desired amount of redundancy (how many provers will run the program) and the running time. The desired amount of provers is then chosen at random from the active prover set, who compete to complete the workload. The fastest prover gets the largest reward, the second fastest a slightly smaller reward, and so on. Distributing the workload randomly and rewarding all provers that manage to contribute a proof in the specified running time in this way, is extremely important to curb the natural tendency towards centralization.
-
Active prover set dynamics: In addition to the reward structures described above we will likely be implementing certain rules for provers who want to remain in the active prover set. We will be using a kind of proof-of-work that provers will need to complete periodically in order to join or remain in the prover set. This proof of work would test for whether the provers are running the hardware they claim to be running and are consistently available. For example, a prover that wants to join the prover set and says they have a GPU that meets the requirements would need to complete a proof which can only be achieved in the time constraints if they actually have a GPU. Here again, if a prover fails the proof-of-work, they cannot join or will be dropped out of the prover set and have a cooldown period before they can unlock their stake.
Resilience and Recovery
From Aztec’s perspective the best way to ensure resilience and recover is to allow for a wide range of proving options, but slash parties who are unable to complete proofs. This will naturally drive participants to find the right amount of redundancy for resilience. Participants can then choose to implement this redundancy on an Aztec level, by choosing multiple parties/services to generate a proof or on Gevulot by increasing redundancy.
In terms of Gevulot’s recovery ability, we are designing the system to always generate a proof if it is possible within the time constraints provided by the user (running time of the program). If a prover declines a workload, that user’s spot in the workload allocation becomes a free-for-all where any prover node can then submit a proof in that prover’s place. This ensures that the end-user always gets the redundancy they pay for or more.