🍀 Gate.io Honor Credits Spring Lucky Draw Round 9️⃣ is Officially Live!
💎 Enter the Draw Now and Seize Your Springtime Luck! 👉 https://www.gate.io/activities/creditprize?now_period=9
To Join:
1️⃣ Open the App 'Home'-'Post', and Tap the Credits Icon Next to Your Profile to Enter the 'Credits Center'.
2️⃣ Complete Tasks like Post, Comment, and Like to Earn Honor Credits.
🎁 Every 300 Credits to Draw 1 Chance, Win a MacBook Air, INTER Water Bottle, Futures Voucher, Points, and More Amazing Prizes!
⏰ Ends on April 5th, 16:00 PM (UTC)
👉 Details: https://www.gate.io/announcements/article/44114
#
Ethereum Governance Observation: The Pre-assembly Process of EIP-2537 | GCC Research
Written by: shew
Overview
EIP-2537 is the EVM pre-assembly instruction that was identified to be added in the latest Pectra fork upgrade. This instruction adds various computational functions 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 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 incorporated into the upgrade.
Proposal Background
In January 2017, Vitalik Buterin introduced pairing algorithms and the alt_bn128 curve for the first time in 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 in the EVM.
In October 2017, the Byzantium upgrade officially incorporated the alt_bn128 curve. Simply put, alt_bn128 achieved curve field pairing calculations within the EVM for the first time, enabling ZK-Snarks proof verification to be conducted 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 an article titled "Pragmatic signature aggregation with BLS" in ethresear, pointing out that the BLS multi-signature algorithm based on the BLS12-381 curve could be used for 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 proposal could accommodate a maximum of 900 validators, thus setting a huge staking scale of 1500 ETH for each validator. With the proposal of the BLS multi-signature scheme, EIP-1011 exited the historical stage. It turned out that the later ETH2 upgrade also ultimately used 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 and hoped that the proposal could be tested together on the ETH2 testnet. EIP-2537 author 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 most famous for its product ZKSync.
Berlin Turmoil
Before introducing the subsequent content, we first need to introduce EIP-1962. EIP-1962 is the first proposal regarding elliptic curve domain pairing precompilation proposed by Matter Labs in April 2019, which supports three curves, namely:
The EIP is ready to add 10 preassembly instructions at once to process different curves. However, after the proposal was born, a significant number of developers questioned that the proposal was too complex for developers to implement. At the same time, due to the high generalization of EIP1962, it is also very cumbersome for smart contract engineers to call. Of course, as the originator of EIP-1962, Matter Labs has essentially completed the development of the elliptic curve algorithm and provided a Rust/Go/C++ reference implementation.
To address the issues of EIP-1962, Matter Labs proposed multiple EIP splits of EIP-1962 in February 2020, all of which partially inherit the interface of EIP-1962. These EIPs include:
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 BLS signatures in the consensus layer 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. If an error is found (for new validators), the deposit will fail, and the ETH deposited by the user will be lost.
In this context, core developers hope to introduce BLS12-381 pre-compiled contracts for implementing signature verification within the deposit contract, to avoid potential losses for users depositing ETH2 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 immediately identified a series of issues with the EIP:
These doubts were only focused on the content of the EIP document, and subsequently, the EIP authors responded and discussed. 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 other EIPs were very effective for recursive SNARK proofs and that they would not harm Ethereum in the long run. At the same time, the meeting 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 higher 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 become the pre-selected EIP list for the Berlin upgrade (, namely Eligibility for Inclusion (EFI)).
During the Ethereum Core Devs Meeting #84 in April 2020, the meeting officially included EIP-2537 in the Berlin hard fork upgrade and determined the timeline for the Berlin upgrade to be implemented in April and tested in May - June. Notably, EIP-2537 was listed as the highest priority item in this discussion.
Subsequently, EIP-2537 entered a large development and testing phase, 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 regarding EIP-2537 that were discussed in each meeting.
In Ethereum Core Devs Meeting #85, Danno and Axic discussed ABI encoding for EIP-2537. Subsequently, the core developers synchronized the current implementation, in which the Besu client declared that the functionality of EIP-2537 was basically implemented due to the fact that Matter Labs, the proposer of EIP-2537, had already completed the implementation of the Rust version, but Geth said that no one is currently working on the implementation of EIP-2537.
In the Ethereum Core Devs Meeting #86, different Ethereum node implementations synchronized again regarding the status of EIP-2537, where Geth indicated that part of the work has been completed, but a large amount of work still remains.
At the Ethereum Core Devs Meeting #87, the core content of this developer meeting was the implementation issue of EIP-2537. Geth developers stated that there is currently a 16,000-line PR implementing EIP-2537, but they cannot confirm whether the PR is a safe and valid implementation of EIP-2537. Therefore, developers can only assess the code's situation through the most straightforward and brute-force fuzz testing.
Geth developers 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," meaning that Geth is unlikely to complete the development related to 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 add some background knowledge, which is that Geth's EIP-2537 implementation PR has heavily used assembly code for 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 review.
We have previously introduced that one of the core goals of EIP-2537 is to assist the ETH2 deposit contract, but at this meeting, the deposit contract developers stated that the deposit contract that does not use EIP-2537 has already been audited, so some developers suggested that it would be better not to launch another deposit contract using EIP-2537.
In the end, it was decided to add a 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 dropped significantly with the completion of the deposit contract, and the Geth developers have already decided that the EIP will most likely not be implemented before the Berlin upgrade. It seems a foregone conclusion that EIP-2537 will not be accepted by the Berlin upgrade.
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 time, 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. A developer suggested using the Go version directly to reduce the difficulty of code review.
During the Ethereum Core Devs Meeting #89, a more serious issue arose where the YOLO test encountered some problems. Developers suspect that the issue was caused by BLS signatures, but the EIP2537 developers refuted this, believing that the testnet issues were not due to BLS signatures. The good news regarding EIP-2537 is that the deposit contract based on EIP-2537 is basically completed and is awaiting contract audit.
During the Ethereum Core Devs Meeting #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91, a developer proposed using a modular solution to reduce development costs in order to 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 was still confirmed as the EIP required for the Berlin upgrade.
In the Ethereum Core Devs Meeting #96, it was mentioned that Celo has already incorporated both EIP-2537 and EIP-2539 into its network hard fork upgrade. Therefore, Matter Labs hopes to 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 yet undergone complete testing within Geth. Ultimately, the meeting decided not to add 2696 to the Berlin upgrade, leaving it for future discussion.
At 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 the 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 offers a more general-purpose elliptic curve computation scheme. However, the core developers expressed concerns about security issues during the meeting discussion.
This is the early history of EIP-2537, which was one of the most important EIPs in the Berlin upgrade in the early days, but was eventually scrapped due to implementation issues. Finally, in April 2021, Ethereum completed the Berlin upgrade, and the actual implementations such as EIP-2565 included in the core of the upgrade are not complicated, and it seems that the Berlin upgrade is a little thin, because the most complex EIP-2537 has been kicked out of the Berlin upgrade.
Subsequent Development
As we all know, each upgrade of Ethereum comes with a core proposal, such as the London upgrade after the Berlin upgrade, which introduced the most important transaction fee proposal in Ethereum's history, EIP-1559. For EIP-2537, which was once a core proposal, it has been difficult for subsequent upgrades to incorporate this proposal.
In the London upgrade after Berlin, developers synced the current development status of EIP-2537 in issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109. At this time, due to the use of other libraries to implement EIP-2537, a discussion about the gas usage of EIP-2537 was introduced. Meanwhile, some developers proposed replacing EIP-2537 with EVM384. 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 lies in the fact that the standard implementation of EIP-2537 changed the dependent libraries, which may cause changes in gas pricing, and different client implementations would require considerable time to reevaluate gas consumption.
In June 2021, it was officially proposed in issues#343 to incorporate EIP-2537 into the Shanghai upgrade. However, it is important to note that after the London upgrade, the Pairs upgrade, also known as The Merge, took up a significant amount of 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, during Ethereum Core Devs Meeting #150, there was a brief discussion on 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 Shanghai upgrade, which focused on enabling withdrawal functionality.
What is even more tragic is that the Cancun upgrade has not discussed EIP-2537, 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 Layer 2's use of Ethereum as a data availability layer.
Finally, during the Ethereum Core Devs Meeting #181 in February 2024, the developers discussed incorporating EIP-2537 into the Pectra upgrade, and at this time, the developers believed that the implementation of EIP-2537 was no longer an issue, with only some concerns regarding Gas consumption pricing.
During 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 topics including the repricing of BLS precompiles. Geth developer Jared Wasinger suggested increasing the gas cost by 20%, which received support from the Besu team's benchmarking.
Summary
It can be seen that whether EIP is included in the Ethereum upgrade "of course depends 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 of 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 given much attention, while a large number of execution EIPs related to PoS were regarded as core upgrade targets, which led to EIP-2537 not being accepted for a long time.