EIP-2537: The Long Road from Controversy to Adoption

EIP-2537 is the EVM precompiled instruction determined to be added in the latest Pectra fork upgrade of Ethereum. This instruction adds various computational functions of the BLS12-381 curve to the EVM, such as pairing computations on the curve field.

EIP-2537 was initially proposed in 2020 and was not confirmed to be included in the Ethereum upgrade until 2025. This article will introduce the governance history of EIP-2537 and explore why this proposal took 5 years to be ultimately adopted.

Proposal Background

In January 2017, Vitalik Buterin first introduced the pairing algorithm and the alt_bn128 curve in an article. Subsequently, Vitalik and Christian Reitwiessner proposed EIP-196 and EIP-197, suggesting the addition of alt_bn128 curve computation support to the EVM.

The Byzantine upgrade in October 2017 officially introduced the alt_bn128 curve, enabling curve pairing computations within the EVM, allowing ZK-Snarks proof verification to be completed within the EVM.

However, with the development of cryptography, in November 2017, the zcash development team proposed the BLS12-381 curve. Compared to alt_bn128, BLS12-381 offers higher security and better performance. Many blockchain protocols later adopted the BLS12-381 curve, abandoning alt_bn128.

In May 2018, Justin Drake published an article pointing out that Ethereum's future PoS and sharding upgrades could use the BLS multi-signature algorithm based on the BLS12-381 curve. This solution addressed the issue of limited validator numbers in earlier PoS schemes. It has been proven that the later ETH2 upgrade indeed adopted the BLS12-381 curve.

As the development of ETH2 progresses, the call to introduce BLS12-381 into the ETH execution layer is growing louder. In February 2020, researchers proposed EIP-2537 and hoped that the proposal could be tested alongside the ETH2 testnet. The author of EIP-2537, Alex Stokes, urged for the inclusion of the proposal in the Berlin hard fork.

It is worth noting that the author of EIP-2537 is also a co-founder of Matter Labs, the development company behind ZKSync.

The twists and turns of the Berlin upgrade

Before introducing the subsequent progress, we need to understand EIP-1962. This is the first proposal regarding elliptic curve domain pairing precompilation proposed by Matter Labs in April 2019, supporting BLS12, BN, and MNT4/6 curves.

The EIP-1962 plan aims to add 10 precompiled instructions at once to handle different curves. However, this proposal has faced skepticism from many developers, who believe it is too complex to implement. Additionally, due to its high degree of generalization, it is also cumbersome for smart contract engineers to invoke. Nevertheless, as the proposing party, Matter Labs has completed the development work on the elliptic curve algorithm and provided reference implementations in multiple languages.

To address the issues with EIP-1962, Matter Labs proposed several EIPs in February 2020 to split EIP-1962, some of which inherit the interfaces of EIP-1962:

• EIP-2537 provides support for BLS12-381
• EIP-2539 provides support for BLS12-377
• PR#2541 provides support for the BLS12-377( Zexe curve ), but the proposal ultimately did not receive an EIP number.

The most important one is EIP-2537, as the consensus layer also uses the BLS12-381 curve. The core goal of both EIP-1962 and EIP-2537 is to achieve BLS signature verification on the consensus layer in the mainnet. At that time, ETH2 was developing the consensus layer deposit contract. In the initial design, since the execution layer did not include the BLS verification algorithm, the deposit contract would not verify signatures. The specific BLS signatures would be verified by the consensus layer after the user's deposit. If any discrepancies were found, the deposit would fail, and the ETH deposited by the user could be lost.

In this context, core developers hope to introduce the BLS12-381 precompiled contract to implement signature verification in the deposit contract to prevent potential loss of user funds. This was also the reason why many developers were focused on EIP-1962 and EIP-2537 at that time.

When EIP-2537 was first proposed, Vitalik pointed out a series of issues with the proposal. These concerns mainly focused on the content of the EIP documentation, and the EIP authors subsequently responded to and discussed these issues.

The 82nd Ethereum core developer meeting on March 6, 2020, discussed EIP-2537. Vitalik believed that this EIP is very effective for recursive SNARK proofs and will not have a negative impact on Ethereum in the long run. The meeting confirmed the priority of EIP-2537, and all clients agreed to implement this EIP as soon as possible, planning to complete all development before the Berlin upgrade.

Subsequently, EIP-2537 became a high-priority task. The 83rd core developer meeting on March 20 once again listed it as a primary proposal for discussion. The meeting confirmed that EIP-2537 would replace EIP-1962 as the core BLS proposal and be included in the Berlin upgrade pre-selection list.

The 84th meeting in April officially incorporated EIP-2537 into the Berlin hard fork upgrade and established a timeline for implementation in April and testing in May-June. It is worth noting that EIP-2537 was listed as a top priority during this discussion.

Subsequently, EIP-2537 entered a large-scale development and testing phase, and there were relevant discussions in almost every one of the nearly 20 core developer meetings that followed.

At the 85th meeting, developers discussed the ABI encoding issue of EIP-2537. Since Matter Labs has basically completed the Rust version implementation, the Besu client stated that it has essentially implemented the EIP-2537 functionality, but the Geth side claimed that no one is currently working on it.

At the 86th meeting, different nodes achieved further synchronization of the progress of EIP-2537. Geth stated that some work had been completed, but there is still a large amount of tasks to be done.

The 87th meeting focused on the implementation issues of EIP-2537. Geth developers stated that there is a 16,000-line PR implementing EIP-2537, but it is unclear whether this PR safely and effectively implements EIP-2537, and the code condition can only be assessed through the simplest fuzz testing.

Geth developers stated: "In my intuition, Geth won't be ready for BLS curve operations before the mainnet launch in July."

Hudson Jameson proposed to find cryptographic engineers to assist with PR reviews for Geth and suggested using the testnet to test the implementation security of EIP-2537. Since the ETH2 development team is also implementing BLS signature verification, they can participate in the testing.

It is worth noting that Geth's implementation PR for EIP-2537 uses a lot of assembly code to ensure efficiency, and this part of the code is very difficult to read and understand. Alex Vlasov suggested removing the complex assembly optimizations in the PR to reduce the difficulty of review.

A core goal of EIP-2537 is to assist the ETH2 deposit contract, but during this meeting, the developers of the deposit contract stated that they will not use the EIP-2537 contract, which has already been audited. Some developers believe it is best not to release a new version of the contract using EIP-2537.

Finally, the meeting decided to add the YOLO testnet specifically for testing EIP-2537. In fact, it can be seen from this meeting that with the completion of the deposit contract, the importance of EIP-2537 has significantly decreased, and at the same time, the Geth developers believe that this EIP is very unlikely to be implemented before the Berlin upgrade. It seems that the non-adoption of EIP-2537 in the Berlin upgrade has become a foregone conclusion.

At the 88th meeting, Geth developers found a series of issues with the EIP-2537 implementation PR, stating that further testing and fixes are needed. At this time, there are two EIP-2537 implementations in the Geth system, one containing assembly optimizations and the other completely written in Go. Some developers suggested directly using the Go version to reduce the difficulty of code review.

At the 89th meeting, a more serious issue arose; the YOLO testnet experienced some anomalies, and developers suspect it is due to BLS signatures, but the EIP-2537 developers refuted this. The good news is that the deposit contract based on EIP-2537 has basically been completed and is awaiting audit.

The 90th meeting set the deadline for the Berlin upgrade to go live in July. The meeting also discussed the issue of client diversity, primarily concerning the dominance of Geth, with developers suggesting freezing the current EIP implementation to reduce development costs for other clients. In the 91st meeting, a developer proposed using a modular approach to lower development costs in order to increase client diversity.

The 92nd meeting still confirmed EIP-2537 as the EIP required for the Berlin upgrade.

At the 96th meeting, since Celo has incorporated both EIP-2537 and EIP-2539 into its network hard fork, Matter Labs hopes to include EIP-2539 in the YOLO v2 test and enter the Berlin upgrade. However, Geth developers opposed this, arguing that the current EIP-2537 has not yet been fully tested within Geth. Ultimately, the meeting decided not to add EIP-2696 to the Berlin upgrade, leaving it for future discussion.

The 99th meeting decided to remove EIP-2537 from the YOLO v3 testnet and the Berlin upgrade. The main reason is that EIP-2537 has consumed too much time from core developers, hindering the development of other EIPs for the Berlin upgrade. A secondary factor is that the Ethereum Foundation proposed EVM384 as an alternative to EIP-2537, providing a more general elliptic curve computation solution. However, core developers expressed concerns about security issues.

This is the early history of EIP-2537. We can see that EIP-2537 was initially one of the most important EIPs in the Berlin upgrade, but it was ultimately abandoned due to implementation issues. In April 2021, Ethereum completed the Berlin upgrade, and the core EIPs like EIP-2565 were not actually complicated to implement, making the upgrade seem somewhat thin, which is precisely because the most complex core EIP-2537 was excluded.

Subsequent Development

As we all know, each upgrade of Ethereum comes with a core proposal. The London upgrade following Berlin introduced the most important fee proposal in Ethereum's history, EIP-1559. For the former core proposal EIP-2537, it is difficult for subsequent upgrades to incorporate it.

The London upgrade after Berlin is underway, with developers considering the addition of EIP-2537 in issues#369. The 109th core developer meeting synchronized the development status of EIP-2537, and discussions regarding gas usage arose due to the implementation using other libraries. Some developers proposed replacing EIP-2537 with EVM384. However, during the 111th meeting in April 2021, EIP-2537 was removed from the London upgrade due to its complexity. The main reason was that the standard implementation of EIP-2537 changed the dependent libraries, which could lead to variations in gas pricing, and different client implementations would require a significant amount of time to reassess gas consumption.

In June 2021, issues#343 officially proposed to include EIP-2537 in the Shanghai upgrade. However, after the London upgrade, The Merge took up a lot of developers' time, and execution layer developers needed to write a large amount of code to implement the PoS upgrade. After The Merge was completed in September 2022, execution layer developers finally had the opportunity to continue discussing the goals of the Shanghai upgrade.

In November 2022, the 150th core developer meeting briefly discussed whether to include EIP-2537 in Shanghai, but the developers believed it should be postponed, as the core of Shanghai is to support PoS withdrawals. Ultimately, EIP-2537 was not included in the withdrawal-focused Shanghai upgrade.

Unfortunately, the Cancun upgrade has not discussed EIP-2537, as the focus of Cancun is to support EIP-4844, providing blobs for Ethereum Layer 2 to use Ethereum as a data availability layer.

It was not until the 181st core developer meeting in February 2024 that developers discussed including EIP-2537 in the Pectra upgrade. By this time, developers believed that the implementation of EIP-2537 was no longer an issue, and only some gas consumption pricing problems needed to be resolved.

At the 202nd meeting on December 19, 2024, the Nethermind developers finalized the pricing model for EIP-2537. It is worth noting that Matter Labs, the original proposer of EIP-2537, had largely withdrawn from the discussion at this point. The 203rd meeting in January 2025 discussed repricing the BLS precompile, where Geth developer Jared Wasinger suggested increasing the gas cost by 20%, which received support from the Besu team's benchmarking.

Summary

The process from the proposal of EIP-2537 to its final adoption has been long and tortuous:

• February 2020: EIP-2537 officially proposed as a split from EIP-1962
• April to October 2020: Multiple discussions on implementation issues, ultimately abandoned due to inability to implement after the Berlin upgrade.
• March-April 2021: Discussion on gas cost issues, abandoned by the London upgrade due to complexity.
• November 2022: Discussion on whether to include the Shanghai upgrade, but no conclusion reached.
• February 2024: It is believed that implementation is no longer an issue, but there are still some gas cost problems that can be included in the Pectra upgrade.
• December 2024 - January 2025: Discuss the specific cost calculation model and officially resolve gas costs.