SP1 Helios
Overview
Implementation of an ZK Ethereum light client using the Altair sync committee with SP1 and Helios.
/program
: The SP1 Helios program./primitives
: Libraries for types and helper functions used in the program./script
: Scripts for getting the contract's genesis parameters and deploying the operator to update the light client.
Deployment
Overview
SP1 Helios verifies the consensus of a source chain in the execution environment of a destination chain. For example, you can run an SP1 Helios light client on Polygon that verifies Ethereum Mainnet's consensus.
Prerequisites
Steps
1. Consensus RPC Setup
To run SP1 Helios, you need a Beacon Chain node for your source chain. For example, to run an Ethereum mainnet light client, you need an Ethereum mainnet beacon node.
The beacon chain node must support the RPC methods for the Altair light client protocol. As of 10/15/24, Nimbus is the only consensus client that supports these "light sync" endpoints by default.
There are a few options for setting up a consensus RPC with "light sync" endpoints:
- Get an RPC from a provider running Nimbus nodes. Chainstack is currently the only provider we're aware of that supports this. Set up a node on Chainstack and use the consensus client endpoint for an Ethereum mainnet node.
- Run a Nimbus eth2 beacon node. Instructions here.
- There is a community-maintained list of Ethereum Beacon Chain light sync endpoints here. These endpoints are not guaranteed to work, and are often unreliable.
The RPC you just set up will be used as the SOURCE_CONSENSUS_RPC_URL
in the next step.
2. Environment Setup
In the root directory, create a file called .env
(mirroring .env.example
) and set the following environment variables:
Parameter | Description |
---|---|
SOURCE_CHAIN_ID | Chain ID for the source chain |
SOURCE_CONSENSUS_RPC_URL | RPC URL for the source chain |
DEST_RPC_URL | RPC URL for the destination chain |
DEST_CHAIN_ID | Chain ID for the destination chain |
PRIVATE_KEY | Private key for the account that will be deploying the contract |
SP1_PROVER | Default: mock . network will generate real proofs using the Succinct Prover Network |
ETHERSCAN_API_KEY | API key for Etherscan verification |
Optional Parameters
Parameter | Description |
---|---|
GUARDIAN_ADDRESS | Defines the owner for the light client. Defaults to the account owner of PRIVATE_KEY |
SP1_PRIVATE_KEY | Required in network mode. The private key of the account that will be requesting proofs from the Succinct Prover Network |
SP1_VERIFIER_ADDRESS | Required in network mode. The address of the verifier contract |
LOOP_DELAY_MINS | The delay between each loop of the operator in minutes. Defaults to 5 |
3. Deploy Contract
Deploy the SP1 Helios contract:
# Load environment variables
source .env
cd contracts
# Install dependencies
forge install
# Deploy contract
forge script script/Deploy.s.sol --ffi --rpc-url $DEST_RPC_URL --private-key $PRIVATE_KEY --etherscan-api-key $ETHERSCAN_API_KEY --broadcast --verify
When the script completes, take note of the light client contract address printed by the script and add it to your .env
file:
Parameter | Description |
---|---|
CONTRACT_ADDRESS | Address of the light client contract deployed |
4. Run Light Client
To run the operator, which generates proofs and keeps the light client updated with chain state:
RUST_LOG=info cargo run --release --bin operator
If successful, you should see logs indicating that the consensus state is being updated:
[2024-10-15T21:01:19Z INFO operator] Starting SP1 Helios operator
[2024-10-15T21:01:20Z WARN helios::consensus] checkpoint too old, consider using a more recent block
[2024-10-15T21:01:20Z INFO operator] Contract is up to date. Nothing to update.
[2024-10-15T21:01:20Z INFO operator] Sleeping for 5 minutes
...
[2024-10-15T21:06:35Z INFO operator] New head: 6107648
[2024-10-15T21:06:50Z INFO operator] Transaction hash: 0x4a0dfa2922704295ed59bf16840454858a4d17225cdf613387de7605b5a41520
[2024-10-15T21:06:50Z INFO operator] Sleeping for 5 minutes
Note: When
SP1_PROVER=mock
, the operator will not generate real proofs.
Components
An SP1 Helios implementation has a few key components:
- An
SP1Helios
contract. Contains the logic for verifying SP1 Helios proofs, storing the latest data from the Ethereum beacon chain, including the headers, execution state roots and sync committees. - An
SP1Verifier
contract. Verifies arbitrary SP1 programs. Most chains will have canonical deployments upon SP1's mainnet launch. Until then, users can deploy their ownSP1Verifier
contracts to verify SP1 programs on their chain. The SP1 Helios implementation will use theSP1Verifier
contract to verify the proofs of the SP1 Helios program. - The SP1 Helios program. An SP1 program that verifies the consensus of a source chain in the execution environment of a destination chain using the
helios
library. - The operator. A Rust script that fetches the latest data from a deployed
SP1Helios
contract and an Ethereum beacon chain, determines the block to request, requests for/generates a proof, and relays the proof to theSP1Helios
contract.
Frequently Asked Questions
How do I prove data on Ethereum against an SP1 Helios light client?
The SP1 Helios light client validates the Ethereum beacon chain's headers are signed correctly by the Altair sync committee. The Helios library verifies that the execution payload in the beacon chain's header is correct here.
You can use storage proofs to Merkle prove data in the Merkle Patricia Trie against the execution state root.
Reproducible Builds
Overview
When deploying SP1 Helios in production, it's important to ensure that the program used when generating proofs is reproducible.
Prerequisites
You first need to install the cargo prove toolchain.
Ensure that you have the latest version of the toolchain by running:
sp1up
Confirm that you have the toolchain installed by running:
cargo prove --version
Verify the SP1 Helios binary
To build the SP1 Helios binary, first ensure that Docker is running.
docker ps
Then build the binaries:
cd program
# Builds the SP1 Helios binary using the corresponding Docker tag, output directory and ELF name.
cargo prove build --docker --tag v4.0.0-rc.10 --elf-name sp1-helios-elf
Now, verify the binaries by confirming the output of vkey
matches the vkeys on the contract. The vkey
program outputs the verification key
based on the ELF in /elf
.
cargo run --bin vkey --release