Run a local Gevulot prover node

How to run a Gevulot node in your local environment and get started with development.

Mar 04, 2024

We have recently started to onboard developers to the Gevulot devnet which is launching on 25 March 2024.

As we are building an internet-scale compute network for zero-knowledge proof generation and verification, the devnet is a major step for us to engage with our partner teams and the developer community more closely, all the while building this core zk-infrastructure together. (If you are interested in joining the devnet but have not signed up yet, you can do so here.)

In this post, we will summarize what features and functionalities developers can expect from the devnet, provide guidance on how to run a local Gevulot node, and give an end-to-end example for testing.

Devnet features

The current devnet will be a permissioned network for testing the proof generation pipeline and other core functionalities, however, it will not have a consensus mechanism and fee structure in place yet. The upcoming devnet will allow node operators to:

Deploy arbitrary provers and verifiers,
Run proving workloads to generate and verify proofs,
Track workload status, and retrieve outputs via an API, and
Store proofs.

The devnet will be free to use for registered users and will initially run for 2 months (starting on 25 March 2024) but may be extended until Q3 2024.

Our permissionless, incentivized testnet is expected to launch in Q3 and will pave the way for the mainnet launch in late 2024 or early 2025 (exact date TBD). You can refer to our docs for more information on the planned scope for the testnet.

Requirements

Hardware requirements

Provers and verifiers that are deployed to Gevulot, are built to run in a Nanos unikernel, ultimately resulting in a VM image. A Gevulot node runs these under the QEMU/KVM hypervisor and therefore an x86-64 architecture processor with hardware acceleration for virtualization is required.

Software requirements

To run a Gevulot node, a modern Linux distribution with Podman (e.g. Fedora 39 or Ubuntu 22.04 or newer) is necessary.

The below instructions provide for a local development node that does not support GPU. To have GPU support, please follow the official node installation instructions that include the details on how to configure PCI passthrough for the GPU.

Prerequisites to be installed:

Rust
Cargo
QEMU (pre-installed and configured on Fedora)
openssl-devel (libssl-dev in Debian derivatives)
protobuf-compiler

Step-by-step guide to run a local Gevulot node

The Gevulot node is written in Rust and packaged as a container for the best possible platform compatibility. It is recommended to run it with Podman.

Clone the Gevulot repository:

git clone https://github.com/gevulotnetwork/gevulot.git

Navigate to the Gevulot Directory:
```
cd gevulot
```
Create data directories:
```
mkdir -p data/{db,node}
```

Set up PostgreSQL container:

podman run -d --rm --name gevulot-postgres --network host -v ./crates/node/migrations:/docker-entrypoint-initdb.d:z -v ./data/db:/var/lib/postgres/data:z --env POSTGRES_USER=gevulot --env POSTGRES_PASSWORD=gevulot --env POSTGRES_DB=gevulot docker.io/library/postgres:16-alpine

Compile the program:
```
cargo build --release
```

Generate a public node key:

./target/release/gevulot generate key --key-file data/node/node.key

Enable module for virtual socket communication:
```
sudo modprobe vhost_vsock
```

Run the Gevulot node:

./target/release/gevulot run --data-directory ./data/node --log-directory ./data/node/log --node-key-file ./data/node/node.key

Test proof generation and verification with our simple end-to-end test

Follow the below steps to generate and whitelist your keys, and to test your local Gevulot node. The end-to-end test in the Gevulot node repository includes deploying a prover and a verifier program and then executing a Run transaction. The transaction will generate a test proof and verify it using the deployed test programs.

Install Ops (https://ops.city/)
Navigate to Gevulot root directory:
```
cd <gevulot source root>
```
Generate a new cryptographic key pair. This will be used to sign transactions.
```
./target/release/gevulot-cli generate-key
```

Whitelist the public key:

./target/release/gevulot peer <pubkey from above> whitelist

Display the public key of your node:

./target/release/gevulot show public-key --key-file data/node/node.key

Add this key to the whitelist:

./target/release/gevulot peer <pubkey from above> whitelist

Navigate to E2E tests directory:
```
cd crates/tests/e2e-tests/
```
Copy the Prover and Verifier to the test directory:
```
cp ../../../target/release/{prover,verifier} .
```

Create the Prover image with Ops:

ops image create -n -c manifest/prover.json

Create the Verifier image with Ops:

ops image create -n -c manifest/verifier.json

Run the end-to-end test:

cargo run -- -p ~/.ops/images/prover -v ~/.ops/images/verifier -k ../../../localkey.pki

If you see the following, the tests were successful:

...
Listening on <your ip address>
request file: 51a68fd499fa25fc5aa5abb5c9a1cb2e2060831c8c6df96c1196a277253865e6
request file: c47255b3c219c4fd7bdb72e2080d5d2b46ac297e4c52bb0ec26b6ffe0e376e90

You can now use your local node via the JSON RPC, which is documented here!

Support and feedback

Should you encounter any issues or have any questions, feel free to contact us through our official TG channel. Our team is committed to supporting you and making your experience as smooth as possible, we are here to support you every step of the way. We also encourage you to share your feedback as it helps us improve and build with the developer community.

Once again, thank you for your interest in joining the Gevulot devnet. Let’s build the decentralised compute network for zk-proving and verification together!

Learn more about Gevulot:

Gevulot Blog

Discussion about this post