Interstellar: Full ZK Pipeline for Noir + Soroban Using BLS12-381 - Ratherlabs

[sebastianlujan]

Interstellar: BLS12-381 Proof Integration for Stellar - Ratherlabs

Summary

Interstellar is a proposal to build a critical bridge between the Noir programming language and the Stellar network. We will develop a new proving backend for Noir that utilizes the BLS12-381 elliptic curve. This will empower developers to write zero-knowledge (ZK) programs in Noir and generate proofs that can be verified by a Soroban smart contract on the Stellar blockchain, all without requiring any changes to the Stellar protocol. This project will unlock a new generation of privacy-focused applications on Stellar, from confidential transactions to identity solutions

The Opportunity: Why This Matters for Stellar
Stellar has a significant advantage with its native support for the highly secure BLS12-381 pairing friendly elliptic curve. However, there's a missing piece: a straightforward way for developers to use this advantage for ZK-proof verification on-chain.

On the other hand, Noir is rapidly becoming the go-to language for ZK development due to its ease of use. But, its default backend, Barretenberg, is built on the BN254 curve, this curve offers only ~100-bit security and is not natively supported in Stellar. BLS12 provides ~128-bit security and is increasingly the curve of choice for modern zk-SNARK applications

Our solution bridges this gap. Instead of costly and complex protocol changes, Interstellar provides a direct, developer-friendly path from a Noir program to a verifiable proof on Soroban.

Interstellar introduces a new ACVM (Abstract Circuit Virtual Machine) backend for Noir, leveraging the powerful and battle-tested Arkworks Rust libraries. This creates a seamless development

Our project will:

• Develop and integrate a BLS12-381 ACVM backend for Nargo, enhancing Noir’s cryptographic efficiency.
• Implement Arkworks’ Groth16 prover and verifier within the Nargo ecosystem, optimizing proof generation and verification performance.
• Deploy a robust WASM verifier contract compatible with Stellar’s Soroban, facilitating secure and efficient on-chain proof verification.

Provide extensive documentation, open-source implementation, and developer-friendly tooling to streamline adoption.

sequenceDiagram
    participant Dev as Developer
    participant Nargo as Nargo CLI
    participant Interstellar as Interstellar Backend
    participant Soroban as Soroban Verifier Contract

    Note over Dev: Writes Noir Circuit (e.g., private_tx.nr)

    Dev->>Nargo: nargo prove
    Nargo->>Interstellar: Compiles to ACIR & requests proof
    Interstellar->>Interstellar: Generates Groth16 proof & Verifying Key (BLS12-381)
    Interstellar-->>Dev: Returns proof.json and vk.json

    Note over Dev: Deploys Verifying Key to a Soroban contract

    Dev->>Soroban: Submits proof for verification
    Soroban->>Soroban: Verifies proof using the deployed key
    Soroban-->>Dev: Returns Verification Result (true/false)

Loading

Key Goals

• Seamless Noir Integration: Developers will use standard Noir tooling. A simple flag, like nargo prove --backend interstellar, will be all that's needed.

• Stellar Verifiability: We will deploy a lightweight Soroban smart contract to verify proofs on-chain, leveraging Stellar's native BLS12-381 host functions for maximum performance and security.

• Developer-First Experience: Ensure a smooth pipeline from Noir → Interstellar → Soroban with minimal changes for existing Noir developers. We will provide comprehensive documentation, example projects, and automated tooling to make building private dApps on Stellar as easy as possible.

• Security & Performance: Use robust, audited libraries (Arkworks, blst) and, where possible, Stellar’s host functions for elliptic curves to ensure verification is secure and efficient. BLS12-381 is more secure than BN254, and the Stellar team has signaled strong support for BLS12-381 going forward
  Stellar talk

• Future Work & Extensibility: The modular design of our backend, conforming to Noir's ACIR interface, paves the way for future enhancements. While this proposal's scope is focused on delivering a robust Groth16 system, the architecture will readily support other proving systems. Future development could include:

PLONK Integration: Adding support for PLONK to enable circuits with custom gates.
UltraPLONK: Evolving to support lookup arguments for even greater efficiency in certain applications.

Solution

Interstellar introduces a new ACVM backend that targets BLS12-381 using Arkworks’ ark_groth16 library. It compiles Noir-generated ACIR to R1CS constraints interpretable by Arkworks and outputs proofs and verifying keys consumable by a Soroban contract. This allows end-to-end ZKP generation and verification with high security and performance.

We implement this in three coordinated layers:

1. Noir Proving Backend with BLS12-381 (ACVM + Arkworks)

We develop a new proving backend for Noir that targets the BLS12-381 curve, fully compatible with the ACIR intermediate representation and Noir’s backend interface. This backend uses the Arkworks Rust cryptographic libraries to implement Groth16 proof generation over BLS12-381. This replaces the current BN254-only Barretenberg backend, unlocking better security and compatibility.

Outcome: Developers write circuits in Noir as usual and compile them into Groth16 proofs using BLS12-381.

2. WASM-Based Groth16 Verifier for Soroban
We build a no_std verifier using ark-groth16 and deploy it as a WASM smart contract on Soroban. This contract will verify BLS12-381 proofs (generated from Noir) on-chain, relying on native elliptic curve host functions where available, or using optimized in-WASM operations otherwise.

Outcome: Zero-knowledge proofs generated in Noir can be verified directly on the Stellar blockchain without external infrastructure or curve emulation.

3. End-to-End Tooling and Workflow Integration
We ensure a seamless developer experience across the entire pipeline:

Noir Source → ACIR → BLS12-381 Proof (Arkworks) → WASM Verifier (Soroban)
This includes CLI integration, documentation, example circuits, test suites, and performance benchmarks. The backend is designed to be modular, so future support for PLONK, Marlin, or recursive proofs can be added on BLS12-381 without reworking the system.

Technical Highlights

• ACIR-to-BLS12-381 Mapping: Translating ACIR circuits from BN254-native constraints to a BLS12-381 field domain, using explicit field lifting and constraint reinterpretation.
• Arkworks R1CS Integration: Constructing a full ConstraintSystem<Bls12_381::Fr> using Arkworks’ Groth16 gadget libraries.
• Modular ACVM Backend: Implementing Noir’s ACIR backend trait, enabling future extensibility (e.g., PLONK, Marlin) without changes to Nargo’s core logic.
• WASM Verifier Deployment: Building a no_std Rust verifier contract for Groth16, compiled to WASM, leveraging Stellar’s native BLS12-381 host functions.
• End-to-End Workflow: Developer-friendly flow:
  Noir Circuit → Interstellar(ACIR → Arkworks → Groth16 Proof) → Soroban Verifier

ACIR Overview and BLS12-381 ACVM Backend Design

What is ACIR? The Abstract Circuit Intermediate Representation represents arithmetic circuits in a solver-friendly format. At its core, ACIR consists of opcodes defining constraints between witness variables. For example, an ACIR Arithmetic opcode might encode a linear combination equals zero (an R1CS-style constraint), and ACIR BlackBox opcodes represent common non-linear gadgets (like hash functions, range checks, etc.)

• The ACIR is solved by assigning witness values that satisfy all constraints
  Once solved (all witness values known), the backend’s job is to prove that those constraints hold (without revealing private witnesses). ACIR is designed to be prover-agnostic, but does assume an underlying field arithmetic. In the Aztec implementation, ACIR uses a prime field of size ~254 bits (suitable for BN254)

Field compatibility challenge

ACIR in Noir is currently parameterized over the BN254 field. However, BLS12-381 has a different base and scalar field, There is no known algebraic isomorphism between these fields that preserves arithmetic and pairing operations in both directions. We do not rely on mathematical curve translations, but instead propose a compiler-level field reinterpretation and backend modularity strategy.

• BN254: 254-bit prime field
• BLS12-381: Base field = 381-bit, Scalar field ≈ 255-bit

Given an integer x ∈ ℤ_p, where p = p_BN (BN254’s scalar field):
Since p_BLS > p_BN, the mapping x ↦ x ∈ ℤ_pBLS is injective.
Thus, arithmetic correctness and constraint integrity are preserved for all x < p_BN.

If we change the proving curve, the field changes: BLS12-381’s base field is 381-bit (and its scalar field is ~255-bit). Thus, one key task is adapting ACIR’s field arithmetic to BLS12-381’s field. New ACVM Backend (BLS12-381 + Arkworks): We will create a new backend that plugs into ACVM. In pseudocode, Noir’s backend trait might look like:

// A simplified representation of the backend trait we will implement
pub trait ACIRBackend {
    fn prove(acir: Acir, witness: WitnessMap) -> Result<Proof, BackendError>;
    fn verify(acir: Acir, public_inputs: WitnessMap, proof: Proof) -> Result<bool, BackendError>;
    fn generate_verifying_key(acir: Acir) -> Result<VerifyingKey, BackendError>;
}

• Witness Map Conversion: The ACVM will supply the solved witness values (each mod the ACIR field prime). We must interpret these values as elements of the BLS12-381 scalar field. For consistency, we will likely compile Noir with an ACIR field of the same size as BLS12-381’s scalar (to avoid any potential overflow issues). If that is not directly supported, our backend will map BN254-field values into BLS12-381 field by treating the integers as usual lib.rs

Constraint Translation: For each ACIR opcode:
Arithmetic constraints: These are expressions of the form ∑(coeff * witness) = 0. We add these to the Arkworks constraint system builder (cs) as linear constraints. If ACIR’s arithmetic gate supports non-linear terms (multiplications), we will linearize them via introduction of intermediate witnesses as needed (Noir might already handle multiplication by creating intermediate constraints).

Black box functions: ACIR defines certain black-box opcodes our BLS381 backend will support a subset of these.

• For example, range checks can be translated to multiple constraints (bit decomposition constraints in R1CS).
• We will leverage Arkworks gadget libraries if available (e.g., Poseidon gadget in arkworks for hashing) or implement simple versions.
• The focus is on basic arithmetic and boolean constraints, which cover many use cases.

R1CS Completion: After translating all ACIR constraints to Arkworks, we will have a complete ConstraintSystemBLS12-381::Fr. We then invoke Arkworks to generate proving and verifying keys (PK/VK).

• Arkworks provides an API to generate keys from the constraint system for Groth16. We’ll use ark_groth16::generate_random_parameters(cs, rng) which returns ProvingKey and VerifyingKey.

Proof Generation

Using the solved witnesses, we call ark_groth16::create_random_proof(proving_key, witnesses, rng) to get a proof. The proof (for Groth16) consists of curve points $A$, $B$, $C$ in G1/G2.
Verification (off-chain): For completeness, the backend can verify proofs by calling ark_groth16::verify_proof(verifying_key, public_inputs, proof). However, our ultimate goal is on-chain verification, so the more important output is the verifying key and proof, which will be used in Soroban.

By implementing these, we effectively enable Nargo to target BLS12-381. A developer would invoke Nargo with a flag (e.g., --backend bls381), and Nargo will use Interstellar’s backend to produce the proof and verifying key. ACIR Field Mapping (BN254 → BLS12-381): As noted, ACIR’s default field is tied to BN254.

We have two approaches here:

Approach A Compiler-Level Output (Preferred)

• Configure Noir to emit ACIR using BLS12-381's scalar field (≈255-bit).
• Cleaner integration if Noir supports configurable field moduli.

Approach B Post-Compilation Mapping (Fallback)

• Translate each BN254 constraint into the BLS12-381 field.
• Since p_BLS > p_BN, any equality that holds mod BN254 will also hold mod BLS12-381, provided:
  • No overflow occurs
  • Coefficient sums are within bounds

If an ACIR constraint uses a constant that is encoded mod BN (e.g., a large constant), we will lift it mod BLS (which should represent the same integer since the constant is presumably smaller than both moduli).

ACIR and ACVM: The ACIR is executed and solved by an Abstract Circuit Virtual Machine (ACVM) which handles witness assignment and constraint solving before passing to the prover. The ACVM defines a trait (interface) for backends – essentially, a backend needs to take the solved ACIR (constraints + full witness values) and produce a proof (and verifying key), or verify a proof against a verifying key. To integrate BLS12-381, we will implement this backend trait, using Arkworks under the hood for the cryptography.

The Soroban Verifier Smart Contract

We will provide tooling to generate a highly optimized WASM verifier contract for Soroban. This contract will embed the verifying key, making it specific to a particular Noir program

// Example of a Soroban verifier contract entrypoint
#[contractimpl]
impl VerifierContract {
    pub fn verify(env: Env, proof: Bytes, public_inputs: Bytes) -> bool {
        // 1. Deserialize proof and public inputs
        // 2. Load the embedded verifying key
        // 3. Call Soroban's native BLS12-381 pairing functions
        // 4. Return the result of the pairing check
    }
}

Verifier Contract Generation: After producing the proof and verifying key, developers need a Soroban contract to perform the verification logic. We will provide a tool or template to generate this contract:

• The contract will likely be written in Rust (using Soroban SDK) and then compiled to WebAssembly (WASM). We will supply either:
  • A generic contract where the verifying key can be uploaded, or
  • A auto-generated specific contract with the verifying key embedded.

Given typical usage, we lean towards generating a specific contract per circuit with the VK embedded:

• This contract could be generated by a Nargo command, reading the vk.dat and producing a Rust source file containing it

• The contract will have a single entry point verify(proof: Bytes, public: Bytes) -> bool. (Public inputs could be concatenated into one Bytes or passed as an array of field elements; we’ll define a clear ABI.)

• Having the VK embedded means the contract is only usable for that circuit, but that’s acceptable since each circuit (Noir program) often has its own verifier. This avoids storing large VK data on-chain as state, at the cost of larger contract code size. Given Soroban’s WASM code size limits are high and VKs for typical circuits are on the order of a few kilobytes, this is feasible.

Compilation to WASM

The contract, once generated, is compiled with cargo build --target wasm32-unknown-unknown --release. The result is a .wasm file that can be deployed to Soroban. We will ensure that the contract code is efficient (dead code elimination, etc., so that unused functions from Arkworks or blst are not included). Deployment: Using Stellar’s CLI or SDK, the developer deploys the WASM to the network. They then have a contract ID which they can invoke. If using an initializer to set the VK (in the case of a generic verifier contract), they would call that once with the VK bytes.

On-Chain Verification Logic
Groth16 Verification Basics: To verify a Groth16 proof, the contract must:

• Compute pairings between certain combinations of proof elements and verifying key elements.

• Check that these pairings satisfy the equation: $e(A, B) \stackrel{?}{=} e(C, vk_\gamma) \cdot e(vk_\alpha, vk_\beta)$ (this is a simplified form; actual equation accounts for public inputs embedded in $C$). Essentially, it boils down to evaluating a product of up to 3 or 4 pairings and verifying equality to another pairing.

• We will utilize these functions for efficiency:
  The contract will call, for example, soroban_env::crypto::Bls12_381::pairing(g1_point, g2_point) to get a GT (pairing result) element. Then multiply pairing results as needed, or directly use a provided pairing check function if available.

If the host provides a single call to do multiple pairings (like Ethereum’s PAIRING_CHECK that takes a list of pairs and returns true if overall product is identity), we will use that for brevity and gas savings.

Tooling and Frameworks

• We will use Rust’s built-in testing framework for unit tests of the backend crate.
• For integration tests, we can set up a Rust test that spins up Soroban’s test environment (there is a crate soroban-env-host that can simulate contract execution in-memory). This would let us call our contract methods directly in a test without needing an external network.
• We will also provide a set of example Noir circuits in a examples/ directory of the repo, each with a script to run proof generation and verification on a local Soroban network. This serves as both documentation and a regression test suite for our system.
• Continuous integration (CI) will be configured to run all these tests on every push, ensuring we catch regressions early.

Timeline 20 Weeks

Core Backend Development (Weeks 1–10)

Weeks	Goal	Deliverables
1–2	Backend Architecture & ACIR Mapping	- Define ACIR trait for BLS12-381 - Set up modular Rust backend (bls381-arkworks-backend) - Initial Noir CLI integration (nargo --target bls381)
3–4	Groth16 + R1CS Translation	- Implement ark_groth16::create_random_proof and verify_proof - Translate ACIR opcodes to Arkworks R1CS - Ensure BN254 → BLS12-381 field mapping
5–6	Verifier Generation & WASM Contract	- Compile Rust verifier to WASM - Use bls12_381 host functions in Soroban - Deploy verifier on Soroban localnet
7–8	Testing & Performance Profiling	- Write unit + integration tests - Benchmark proof size, runtime, and gas cost - Test edge cases (e.g. invalid or empty proof)
9–10	Docs, Examples, Open Source Launch	- Developer documentation and examples - Open-source CLI tool, contract, backend - Community announcement and onboarding

---

Integration & Developer Tooling (Weeks 11–20)

Weeks	Goal	Deliverables
11–13	Dev Tooling & Error Handling	- Improve nargo UX and diagnostics - Add support for Pedersen, range checks
14–16	SDK Wrappers & Verifier ABI	- Safe ABI crate for verifier - SDK helpers like verify_zk_proof, format_vk
17–18	Real-World Use Case Integration	- zkCreditScore demo application example - Full dApp using Soroban + Noir proof
19–20	Grant Report & CAP Proposal	- Document verifier interface + constraints - Submit CAP for native BLS12-381 precompiles - Publish benchmarks + roadmap

The Team

Ignacio Fabre — Head of Innovation

PhD in Theoretical Physics with 15+ publications. Former ML professor, co-founder of TranscribeMe, and current Head of Innovation at Rather Labs. Leads R&D on ZK cryptography and blockchain infrastructure, including advanced tooling and smart contract systems.

Sebastián Luján — R&D Blockchain Engineer

[email protected]
Blockchain engineer with 5+ years in Solidity, Rust, and systems design. Finalist at the Noir Hackathon for ZK-Drop (ZK proof-of-location). Contributor to ETH Uruguay and ETH Argentina. Builds cross-chain DeFi, NFTs, and ZK integrations.

Start Date

Jun 6 2025

[aolieman]

An opportunity well-spotted!