This update introduces essential team administration capabilities, making it easier to collaborate on projects.

What's New​

You can now manage your teams directly from the Sindri dashboard. The new team management interface allows you to create teams, invite team members via email, and oversee team membership all in one place. Team members can see their team affiliations and easily navigate between different team contexts.

Key Features​

The initial release includes core team management functionality:

• Team creation and membership overview
• Email-based team member invitations
• Self-service team membership management

Getting Started​

Visit the Settings section in your Sindri dashboard. From there, you can create new teams or manage existing ones.

Looking Ahead​

This release marks our first step toward more robust collaboration features.

Sindri now supports compiled Leo programs, enabling developers to leverage SnarkVM, the zero-knowledge virtual machine powering Aleo. Leo is a high-level language for writing applications on Aleo, while SnarkVM executes these programs efficiently using zero-knowledge proofs. One of the features of Leo that developers find beneficial is that it feels natural to use because it's designed with Rust-like syntax.

SnarkVM Integration & Network Specification

When using Sindri with SnarkVM, your project should include your Aleo program file(s) and a sindri.json file. Unique to SnarkVM, however, is the ability to specify the network inside this file. By default, the network is set to mainnet, but you can also specify testnet. A circuit must be compiled and proved on the same network, so the network must be provided during compilation, not just at prove time. Of course, if you are developing locally, no network needs to be specified.

Additionally, your functionName should specify the function in your main Aleo program that you want Sindri to prove. An example sindri.json with these fields demonstrated is below:

{
  "name": "battleship_initialize_board",
  "circuitType": "snarkvm",
  "functionName": "initialize_board",
  "network": "mainnet"
}

Input Passing for Aleo Programs

If your Aleo program includes a record or network definition, you will need to supply a private key in your input.json file. Important: Only use development/test private keys - never include production or mainnet private keys in your input files. Production private keys should be managed through secure key management systems. An example input.json is below:

{
  "PRIVATE_KEY": "APrivateKey1zk...",
  "inputs": ["aleo14vccuxzlf2rsh8rf6ky...", "100000u64"]
}

Example Implementations

For more details and example implementations, check out our Sindri resources repository.

Sindri now supports the SP1 zkVM, streamlining the integration of production-ready proving frameworks into developer workflows. Together with our Jolt integration, this makes zkVM-as-an-API through Sindri both accessible and indispensable for the modern developer toolkit.

To generate SP1 proofs on Sindri, developers upload a project directory containing the guest code files along with the a sindri.json manifest.

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

All self-contained guest code examples from the SP1 examples directory are uploadable to Sindri. Guest programs that reference struct and function definitions outside of the program/ directory will need to be modified so that those definitions are included with the guest code files uploaded to Sindri.

An example of a sindri.json file that specifies the required fields for a SP1 project is shown below:

{
  "name": "fibonacci",
  "circuitType": "sp1",
  "provingScheme": "groth16",
  "sp1Version": "3.0.0"
}

Users can specify one of four supported SP1 proof types by changing the provingScheme field in the sindri.json file to one of: core, compressed, plonk, or groth16.

Proof inputs submitted to Sindri should be formatted as an SP1 SP1Stdin struct:

{
  "buffer": [[20, 0, 0, 0]],
  "ptr": 0,
  "proofs": []
}

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!