SIMD-0388

TL;DR

This proposal introduces a new family of syscalls to provide native support for cryptographic operations on the BLS12-381 elliptic curve. These syscalls will expose: 1. **Group operations** (addition, subtraction/negation, and scalar multiplication) in G1 and G2 2. **Point validation** in G1 and G2 3. **Pairing operation** 4. **Decompression operations** in G1 and G2 Poseidon hash support is outside the scope of this SIMD.

Summary

This proposal introduces a new family of syscalls to provide native support for cryptographic operations on the BLS12-381 elliptic curve. These syscalls will expose: 1. **Group operations** (addition, subtraction/negation, and scalar multiplication) in G1 and G2 2. **Point validation** in G1 and G2 3. **Pairing operation** 4. **Decompression operations** in G1 and G2 Poseidon hash support is outside the scope of this SIMD.

Motivation

Solana's current support for pairing-based cryptography is limited to the `alt_bn128` (also known as BN254) curve. Pairing-friendly curves are the foundation for many efficient and modern zero-knowledge proof systems, such as those based on Groth16. While the BN254 curve enables basic cryptography and zero-knowledge applications, it does not provide a 128-bit security level, which is insufficient for high-security protocols. The BLS12-381 curve is a modern, widely adopted standard for a pairing-friendly curve that achieves a 128-bit security level. It is adopted in other major ecosystems, such as Ethereum, which already supports it via a precompile. Adding support for the BLS12-381 curve is important for enabling Alpenglow consensus ([SIMD 326](https://github.com/solana-foundation/solana-improvement-documents/pull/326)) as well. Alpenglow consensus votes themselves do not require a BLS12-381 syscall as they are processed differently than regular transactions. However, when a validator registers their BLS public key, it must do so using a regular on-chain transaction that will pass through the normal transaction pipeline. This transaction must contain a BLS Proof of Possession (PoP) to validate ownership of the BLS public key. This PoP is a cryptographic proof that is crucial to prevent a "rogue-key-attack", where a malicious validator could try to register a key that is an algebraic combination of their own key and a victim's key. This would allow the attacker to forge aggregate signatures that appear to come from the entire group, even without the victim's participation. Initially, the vote program will natively execute PoP verification (see [SIMD-0387](https://github.com/solana-foundation/solana-improvement-documents/pull/387)). However, when the vote program eventually transitions to BPF, it will require a way to efficiently verify PoP inside a BPF program. By introducing syscalls for BLS12-381, a standard BPF program can efficiently verify these PoPs.

Key Changes

• Proof of Possession (PoP): A cryptographic proof that an entity (e.g., a validator) holds the secret private key corresponding to a public key that they are attempting to register. In the context of BLS, this is typically a signature created with the private key over a message derived from the public key itself.
• Group operations (addition, subtraction/negation, and scalar multiplication) in G1 and G2
• Point validation in G1 and G2
• Pairing operation
• Decompression operations in G1 and G2
• Fq Elements: A 381-bit field element is encoded in 48 bytes.
• _BE variants expect this 48-byte array in big-endian.
• _LE variants expect this 48-byte array in little-endian.
• Fq^2 Element Ordering: An Fq^2 element (c0 + c1 u) is encoded as 96 bytes.
• _BE variants: The Zcash standard's structural ordering is preserved. The 48-byte encoding of the c1 component (imaginary) comes first, followed by the 48-byte encoding of the c0 component (real).
• _LE variants: The structural ordering follows the canonical memory layout of Rust structs and Little-Endian polynomial representation. The 48-byte encoding of the c0 component (real) comes first, followed by the 48-byte encoding of the c1 component (imaginary).
• Compressed Point Control Bits: For compressed representations (used by sol_curve_decompress), the Zcash standard uses the 3 most-significant-bits of the entire byte string (e.g., the first bits of the 48-byte G1 array) for flags (compression, infinity, and sign).
• _BE variants: The flags are located in the 3 most significant-bits of the first byte (offset 0) of the 48-byte array.
• _LE variants: The flags are located in the 3 most-significant-bits of the last byte (offset 47) of the 48-byte array.
• BLS12-381 inputs (using BLS12_381_G1_{BE,LE}, BLS12_381_G2_{BE,LE}) will be interpreted as points in affine representation in either little-endian or big-endian.
• Curve25519 inputs (using CURVE25519_EDWARDS or CURVE25519_RISTRETTO) are interpreted as points in their respective Edwards or Ristretto representations in compressed little-endian representations.
• Addition (ADD) and Subtraction (SUB): Input points MUST be validated to ensure that they are on the curve (satisfy the curve equation). However, the _subgroup check is skipped_.
• _Reasoning_: The addition formulas are valid for any point on the curve, even those not in the prime-order subgroup. Skipping the costly subgroup check allows for cheaper accumulation of points, assuming the final result will be validated or processed by an operation that enforces it.
• _Scalar Multiplication (MUL)_: Input points MUST undergo _full validation_, including the field check, curve equation check, and the _subgroup check_.
• _Reasoning_: Enforcing the subgroup check allows the runtime to safely use faster endomorphism-based scalar multiplication algorithms (e.g., GLV), which are only valid for points in the correct subgroup.

Impact

This will enable ZK and other more advanced pairing-based cryptography applications to be built on Solana based on a more secure and modern curve.

Security Considerations

The necessary security considerations such as point validation, memory safety, etc. are detailed in the Detailed Design section.