Skip to content

Question: should BN254 host functions also expose Go-side wrappers, or follow the BLS12-381 precedent of staying VM-internal? #735

Description

@Dragonmonk111

Context

This is the wasmvm-side companion to CosmWasm/cosmwasm#2685 — a proposal to add BN254 (alt_bn128) host functions to CosmWasm, motivated by Juno governance proposal #374 (passed 2026-05-05, ~80% Yes / 22% Abstain / 0.003% No-with-Veto).

The cosmwasm-side issue covers the host-function ABI, the Rust crate, the gas schedule, and the measured 1.823× gas reduction (370,600 → 203,266 SDK gas per Groth16 verification, 5 samples σ = 0). The patches there target three cosmwasm tags in parallel — v2.2.2 (audit baseline), v2.2.7 (latest 2.2.x), and v3.0.6 (latest v3) — all 10/10 CLEAN.

This wasmvm-side issue is now smaller in scope than originally drafted. When we tried to author Go-side wrappers (mirroring the BLS12-381 pattern we expected), the patches failed because BLS12-381 itself has no Go-side wrappers in either wasmvm v2.2.4 or wasmvm v3.0.4. We dropped the wrapper patches and would like to confirm that this absence is intentional design before deciding whether to contribute the wrappers ourselves.

The single question

Is the absence of Go-side wrappers for BLS12-381 (and by extension, BN254) intentional design — i.e. "these primitives are for use by Wasm contracts via host-function imports only, never by direct Go callers in x/wasm-adjacent code" — or is it a not-yet-done that you'd accept a contribution for?

We're happy with either answer:

  • "Intentional, leave it out": then the BN254 work is cosmwasm-only. Issue 1 is the entire upstream surface and this issue closes once that's confirmed.

  • "Not-yet-done, contribution welcome": then we'd open a follow-up wasmvm PR with the BLS12-381 + BN254 Go wrappers in one symmetrical change. The Go-side surface for BN254 alone would look like:

    // internal/api/bn254.go (new)
    func Bn254Add(a, b []byte) ([]byte, error) { ... }
    func Bn254ScalarMul(point, scalar []byte) ([]byte, error) { ... }
    func Bn254PairingEquality(input []byte) (bool, error) { ... }Test body

Activity

  1. Dragonmonk111 commented on Jun 28, 2026

    @Dragonmonk111
    Author

    Hi team — quick follow-up on this one, which is the companion to CosmWasm/cosmwasm#2685. 👋

    Our open question is purely about the integration pattern, and your answer determines
    whether our do_bn254_verify work can be upstreamed as a clean patch:

    • Option A — VM-internal only (the BLS12-381 precedent): the BN254 ops live entirely inside
      the VM and are reachable only via the cosmwasm-std host-function imports. No new Go-side public API.
    • Option B — Go-side wrappers too: expose Go wrappers (analogous to other api/ functions) so
      chains can call BN254 ops directly from Go as well.

    We currently run Option A in our fork (it's the smaller surface and matches BLS12-381), and we're
    happy to align with that if it's your preferred direction. If you'd rather have Go-side wrappers,
    we can prepare that instead — we just want to match the pattern you'll accept before sending a PR.

    We've drafted a PR description at our end (docs/WASMVM_BN254_PR_DESCRIPTION.md) and can adapt it
    to whichever direction you choose. Could you confirm A vs B? Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions