Author: shew

Overview

EIP-2537 is the newly confirmed EVM pre-assembly instruction added in the latest Pectra fork upgrade. This instruction adds various computational functionalities of the BLS12-381 curve to the EVM, such as pairing computations on the curve domain.

EIP-2573 was initially proposed in 2020 and was confirmed for inclusion in the Ethereum upgrade in 2025. This article mainly discusses the governance history of EIP-2537 and explores why it took 5 years for this proposal to be included in the upgrade.

Proposal Background

In January 2017, Vitalik Buterin first introduced pairing algorithms and the alt_bn128 curve in Exploring Elliptic Curve Pairings. Subsequently, in February 2017, Vitalik Buterin and Christian Reitwiessner proposed EIP-196 and EIP-197, which aimed to add support for alt_bn128 curve computations to the EVM.

In the Byzantium upgrade in October 2017, the alt_bn128 curve was officially included. In simple terms, alt_bn128 first enabled 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 introduced the BLS12-381 curve in BLS12-381: New zk-SNARK Elliptic Curve Construction. Compared to alt_bn128, BLS12-381 offers higher security and better performance. Many blockchain protocols subsequently adopted the BLS12-381 curve, abandoning the alt_bn128 curve.

In May 2018, Justin Drake published Pragmatic signature aggregation with BLS on ethresear, pointing out that the BLS multi-signature algorithm based on the BLS12-381 curve could be used in Ethereum's future PoS and sharding upgrades. At that time, Ethereum researchers hoped to use EIP-1011 to address consensus layer issues, but the EIP-1011 proposal could accommodate a maximum of 900 validators, setting a massive staking requirement of 1500 ETH per validator. With the introduction of the BLS multi-signature scheme, EIP-1011 exited the historical stage. It turned out that the later ETH2 upgrade ultimately used the BLS12-381 curve.

As ETH2 development progressed, there were calls to introduce the BLS12-381 curve into the ETH execution layer. In February 2020, some researchers proposed EIP-2537 and hoped that the proposal could be tested together on the ETH2 testnet. The author of EIP-2537, Alex Stokes, called for the inclusion of EIP-2537 in the Berlin hard fork in his article What eth2 needs from eth1 over the next six months.

Interestingly, 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, we need to first discuss EIP-1962. EIP-1962 is the first proposal for elliptic curve domain pairing pre-assembly put forward by Matter Labs in April 2019, supporting three curves:

• BLS12
• BN
• MNT4/6 (Ate pairing)

This EIP aimed to add 10 pre-assembly instructions at once to handle different curves. However, after the proposal was born, many developers questioned its complexity, making it difficult for developers to implement. Additionally, due to the high generalization of EIP-1962, it was also quite cumbersome for smart contract engineers to call. Of course, as the proposer of EIP-1962, Matter Labs had essentially completed the development work on elliptic curve algorithms and provided reference implementations in Rust / Go / C++.

To address the issues with EIP-1962, Matter Labs proposed multiple EIPs to split EIP-1962 in February 2020, with these EIPs partially inheriting the interfaces of EIP-1962. These EIPs include:

• EIP-2537 providing support for BLS12-381
• EIP-2539 providing support for BLS12-377
• PR#2541 providing support for BLS12-377 (Zexe curve), but note that this proposal ultimately did not receive an EIP number and cannot be found on the EIP documentation website.

Among these EIPs, the most important is EIP-2537, as the consensus layer also uses the BLS12-381 curve. The core purpose of both EIP-1962 and EIP-2537 is to implement the verification of consensus layer BLS signatures on the mainnet. At that time, ETH2 was developing the design of the deposit contract for the consensus layer. In the initial design of the deposit contract, 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 deposit, and if found incorrect (for new validators), the deposit would fail, and the ETH deposited by the user would be lost.

In this context, core developers hoped to introduce BLS12-381 pre-assembly into the deposit contract to implement signature verification, avoiding potential losses of user funds deposited into ETH2. This was also the reason why many developers focused on EIP-1962 and EIP-2537.

When EIP-2537 was first proposed, Vitalik immediately identified a series of issues with the EIP:

These concerns were primarily focused on the content of the EIP document, and the EIP authors subsequently responded and discussed them. Then, on March 6, 2020, during the Ethereum Core Devs Meeting #82, Ethereum core developers discussed EIP-2537. In this meeting, Vitalik believed that EIP-2537 and similar EIPs were very effective for recursive SNARK proofs and would not harm Ethereum in the long run. The meeting also confirmed the priority of EIP-2537, with all clients agreeing to implement EIP-2537 as soon as possible and planning to complete all development before the Berlin upgrade.

Subsequently, EIP-2537 became a high-priority task. On March 20, 2020, during the Ethereum Core Devs Meeting #83, EIP-2537 was still the first proposal discussed. This meeting confirmed that EIP-2537 would replace EIP-1962 as the core BLS proposal and become part of the pre-selection EIP list for the Berlin upgrade (i.e., Eligibility for Inclusion (EFI)).

In the Ethereum Core Devs Meeting #84 in April 2020, the meeting officially included EIP-2537 in the Berlin hard fork upgrade and established a timeline for the Berlin upgrade, with implementation in April and testing in May to June. Notably, during this discussion, EIP-2537 was listed as a top priority.

Subsequently, EIP-2537 entered a significant development and testing phase, with discussions about EIP-2537 occurring in nearly every one of the subsequent 20 core developer meetings. Next, we can look at the issues discussed regarding EIP-2537 in each meeting.

In Ethereum Core Devs Meeting #85, Danno and Axic discussed the ABI encoding issues of EIP-2537. Following that, core developers synchronized the current implementation status, where the proposer of EIP-2537, Matter Labs, had already completed the Rust version of the implementation, so the Besu client stated that it had basically implemented the functionalities of EIP-2537. However, the Geth team indicated that no one was currently working on the implementation of EIP-2537.

In Ethereum Core Devs Meeting #86, different Ethereum node implementations again synchronized the implementation status of EIP-2537, with Geth stating that some work had been completed, but a lot of work remained to be done.

In Ethereum Core Devs Meeting #87, the core content of this developer meeting was the implementation issues of EIP-2537. Geth developers mentioned that there was currently a 16,000-line PR implementing EIP-2537, but they could not determine whether the PR was a safe and effective implementation of EIP-2537, so developers could only assess the code's status through simple fuzz testing.

Geth developers stated, "So my gut reaction is that there is no chance that Geth will be ready with the BLS curve operations for mainnet launch in July," indicating that Geth was unlikely to complete the relevant development of EIP-2537 before the scheduled time for Berlin.

Hudson Jameson proposed finding cryptographic engineers to assist with the PR review for Geth and suggested using the testnet to test the security of the EIP-2537 implementation. Since the ETH2 development team was also implementing BLS signature verification at that time, the ETH2 team could participate in the testing.

Here, we need to add some background knowledge: the Geth implementation PR for EIP-2537 used a lot of assembly code to ensure efficiency, which was very difficult to read and understand. Therefore, Alex Vlasov suggested removing the complex assembly optimizations within the PR to lower the review difficulty.

As mentioned earlier, a core goal of EIP-2537 was to assist the ETH2 deposit contract, but during this meeting, deposit contract developers stated that the deposit contract not using EIP-2537 had already been audited, so some developers suggested it would be best not to introduce another deposit contract using EIP-2537.

In the end, the meeting decided to add the YOLO testnet, which was primarily focused on testing EIP-2537. In fact, during this meeting, we could see that the importance of EIP-2537 had significantly decreased with the completion of the deposit contract, and Geth developers had already believed that this EIP was very likely to be unimplemented before the Berlin upgrade. It seemed that EIP-2537's acceptance into the Berlin upgrade had become a foregone conclusion.

In Ethereum Core Devs Meeting #88, Geth developers discovered a series of issues with the implementation PR of EIP-2537, stating that further testing and fixes were needed. At this time, there were two implementations of EIP-2537 within the Geth system, one of which included assembly optimizations, while the other was entirely written in Go. Some developers suggested directly using the Go version to reduce the difficulty of code review.

In Ethereum Core Devs Meeting #89, more serious problems arose, as the YOLO test encountered some issues. Developers suspected that the problems were caused by BLS signatures, but EIP-2537 developers refuted this, arguing that the testnet issues were not caused by BLS signatures. The good news for EIP-2537 was that the deposit contract based on EIP-2537 was basically completed and was awaiting contract auditing.

In Ethereum Core Devs Meeting #90, this meeting locked in July for the launch of the Berlin upgrade DDL. Of course, another interesting point of discussion in this meeting was the issue of client diversity. Developers mainly discussed the dominance of Geth, and some proposed freezing the current EIP implementations to reduce the development costs for other clients. Even more interestingly, in meeting #91, some developers suggested using a modular approach to reduce development costs and increase client diversity. If readers are interested in Ethereum client diversity, they can read the records of these two meetings.

In Ethereum Core Devs Meeting #92, EIP-2537 was still confirmed as a necessary EIP for the Berlin upgrade.

In Ethereum Core Devs Meeting #96, since Celo had already included both EIP-2537 and EIP-2539 in its network hard fork upgrade, Matter Labs hoped to test EIP-2539, which was proposed simultaneously with EIP-2537, in the YOLO v2 testnet and include it in the Berlin upgrade. However, Geth developers opposed this, arguing that the current EIP-2537 had not yet undergone complete testing within Geth. Ultimately, the meeting decided not to include EIP-2539 in the Berlin upgrade, leaving it for future discussion.

In Ethereum Core Devs Meeting #99, this meeting decided to remove EIP-2537 from the YOLO v3 testnet and the Berlin upgrade, primarily because EIP-2537 had wasted too much time for core developers, hindering the development of other EIPs for the Berlin upgrade. A secondary factor was that the Ethereum Foundation proposed EVM384 as a replacement for EIP-2537, which provided a more general elliptic curve computation solution. However, core developers expressed concerns about security issues during the meeting discussions.

The above content outlines the early history of EIP-2537. We can see that EIP-2537 was one of the most important EIPs in the early stages of the Berlin upgrade, but it was ultimately abandoned due to implementation issues. Finally, in April 2021, Ethereum completed the Berlin upgrade, and the core EIPs included in the upgrade, such as EIP-2565, were not particularly complex. It appeared that the Berlin upgrade was somewhat thin because the most complex core EIP, EIP-2537, had been excluded from the Berlin upgrade.

Subsequent Developments

As we all know, each Ethereum upgrade has a core proposal, such as the London upgrade after the Berlin upgrade, which introduced the most important fee proposal in Ethereum's history, EIP-1559. For EIP-2537, which was once a core proposal, it has been difficult to incorporate this proposal into subsequent upgrades.

During the London upgrade after Berlin, developers considered adding EIP-2537 in issues#369. In Ethereum Core Devs Meeting #109, developers synchronized the current development status of EIP-2537. At this time, due to the use of other libraries for the implementation of EIP-2537, a discussion about gas usage for EIP-2537 was introduced. Meanwhile, some developers proposed using EVM384 to replace EIP-2537. However, in the Ethereum Core Devs Meeting #111 in April 2021, EIP-2537 was removed from the London upgrade due to its complexity. The core complexity lay in the fact that the standard implementation of EIP-2537 changed its dependency library, which could lead to changes in gas pricing, requiring different client implementations to spend considerable time reassessing gas consumption.

In June 2021, issues#343 formally proposed including EIP-2537 in the Shanghai upgrade. However, it is important to note that after the London upgrade, the Pairs upgrade, also known as The Merge, occupied a significant amount of developers' time, as execution layer developers needed to write a large amount of code to implement the PoS upgrade. By September 2022, the Pairs upgrade was completed, and execution layer developers finally had the opportunity to continue discussing some goals for the Shanghai upgrade.

In November 2022, during Ethereum Core Devs Meeting #150, there was a brief discussion about whether to include EIP-2537 in the Shanghai upgrade, but developers believed that EIP-2537 needed to be postponed, as the core of the Shanghai upgrade was to support PoS withdrawals. Ultimately, EIP-2537 was not included in the Shanghai upgrade, which focused on implementing withdrawal functionality.

Even more unfortunately, the Cancun upgrade did not discuss EIP-2537 at all, as the core of the Cancun upgrade was for execution layer nodes to support EIP-4844. EIP-4844 provides blobs for Ethereum Layer 2 to facilitate the use of Ethereum as a data availability layer.

Finally, in the Ethereum Core Devs Meeting #181 in February 2024, developers discussed including EIP-2537 in the Pectra upgrade, and at this time, developers believed that the implementation of EIP-2537 was no longer an issue, with only some concerns remaining regarding gas consumption pricing.

On December 19, 2024, in the Ethereum Core Devs Meeting #202, Nethermind developers finalized the pricing model for EIP-2537. Yes, as the original proposer of EIP-2537, Matter Labs had nearly withdrawn from the discussion at this point. In the subsequent Ethereum Core Devs Meeting #203 in January 2025, developers discussed including the repricing of BLS precompiles, with Geth developer Jared Wasinger suggesting a 20% increase in gas costs, which received support from the Besu team's benchmarking.

Summary

| Date | Event | |---------------------|--------------------------------------------------------------------------------------------| | February 2020 | EIP-2537 was officially proposed by splitting EIP-1962. | | April 2020 - October 2020 | Developers discussed the implementation issues of EIP-2537 multiple times, ultimately abandoning it due to implementation difficulties in the Berlin upgrade. | | March 2021 - April 2021 | Developers discussed the gas cost issues of EIP-2537, ultimately abandoning it due to complexity in the London upgrade. | | November 2022 | Developers discussed whether to include EIP-2537 in the Shanghai upgrade, but to no avail. | | February 2024 | Developers believed there were no implementation issues with EIP-2537, but some gas cost issues remained, and they considered including it in the Pectra upgrade. | | December 2024 - January 2025 | Developers discussed specific cost calculation models, formally resolving the cost issues of EIP-2537. |

It is evident that whether EIP is included in Ethereum upgrades "certainly relies on self-struggle, but also needs to consider the historical journey." Each Ethereum upgrade has its own theme, just as EIP-2537 once became the most important EIP in the Berlin upgrade, but was abandoned due to its implementation difficulty and complexity. Subsequently, Ethereum entered the historical process of PoS, where complex pure execution layer EIPs were not prioritized, while numerous execution EIPs related to PoS were viewed as core upgrade objectives, leading to the prolonged rejection of EIP-2537.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。