Ethereum developers cut EIP-2537 from Berlin path as January became a soft target

Ethereum’s All Core Developers meeting on October 30, 2020 narrowed the path toward the Berlin upgrade by removing EIP-2537 from the planned YOLOv3 test network and delaying the proposal until after the next hard fork. During the same call, participants discussed mid-January 2021 as a plausible estimate for Berlin, but they did not set an activation block or approve a binding launch date.

That distinction matters. The recorded decision concerned scope: meeting notes list only one formal decision, that EIP-2537 was “out of YOLOv3” for the time being. The January window was an estimate voiced during discussion. Contemporaneous coverage accurately described it as a soft target, not a schedule.

A smaller package to keep Berlin moving

Berlin was the name for a backward-incompatible upgrade to Ethereum’s existing proof-of-work chain, then commonly called Eth 1.x. Such upgrades require independently maintained clients to implement the same rule changes and node operators to adopt compatible software. Coordination, testing and specification stability therefore mattered as much as the code itself.

EIP-2537 proposed precompiled operations for the BLS12-381 cryptographic curve, including operations needed for efficient BLS-signature verification. The proposal’s potential connection to the proof-of-stake system under development made it strategically interesting, but the October 30 discussion exposed unresolved implementation, performance and security questions. Participants debated whether an alternative called EVM384 could offer the required functionality and whether either approach had an acceptable attack surface.

The meeting notes show why the group chose subtraction. Client implementers said they could generally prepare YOLOv3 work within two to four weeks, while the BLS discussion threatened to extend Berlin’s timeline. Developers also reported differing readiness across Besu, Geth, Nethermind and OpenEthereum. Removing EIP-2537 reduced the number of unsettled components that had to converge before another multi-client test.

That was not a rejection of BLS cryptography or a finding that EIP-2537 was defective. It was a sequencing decision under uncertainty. The call recorded that fuzzing had run 270 million iterations across Rust and Go implementations without finding incompatibilities, plus another one million rounds through the Geth RPC. Those figures were developer-reported test counts, not an independent security audit and not proof that every implementation risk had been eliminated.

What the January estimate meant

When asked for timing, moderator Hudson Jameson put the earliest Berlin window at two to three months. Tim Beiko said a rushed release might be possible by mid-December 2020, while mid-January 2021 was a better estimate if the BLS debate no longer blocked progress. No precise January date, block height or client release requirement was adopted.

The institutional significance was Ethereum’s governance process in action. There was no company executive issuing a release order. Client teams and protocol contributors used a public call, test networks and Ethereum Improvement Proposals to reduce scope until a compatible upgrade could be coordinated. For exchanges, custodians, application developers and node operators, the useful signal on October 30 was that Berlin was moving again, but remained provisional.

EIP-1559, the separate proposal to redesign Ethereum’s fee mechanism, was also outside Berlin’s contemplated package. Conflating Berlin with that fee change would misstate the October 30 record.

Later context

Later records show that the January estimate did not hold. Ethereum ultimately activated Berlin at block 12,244,000 on April 15, 2021. The final upgrade included EIP-2565, EIP-2718, EIP-2929 and EIP-2930; EIP-2537 was not part of it. That later outcome confirms the October 30 scope decision, while also illustrating why the event-day timing had to be treated as tentative rather than promised.