EIP-2537: The Long Journey from 2020 to 2025

EIP-2537 is the EVM precompiled instruction confirmed 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 for inclusion in the Ethereum upgrade until 2025. This article will introduce the governance process of EIP-2537 and explore why this proposal took 5 years to be finally adopted.

Proposal Background

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

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

But with the development of cryptography, in November 2017, the zcash team proposed the BLS12-381 curve, which has higher security and better performance compared to alt_bn128. Many blockchain protocols subsequently adopted the BLS12-381 curve to replace alt_bn128.

In May 2018, Justin Drake published an article pointing out that Ethereum's future PoS and sharding upgrades could utilize the BLS multi-signature algorithm based on BLS12-381. This laid the foundation for the later ETH2 upgrade.

With the development of ETH2, the call to introduce BLS12-381 into the execution layer is growing. In February 2020, researchers proposed EIP-2537, hoping to test it alongside the ETH2 testnet. EIP-2537 author Alex Stokes called for its inclusion in the Berlin hard fork.

It is worth mentioning that the author of EIP-2537 is also a co-founder of Matter Labs, whose most famous product is ZKSync.

Berlin Turmoil

Before introducing the subsequent content, it is necessary to first understand EIP-1962. This is the first elliptic curve domain pairing precompiled proposal put forward by Matter Labs in April 2019, supporting three curves: BLS12, BN, and MNT4/6.

The EIP-1962 plans to add 10 precompiled instructions to handle different curves all at once. However, many developers believe it is too complex to implement and unfriendly for smart contract engineers. Nevertheless, Matter Labs has completed the algorithm development and provided multi-language reference implementations.

To address the EIP-1962 issue, Matter Labs proposed multiple EIP split proposals in February 2020:

• EIP-2537 provides BLS12-381 support
• EIP-2539 provides support for BLS12-377
• PR#2541 provides support for BLS12-377(Zexe curve), but has not received an EIP number.

Among them, EIP-2537 is the most important, as the consensus layer also uses the BLS12-381 curve. The core goal of EIP-1962 and EIP-2537 is to achieve BLS signature verification in the consensus layer on the mainnet.

At that time, ETH2 was developing the deposit contract. Due to the lack of BLS verification in the execution layer, the original design of the deposit contract did not verify signatures, but instead was verified by the consensus layer. If incorrect, the deposit would fail, resulting in a loss of funds.

Therefore, the core developers hope to introduce BLS12-381 precompiled contracts to verify signatures in the deposit contract to avoid financial risks. This was also the reason why developers were concerned about EIP-1962 and EIP-2537 at that time.

After the proposal of EIP-2537, Vitalik immediately pointed out a series of issues, mainly focusing on the content of the documentation. The author subsequently responded and discussed.

The core developer meeting on March 6, 2020, discussed EIP-2537. Vitalik believes it is effective for recursive SNARK proofs and will not harm Ethereum in the long run. The meeting confirmed the priority of EIP-2537, and all clients agreed to implement it as soon as possible and complete development before the Berlin upgrade.

Subsequently, EIP-2537 became a high-priority task. The meeting on March 20 prioritized discussion of this proposal again, confirming its replacement of EIP-1962 as the core BLS proposal and including it in the pre-selection list for the Berlin upgrade.

The April meeting 84 officially incorporated EIP-2537 into the Berlin hard fork, establishing a timeline for implementation in April and testing in May-June. EIP-2537 has been listed as a top priority.

Since then, EIP-2537 has entered a large-scale development and testing phase, with related discussions occurring in almost every one of the nearly 20 subsequent core developer meetings.

The ABI encoding issue was discussed in Meeting 85. As Matter Labs has basically completed the Rust implementation, the Besu client stated that it has basically implemented the EIP-2537 functionality, but Geth indicated that it has not yet started the implementation work.

The meeting 86 reported the synchronization status of each node again. Geth indicated that some work has been completed, but there are still a large number of tasks to be completed.

The core content of Meeting 87 is the implementation issue of EIP-2537. Geth developers stated that there is a 16,000-line PR implementing EIP-2537, but it cannot be determined whether it is safe and effective, and can only be assessed through simple fuzz testing. Geth believes it is highly unlikely that the relevant development can be completed before the scheduled time in Berlin.

Hudson Jameson proposed to find a cryptographic engineer to assist with PR reviews for Geth and suggested testing the implementation for security on the testnet. The ETH2 team can also participate in the testing.

It should be noted that Geth's implementation PR for EIP-2537 uses a lot of assembly code to ensure efficiency, making it difficult to read and understand. Alex Vlasov suggested removing complex assembly optimizations to reduce the review difficulty.

Although one of the core goals of EIP-2537 is to assist the ETH2 deposit contract, developers of the deposit contract at this meeting indicated that the version not using EIP-2537 has already been audited, and some developers suggested not to release a new version using EIP-2537.

The final meeting decided to increase the YOLO testnet specifically to test EIP-2537. At this point, it can be seen that as the deposit contract is completed, the importance of EIP-2537 has significantly decreased, and the Geth developers believe it is very likely that it cannot be implemented before the Berlin upgrade. It seems that the exclusion of EIP-2537 from Berlin has become a foregone conclusion.

During the meeting 88, Geth developers found a series of issues with the implementation of EIP-2537 in the PR, indicating that further testing and fixes are needed. At this point, Geth has two implementation versions, one with assembly optimizations and the other completely written in Go. Some suggested directly using the Go version to reduce the difficulty of code review.

Meeting 89 encountered more serious issues, with the YOLO testnet showing abnormalities, suspected to be caused by BLS signatures, but EIP-2537 developers refuted this. The good news is that the deposit contract based on EIP-2537 is basically completed and is awaiting audit.

The meeting 90 set the deadline for the Berlin upgrade to go live in July. The meeting also discussed the issue of client diversity, with some proposing to freeze the current EIP implementations to reduce development costs for other clients. Meeting 91 even suggested using a modular approach to increase client diversity.

Meeting 92 once again confirmed EIP-2537 as the required EIP for the Berlin upgrade.

Meeting 96 discussed whether to include EIP-2539 in the Berlin test, as Celo has already included EIP-2537 and EIP-2539 in its network upgrade. However, Geth developers opposed this, arguing that EIP-2537 itself has not been fully tested. The final decision was not to add EIP-2696 in Berlin.

The meeting 99 decided to remove EIP-2537 from the YOLO v3 testnet and the Berlin upgrade, mainly because it consumed too much of the developers' time affecting the development of other EIPs. A secondary factor is that the Ethereum Foundation proposed EVM384 as an alternative. However, developers expressed concerns about its security.

This is the early history of EIP-2537. It was one of the most important EIPs in the Berlin upgrade, but was ultimately abandoned due to implementation issues. In April 2021, Ethereum completed the Berlin upgrade, and the implementation of core EIPs such as EIP-2565 was relatively simple, appearing somewhat thin, precisely because the most complex EIP-2537 was removed.

Future Development

As we all know, every upgrade of Ethereum has a core proposal, such as the introduction of EIP-1559 after Berlin's London. For EIP-2537, which was once a core proposal, it is difficult to incorporate it into subsequent upgrades.

During the London upgrade, developers considered adding EIP-2537. Meeting 109 synchronized its development status, which sparked discussions about gas due to the use of the new library. Some proposed replacing it with EVM384. However, Meeting 111 removed it from the London upgrade due to its complexity, mainly because the change in the dependent library led to variations in gas pricing, necessitating a reassessment.

In June 2021, it was officially proposed to include EIP-2537 in the Shanghai upgrade. However, after London, The Merge occupied a lot of developers' time. After The Merge was completed in September 2022, the execution layer developers finally had the opportunity to continue discussing the goals of Shanghai.

In the November 2022 meeting, there was a brief discussion about whether to include Shanghai, but developers believed it should be postponed. The core of Shanghai is to support PoS withdrawals. Ultimately, EIP-2537 was not included in the Shanghai upgrade, which focuses on withdrawals.

Worse still, the Cancun upgrade has not discussed EIP-2537, as its core is to support EIP-4844, providing Blob data availability for Layer 2.

Finally, the discussion at the February 2024 meeting 181 on the Pectra upgrade to include EIP-2537 concluded that implementation is no longer an issue, only gas pricing remains a concern.

On December 19, 2024, at meeting 202, Nethermind developers finalized the EIP-2537 pricing model. The original proposer, Matter Labs, had nearly withdrawn from the discussion by this time. Meeting 203 in January 2025 discussed repricing, where Geth developers suggested a 20% increase in gas costs, which received support from the Besu team.

Summary

EIP-2537 has gone through a long 5-year period from proposal to adoption. It was once at the core of the Berlin upgrade but was abandoned due to implementation difficulties. Subsequently, Ethereum entered the PoS historical process, and the complex pure execution layer EIPs were not prioritized, leading to many PoS-related EIPs becoming core targets, which caused EIP-2537 to remain unaccepted for an extended period. Until 2025, with the resolution of major technical challenges, EIP-2537 is finally expected to be realized in the Pectra upgrade.

This journey indicates that whether an EIP can be incorporated into an Ethereum upgrade depends not only on its own technical value but also on the overall development stage and priorities of Ethereum. Each upgrade has its own theme, and only those EIPs that meet current demands and are technically mature can ultimately be adopted.