We are excited to announce support for the Jolt zkVM in Sindri! Jolt is a state of the art zero-knowledge virtual machine that leverages the power of Just One Lookup Table to achieve high performance and scalability.

This update expands Sindri's pallet of proving frameworks beyond circuit DSL's, enabling users to generate proofs of correct execution from arbitrary Rust programs. Users can generate proofs one of two polynomial commitment schemes (PCS's) currently supported in Jolt:

• HyperKZG
• Zeromorph

The project directory that users upload to Sindri should closely resemble the structure of the guest code directory from the Jolt template, with the addition of a sindri.json manifest file and a utils.rs file.

📦guest
 ┣ 📂src
 ┃ ┣ lib.rs
 ┃ ┗ utils.rs
 ┣ 📜Cargo.toml
 ┗ 📜sindri.json

Here is an example sindri.json file that specifies the required fields for a Jolt project using the HyperKZG commitment scheme.

{
  "name": "fibonacci",
  "circuitType": "jolt",
  "provingScheme": "jolt",
  "commitmentScheme": "hyperkzg",
  "joltVersion": "0.1.0",
  "stdEnabled": false,
  "packageName": "fibonacci",
  "guestFunction": "fib"
}

Users can also choose to enable the standard library by setting the stdEnabled field to true or false.
If set to true, the guest code and Cargo.toml file should be modified per the instructions in the Jolt documentation.

The utils.rs file will contain definitions for an Input and Output struct. An example of a utils.rs file is shown below:

use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize)]
pub struct Input {
    pub n: u32,
}

#[derive(Serialize, Deserialize, Debug)]
pub struct Output {
    pub output: u128,
}

The guest code contained in lib.rs will need to import the utils.rs file and format the inputs and outputs for the fib function.

#![cfg_attr(feature = "guest", no_std)]
#![no_main]
pub mod utils;
pub use utils::{Input, Output};

#[jolt::provable]
fn fib(input: Input) -> Output {
    let mut a: u128 = 0;
    let mut b: u128 = 1;
    let mut sum: u128;
    for _ in 1..input.n {
        sum = a + b;
        a = b;
        b = sum;
    }

    let out: Output = Output { output: b };

    out
}

Users can explore sample guest code in the sindri-resources repository to get started creating Jolt proofs.

We have expanded the slate of supported proving frameworks to include Plonky2 from Polygon Zero. Users who have previously utilized Sindri's API for Halo2 circuits, will find the project layout structure familiar. Here is an example sindri.json file that specifies the required fields for the Plonky2 framework.

{
  "$schema": "https://sindri.app/api/v1/sindri-manifest-schema.json",
  "name": "my-circuit",
  "circuitType": "plonky2",
  "structName": "my_rust_package::MyCircuit",
  "plonky2Version": "0.2.2",
  "provingScheme": "plonky2",
  "packageName": "my_rust_package"
}

To prove Plonky2 circuits, users must define three configuration parameters and implement the prove method for the MyCircuit struct. The three configuration parameters are:

• The extension field degree. For the Golidlocks field, this is typically set to 2.
• The hash function coonfiguration (either PoseidonGoldilocksConfig or KeccakGoldilocksConfig).
• The prime field.

// Extension field degree
pub const D: usize = 2;

// Hash function configuration
pub type C = PoseidonGoldilocksConfig;

// Prime field
pub type F = <C as GenericConfig<D>>::F;


pub struct MyCircuit{
    pub proof: ProofWithPublicInputs<F, C, D>,
    pub verifier_only: VerifierOnlyCircuitData<C, D>,
    pub common: CommonCircuitData<F, D>,
}

impl MyCircuit {
  pub fn prove(path: &str) -> Self {
  // Construct the arithmetic circuit using the Plonky2 CircuitBuilder
  // Load input data into the circuit using the path argument
  // Configure the partial witness and prove the circuit
  // Return an instance of the MyCircuit struct
  }
}

Users can explore some example circuits in the sindri-resources repository to get started creating Plonky2 proofs.

We're excited to announce enhanced support for Halo2 circuits structured as Cargo workspaces!

This update broadens Sindri's compatibility with various Halo2 project structures, making it easier for developers to work with more complex circuit architectures. Key improvements:

• Support for virtual workspaces: Sindri now accommodates Halo2 projects using virtual workspaces with no root package.
• Flexible package location: The main circuit can now be defined in any member package of the workspace, not just the root.
• Improved package discovery: A new method scans and maps all package locations within the uploaded project structure.

To use this feature, simply ensure your sindri.json manifest file correctly specifies the packageName field. No additional manifest fields are required - just upload your workspace as usual, and Sindri will handle the rest!

Note: you'll still want to be sure your main package being sent to Sindri is accompanied by all the supporting code defined locally which can be done through our SDK or CLI.

Sindri now supports Gnark version v0.10.0!

This update brings a host of new features and performance improvements to enhance your development experience.

With this upgrade, you can leverage Sindri with the latest advancements in Gnark (the full changes can be found in the Gnark release notes) including the following:

• Groth16 and PlonK Enhancements: This version includes the latest Groth16 and PlonK implementations.
• PlonK has been updated to the latest paper version which was previously incompatible with earlier Gnark versions.
• Efficient PlonK Recursion: Support for efficient PlonK recursion with 2-chains (BLS12-377 / BW6-761)
• Groth16 Solidity Verifier Enhancements: The Groth16 Solidity verifier now supports commitments

Sindri now supports Noir circuit versions v0.24.0 through v0.28.0!

This means you can utilize Sindri's accelerated proving backend while still benefitting from the exciting new zk-app development tools introduced by recent Noir versions. If you use v0.25.0 or above, you can combine the local Nargo codegen functionality to quickly autogenerate return types for proofs and public variables obtained via with Sindri's TypeScript SDK.

The rapidly-expanding Noir standard library is another reason to upgrade your circuits:

• With v0.24.0 or above, you can use Bounded Vectors to maintain dynamic lists efficiently.
• With v0.25.0 or above, you can use Hashmaps to encode key-value data structures within a circuit.
• With v0.28.0, you can use min and max to easily constrain the extreme values of a list.

We have broadened our coverage over the Halo2 ecosystem by integrating the PSE fork of Halo2 accelerated by Sindri proprietary algorithms across MSM and NTT. If you have previously utilized Sindri's API for Axiom v0.2.2 or Axiom v0.3.0 circuits, you will find that many of the requirements are the same. In particular, here is an example sindri.json file that specifies the required fields for the PSE v0.3.0 framework.

{
  "$schema": "https://sindri.app/api/v1/sindri-manifest-schema.json",
  "name": "my-circuit",
  "circuitType": "halo2",
  "className": "my_rust_package::MyCircuit",
  "degree": 8,
  "halo2Version": "pse-v0.3.0",
  "packageName": "my_rust_package"
}

Compatible circuits must implement the Circuit trait and provide definitions for the following two functions.

pub fn from_json(json_loc: &str) -> (MyCircuit<Fr>, Vec<Vec<Fr>>) {
  // Construct a circuit by loading a JSON file from the path argument
  // Also send back the concrete instances which should be passed
  // to create_proof
}

pub fn keygen_circuit() -> MyCircuit<Fr> {
  // Construct an empty or default circuit for key generation
}

You should expect broader curve coverage in the future! But for now, Fr above, must be the scalar field for BN254.

Check out some example circuits in the sindri-resources repository to get started creating proofs via the PSE fork of Halo2. You can also use the Sindri CLI init command to create a minimal PSE-halo2 template to work from.

Until recently, Groth16 was Sindri's only supported proving scheme when targeting the gnark framework. Today, we're pleased to announce support for the PlonK proving scheme with full GPU acceleration in gnark versions v0.9.0 and above. All you need to do to use PlonK as a proving backend is to set the provingScheme to plonk in your sindri.json manifest file, like so:

{
  "$schema": "https://sindri.app/api/v1/sindri-manifest-schema.json",
  "circuitStructName": "MyCircuit",
  "circuitType": "gnark",
  "curve": "bn254",
  "gnarkVersion": "v0.9.0",
  "name": "my-circuit",
  "packageName": "mypackage",
  "provingScheme": "plonk"
}

PlonK is particularly well-suited for situations where you need to write a large number of different circuits implementing separate business logic flows. The fact that it supports a universal trusted setup makes it easy to manage securely deploying many circuits compared to Groth16 (which requires circuit-specific trusted setups). For example, our friends over at Maya Labs are using Gnark PlonK circuits with Sindri to provably verify the integrity and trustworthiness of digital media.

You can check out Consensys' guide on proving schemes and curves to learn more about the tradeoffs between Groth16 and Plonk!

Previous to this release, your import of the Sindri API client in a python script looked something like this:

from sindri.sindri import Sindri

As a small act of service, we've simplified that to

from sindri import Sindri

No need to update your existing code, as the old version version still works!

This release of Sindri's CLI allows you to share and learn from public circuits. Specifically, any version tag of any circuit marked as a public project can be downloaded via the sindri clone command.

All of the circuits in our sindri-resources database are public projects and are available to clone. Try something like:

sindri clone sindri/decision-tree:public

Prove via Public Circuits​

This release of the API allows you to prove from circuits that have previously been compiled from any other user or team, as long as they are marked public.

All of the circuits in our sindri-resources database are public projects and are available to clone. Try something like:

prove sindri/multiplier2:public '{"X":7, "Y": 3}'

Streamlining Proof Lists​

Previously, when you requested a list of proofs from a circuit, the API sent back one bulk response containing all of the details for all proofs. For an older circuit that has built up many proofs over time, this can cause sluggish behavior while your application receives and processes all that data.

As of this release, the proof detail endpoint is the only place where you can retrieve the full data for a proof (including the proof and public fields). You can still incorporate logic into your application that retrieves all of the proofs for a single circuit; you'll just have to separate that process into two steps:

1. Request all of the proofs for a specific circuit
2. Loop over the proof_id field and request the proof details for each