Please reach out to request an API key and generate a proof in only a few minutes.
Proof Generation
The high-level flow is to start the session, send requests containing SVM transactions, end the session to trigger proof generation, and poll the endpoint to retrieve summary statistics.
1
Install Rust Dependencies (Optional)
If using the zkSVM Rust client, install the necessary crates.
Kick off a session and initialize the genesis accounts that should exist before transaction processing. The request will be rejected if it doesn't contain a valid access key.
use zksvm_client::session::Session;
let mut session = Session::new(SERVER_URL, SERVER_PORT, API_KEY)?;
let session_id = session.start(genesis_accounts).await?;
Send SVM transactions that the prover should include in the ZK proof.
There's a max cap of 50 due to memory constraints of the underlying zkVM, and the server will return how many transactions are remaining for the current session.
let remaining_txs = session.send_transaction(tx).await?;
assert_eq!(49, remaining_txs);
Request
POST /session/<session_id>/transactions
{
"transaction": [...]
}
Response
{
"remaining_transactions_in_session": 25
}
4
End Session
End the session to trigger proof generation and select the SP1 proof type. Supported types are core, compressed, and groth16. The last option is recommended for most uses, including on-chain verification.
Since proving is async, the response only contains a successful acknowledgement of the request but not the completed proof details.
use zksvm_api_types::common::ProofType;
session.end(ProofType::Groth16).await?;
Request
PUT /session/<session_id>
{
"proof_type": "groth16"
}
Response
{}
5
Poll Session
Poll the session to see the latest details on its status.
let res = session.poll_status().await?;
assert_eq!(session_id, res.session.session_id);
assert_eq!(ProofState::InProgress, res.session.proof.state);
use zksvm_client::Session;
use sp1_sdk::{HashableKey, SP1ProofWithPublicValues, SP1VerifyingKey};
use zksvm_client::verify::verify_locally;
#[tokio::main]
async fn main() {
let session = Session::existing(SERVER_URL, SERVER_PORT, API_KEY, SESSION_ID).unwrap();
let status = session.poll_status().await.unwrap();
let proof = res.session.proof;
let bytes = proof.proof.unwrap();
let groth_proof = bincode::deserialize::<SP1ProofWithPublicValues>(bytes.as_slice()).unwrap();
assert_eq!(64, groth_proof.public_values.to_vec().len());
let res = verify_locally(proof);
assert!(res.is_ok());
}
On-chain Verification
If it's a Groth16 proof, it can also be verified on-chain via a verifier program.
use solana_client::rpc_client::RpcClient;
use zksvm_client::verify::verify_on_chain;
#[tokio::main]
async fn main() {
// assume zkproof from the server exist
verify_on_chain(
// (change this URL if using mainnet or testnet)
RpcClient::new(RPC_URL.to_string()),
verifier_program_id,
payer,
zkproof,
)
.expect("Failed to verify proof on chain");
}
Test Utilities
The library provides a few utilities to initialize program accounts and generate sample SVM transactions for convenience.
use zksvm_client::test_utils::{prepare_deploy_program_transactions, prepare_sol_tx, prepare_spl_tx};
fn main() {
// assume a set of all keypairs exist
let sol_tx = prepare_sol_tx(&payer, &alice, &bob, &source);
let spl_tx = prepare_spl_tx(&payer, &alice, &bob, &minter, &mint_authority);
// assume program bytecode and keypair exist
let deploy_program_txs = prepare_deploy_program_transactions(
payer,
&program_keypair,
program_authority,
bytecode.to_vec(),
// assume latest blockhash exists
latest_blockhash,
)
.expect("Failed to create transactons for deploying a program");
}
System Constraints
There are a few limitations to keep in mind. The system currently places a hard cap of 50 transactions per session due to memory constraints of the underlying zkVM, which is around 24B cycles. The server will reject requests that send additional transactions beyond 50. Not that if you start a new session, old data from previous sessions are not persisted.
The zkSVM contains several pre-installed Solana Program Library (SPL) programs, e.g. the token and token-2022 programs, but any custom programs need to be deployed before they can be interacted with.
