Ethereum Governance Observation: EIP-2537 Pre-Assembly 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 a variety of calculation functions of the BLS12-381 curve to the EVM, such as pairing calculations on the curve domain.

EIP-2573 was originally proposed in 2020 and was not confirmed to be included in the Ethereum upgrade until 2025. This article mainly introduces the governance history of EIP-2537 and explores why it took 5 years to include this proposal in the upgrade.

Proposal Background

In January 2017, Vitalik Buterin first introduced the pairing algorithm and the alt_bn128 curve in Exploring Elliptic Curve Pairings . Then in February 2017, Vitalik Buterin and Christian Reitwiessner proposed EIP-196 and EIP-197 , which added support for alt_bn128 curve calculations to the EVM.

The alt_bn128 curve was officially incorporated into the Byzantium upgrade in October 2017. In short, alt_bn128 implements the curve domain pairing calculation inside the EVM for the first time, which enables ZK-Snarks proof verification to be completed within the EVM.

However, with the development of cryptography, in November 2017, the zcash development team first gave the BLS12-381 curve in BLS12-381: New zk-SNARK Elliptic Curve Construction . Compared with alt_bn128 , BLS12-381 has higher security and better performance. Many blockchain protocols have since used the BLS12-381 curve and abandoned alt_bn128 curve.

In May 2018, Justin Drake published an article titled Pragmatic signature aggregation with BLS in ethresear , pointing out that the BLS multi-signature algorithm based on BLS12-381 curve can be used in Ethereum's future PoS and sharding upgrades. At that time, Ethereum researchers hoped to use EIP-1011 to solve the consensus layer problem, but the EIP-1011 solution can accommodate up to 900 validators, so a huge staking scale of 1,500 ETH was set for each validator. With the introduction of the BLS multi-signature solution, EIP-1011 withdrew from the stage of history. As it turned out, the subsequent ETH2 upgrade also eventually used the BLS12-381 curve.

With the development of ETH2, calls for the introduction BLS12-381 used by ETH2 into the ETH execution layer began to be made. In February 2020, some researchers proposed EIP-2537 and hoped that the proposal could be tested together on the ETH2 testnet. Alex Stokes, the author of EIP-2537, called for the inclusion of EIP-2537 in the Berlin hard fork in the article What eth2 needs from eth1 over the next six months .

Interestingly, the author of EIP-2537 is also the co-founder of Matter Labs, and the most famous product of Matter Labs is ZKSync

Berlin Unrest

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

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

The EIP plans to add 10 pre-assembled instructions at a time to handle different curves. However, after the proposal was born, many developers questioned that the proposal was too complicated and difficult for developers to implement. At the same time, due to the high degree of generalization of EIP1962, it is also very troublesome for smart contract engineers to call it. Of course, as the proposer of EIP-1962, Matter Labs has essentially completed the development of the elliptic curve algorithm and provided Rust/Go/C++ reference implementations.

In order to solve the problem of EIP-1962, Matter Labs proposed several EIPs to split EIP-1962 in February 2020. These EIPs 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 please note that this proposal did not get an EIP number and cannot be found on the EIP document website.

Among these EIPs, the most important one is EIP-2537, because 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 the BLS signature of the consensus layer in the main network. At that time, ETH2 was developing the deposit contract design of the consensus layer. When the deposit contract was originally designed, the execution layer did not contain the BLS verification algorithm, so the deposit contract would not verify the signature. The specific BLS signature would be verified by the consensus layer after the user deposited. If it was found to be incorrect (for new validators), the deposit would fail and the ETH deposited by the user would be lost.

In this context, the core developers hope to introduce BLS12-381 pre-assembly to implement signature verification in the deposit contract to avoid possible losses of users' ETH2 deposits. This is also the reason why a large number of developers paid attention to EIP-1962 and EIP-2537 at that time.

When EIP-2537 was first proposed, Vitalik immediately discovered a series of problems with EIP :

These questions were mainly focused on the content of the EIP document, and the EIP author responded and discussed it. Later, on March 6, 2020, at the Ethereum Core Devs Meeting #82 , Ethereum core developers discussed EIP-2537. In this meeting, Vitalik believed that EIPs such as EIP-2537 are very effective for recursive SNARK proofs and will not harm Ethereum in the long run. At the same time, the meeting also confirmed the priority of EIP-2537, and all clients agreed to implement EIP-2537 as soon as possible and planned to complete all development before the Berlin upgrade.

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

At the Ethereum Core Devs Meeting #84 in April 2020 , the meeting formally included EIP-2537 in the Berlin hard fork upgrade, and determined the Berlin upgrade timeline of implementation in April and testing in May-June. It is worth noting that in this discussion, EIP-2537 was listed as the highest priority.

Subsequently, EIP-2537 entered a large number of development and testing phases. In the nearly 20 subsequent core developer meetings, almost every meeting involved discussions on EIP-2537. Next, we can see what issues about EIP-2537 were discussed in each meeting.

In Ethereum Core Devs Meeting #85 , Danno and Axic discussed the ABI encoding issue of EIP-2537. Afterwards, the core developers synchronized the current implementation. Since Matter Labs, the proposer of EIP-2537, had basically completed the implementation of the Rust version, the Besu client claimed that it had basically implemented the functions of EIP-2537, but Geth said that no one is currently working on the implementation of EIP-2537.

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

In Ethereum Core Devs Meeting #87 , the core content of this developer meeting was the implementation of EIP-2537. Geth developers said that there is currently a 16,000-line PR that implements EIP-2537, but Geth developers cannot determine whether the PR implements EIP-2537 safely and effectively, so developers can only judge the code through the simplest and crudest fuzz test.

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 development of EIP-2537 before the scheduled time in Berlin.

Hudson Jameson proposed to find a cryptography engineer for Geth to assist in PR review, and proposed to use the test network to test the implementation security of EIP-2537. Because the ETH2 development team is also implementing BLS signature verification at this time, the ETH2 team can participate in the test.

Here, we need to add some background knowledge, that is, Geth's EIP-2537 implementation PR uses a lot 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 optimization inside the PR to reduce the difficulty of review.

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

In the end, the meeting decided to add the YOLO testnet, the core of which is to test EIP-2537. In fact, in this meeting, we can see that the importance of EIP-2537 has been greatly reduced with the completion of the deposit contract, and Geth developers have already believed that this EIP is very likely to not be implemented before the Berlin upgrade. It seems that EIP-2537 will not be accepted by the Berlin upgrade.

In Ethereum Core Devs Meeting #88 , Geth developers found a series of problems in the implementation PR of EIP-2537, and the developers said that further testing and repair are needed. At this time, there are two EIP-2537 implementations in the Geth system, one of which contains assembly optimization, and the other is written entirely in go language. Some developers proposed to use the go language version directly to reduce the difficulty of code review.

In Ethereum Core Devs Meeting #89 , more serious problems occurred. There were some problems with the YOLO test. The developers suspected that the problem was caused by the BLS signature, but the EIP2537 developers refuted this and believed that the test network problem was not caused by the BLS signature. The good news for EIP-2537 is that the deposit contract based on EIP-2537 has been basically developed and is awaiting contract audit.

In Ethereum Core Devs Meeting #90 , the meeting locked the DDL for the Berlin upgrade to be launched in July. Of course, another interesting argument in this meeting was the client diversity issue. In this meeting, developers mainly discussed the situation where Geth is dominant, and some developers proposed freezing the current EIP implementation to reduce the development costs of other clients. Even more interesting is that in the #91 meeting, some developers proposed using modular solutions 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 , 2537 is still confirmed as the EIP required for the Berlin upgrade.

In Ethereum Core Devs Meeting #96 , since Celo has already included both EIP-2537 and EIP-2539 in its network hard fork upgrade, Matter Labs hopes to put EIP-2539, which was proposed at the same time as EIP-2537, on the YOLO v2 testnet for testing and into the Berlin upgrade. However, Geth developers objected, believing that the current EIP-2537 has not been fully tested within Geth. In the end, the meeting decided not to add 2696 to the Berlin upgrade, leaving it for future discussion.

In Ethereum Core Devs Meeting #99 , the meeting decided to remove EIP-2537 from the YOLO v3 testnet and Berlin upgrade. The core reason was that EIP-2537 wasted too much time of core developers, which hindered the development of other EIPs in the Berlin upgrade. A secondary factor was that the Ethereum Foundation proposed EVM384 as a replacement for EIP-2537. EVM 384 provides a more general elliptic curve calculation solution. However, the core developers expressed concerns about security issues during the meeting discussion.

The above content is the early history of EIP-2537. We can see that EIP-2537 was one of the most important EIPs in the Berlin upgrade in the early days, but it was eventually abandoned due to implementation issues. Finally, in April 2021, Ethereum completed the Berlin upgrade. The actual implementation of EIP-2565 and other core implementations included in the upgrade was not complicated. It seems that the Berlin upgrade seems a bit thin. This is because the most core and complex EIP-2537 was kicked out of the Berlin upgrade.

Subsequent development

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

In the London upgrade after Berlin, developers considered adding EIP-2537 to the London upgrade in issues #369 . In Ethereum Core Devs Meeting #109 , developers synchronized the current development of EIP-2537. At this time, due to the use of other libraries to implement EIP-2537, a discussion about the use of gas by EIP-2537 was introduced. At the same time, some developers proposed to use EVM384 to replace EIP-2537. However, in 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 EIP-2537 standard implementation replaces the dependent library, which may cause changes in gas pricing, and different client implementations need to spend considerable time re-evaluating gas consumption.

In June 2021, issue #343 formally proposed to include EIP-2537 in the Shanghai upgrade. However, it should be noted that after the London upgrade, the Pairs upgrade, also known as The Merge, actually took up a lot of developer time, and the executive layer developers needed to write a lot of code to implement the PoS upgrade. In September 2022, the Pairs upgrade was completed, and the executive 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, and the core of the Shanghai upgrade was to support PoS withdrawals. In the end, EIP-2537 was not included in the Shanghai upgrade, which was centered on implementing the withdrawal function.

What’s even more tragic is that the Cancun upgrade has not discussed EIP-2537, because the core of the Cancun upgrade is that the execution layer nodes support EIP-4844. EIP-4844 provides Blob for Ethereum Layer 2 to facilitate the use of Ethereum as a data availability layer for Layer 2.

Finally, in the Ethereum Core Devs Meeting #181 in February 2024 , developers discussed incorporating EIP-2537 into the Pectra upgrade, and at this point the developers believed that the implementation of EIP-2537 was no longer a problem, with only part of the problem being with gas consumption pricing.

In Ethereum Core Devs Meeting #202 on December 19, 2024 , Nethermind developers finalized the pricing model for EIP-2537. Yes, Matter Labs, the original proposer of EIP-2537, has almost withdrawn from the discussion at this time. In the subsequent Ethereum Core Devs Meeting #203 in January 2025 , developer discussions included repricing BLS precompiles, and Geth developer Jared Wasinger suggested increasing gas costs by 20%, which was supported by the Besu team's benchmark test.

Summarize

It can be seen that whether EIP is included in the Ethereum upgrade "of course depends on self-struggle, but also takes into account the course of history". Every Ethereum upgrade will have its own theme, just as EIP-2537 once became the most important EIP for the Berlin upgrade, but was abandoned due to its difficulty and complexity in implementation. Subsequently, Ethereum entered the historical process of PoS, and the complex pure execution layer EIP was not taken seriously, while a large number of PoS-related execution EIPs were regarded as core upgrade goals, which led to EIP-2537 not being accepted for a long time.