Amendment XLS: Host Functions for zkSNARK Proof Over Curve BN254

[ZhangxiangHu-Ripple]

Amendment XLS: Host Functions for zkSNARK Proof Over Curve BN254

Title:        BN254 Curve Host Functions
Description:  zkSNARK verification requires host functions for elliptic curve arithmetic operations in order to reduce the gas cost, execution time, and code size in WASM runtime. 
Author:       Zhangxiang Hu (Ripple)
Status:       Discussion
category:     Amendment
created:      2025-09-25

Host functions for elliptic curve arithmetic operations over BN254

Abstract

This XLS proposal suggests adding WASM host functions for elliptic curve arithmetic operations over the BN254 curve on the XRP Ledger. These functions provide the capability of efficiently verifying Zero-Knowledge Succinct Non-interactive Argument of Knowledge (zkSNARK) in XRPL WASM runtime. By enabling zkSNARK verification and combining with XRPL programmability, it is possible to unlock new features of privacy, scalability, and interoperability for XRPL.

1. Introduction

The Smart Escrows Specification proposes leveraging a WebAssembly (WASM) engine to enable programmability within XRPL Escrows, introducing the concept of smart escrows. Rather than the simple time-based or crypto-conditional constraints, the smart escrows allow users to write complex self-defined constraints for releasing the funds, including the verification of zkSNARK proofs.

However, executing the zkSNARK proof verification directly in WASM runtime is extremely expensive in terms of the running time, code size, and gas cost. This is because zkSNARK verification relies heavily on arithmetic operations over large integers such as elliptic curve operations and pairing computations, while WASM was originally designed to support high-performance, low-level code execution for web applications instead of computational workloads involving large-number arithmetic. Therefore, this specification proposes XRPL host functions for fundamental arithmetic operations over elliptic curves to enable the zkSNARK proof verification in a more efficient and economic way.

Here a host function is a function defined outside the WebAssembly module and made available to it via imports. These functions allow a WASM module to interact with the external environment, such as accessing system resources, performing native computations, or retrieving data, by invoking functionality implemented in the host runtime (e.g., the Rippled runtime), which can be used to save gas and computing time in WASM. Host functions are conceptually similar to precompiles in the EVM, as both provide efficient access to complex native operations. Some examples of XRPL host functions can be found in XLS-102d.

2. Curve and Group Specification

This specification proposes arithmetic operations over Barreto–Naehrig curve BN254. For pairing-friendly curves and the parameters, we refer to NIST standard, libff, and Arkworks for more details. BN254 is a pairing-friendly elliptic curve with embedding degree $$k = 12$$ over a 254-bit prime field. The seed parameter in BN254 is 4965661367192848881 which specifies the base field modulus $$q$$ and scalar field modulus $$r$$ as

q = 21888242871839275222246405745257275088696311157297823662689037894645226208583 
r = 21888242871839275222246405745257275088548364400416034343698204186575808495617

The BN254 curve $$E$$ over $$F_q$$ is defined by $$E: y^2 = x^3 + 3$$ and its twist $$E'$$ over the extension field $$F_{q^2}$$ is defined by $$E': y^2 = x^3 + 3/\xi$$ where $$\xi = i + 9$$ is a non-residue with $$i^2 = -1$$. $$F_{q^2}$$ is defined as $$Fq[i]/(x^2 + 1) = F_{q^2}$$

(
  19485874751759354771024239261021720505790618469301721065564631296452457478373, 
  266929791119991161246907387137283842545076965332900288569378510910307636690
)

We also define two cyclic group, $$G_1$$ and $$G_2$$, each of prime order $$r$$, where

• Group $$G_1$$ is a subgroup of the elliptic curve $$E(F_q)$$ with generator (x = 1, y = 2)
• Group $$G_2$$ is a subgroup of the twisted curve $$E'(F_{q^2})$$ with generator

(
  x = 10857046999023057135944570762232829481370756359578518086990519993285655852781 
  + 11559732032986387107991004021392285783925812861821192530917403151452391805634 i, 
  y = 8495653923123431417604973247489272438418190587263600148770280649306958101930 
  + 4082367875863433681332203403145435568316851327593401208105741076214120093531 i 
)

Note that the expression here follows the convention in mathematics that the real part is presented before the imaginary part. However, in the serialization/deserialization of data, the imaginary part will be encoded before the real part. See section Encoding and Decoding.

3. Host Functions on BN254 Curve

This section specifies the host functions of elliptic curve arithmetic operations over BN254. All functions follow the same format defined in XLS-102d such that the returned value is i32, unless otherwise noted. If the value is positive, it's a length. If it's negative, it's an error code.

3.1 Negation

The negation host function ec_neg_helper takes the input of a point P1 and computes -P1, where the operation "-" is elliptic curve point negation. This function is used for negating an elliptic curve point to meet the requirements of the pairing check host function.

Function Signature	Description	Gas Cost
ec_neg_helper(      p1_ptr: i32,      p1_len: i32,      out_buff_ptr: i32,      out_buff_len: i32 )	Compute the negation of a G1 point	500

p1_len is the length of input point P1 in bytes. The P1 length should be more than 64 bytes. out_buff_len is the length of the output buffer that stores the result of -P1 after encoding.

3.2 Addition

The elliptic curve addition host function ec_add_helper takes the input of two points (P1, P2) and computes P1 + P2, where the operation "+" is point addition over curve BN254.

Function Signature	Description	Gas Cost
ec_add_helper(      p1_ptr: i32,      p1_len: i32,      p2_ptr: i32,      p2_len: i32,      out_buff_ptr: i32,      out_buff_len: i32 )	Compute the addition of two G1 points P1 and P2 on curve BN254.	500

p1_len and p2_len are the length of input points P1 and P2 in bytes. The P1 length should be more than 64 bytes. out_buff_len is the length of the output buffer that stores the result of P1 + P2 after encoding.

3.3 Scalar Multiplication

The elliptic curve scalar multiplication host function ec_mul_helper takes the input of a point P1 and the scalar, and computes scalar * P1, where the operation "*" is scalar multiplication over the curve BN254

Function Signature	Description	Gas Cost
ec_mul_helper(      p1_ptr: i32,      p1_len: i32,      scalar_ptr: i32,      scalar_len: i32,      out_buff_ptr: i32,      out_buff_len: i32 )	Compute the scalar multiplication of a scalar and a G1 point P1 on curve BN254	6000

p1_len and scalar_len are the length of input point P1 and scalar in bytes. The P1 length should be more than 64 bytes and the scalar length should be more than 32 bytes.out_buff_len is the length of the output buffer that stores the result of scalar * P1 after encoding.

3.4 Pairing Check

The pairing check host function takes the input of $$n$$ pairs of points $$(Pi, Qi) \in G_1 \times G_2$$, and checks if $$\Pi_{i=1}^{n} e(Pi, Qi) = 1$$ where $$e: G_1 \times G2 \rightarrow G_T$$ is a bilinear pairing operation. Here $$G_T$$ is the target group and 1 is the identity element of $$G_T$$.

Function Signature	Description	Gas Cost
ec_pairing_check_helper(      pairing_ptr: i32,      pairing_len: i32 )	Checks if the product of all pairings equals the identity element of $$G_T$$	40,000

pairing_ptr is a pointer that points to a byte array that stores the concatenation of encoded $$(Pi, Qi)$$. For example, for two pairs (P1, Q1) and (P2, Q2), the byte array is [encoded P1 bytes || encoded Q1 bytes || encoded P2 bytes || encoded Q2 bytes]. pairing_len is the length of the byte array. The length should be more than 4*(64+128)=768 bytes. The function will return 1 if the pairing check is valid and -1 if invalid. For other reasons that fail to perform the pairing check, it returns the error codes.

Here, we use a fixed gas cost for the pairing check and limit the number of input pairs to a maximum of four. In the future, we will support an arbitrary number of input pairs once XRPL WASM VM allows dynamic gas cost.

4. Encoding and Decoding

All of the curve data is encoded in uncompressed format. Therefore,

• Scalars.
  • An encoded scalar occupies 32 bytes.
  • Scalar is in big-endian format after encoding.
• Curve points of $$G_1$$.
  • An encoded $$G_1$$ point occupies 64 bytes.
  • A $$G_1$$ point is expressed as $$(x, y) \in F_q \times F_q$$.
  • Each $$F_q$$ element is in big-endian format that occupies 32 bytes.
• Curve points of $$G_2$$.
  • An encoded $$G_2$$ point occupies 128 bytes.
  • A $$G_2$$ point is defined over the quadratic extension field $$F_{q^2}$$ and is expressed as $$(x, y) \in F_{q^2} \times F_{q^2}$$.
  • Each $$F_{q^2}$$ element is represented as two values from $$F_q$$ in big-endian format that occupy 32 bytes, thus 128 bytes in total for a $$G_2$$ point.
  • For each $$F_{q^2}$$ element $$c_0 + c_1 * i$$, $$c_1$$ is encoded before $$c_0$$. Therefore, a $$G_2$$ point is encoded as
    $$x.c_1.encoded || x.c_0.encoded || y.c_1.encoded || y.c_0.encoded$$.

Appendix

Appendix A: FAQ

A.1: Why picking BN254 curve instead of BLS12-381?

BN254 curve is natively supported by Ethereum. By supporting the same curve on XRPL, users can easily move their ZK verification code from Solidity to XRPL. In addition, most Zero-knowledge virtual machines (zkVMs) allow users to generate Groth16 proofs based on BN254 curve because of its efficiency when compared to BLS12-381. We are also considering adding host functions for operations over BLS12-381 curve in the future since it is more secure than BN254 curve.

A.2: Why add host operations for elliptic curve operations rather than a host function for directly verifying zkSNARK proof?

1. The main reason is the security concern.
   If XRPL provides a host function for directly verifying zkSNARK proof, once it is compromised, all escrows would be affected and the whole XRPL network would be under threat. If XRPL only provides host functions for EC operations and once the verifier in an escrow is compromised, only that escrow would be affected.
2. More flexible and scalable. These functions are fundamental elliptic operations and could be applied to other use cases in the future such as in the BLS signature.

A.3: Why add an extra negation function?

For the purpose of user-friendly. Otherwise, users have to manually perform the negation of a point before sending it to the pairing check. It requires familiarity with the BN254 curve and arithmetic operations on big numbers in WASM runtime.

It is possible to flip the sign bit to negate a point, but the sign bit relies on the encoding/decoding details, which could be changed in the future.

[funkspock]

Hi @ZhangxiangHu-Ripple
Both BN254 and BLS12-381 are susceptible to quantum computer attacks and are being replaced by quantum-resistant cryptographic methods. Quantum-safe alternatives, like those under development by NIST and described in post-quantum cryptography (PQC) standards, are necessary to protect against future quantum computing threats.

Here are two interesting blogs on this topic.
https://blog.sui.io/post-quantum-computing-cryptography-security/
https://pchojecki.medium.com/quantum-computers-threat-to-ethereum-3598580b69f5

Perhaps also good to have an emergency function to easily rotate/migrate algorithm in case of vulnerability/compromise

[ZhangxiangHu-Ripple]

Hi @funkspock ,
Thanks for the comments and for sharing the blogs on the quantum-safe cryptography.

You’re absolutely right that BN254 and BLS12-381 (and other elliptic curve cryptography like XRPL ECDSA) are not quantum safe. Once quantum computers become practical, they would be vulnerable to attacks. So moving toward post-quantum cryptography will be critical to ensure long-term security for XRPL.

Having an emergency mechanism to rotate/migrate algorithms is a very good idea. In addition, we are also exploring quantum-safe ZK algorithms such as STARKs (and other cryptographic primitives, e.g., quantum safe signature schemes) which could eventually replace the pairing-based SNARKs in the future to enhance the quantum resilience of XRPL.

[Argzero]

The other benefit with STARKs is it is more possible to have decentralized proofs.