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
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
wasmvmv2.2.4 orwasmvmv3.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: