Anoma Risc0 Resource Machine

This is a shielded resource machine implementation based on Risc0-zkvm

Docs

• General RM Specification
• Shielded RM Specification(TBD)
• Anoma SDK

ARM-RISC0 Directory Structure

• arm/: The main Anoma Shielded Resource Machine implementation providing the core functionality for Anoma SDK and Validator.

• arm_circuits/: Demonstration circuits for arms and applications:

  • compliance: Basic compliance checking circuit
  • trivial_logic: Minimal logic circuit example, also used in padding resources
  • proof aggregation (batch_aggregation, sequential_aggregation): Circuits for single-run aggregation and IVC-based aggregation, respectively

• arm_gadgets/: It provides a range of commonly used components for resource logic circuits, such as verifiable encryption and ECDSA signature authentication.

• arm_tests/: It encompasses a basic resource logic instantiation and transaction tests.

ARM-RISC0 Application Examples

Several application examples are available at here, including the simple counter application, token transfer application, and the kudo application.

Getting Started

Dependencies

• Rust: install rust instructions
• Risc0 toolchain: install risc0 instructions

Note: The installation of the Risc0 toolchain is required only if you intend to develop resource logics(circuits).

Build and Test

• Compile arm libs

cargo build

• Run arm tests

# run tests in dev-mode: no real proofs are generated
RISC0_DEV_MODE=1 cargo test

# run tests in release mode: default succinct(stark) proofs are generated
cargo test --release

Run tests and examples on Bonsai

Bonsai is a remote and high-performance service provided by RISC0 for generating proofs. To use Bonsai, you can request an API key here, and then set the environment variables. Once set up, your proof generation tasks will be automatically offloaded to Bonsai.

export BONSAI_API_URL=<BONSAI_URL>
export BONSAI_API_KEY=<YOUR_API_KEY>

Benchmark

• Compliance circuit benchmark

Feature flags

We have the following feature flags in arm lib:

Feature	Implies	Description
compliance_circuit		A specific feature for compliance circuit
transaction (default)	compliance_circuit, client	It provides full transaction processing capabilities and supports Succinct(STARK) and Groth16 proof types. Groth16 proofs require x86_64 machines.
prove		Enables RISC0 proving capabilities (required for actual proof generation)
bonsai		Enables RISC0 bonsai sdk
client		Enables RISC0 client sdk
cuda		Enables CUDA GPU acceleration for the prover. Requires CUDA toolkit to be installed.
aggregation_circuit		A specific feature for (pcd-based) aggregation circuits
aggregation	aggregation_circuit, transaction	Enables proof aggregation (only succinct proofs can be aggregated)

Usage Examples

# Default configuration
arm = "0.13.0"

# Proof aggregation (a single succinct proof per transaction)
arm = { version = "0.13.0", features = ["aggregation"] }

# Logic-circuit-only usage
arm = { version = "0.13.0", default-features = false }

Reproducibly generate proving and verifying keys (ELF and ImageID)

You may generate different ELFs and ImageIDs on different machines and environments. To reproduce the same output and publicly verify that the ELF and ImageID correspond to the specific circuit source code, use the following tool and command.

For example, build the compliance circuit in RM:

cargo risczero build --manifest-path arm_circuits/compliance/methods/guest/Cargo.toml

will reproduce the output to:

View build details: docker-desktop://dashboard/build/desktop-linux/desktop-linux/zbrzf1brqyb5evydjxs9h3gvl

ELFs ready at:
ImageID: 5d3ea0a27561e9e66e6a7c12c7022d1a814a0724d13f7f8e083c4b4f14b5f1c7 - 
arm-risc0/arm_circuits/compliance/methods/guest/target/riscv32im-risc0-zkvm-elf/docker/compliance-guest.bin

Note: The unstable feature of risc0-zkvm currently causes issues in circuits. This can be temporarily fixed by manually updating the tool. The problem will be fully resolved in the next release of RISC Zero.

cargo install --force --git https://github.com/risc0/risc0 --tag v3.0.3 -Fexperimental cargo-risczero

Proof aggregation

If a single transaction bundles too many resources, it is possible to aggregate all compliance and logic proofs into a single aggregation proof, attesting to the validity of them all. This reduces overall verification time and transaction size.

Before aggregation

Generate the transaction in the normal way in your workflow. But note that succinct proofs will yield faster aggregation.

Warning: It does not support in-circuit verification of Groth16 proofs. You would need to generate succinct compliance and logic proofs instead.

Prove aggregations

You need to enable the aggregation feature to be able to prove or verify aggregations.

The aggregation proof type is specified by the ProofType argument. The inner proofs must be Succinct.

We currently support two different aggregation strategies. The batch strategy aggregates all proofs in the transaction in a single run. It is the default aggregation.

use arm::transaction;

// Just a dummy tx, for illustration. The inner proofs must be Succinct.
let mut tx = generate_test_transaction(1, 1, ProofType::Succinct);

// Upon succesful aggregation, compliance and resource logic proofs are erased.
// The aggregated proof_type can be ProofType::Succinct or ProofType::Groth16
assert!(tx.aggregate(proof_type).is_ok());

The sequential strategy aggregates sequentially, in an IVC style.

use arm::aggregation::AggregationStrategy;

assert!(tx.aggregate_with_strategy(AggregationStrategy::Sequential, proof_type).is_ok());

Warning: Once again, aggregation erases all the individual proofs from tx and replaces them with the (single) aggregation proof in a dedicated field. This is why the transaction must be mut. This is true independently of the strategy used.

Verify after aggregation

Use tx.verify(), as when there is no aggregated proof. Feature aggregation must be enabled. Otherwise, it will result in an error.

External verification of the aggregation proof

Use tx.get_raw_aggregation_proof() to get the RISC0 InnerReceipt (the actual proof). The verifier would also need to derive the aggregation instance from tx on its own, and wrap both in a RISC0 Receipt.

Comparison

Strategy	Prover cost	Public input size	Aggregation scope	Memory efficient
batch	amortized among all tx proofs	linear in #{tx proofs}	fixed (single prover)	for RISC0 yes. In general, depends on the zkVM (if supports continuations)
sequential	linear in #{tx proofs}	constant	composable (different provers)	by design

The sequential (IVC) strategy is an example of proof-carrying data computation. PCD-based aggregation can be distributed across mutually untrusted nodes, and proofs to be aggregated arbitrarily grouped and arranged in different transcripts.

[TODO] Parallel proving at the ARM level. It is possible with tree-like transcripts. Currently not supported, but planned.