Extend the Alt-BN128 syscalls to add G2 Arithmetic

[blockiosaurus]

---

simd: 'XXXX'
title: G2 Arithmetic Syscalls
authors:

• Blockiosaurus (Metaplex Foundation)
  category: Standard
  type: Core
  status: Draft
  created: 2025-05-30

---

Summary

Extend the existing sol_alt_bn128_group_op syscall to support native G2 curve point arithmetic (addition, subtraction, and scalar multiplication) on the BN254 curve.

Motivation

Solana today provides syscalls for Alt‑BN128 G1 group operations (ALT_BN128_ADD, ALT_BN128_SUB, ALT_BN128_MUL) and for pairing checks, as well as compression/decompression for G2 points. However, there is no direct support for arithmetic on G2 points themselves, as they were not included in the Ethereum Precompile on which the syscalls were based.

Adding native G2 syscalls will enable:

• Batch Groth16 verification: Multiple proofs could be aggregated into single verification calls
• KZG polynomial commitments: Enable efficient multi-point opening proofs and batch verification
• Other more advanced ZK systems for batch or direct verification

New Terminology

• G2 point: A point on the twist subgroup of BN254, represented as two Fq₂ elements (each element is a pair of 32‑byte field coefficients).

Detailed Design

New Constants

// Field and point sizes
pub const ALT_BN128_FIELD_SIZE:       u64 = 32;              // bytes per Fq element
pub const ALT_BN128_G2_POINT_SIZE:    u64 = ALT_BN128_FIELD_SIZE * 4;  // x=(x0,x1), y=(y0,y1) each 32‑byte

// G2 addition/subtraction
pub const ALT_BN128_G2_ADDITION_INPUT_LEN:   u64 = ALT_BN128_G2_POINT_SIZE * 2; // 256
pub const ALT_BN128_G2_ADDITION_OUTPUT_LEN:  u64 = ALT_BN128_G2_POINT_SIZE;     // 128

// G2 scalar multiplication
pub const ALT_BN128_G2_MULTIPLICATION_INPUT_LEN:  u64 = ALT_BN128_G2_POINT_SIZE + ALT_BN128_FIELD_SIZE; // 160
pub const ALT_BN128_G2_MULTIPLICATION_OUTPUT_LEN: u64 = ALT_BN128_G2_POINT_SIZE;                       // 128

### New Opcodes
pub const ALT_BN128_G2_ADD: u64 = 4;
pub const ALT_BN128_G2_SUB: u64 = 5;
pub const ALT_BN128_G2_MUL: u64 = 6;

Alternatives Considered

• Separate G2‑only syscall entrypoint rather than extending sol_alt_bn128_group_op.
• Drawback: Increases API surface, doubles maintenance.
• Library‑level intrinsics (BPF C/Rust) for G2 math as fallback.
• Drawback: Slower, higher compute cost than native syscalls.

Impact

• Native G2 ops reduce compute units by approximately 10×–20× compared to pure‑BPF implementations.
• Enables newer and more advanced ZK verification methods as well as batch proof verification

Security Considerations

None

[t-nelson]

concept ack

cc/ @samkim-crypto for review

[deanmlittle]

Assuming not much pushback, consider making this an extension of the recently accepted simd-0284 so we don't have to feature gate twice? https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0284-alt-bn128-little-endian.md

[blockiosaurus]

I wonder if it would also make sense to make syscalls for hash_to_curve since those seem to be fairly ubiquitous in G1 and G2, though maybe that falls under a separate SIMD.

[deanmlittle]

Imo, not necessary. That's how you end up with Sui's current Groth16 implementation that forces you into using Poseidon. G1 is extremely easy to implement manually in a way that is very flexible: https://github.com/deanmlittle/solana-alt-bn128-bls/blob/master/src/schemes/sha256_normalized.rs

If we have G2 addition, hash to G2 is not really needed imo

[blockiosaurus]

True, having opinionated hashing is the downside. How much variability does iterating to find a valid point introduce, though? find_program_address is already annoying enough to estimating CU.

[deanmlittle]

it's pretty reasonable.

[blockiosaurus]

Cool, I'll leave it out then.

[0x0ece]

I'm not against G2 for alt-bn-128, but how about we just build a full API for BLS12-381, including G1, G2 and pairing?

Both Agave and Firedancer have https://github.com/supranational/blst as their dependencies (because of Alpenglow), so it should be an easy addition.

Is there any need specifically for bn128? It feels a bit low security to me.

[deanmlittle]

We should do both! Altbn128 for compatability. BLS12-381 for future-proofing and security.

[samkim-crypto]

Yeah I am not against this if @0x0ece is in support.

We would need to maintain the existing alt-bn128 syscalls for the current projects that use it, so I think it makes sense to add the g2 functionality to the existing alt-bn128 syscalls. For future curves like bls12-381, we can build on top of the more general curve-group-op syscalls.

[0x0ece]

I’m good!

[zfedoran]

Would love to see this get more attention, or bls12381 :)