🛰️ UltraHonk Verifier for Soroban: Arkworks-Based Rapid Prototyping & BN254 Precompile Integration

[yugocabrio]

🛰️ UltraHonk Verifier for Soroban: Arkworks-Based Rapid Prototyping & BN254 Precompile Integration

This proposal reflects our initial plan, and we welcome feedback or suggestions to align it better with community needs.

🔄 Changelog

• May 14, 2025 – Initial version submitted. As with our UltraHonk Verifier proposal for Arbitrum Stylus, we planned to extract the verifier from co-noir’s UltraHonk (Arkworks-based), refactor it to no_std, and implement BN254 elliptic curve operations from scratch in userland Rust for Soroban.
• May 16, 2025 – Added mathematical discussion of the BN254 curve and detailed smart contract-level implementation plan.
• May 21, 2025 – Revised strategy based on feedback from the Stellar team: we now propose to integrate BN254 as a native precompile via CAP and rs-soroban-env, following the successful precedent of CAP-0059: Host Functions for BLS12-381.

📌 Summary

We propose a Rust implementation of the UltraHonk verifier (from Taceo Labs’ co-noir), which is compatible with Aztec/Barretenberg proof formats and adapted for deployment on the Stellar Soroban.

Our primary goal is to deliver an end-to-end verifier prototype that runs on Soroban’s no_std environment using Arkworks-based BN254 (ark_bn254). This enables rapid development and immediate compatibility testing with Noir proofs, while deferring native cryptographic integration as a future optimization via host functions (CAP).

The verifier will use a modular elliptic curve abstraction trait, enabling the same core logic to operate over multiple cryptographic backends. This allows us to begin with a functional Arkworks-based verifier for development, while maintaining the possibility of transitioning to a native BN254 backend via host functions for the future.

This phased approach ensures:

• Phase1: Quick delivery of a working UltraHonk verifier within Soroban’s localnet and dev environments using ark_bn254.
• Phase2: Future on-chain support architecture, enabling seamless upgrade to a native BN254 backend when host function support is added via CAP.

Our primary deliverable is a fully functional and testable verifier prototype using Arkworks.

Thanks to the EC abstraction trait interface, we ensure that Phase 1 (Arkworks backend) and Phase 2 (native precompile) share the same core logic, requiring no major rewrites.

🌟 Motivation

Noir, Aztec’s universal zkSNARK language, outputs proofs using the Barretenberg backend targeting the BN254 curve (alt_bn128) — widely adopted across Ethereum-compatible ZK systems.

However, Soroban currently supports only BLS12-381 via host functions, making it impossible to natively verify Noir-generated proofs. This limits integration with tools like Barretenberg and constrains ZK-based use cases.

To address this, we propose bringing UltraHonk, Aztec’s recursive SNARK verifier, to Soroban in a way that is feasible today and future-compatible with native BN254 support.

We propose building on the well-maintained, community-recognized co-snarks(co-noir) Rust-based UltraHonk implementation, which already targets Barretenberg v0.86.0. Rather than starting from scratch, we will adapt this mature Rust codebase to Soroban, ensuring correctness, upstream compatibility with Noir ecosystem, and efficient use of engineering resources focused on integration to Stellar Soroban and optimization.

🧭 Strategy Shift: Prototype First with Arkworks, Plan for Native Integration

Feedback from the Soroban core team confirmed that BN254 operations in WASM exceed on-chain compute limits, especially for pairings. The recommended path is to use native host functions, as done for BLS12-381 (CAP-0059).

In response, we will:

• Start with a functional ark_bn254-based prototype in localnet (no compute limits),
• Then plan for native BN254 host function integration via CAP for production use.

This two-phase strategy balances immediate progress with long-term viability.

1. Phase 1: Rapid Prototyping with ark_bn254

   • Use ark_bn254 to prototype the UltraHonk verifier in localnet, where compute is unrestricted.
   • Validate full proof verification against Noir/Barretenberg outputs.
   • Refactor co-noir’s std-based verifier to no_std for Soroban.
   • Structure verifier logic around a pluggable EC abstraction trait, allowing easy backend replacement.

2. Phase 2: BN254 Host Support via CAP

   • Draft a Soroban CAP to propose native BN254 host functions (e.g., g1_add, pairing).
   • Submit a reference PR to rs-soroban-env and SDK, modeled on BLS12-381.
   • Enable efficient on-chain verification within Soroban’s compute limits.

🔧 Technical Constraints & Design Motivation

• Arkworks (ark_bn254) is actively maintained and used in co-noir — ideal for fast prototyping and integration.
• Soroban’s no_std WASM target restricts std, but supports ark_bn254 via its SDK allocator.
• Our verifier design will abstract EC operations via traits, so we can write the verifier logic once, and support both:
  • Fast prototyping and correctness validation with Arkworks,
  • Efficient and practical deployment with a native BN254 backend.

🌐 Ecosystem Impact

This project will deliver:

• A working UltraHonk verifier prototype with ark_bn254, locally verifiable with unlimited compute.
• A CAP, implementation of BN254 precompile in Soroban native environment, and its SDK.
• UltraHonk Verifier for Soroban with BN254 Precompile backend.

⚙️ Methodology

We will begin by developing and testing in Soroban’s localnet environment, where relaxed compute limits allow end-to-end validation of proof verification using ark_bn254. This enables us to iterate quickly without being blocked by on-chain constraints.

Our approach consists of two complementary tracks:

1. A no_std-compatible UltraHonk verifier prototype using ark_bn254, enabling local testing of proof format compatibility, hashing, and verification logic.
2. A stretch goal to propose and implement BN254 host functions as Soroban precompiles via a CAP. This would unlock full on-chain proof verification under real compute budgets.

By architecting the verifier around a modular elliptic curve trait, we ensure the core logic remains backend-agnostic — supporting seamless transitions from Arkworks-based development to future native precompile integration.

Phase 1: Rapid Prototyping with ark_bn254

1. Verifier Extraction & no_std Refactor

Verifier Extraction

• Start with the existing UltraHonk verifier implementation from Taceo Labs' co-noir repository.
  • Analyze src/verifier.rs, src/decider/, src/oink/, and src/transcript.rs, and trace all proof structure, memory, and transcript dependencies.
  • Identify the minimal set of types required for proof, verification key, and transcript compatibility.

no_std Refactor

We will refactor the UltraHonk::verify stack into a #![no_std]-compatible crate tailored for Soroban's WASM runtime.

• Std removal: Replace std types (Vec, String, Arc, etc.) with alloc equivalents or eliminate where unneeded. Disable tracing via #[cfg(feature = "std")].
• Dependency auditing: Ensure ark-ff, ark-ec, ark-bn254, and co-builder are no_std-aware (default-features = false). Replace eyre with lightweight error types or Result<T, ()>.
• Memory model: Avoid dynamic allocations. Use fixed-size buffers or heapless::Vec, and allocate with Box where necessary to align with WASM's memory model.
• Deserialization: Eliminate serde and file I/O. Reimplement Transcript and Manifest using alloc or static structures, and parse .proof and .vk from &[u8] buffers.
• We will expose an internal verification function in the form:

  pub fn verify_proof<B: G1ArithmeticBackend>(
      proof: &HonkProof,
      vk: &VerifyingKey,
      public_inputs: &[Fr],
      zk_flag: ZeroKnowledge
  ) -> bool

• Compatibility Verification
  • Generate Noir proofs via Barretenberg-compatible CLI
  • Export proof and verification keys
  • Ensure our extracted and no_std refactored UltraHonk Verifier can verify the proof correctly
  • Validate hashing/transcript compatibility

2. EC Trait Abstraction: Pluggable Backend Architecture

Following the architecture used in Renegade-Fi and our Stylus proposal, we introduce a unified trait that abstracts the core elliptic curve operations required by the UltraHonk verifier. Renegade-Fi uses Arkworks for development and switches to EVM precompiles for on-chain use. While Stylus and Soroban differ, both support Rust-based WASM, making this dual-backend model equally applicable to Soroban.

We define a unified interface, G1ArithmeticBackend, which encapsulates the core elliptic curve operations required for pairing-based proof verification:

pub trait G1ArithmeticBackend {
    fn ec_add(a: G1Affine, b: G1Affine) -> Result<G1Affine, Error>;
    fn ec_mul(scalar: Scalar, point: G1Affine) -> Result<G1Affine, Error>;
    fn pairing(p: G1Affine, q: G2Affine) -> Result<GT, Error>;
}

The verifier logic will be wrapped in a generic struct over the backend:

pub struct Verifier<B: G1ArithmeticBackend> {
    backend: PhantomData<B>,
}

impl<B: G1ArithmeticBackend> Verifier<B> {
    pub fn verify_proof(
        &self,
        proof: &HonkProof,
        vk: &VerifyingKey,
        public_inputs: &[Fr],
        zk: ZeroKnowledge,
    ) -> bool {
    }
}

This abstraction cleanly separates the cryptographic implementation from the proof logic, allowing backends to define their own elliptic curve operations and associated serialization/deserialization strategies.

Phase 1: ArkworksBackend Implementation for Development

In the development phase, we implement this trait for Arkworks via ark_bn254, resulting in an ArkworksBackend. This backend will be used to run the verifier end-to-end within Soroban’s localnet environment, where compute limits can be relaxed. It enables immediate validation of Noir-generated Barretenberg proofs in a testable and debuggable context.

Phase 2: SorobanPrecompileBackend for On-Chain Deployment

In the deployment phase, we implement a second backend, SorobanPrecompileBackend, where the trait methods are fulfilled via native host functions for BN254, introduced through a Soroban Core Advancement Proposal (CAP). These host functions will be exposed as precompiled operations, specifically designed for Soroban’s native SDK and runtime.

This backend enables full proof verification within Soroban's production compute budget, without altering the verifier logic itself.

⚠️ Note: While this abstraction approach is inspired by the architecture used in Renegade-Fi, our implementation will be designed specifically for Soroban’s WASM model and will not reuse any proprietary code.

🔁 Shared Infrastructure across Stylus and Soroban Tracks

This proposal is part of a unified UltraHonk strategy targeting both Stellar Soroban and Arbitrum Stylus.

Despite different runtimes, both verifiers:

• Share a common Rust codebase,
• Use the same no_std verifier core,
• Leverage a pluggable G1ArithmeticBackend trait.

This architecture ensures maintainability, consistent correctness across platforms, and engineering efficiency through shared infrastructure.

3. Soroban Smart Contract Interface

Once both the verifier logic and BN254 backend(ArkworksBackend) are complete, we expose the verifier as a Soroban smart contract callable from external clients or other contracts.

This contract interface is designed to be simple and developer-friendly, enabling on-chain proof verification with minimal integration overhead.

API

#[external]
fn verify_proof(proof: Bytes, vk: Bytes, public_inputs: Bytes, has_zk: bool) -> bool;

Inside the contract, we will deserialize all inputs from Bytes to native Rust types prior to invoking the core verifier:

let proof: HonkProof = deserialize_proof(&proof)?;
let vk: VerifyingKey = deserialize_vk(&vk)?;
let public_inputs: Vec<Fr> = parse_public_inputs(&public_inputs)?;
let zk_flag = if has_zk { ZeroKnowledge::Enabled } else { ZeroKnowledge::Disabled };

Phase 2: BN254 Host Support via CAP

Using the same verifier logic from Phase 1, we simply swap out the ArkworksBackend for a new SorobanPrecompileBackend. Thanks to the G1ArithmeticBackend trait, this transition is seamless and requires no changes to the core verifier code.

4. BN254 Precompile: CAP Proposal and Native Host Functions (Stretch Goal)

Our main deliverable is the ark_bn254-based prototype, but we intentionally structure the verifier to remain compatible with a potential native BN254 integration via a Soroban CAP, which we treat as an optional stretch goal. This allows us to seamlessly swap in native operations once available, without rewriting verifier logic.

The CAP and host-side implementation are planned as a stretch goal, to be pursued in parallel where feasible. If timing and review bandwidth allow, we will also draft the CAP specification and contribute a reference PR to rs-soroban-env.

a. Draft and submit a Soroban CAP defining BN254 host functions:

1. Introduction & Scope

   • Propose adding a set of native host functions to Soroban to support BN254 operations without inflating the WASM binary.
   • Scope covers curve arithmetic (G1, G2), pairing, subgroup validation, I/O formats, and error semantics.

2. Function Signatures & Semantics

Function	Inputs	Output	Description
bn254_g1_add	Bytes(g1), Bytes(g1)	Bytes(g1)	Affine addition on G1
bn254_g1_mul	Bytes(g1), U256(scalar)	Bytes(g1)	Scalar multiplication on G1
bn254_g2_add	Bytes(g2), Bytes(g2)	Bytes(g2)	Affine addition on G2
bn254_g2_mul	Bytes(g2), U256(scalar)	Bytes(g2)	Scalar multiplication on G2
bn254_pairing	Vec<Bytes(g1), Bytes(g2)>	Bool	Verify $\prod e(P_i, Q_i) = 1$ in GT
bn254_fp2_mul	Bytes(fp2), Bytes(fp2)	Bytes(fp2)	Low-level Fp2 multiplication (opt.)

Optional extensions: fp12_mul, fp12_exp, fr_add, fr_mul, etc.

3. Input/Output Encoding Formats

   • Fp / Fr: 32-byte Big Endian
   • Fp2: two consecutive Fp values (c1, c0)
   • Fp12: six Fp2 values in fixed order for final exponentiation inputs
   • G1 (affine): (x, y) → 64 bytes
   • G2 (affine): (x_im, x_re, y_im, y_re) → 128 bytes
   • Collections: BytesObject and VecObject per Soroban SDK conventions

4. Validation & Checks

   • Input Buffer Length check → ERR_INVALID_LENGTH
   • On-curve check → ERR_MALFORMED_POINT
   • Subgroup check → ERR_SUBGROUP
   • Perform cofactor-clearing; fail if result $\neq \infty$
   • Pairing result
     • If $\prod e(P_i, Q_i) \neq 1$, return false (ERR_PAIRING_MISMATCH only for internal logs)

5. References & Compatibility

   • Mirrors CAP-0059 for BLS12-381: same section numbering, table formats, and vocabulary.
   • Ethereum’s alt_bn128 precompile test vectors for conformance.
   • Barretenberg’s BN254 manifest for proof-generation compatibility.

b. Implement a reference PR to rs-soroban-env:

• host/bn254.rs: Rust definitions of each extern “C” host function stub.
• bn254_impl/: Pure-Rust optimized BN254 library (based on ark-bn254), no_std-compatible.
• tests/:
  • Unit tests against Ethereum JSON RPC alt_bn128 vectors.
  • Barretenberg proof fixtures for end-to-end SNARK verification
• Example snippet:

  // In a contract:
  let p_bytes: BytesObject = /* … */;
  let q_bytes: BytesObject = /* … */;
  let sum = bn254_g1_add(ctx, &p_bytes, &q_bytes)?;

• End-to-end demo in examples/zk_snark_verifier.rs.

c. Integrate SDK support:

1. Wrapper Functions

   pub fn g1_add(
       host: &Host,
       p: &BytesObject,
       q: &BytesObject,
   ) -> Result<BytesObject, HostError> {
       host.call_fn("bn254_g1_add", &[p.to_val(), q.to_val()])?
           .try_into()
   }

• Similar wrappers for g1_mul, g2_add, pairing, etc.

2. Type Conversions & Serialization

   • From (Point<Fp>, Scalar) $\rightarrow$ BytesObject using to_be_bytes().
   • From returned BytesObject $\rightarrow$ domain types with validation.
   • Utilities in soroban_sdk::bn254 module for high-level usage.

3. Example SDK Interface

   #[contract]
   pub fn verify_proof(
       ctx: &Host,
       proof: VecObject,
       vk: VecObject,
   ) -> bool {
       // Deserialize G1/G2 elements, call bn254_pairing, etc.
   }

This work is treated as a stretch goal — the verifier is fully usable with the Arkworks backend in development settings. Native precompile integration is only required for production-grade deployment.

5. Mathematical Structure of BN254

This section outlines the core mathematical structures needed for BN254 precompiles. Feel free to skip it if you're only looking to understand the overall proposal.

Soroban currently lacks native support for the BN254 elliptic curve (also known as alt_bn128), which is used in Noir/Barretenberg proofs. To enable on-chain proof verification within Soroban's instruction limit, we will build BN254 curve in precompiled layer. Also, we will commit our BN254 elliptic curve feature to native Soroban-SDK.

Key Components to Implement

1. G1 / G2 Arithmetic (Affine & Projective Coordinates)

• G1 (base curve over Fp):

  • Use curve equation: $y^2 = x^3 + 3$, with parameters $a = 0$, $b = 3$
  • Implement point addition and doubling in projective or Jacobian coordinates, following standard formulas (adapted from BLS12 code with $b = 3$)
  • Use the same point layout/struct as BLS12 for consistency and interoperability

• G2 (twist over Fp2):

  • Use sextic twist of the curve: $y^2 = x^3 + 3/\xi$ over $\mathbb{F}_{p^2}$
  • Represent points as two Fp2 coordinates
  • Adapt G1’s formulas to Fp2 arithmetic by replacing scalar operations with Fp2 ops and constants with $3/\xi$ equivalents
  • Example: projective formulas such as $X_3 = b_2 \cdot XY$, applied over Fp2

• Subgroup Checks:

  • G1: No subgroup check is needed, as BN254 has cofactor 1 on $E(\mathbb{F}_p)$—all curve points are already in the correct subgroup
  • G2: Twist curve has cofactor $c_2 \ne 1$. To ensure inputs lie in the $r$-torsion subgroup:
    • Perform a full scalar multiplication check: $[r]P = \mathcal{O}$
    • Or, use the endomorphism-based Galbraith–Scott test:
      $\psi^2(P) - [t]\psi(P) + [p]P = \mathcal{O}$
      where $\psi$ is the Frobenius endomorphism on $\mathbb{F}_{p^2}$

• Group Generators:

  • G1: Hardcode $P_1 = (1, 2)$, a generator of prime order $r$
  • G2: Use standard generator $P_2$ from EIP-197

2. Finite Field Arithmetic: Fp, Fp2, Fp6, Fp12

• Fp:

  • Implement over 254-bit prime field $\mathbb{F}_p$
  • Use 4×64-bit limbs (256-bit representation)
  • Support modular add, sub, mul, square, inv using Montgomery or extended Euclidean methods
  • Precompute constants:
    • $R^2 \bmod p$ for Montgomery form
    • $R^{-1}$, $p'$ for reduction

• Fp2:

  • Define $\mathbb{F}_{p^2} = \mathbb{F}_p[u]/(u^2 + 1)$ with nonresidue $\beta = -1$
  • Represent elements as $(a + bu)$
  • Implement standard complex arithmetic:
    add, sub, mul, square, neg, inv

• Fp6 (cubic extension over Fp2):

  • Define $\mathbb F_{p^6} = \mathbb F_{p^2}[v]/(v^3 - \xi)$, where $\xi = 9 + u$
  • Elements: $a + b \cdot v + c \cdot v^2$
  • Implement optimized multiplication and squaring using Karatsuba or Montgomery-style formulas

• Fp12 (quadratic extension over Fp6):

  • Define $\mathbb F_{p^{12}} = \mathbb F_{p^6}[w]/(w^2 - v)$
  • Represent elements as $c_0 + c_1 \cdot w$
  • Implement:
    • $(c_0 + c_1w)(d_0 + d_1w) = (c_0 d_0 + c_1 d_1 v) + (c_0 d_1 + c_1 d_0) w$
    • Efficient square, inv, and Frobenius map applications
  • Adapt BLS12 code with correct BN254-specific $\xi$

• Frobenius Coefficients:

  • Precompute all required Frobenius powers for $\mathbb F_{p^2}\text{ and }\mathbb F_{p^{12}}$
  • Replace BLS12’s coefficients with those derived from BN254’s structure

3. Pairing Computation

• Loop Parameter:

  • Use Optimal Ate pairing with $x = 4965661367192848881$
  • Miller loop executed over $6x + 2$ iterations (as per BN254 specs)

• Miller Loop:

  • Use double-and-add method to compute intermediate lines:
    • $l_{T,T}(P)$, $l_{T,Q}(P)$
  • Accumulate results in $\mathbb{F}_{p^{12}}$ via pairing function

• Final Exponentiation:

  • Raise Miller loop result to $(p^{12} - 1)/r$
  • Decompose into:
    • Easy part: $f^{p^6 - 1}$, $f^{p^2 + 1}$
    • Hard part: use Frobenius maps, cyclotomic subgroup tricks, or BN254-specific addition chains

6. Testing & Validation

• Use official Noir + Barretenberg CLI:
  • Compile Noir circuits (nargo compile)
  • Export witness (nargo execute witness)
  • Generate proof & vk via bb prove, bb write_vk
• Validate output against Rust no_std verifier.
• Unit test verifier logic independently of Stellar.
• Deploy verifier on Stellar network and simulate proof verification under realistic gas and memory constraints
• Cross-validate pairing results between Arkworks and our BN254 backends to ensure functional equivalence
• Validate consistent parsing and hashing of serialized inputs across backends and ensure exact proof reproduction across environments.
• Benchmark Soroban wasm form versus precompile backend

7. Deliverables

Phase 1: Prototype Verifier (Arkworks-based)

• Modular no_std Rust verifier crate using ark_bn254
• Trait-based EC abstraction layer (backend agnostic)
• Test suite with end-to-end proof validation (Noir/Barretenberg-compatible)
• Verifier contract template runnable in Soroban localnet
• Documentation for verifier integration and usage

Phase 2 (Stretch Goal): BN254 Precompile Integration

• Draft of Soroban CAP defining BN254 host functions
• Reference implementation of BN254 host functions in rs-soroban-env
• SDK wrapper functions in rs-soroban-sdk
• On-chain verifier integration using native host calls

📅 Schedule

Phase 1

Week	Goal
1–2	Kickoff & Verifier Extraction • Project kickoff: clone co-noir UltraHonk repo, spin up Soroban localnet, CI baseline • Extract core modules (verifier.rs, transcript.rs, decider/, oink/) • Stub out data structures for proof, VK, transcript
3–4	no_std Refactor & Dependency Audit • Remove std types in core modules: replace Vec, String, Arc → alloc/heapless • Disable tracing and file-I/O features • Audit & strip heavy deps (eyre, serde): substitute lightweight error types • Verify successful build on #![no_std] target • Finalize memory model: fixed-size buffers or Box alloc, avoid dynamic alloc • Reimplement Transcript parsing from &[u8] buffer
5–8	BN254 Backend & EC Abstraction • Define G1ArithmeticBackend trait (add, mul, pairing) • Wire up ark_bn254 for ec_add & ec_mul via ArkworksBackend • Implement pairing + subgroup checks in ArkworksBackend • Map Arkworks errors to our trait’s Error type • Hook ArkworksBackend into UltraHonk::verify logic • Eliminate residual std API calls
9–11	Contract Integration & Testing • Build Soroban contract stub for fn verify_proof(proof: Bytes, vk: Bytes, public_inputs: Bytes, has_zk: bool) -> bool; • Load proof/VK as Bytes in localnet • End-to-end proof validation: run Barretenberg proofs against #![no_std] verifier • Benchmark runtime in unrestricted localnet • Optimize hotspots (e.g. buffer handling, pairing calls) • Harden contract API: error codes, safe unwraps, logging • Add unit tests for edge cases (empty proof, malformed VK)
12	Documentation & Demo • Write README: getting started, build instructions, example CLI & contract calls • Prepare tutorial showing proof generation → on-chain verify • Internal demo for stakeholders: showcase prototype in Soroban localnet • Gather feedback & adjust Phase 2 plans

Phase 2

This schedule can be changed, as it will be a collaborative effort with the stellar team, but this is our overall schedule.

Week	Goal
13-14	CAP Spec Draft & Review • Outline CAP structure (mirror CAP-0059): intro, scope, function list • Define host fns: bn254_g1_add, g2_mul, pairing, etc. • Detail I/O encoding (Fp, Fp2, G1, G2 byte formats) • Specify error codes, length & subgroup checks • Circulate draft with Stellar core team • Incorporate feedback, finalize CAP document
15–21	Reference Precompile & Math Core Implementation • Add extern "C" host-function stubs in rs-soroban-env • Define raw byte interfaces for each BN254 op • Implement Fp arithmetic (add, sub, mul, inv) in 256-bit Montgomery form • Implement Fp2 (complex), Fp6 & Fp12 extensions • Implement G1/G2 projective formulas & subgroup checks • Miller loop & final exponentiation for Optimal Ate pairing
22–24	SDK Wrappers, Integration Tests & Final Report • Add high-level wrappers in soroban_sdk::bn254 (g1_add, pairing) • End-to-end tests: Noir → host precompile → contract verify • Consolidate deliverables, publish grant report with benchmarks & links

Total epoch: 24 weeks

👯 Team

Yugo Cabrio: Cryptography research engineer with experience across SNARK/STARK ecosystems. Integrated Circom with Sonobe’s folding scheme (PR), and authored technical explainers on Nova and Circle STARKs. Received community grants from PSE and zkBankai. Experienced in Rust-based implementation of cryptographic protocols, MEV tooling, and various ZKP schemes.

Contact: [email protected] / GitHub: @yugocabrio / Telegram: zeroxyg

Changmin Cho: Cryptography engineer with a strong mathematical background, particularly in algebraic topology. Implemented Circom-tfhe, zk-fft, and o1js-matrix for PSE and Mina. Interned at Nethermind, contributing to research on FRI and LatticeFold. Previously worked as a software engineer at a quantitative trading firm.

Contact: [email protected] / GitHub: @indextree / Telegram: indextree

AshWhitehat: Advisor to this project. A former zkEVM engineer at PSE, Ash has prior experience implementing BN254 and elliptic curve–based zkSNARKs from scratch. He and Yugo have held weekly technical study sessions for over two years, and he will continue to provide advisory input, particularly on the BN254 curve implementation.

Contact: GitHub: @ashWhiteHat

We will dedicate a combined 1.2–1.8 FTE (Full-Time Equivalent) per week to this project.

🔜 Start Date

June 7, 2025

[tomerweller]

Hey @yugocabrio, thanks for this excellent proposal! I'm Tomer from the product team at SDF.

Overall I think this is a great proposal with one caveat: I have some doubts about the feasibility and necessity of the custom BN254 backend.

As you can see in this example using ark_bn254 in a smart contract blows through the compute budget of a transaction by an order of magnitude: total limit is 100M instructions and this is 560M instruction for a single pairing. I believe that you can optimize the code but can you reduce it 10x?

With that said, I believe the main value prop of this proposal is to provide an end-to-end functional prototype of ultrahonk running on stellar/soroban. For the purpose of the prototype it's ok to blow through the budget using ark_bn254 since you can run local tests with unlimited budget and even run a local test network with increased limits.

If you do want to help take this to production in this proposal than instead of the custom backend I would consider creating a CAP for bn254 (similar to this for BLS12-381) and a PR implementing it to rs-soroban-env.

@jayz22 from the stellar core team, who implemented the bls12-381 proposal, can provide guidance.

[jayz22]

Hi @indextree, would you mind elaborating a bit on 2, what would that mean in terms concrete work and deliverables?

I assume the untrahonk protocol has already been developed and analyzed for correctness etc, and the version you guys built for Soroban will conform to the same standard in terms of mathematical correctness and code quality. Or do you mean additional code analysis tool will have to be built to achieve that?

From our standpoint, we would definitely like have a end-to-end integrated product on Soroban as the main goal, and to drive adoption from the existing noir ecosystem. For that we recommend sticking with guest-imported crypto libraries (i.e. ark_bn254) instead of trying to building them from scratch, that'll be the most useful allocation of time and resource (it's a lot easier for us to add bn254 host functions later if needed). Does that make sense?

[yugocabrio]

From our standpoint, we would definitely like have a end-to-end integrated product on Soroban as the main goal, and...

Thanks for the clarification. It makes perfect sense, and we’re fully aligned with your thinking.
We’ve also been leaning toward the same approach: delivering an end-to-end UltraHonk verifier prototype using ark_bn254 as the most direct and useful path, while keeping the architecture flexible for future native support via host functions.

We’ll be uploading the revised version of the proposal (with these changes reflected) within the next hour or so.

Thanks again for your helpful feedback.

[yugocabrio]

Thanks for the guidance @tomerweller @jayz22 — we’ve pushed an updated version of the proposal reflecting your suggestions.

The structure now clearly emphasizes our two-phase strategy:

• Phase 1: Rapid prototyping using ark_bn254 on Soroban’s localnet, to validate end-to-end proof verification.
• Phase 2 (Stretch): CAP proposal and host-side support for BN254.

We’ve focused on delivering a functional and testable verifier first, while keeping native integration as a future optimization.

Still polishing the draft, but the overall direction is now in place — we’d really appreciate any further feedback as we finalize.

[tomerweller]

Thanks @yugocabrio this is looking great, especially Phase 1.

Wrt Phase 2, one recent development is that some other teams in the Stellar ecosystem are working towards a Bn254 CAP and Host functions. Redundancy is not a problem but maybe we can direct your phase 2 towards something that is more noir-lang specific?

For example, maybe we can port over some noir+eth examples to Stellar/Soroban? Things like stealthdrop or others?

[yugocabrio]

Thanks! @tomerweller Really appreciate the feedback.
For Phase 2, we're happy to stay flexible and focus on where we can add the most value.

If native BN254 support is progressing with other teams, we’d be glad to start by integrating our verifier with the new host functions — and then shift focus to a Noir-specific application, such as porting a real-world use case to Soroban.

[Savio-Sou]

Hi @yugocabrio, thanks for the great write-up.

Similar to my comment in the other proposal, minor suggestion on "Testing & Validation" that testing compatibility with just Barretenberg (instead of Taceo's co-noir) could better benefit all Noir devs working with Barretenberg.

No other comment from me 👍