Feature: Proposal - Improve BLS12-381 Functions for Compatibility with EIP-2537

[mrLSD]

Contact Details

[email protected]

Feature Request

Description

➡ Improve BLS12-381 Functions to Support Ethereum Precompiles (EIP-2537)

The current implementation of nearcore includes NEP-488, which provides BLS12-381 host-functions. However, during practical application in the Aurora project, it became evident that these functions are not well-suited for direct use as Ethereum precompiles according to EIP-2537.

Problem Statement

EIP-2537 defines a different ABI for input and output when handling BLS12-381 precompiles, which leads to compatibility issues when trying to utilize the existing nearcore BLS12-381 functions. These differences introduce multiple challenges and limitations, making it difficult to integrate nearcore’s implementation with Ethereum-based projects like Aurora.

EIP-2537 defines a different ABI for input/output when handling BLS12-381 precompiles, which creates several integration challenges:
➡ Input Transformation: Currently, nearcore requires a specialized data transformation before passing parameters to BLS12-381 host functions. This includes:

• Unpadding
• Zero-point validation
• Other data format adjustments

➡ Output Transformation: Similarly, the results must go through reverse transformations, including:

• Padding
• Zero-element validation
• Format adjustments

Since these pre/post-processing steps are currently required outside of nearcore’s BLS12-381 implementation, using these functions for EIP-2537 precompiles requires additional custom logic, making them impractical for direct use.

Example of that intagration is Aurora Engine BLS12-381 intagrations: aurora-is-near/aurora-engine#999

Proposed Solution:

To improve compatibility with EIP-2537 while minimizing API changes, we propose extending the NEP-488 BLS12-381 host functions with an additional parameter:

API Change Proposal:

✅ Add an optional parameter to all BLS12-381 host functions:

fn bls12_381_function(..., is_eip2537: bool) -> ...;

• When is_eip2537 = false (default behavior), the function behaves as it does today, maintaining backward compatibility.
• When is_eip2537 = true, the function:
  • Processes input data according to EIP-2537 requirements (unpadding, zero-point validation, proper encoding etc.).
  • Returns output in full compliance with EIP-2537 specifications (padding, encoding, and zero-element handling etc.).

This approach ensures minimal API changes while allowing native EIP-2537 compatibility within nearcore itself.

🚀 Impact & Benefits:

• Simplifies interoperability between Near and Ethereum for projects utilizing BLS12-381 cryptographic functions.
• Reduces the need for custom conversion logic in external projects like Aurora.
• Reduces NEAR gas costs consumptions for additional transformations
• Enhances developer experience by providing a more standardized approach.
• Avoids security vulnerabilities associated with additional complex data transformations

Beneficiary

Aurora

Priority

High priority. It's part of upcoming Ethereum Prague hard fork

Contributing

• Yes, I am interested

[mrLSD]

cc: @olga24912

[nagisa]

using these functions for EIP-2537 precompiles requires additional custom logic, making them impractical for direct use.

Example of that intagration is Aurora Engine BLS12-381 intagrations: aurora-is-near/aurora-engine#999

You mention it is impractical, but then in the next paragraph provide an example of it being done. Is impractical here means they are a chore to use in that particular application (vs. impossible?)

The reason I ask is because I don't think it is a goal to have host functions do everything in as straightforward way as possible. Rather the only reason they are a part of a host interface at all is because compiling the equivalent code to pure contract WASM makes it prohibitively expensive to run it in terms of gas. As long as the functions allow for accelerating computations in all applicable use-cases, even if using them is a chore, then these host functions serve their principal purpose.

On a more pragmatic note, adding new host functions to NEAR is quite a difficult task and changing existing ones is borderline impossible. WASM does not have a concept of optional parameters so extending the existing host functions in a backwards compatible manner is not a thing that we can do.

[mrLSD]

You mention it is impractical, but then in the next paragraph provide an example of it being done. Is impractical here means they are a chore to use in that particular application (vs. impossible?)

“Impractical” in this case is meant in the most literal sense, and it has been explained in detail why.

These functions are expected to work just like other host functions we use for Ethereum precompiles: we pass an input and receive an output - the function itself is treated as a black box. The BLS12-381 functions should follow the same principle.

In Aurora, we implemented our own version of these functions at the smart contract level. While they work correctly, they consume significantly more NEAR gas.

Additionally, it’s worth noting that the current input/output transformations count for 1/3 of the entire function logic, which makes them impractical in case of near host functions.

➡ NEP-488 context

The nearcore BLS12-381 functions were implemented based on NEP-488.
1. NEP-488 should have made a direct statement regarding compatibility with EIP-2537, but this was not done. However, it should have been, as explicit compatibility with Aurora was declared. This proposal provides a way to address this issue.
2. #12928 also describes that the current BLS12-381 implementation contains bugs and does not function correctly.

Host functions are, in fact, an ABI for accessing external functions. You probably meant that changing the ABI would break backward compatibility for contracts that are already using these functions.

In that case, there’s a very simple solution to the problem:
• If the input length matches the expected length of EIP-2537 parameters, process it according to EIP-2537 logic and apply the corresponding transformation to the output.

This is a straightforward task that should take about an hour of work.