NEWTON Prover zkvm Proof Systems

The NEWTON Prover supports two zkvm proof systems: Risc0 and Sp1.

Risc0 zkvm Proof System

The Risc0 zkvm proof system is a zero-knowledge proof system that uses the Risc0 zkvm as its proof generator. The Risc0 zkvm is a zero-knowledge proof system that uses the Risc0 instruction set architecture (ISA) to generate proofs.

The expected ImageID to perform SNARK verification on-chain for the Risc0 zkvm proof system is: 4cf071b3cc25d73e77f430b65f5700dd53522dacc21c1bfc0862b2e46fda3584

Sp1 zkvm Proof System

The Sp1 zkvm proof system is a zero-knowledge proof system that uses the Sp1 zkvm as its proof generator. The Sp1 zkvm is a zero-knowledge proof system that uses the Sp1 instruction set architecture (ISA) to generate proofs.

The expected VKEY to perform SNARK verification on-chain for the Sp1 zkvm proof system is: 0021feaf3f6c78429dac7756fac5cfed39b606e34603443409733e13a1cf06cc

Digest Module

The common/digest module provides digest computation utilities for BLS signature consensus.

Two-Digest System

BLS signature aggregation requires all operators to sign the same message. However, operators independently generate unique ECDSA attestations (each signs policyTaskData with their own key). The Two-Digest System solves this conflict:

Functions

• compute_consensus_digest(task_response): Computes digest with attestation fields zeroed out. All operators produce identical consensus digests even with different ECDSA signatures.
• compute_full_digest(task_response): Computes complete hash including attestations for on-chain storage and challenge verification.

Usage

use newton_prover_core::common::{compute_consensus_digest, compute_full_digest};

// For BLS signing - all operators get same digest
let consensus_digest = compute_consensus_digest(&task_response);

// For on-chain storage - full response integrity
let full_digest = compute_full_digest(&task_response);

Database Module

The database module provides PostgreSQL integration for the Gateway with type-safe query execution and connection pooling.

Components

• api_keys.rs: API key management with permissions, rate limiting, and expiration support
• wasm_secrets.rs: Encrypted secrets storage and retrieval scoped to (policy_client, policy_data) pairs
• permissions.rs: Permission system (RpcRead, RpcWrite, Admin)
• mod.rs: Database manager with dual-pool architecture (deadpool-postgres + sqlx)

Features

• Connection Pooling: Efficient deadpool-postgres and sqlx dual-pool integration
• Offline Mode: SQLx compile-time query verification without database connection
• Migration Management: Versioned schema migrations via sqlx-cli
• Type Safety: Compile-time SQL query validation
• Health Checks: Built-in database health monitoring
• Referential Integrity: Foreign key constraints with CASCADE delete

Usage

use newton_prover_core::database::{
    initialize_database, get_database, DatabaseConfig,
    ApiKeyRepository, WasmSecretRepository
};

// Initialize database singleton
let config = DatabaseConfig::default();
initialize_database(config).await?;

// Access database
let db = get_database();
let pool = db.pool();

// Use repositories
let api_key_repo = ApiKeyRepository::new(db.clone());
let keys = api_key_repo.get_all_active().await?;

For database management guide, see src/database/README.md. For secrets management data model, see ../gateway/src/rpc/api/README.md.