Ethereum Governance Observation: EIP-2537 Pre-Compilation Process

Author: shew

Overview

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

EIP-2573 was initially proposed in 2020 and was not confirmed to be included in the Ethereum upgrade until 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 introduced pairing algorithms and the alt_bn128 curve for the first time at Exploring Elliptic Curve Pairings. Then 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.

The alt_bn128 curve was officially incorporated in the Byzantium upgrade in October 2017. Simply put, alt_bn128 implemented curve field pairing calculations inside the EVM for the first time, allowing ZK-Snarks proof verification to be completed within the EVM.

However, with the development of cryptography, in November 2017, the zcash development team first 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. Quite a number of blockchain protocols have since adopted the BLS12-381 curve and abandoned the alt_bn128 curve.

In May 2018, Justin Drake published the article Pragmatic signature aggregation with BLS in ethresear, stating that future PoS and shard upgrades on Ethereum could use the BLS multisig algorithm based on the 'BLS12-381' curve. At the time, Ethereum researchers wanted to use EIP-1011 to solve the consensus layer problem, but the EIP-1011 scheme could accommodate up to 900 validators, so a huge stake size of 1,500 ETH was set for each validator. With the introduction of the BLS multisig scheme, EIP-1011 has withdrawn from the stage of history. As it turns out, later ETH2 upgrades also ended up using the 'BLS12-381' curve.

With the development of ETH2, the BLS12-381 used by ETH2 has begun to be called for the ETH execution layer. In February 2020, some researchers proposed EIP-2537, hoping that this 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, which is best known for its product ZKSync.

Berlin turmoil

Before we introduce the subsequent content, we need to first introduce EIP-1962. EIP-1962 is the first proposal regarding elliptic curve domain pairing pre-assembly put forward by Matter Labs in April 2019, which supports three curves, namely:

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

This EIP is set to add 10 pre-assembly instructions at once to handle different curves. However, after the proposal was born, a considerable number of developers questioned that the proposal was too complex for developers to implement. At the same time, due to the high generalization of EIP-1962, invoking it is also quite troublesome for smart contract engineers. Of course, as the proposer of EIP-1962, Matter Labs has essentially completed the development work of the elliptic curve algorithm and provided Rust / Go / C++ reference implementations.

To address the issues of EIP-1962, Matter Labs proposed several EIP splits of EIP-1962 in February 2020, all of which partially inherit the interface of EIP-1962. These EIPs include:

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

Among these EIPs, the most important one 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 BLS signatures on the consensus layer within the mainnet. At that time, ETH2 was developing the deposit contract design for the consensus layer. In the initial design of the deposit contract, since the execution layer did not contain the BLS verification algorithm, the deposit contract would not verify signatures. The specific BLS signature would be verified by the consensus layer after the user’s deposit. If it is found to be incorrect (for new validators), the deposit will fail, and the ETH deposited by the user will be lost.

Against this backdrop, core developers hope to introduce BLS12-381 pre-assembly to implement signature verification within the deposit contract, in order to avoid potential losses for users depositing ETH2 funds. This was also the reason why many developers paid attention to EIP-1962 and EIP-2537 at that time.

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

These doubts were only focused on the content of the EIP document, to which the EIP authors responded and discussed. Subsequently, 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 other EIPs are very effective for recursive SNARK proofs, and in the long run, they would not harm Ethereum. Meanwhile, the meeting also confirmed the priority of EIP-2537, and all clients agreed to implement EIP-2537 as soon as possible, planning to complete all development before the Berlin upgrade.

Subsequently, EIP-2537 became a high-priority task. On March 20, 2020, during 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 be included in the pre-selection EIP list for the Berlin upgrade (, namely Eligibility for Inclusion ( EFI ) ).

During the Ethereum Core Devs Meeting #84 in April 2020, the meeting officially incorporated EIP-2537 into the Berlin hard fork upgrade and established a timeline for the Berlin upgrade to be implemented in April and tested in May-June. Notably, EIP-2537 was listed as a top priority in this discussion.

Subsequently, EIP-2537 entered a large number of development and testing phases, and in nearly 20 subsequent core developer meetings, each meeting basically involved discussions about EIP-2537. Next, let's take a look at the issues related to EIP-2537 discussed in each meeting.

During the Ethereum Core Devs Meeting #85, Danno and Axic discussed the ABI encoding issues of EIP-2537. Subsequently, the core developers synchronized the current implementation status, noting that the proposer of EIP-2537, Matter Labs, had basically completed the Rust version of the implementation. As a result, the Besu client declared that it had essentially implemented the functionality of EIP-2537, while the Geth side stated that no one is currently working on the implementation of EIP-2537.

In the Ethereum Core Devs Meeting #86, different Ethereum node implementations synchronized their progress on EIP-2537. Geth indicated that it has completed some work, but there is still a significant amount of work left to be done.

In the Ethereum Core Devs Meeting #87, the core topic of this developer meeting was the implementation issue of EIP-2537. The Geth developers stated that there is currently a 16,000-line PR implementing EIP-2537, but the Geth developers cannot determine if the PR is a safe and effective implementation of EIP-2537. Therefore, developers can only assess the code situation through the simplest and most brute-force fuzz testing.

The Geth developer said: "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," which means that Geth is unlikely to complete the relevant development for EIP-2537 before the scheduled time in Berlin.

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. At this time, the ETH2 development team is also implementing BLS signature verification, so the ETH2 team can participate in the testing.

Here, we need to provide some background knowledge: the implementation PR of Geth's EIP-2537 has made extensive use of assembly code to ensure efficiency, and this part of the assembly code is very difficult to read and understand. Therefore, Alex Vlasov suggested removing the complex assembly optimizations within the PR to reduce the difficulty of the review.

We have already introduced that a core goal of EIP-2537 is to assist the ETH2 deposit contract. However, at this meeting, the deposit contract developers stated that the deposit contract not using EIP-2537 has already been audited, so some developers suggested that it would be best not to launch another deposit contract using EIP-2537.

In the end, the meeting decided to increase the YOLO testnet, which is primarily focused on testing EIP-2537. In fact, during this meeting, we can see that the importance of EIP-2537 has significantly decreased with the completion of the deposit contract, while Geth developers have already considered that this EIP is very likely to be unable to be implemented before the Berlin upgrade. It seems that the rejection of EIP-2537 by the Berlin upgrade has become a foregone conclusion.

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

At the Ethereum Core Devs Meeting #89, a more serious issue arose, as there were some problems with the YOLO test. Developers suspect that the issue was caused by BLS signatures, but the EIP2537 developers refuted this, believing that the testnet issue was not caused by BLS signatures. The good news regarding EIP-2537 is that the deposit contract based on EIP-2537 is basically completed and is awaiting contract auditing.

At the Ethereum Core Devs Meeting #90内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91, a developer proposed 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.

At the Ethereum Core Devs Meeting #92, 2537 is still confirmed as the EIP required for the Berlin upgrade.

At the Ethereum Core Devs Meeting #96, it was noted that Celo has already incorporated EIP-2537 and EIP-2539 into its network hard fork upgrade. Therefore, Matter Labs hopes to also test EIP-2539, which was proposed alongside EIP-2537, on the YOLO v2 testnet and include it in the Berlin upgrade. However, Geth developers opposed this, arguing that the current EIP-2537 has not been fully tested within Geth. Ultimately, the meeting decided not to add 2696 to the Berlin upgrade and to leave it for future discussion.

During the Ethereum Core Devs Meeting #99, it was decided to remove EIP-2537 from the YOLO v3 testnet and the Berlin upgrade. The main reason is that EIP-2537 wasted too much time for core developers, hindering the development of other EIPs within the Berlin upgrade. A secondary factor is that the Ethereum Foundation proposed EVM384 as a replacement for EIP-2537, which provides 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 Berlin upgrade, but it was ultimately abandoned due to implementation issues. Finally, in April 2021, Ethereum completed the Berlin upgrade, which included core EIPs like EIP-2565 that were not particularly complex. It seems that the Berlin upgrade was somewhat lacking because the most complex and core EIP-2537 was excluded from the upgrade.

subsequent development

As we all know, every Ethereum upgrade comes with a core proposal, such as the London upgrade following 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 include this proposal in subsequent upgrades.

In the London upgrade following Berlin, developers discussed the current development status of EIP-2537 in issues#369曾考虑在 London 升级中增加 EIP-2537。在Ethereum Core Devs Meeting #109. At that time, due to the implementation of EIP-2537 using other libraries, a discussion regarding the gas usage of EIP-2537 was introduced. Meanwhile, some developers proposed replacing EIP-2537 with EVM384. However, during the Ethereum Core Devs Meeting #111 in April 2021, EIP-2537 was removed from the London upgrade due to its complexity. The core complexity lies in the fact that the standard implementation of EIP-2537 changed its dependency libraries, which may lead to changes in gas pricing, and different client implementations would require considerable time to reassess gas consumption.

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

In November 2022, the Ethereum Core Devs Meeting #150 briefly discussed whether EIP-2537 should be included in the Shanghai upgrade, but the developers believed that EIP-2537 needed to be postponed, as the core of the Shanghai upgrade is to support PoS withdrawals. Ultimately, EIP-2537 was not included in the internally focused Shanghai upgrade aimed at enabling withdrawal functions.

Even more tragically, there has been no discussion about EIP-2537 in the Cancun upgrade, as the core of the Cancun upgrade is the execution layer nodes supporting EIP-4844. EIP-4844 provides blobs for Ethereum Layer 2 to facilitate the use of Ethereum as a data availability layer.

Finally, during the Ethereum Core Devs Meeting #181 in February 2024, developers discussed incorporating EIP-2537 into the Pectra upgrade, and at this point, developers believe that the implementation of EIP-2537 is no longer an issue, with only some concerns regarding gas consumption pricing.

At the Ethereum Core Devs Meeting on December 19, 2024, #202内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的Ethereum Core Devs Meeting #203, developers discussed the repricing of the BLS precompile. Geth developer Jared Wasinger suggested increasing the gas cost by 20%, which was supported by benchmarking from the Besu team.

Summary

| Date | Event | | --- | --- | | February 2020 | Split EIP-1962 officially proposed EIP-2537 | | April 2020 - October 2020 | The developer meetings discussed the implementation issues of EIP-2537 multiple times, and ultimately it was abandoned in the Berlin upgrade due to inability to implement it | | March 2021 - April 2021 | Developer meeting discussed the gas cost issue of EIP-2537, ultimately abandoned due to complexity in the London upgrade | | November 2022 | Developer meeting discussed whether to include Shanghai upgrade, no results | | February 2024 | Developers believe that EIP-2537 has no implementation issues, but there are still some gas cost problems that can be included in the Pectra upgrade | | December 2024 - January 2025 | Developers meeting to discuss specific cost calculation models, officially addressing the EIP-2537 cost issue |

It can be seen that whether EIP is included in Ethereum upgrades "depends on self-struggle, but also on the historical journey." Each Ethereum upgrade has its own theme, just as EIP-2537 once became the most important EIP for the Berlin upgrade, but was abandoned due to its implementation difficulty and complexity. The subsequent Ethereum entered the historical process of PoS, where complex pure execution layer EIPs were not given attention, while a large number of execution EIPs related to PoS were regarded as core upgrade goals, leading to EIP-2537 not being accepted for a long time.