bn254 host functions

[tomerweller]

Should we introduce host functions to support the bn254 pairing friendly ellipctic curve?

Creating this issue to collect signal and to unpack the required set of host functions.

Currently, Soroban only supports the bls12-381 pairing friendly elliptic curve (prior discussion). Originally we chose bls12-381 over bn254 given its better security properties and adoption/momentum within the zk community. Bls12-381 has indeed gained more adoption (eip2537 is in the Ethereum Pectra upgrade). However, many ZK applications still rely on the bn254 ellptic curve.

Some of these applications include:

• Risc0 ZkVM verifier
• NoirLang UltraHonk verifier

[Savio-Sou]

Elaborating on @tomerweller's original post, the most popular Noir proving backend thus far is UltraHonk Barretenberg (which is BN254-based). Introducing host functions on Stellar would fundamentally improve Noir devs' journeys in building and deploying privacy apps with Stellar.

On top of that, there are also many new researches and developments on top of BN254 still (e.g. PSE recently released their Metal MSM v2 research). It's a popular and active elliptic curve, and could likely remain so.

[Fantoni0]

In addition to the points already discussed, these host functions will also enable the possibility of defining algebraic hash functions (e.g., Poseidon2) over BN254. This will enable having the same hashes as other popular implementations, facilitating adoption and interoperability:

• Projects bridging from/to Stellar can benefit from having equivalent hashes. No need for foreign arithmetic, easy to verify, possible to use on-chain accumulators.
• As already mentioned, most ZK provers/libraries will target BN254 due to its popularity. Having equivalent hashes to these implementations will greatly improve the dev experience.

[yugocabrio]

Hi, we are building an UltraHonk (Noir/Barretenberg, BN254) verifier for Soroban.

• Status: Off-chain verification works in Rust using Arkworks BN254 with bb v0.87.0 / Nargo 1.0.0-beta.9.
• Blocker: On-chain is not feasible today because BN254 host functions are missing. A pure-WASM fallback is likely to exceed the ~64 KB contract code size and blow CPU budgets.

Minimal host functions we need

• G1 MSM: batched multi-scalar multiplication on G1 to avoid excessive host-call overhead.
• Pairing product check: accept a list of (G1, G2) pairs and return whether Π e(Pᵢ, Qᵢ) == 1.
• Encodings & checks: clear point/field encodings (prefer uncompressed big‑endian; e.g., G1: x‖y with 32B each; G2: x.c1‖x.c0‖y.c1‖y.c0 with 32B each), reject non‑canonical encodings, enforce on‑curve & subgroup checks (including cofactor handling), and define the infinity representation
• Optional helpers: single G1 add/mul; G2 add/mul (convenient but not required for our verifier if the pairing-product API exists).

Questions

• Any devnet/feature flag or tentative timeline we could test against?

We’re happy to integrate against early/flagged BN254 host functions and provide conformance & performance feedback (with Barretenberg v0.87.0 vectors for G1/G2, pairings, MSM).

Repos:

• Rust verifier: https://github.com/yugocabrio/ultrahonk-rust-verifier
• Soroban harness: https://github.com/indextree/ultrahonk_soroban_contract

Thanks!

[sisuresh]

Thanks for the feedback! For my own understanding, I wanted to ask how feasible it would be to adapt these applications that use bn254 to bls12-381. What are the challenges?

[Savio-Sou]

Swapping Barretenberg's field from BN254 to BLS12-381 would require something in the range of multiple months from a cryptographic engineering team dedicating full time towards engineering the initiative, then re-audits.

Not necessarily infeasible, but it would be a multi-million dollar effort for Barretenberg alone.

[sisuresh]

Are the following host functions sufficient? The EVM has support for addition, scalar multiplication, and the pairing check, which are more than covered here.

bn254_g1_add
bn254_g1_mul
bn254_g1_msm
bn254_g2_add
bn254_g2_mul
bn254_g2_msm
bn254_multi_pairing_check

[sisuresh]

I've seen some support for add and mult on the G2 group in other libraries. msm on G1 was requested by @yugocabrio. The set of functions above expand on what's available on Ethereum with additional functions that are easy to implement. On the other hand, if they aren't necessary, I think it makes sense to keep the added functions to a minimum for simplicity, especially because we should be encouraging the use of bls12-381 over bn254.

The following gives us parity with Ethereum -

bn254_g1_add
bn254_g1_mul
bn254_multi_pairing_check

@yugocabrio is msm on G1 required if add/mul are included?
@Savio-Sou and @Fantoni0 are these host functions sufficient for your use cases?

[sisuresh]

To be clear, I don't think it's an issue to add msm on G1, but I'd like to gather input on what is required.

[Fantoni0]

Yes @sisuresh , that would be enough for our use cases. Thanks 🙏

[Savio-Sou]

For EVM parity with Barretenberg: add, mul, and pairing check on the G1 curve are sufficient.

[yugocabrio]

Yes. For our UltraHonk verifier, bn254_g1_add, bn254_g1_mul, bn254_multi_pairing_check are sufficient. A native bn254_g1_msm would be a nice-to-have for performance, but is not required.