EIP-2537: 論争から採用までの長い道のり

EIP-2537は、Ethereumの最新のPectraフォークアップグレードで追加が決定されたEVMのプリコンパイル命令です。この命令は、EVMにBLS12-381曲線のさまざまな計算機能を追加し、曲線領域でのペアリング計算などを可能にします。

EIP-2537は2020年に最初に提案され、2025年にようやくイーサリアムのアップグレードに組み込まれることが確認されました。本記事ではEIP-2537のガバナンスの歴史を紹介し、なぜこの提案が5年かけて最終的に採用されたのかを探ります。

提案の背景

2017年1月、ヴィタリック・ブテリンは初めて記事の中でペアリングアルゴリズムとalt_bn128曲線を紹介しました。その後、ヴィタリックとクリスティアン・ライトウィスナーはEIP-196とEIP-197を提案し、EVMにalt_bn128曲線計算のサポートを追加することを推奨しました。

2017年10月のビザンチンアップグレードは正式にalt_bn128曲線を導入し、EVM内部での曲線ドメインペアリング計算を実現し、ZK-Snarks証明の検証がEVM内で完了できるようにしました。

しかし、暗号学の発展に伴い、2017年11月にzcash開発チームはBLS12-381曲線を提案しました。alt_bn128と比較して、BLS12-381はより高い安全性とより良い性能を持っています。その後、多くのブロックチェーンプロトコルがBLS12-381曲線を採用し、alt_bn128を放棄しました。

2018年5月、ジャスティン・ドレイクは記事を発表し、イーサリアムの将来のPoSとシャーディングのアップグレードがBLS12-381曲線に基づくBLSマルチシグネチャアルゴリズムを使用できることを指摘しました。このソリューションは、初期のPoSスキームにおけるバリデーターの数が制限される問題を解決しました。実際、後のETH2アップグレードは確かにBLS12-381曲線を採用しました。

ETH2の開発が進むにつれて、ETH実行層へのBLS12-381の導入を求める声がますます高まっています。2020年2月、研究者たちはEIP-2537を提案し、この提案がETH2テストネットと一緒にテストされることを期待しました。EIP-2537の著者であるAlex Stokesは、Berlinハードフォークにこの提案を含めるよう呼びかけました。

EIP-2537の著者は、ZKSyncの開発会社であるMatterLabsの共同創設者でもあることは注目に値します。

ベルリンのアップグレードの波折

次の進捗を紹介する前に、EIP-1962について理解する必要があります。これは、Matter Labsが2019年4月に提案した最初の楕円曲線ドメインペアリングのプレコンパイルに関する提案で、BLS12、BN、およびMNT4/6の3つの曲線をサポートしています。

EIP-1962は、異なる曲線を処理するために10個のプリコンパイル命令を一度に追加する計画です。しかし、この提案は多くの開発者から疑問視されており、実現が難しすぎるとの意見があります。また、高度に汎用化されているため、スマートコントラクトエンジニアにとって呼び出すのも非常に面倒です。しかし、提案者であるMatter Labsは、楕円曲線アルゴリズムの開発作業を完了しており、さまざまな言語の参考実装を提供しています。

EIP-1962の問題を解決するために、Matter Labsは2020年2月にEIP-1962を分割するための複数のEIPを提案しました。これらのEIPはEIP-1962のインターフェースの一部を継承しています。

• EIP-2537はBLS12-381のサポートを提供します
• EIP-2539はBLS12-377のサポートを提供します
• PR#2541はBLS12-377(Zexe曲線)のサポートを提供しましたが、この提案は最終的にEIP番号を取得しませんでした。

最も重要なのはEIP-2537であり、コンセンサス層もBLS12-381曲線を使用しています。EIP-1962とEIP-2537の核心的な目標は、メインネットでコンセンサス層のBLS署名検証を実現することです。当時、ETH2はコンセンサス層の預金契約を開発中でした。最初の設計では、実行層がBLS検証アルゴリズムを含まないため、預金契約は署名を検証せず、具体的なBLS署名はユーザーの預金後にコンセンサス層によって検証されます。不正が発見された場合、預金は失敗し、ユーザーが預けたETHが失われる可能性があります。

このような背景の中で、コア開発者は、ユーザーの資金の損失を避けるために、預金契約において署名検証を実現するためにBLS12-381のプリコンパイルを導入したいと考えています。これが当時、多くの開発者がEIP-1962およびEIP-2537に注目していた理由でもあります。

EIP-2537が提案された際、Vitalikは提案に存在する一連の問題を指摘しました。これらの疑問は主にEIP文書の内容に集中しており、その後EIPの著者はこれに対して返信し議論を行いました。

2020年3月6日第82回イーサリアムコア開発者会議ではEIP-2537について議論されました。ヴィタリックはこのEIPが再帰的SNARK証明に非常に効果的であり、長期的にはイーサリアムに悪影響を与えないと考えています。会議ではEIP-2537の優先順位が確認され、すべてのクライアントができるだけ早くこのEIPを実装し、Berlinアップグレード前にすべての開発を完了することを計画しています。

その後、EIP-2537は優先度の高いタスクとなりました。3月20日の第83回コア開発者会議では、再び主要な議題として提案されました。会議では、EIP-2537がEIP-1962に代わってコアBLS提案となり、ベルリンアップグレードの予備リストに含まれることが確認されました。

4月の第84回会議は正式にEIP-2537をBerlinハードフォークアップグレードに組み込み、4月の実施、5-6月のテストのタイムラインを決定しました。注目すべきは、EIP-2537が今回の議論で最高優先事項として挙げられたことです。

その後、EIP-2537は大量の開発とテスト段階に入り、以降の約20回のコア開発者会議のほぼすべてで関連する議論が行われました。

第85回の会議では、開発者たちがEIP-2537のABIエンコーディングの問題について議論しました。Matter Labsが以前にRustバージョンの実装をほぼ完了しているため、BesuクライアントはEIP-2537の機能をほぼ実装したと述べていますが、Geth側は現在この関連作業を行っている人はいないとしています。

第86回の会議で、異なるノードが再びEIP-2537の進捗を同期しました。Gethは部分的な作業が完了したと述べましたが、まだ多くのタスクが残っています。

第87回会議ではEIP-2537の実装問題が重点的に議論されました。Gethの開発者はEIP-2537を実装するための16000行のPRが存在すると述べましたが、そのPRがEIP-2537を安全かつ効果的に実装しているかどうかは不明であり、コードの状況を判断するためには最も簡単なファジーテストを通じてのみ行えるとしています。

Gethの開発者は言った:"私の直感では、Gethは7月のメインネットリリース前にBLS曲線操作を準備できない。"

ハドソン・ジェイムソンは、Gethのために暗号エンジニアを探してPRレビューを支援することを提案し、EIP-2537の実装の安全性をテストネットでテストすることを推奨しました。ETH2開発チームもBLS署名検証を実装しているため、テストに参加できます。

補足として、GethのEIP-2537実装PRは効率を確保するために大量のアセンブリコードを使用しており、この部分のコードは非常に読みづらく、理解しにくいです。Alex Vlasovは、レビューの難易度を下げるためにPR内の複雑なアセンブリ最適化を取り除くことを提案しています。

EIP-2537の核心的な目標の一つはETH2の預金契約を支援することですが、今回の会議で預金契約の開発者はEIP-2537の契約を使用しないことが監査済みであると述べ、一部の開発者はEIP-2537を使用した新しい契約を再度リリースしない方が良いと考えています。

最後に、会議ではYOLOテストネットを追加することが決定され、EIP-2537のテスト専用となります。実際、この会議からは、預金契約の完成に伴い、EIP-2537の重要性が大幅に低下していることがわかります。また、Gethの開発者たちは、このEIPがBerlinアップグレード前に実現する可能性が非常に低いと考えています。EIP-2537がBerlinアップグレードに採用されないことは、すでに決定的な状況のようです。

第88回の会議で、Gethの開発者たちはEIP-2537の実装PRに一連の問題があることを発見し、さらなるテストと修正が必要であると述べました。この時、Gethシステムには2つのEIP-2537の実装が存在し、一つはアセンブリの最適化を含み、もう一つは完全にGo言語で書かれています。ある開発者は、コードレビューの難易度を下げるために、Go言語のバージョンを直接使用することを提案しました。

第89回の会議でより深刻な問題が発生し、YOLOテストネットにいくつかの異常が見られ、開発者はBLS署名が原因ではないかと疑っていますが、EIP-2537の開発者はこれに反論しました。良いニュースは、EIP-2537に基づくデポジット契約が基本的に開発を完了し、監査を待っていることです。

第90回会議では、7月にBerlinアップグレードをローンチする最終期限が決定されました。また、会議ではクライアントの多様性問題が議論され、主にGethが支配的な状況について、開発者からは他のクライアントの開発コストを削減するために現在のEIP実装を凍結することが提案されました。第91回会議では、開発者から開発コストを削減してクライアントの多様性を増やすためにモジュール化の提案がありました。

第92回会議では、EIP-2537がベルリンアップグレードに必要なEIPとして引き続き確認される。

第96回の会議では、CeloがEIP-2537とEIP-2539を同時にそのネットワークのハードフォークに組み込んだため、Matter LabsはEIP-2539もYOLO v2テストに加え、Berlinアップグレードに進めたいと考えていました。しかし、Gethの開発者は反対し、現在EIP-2537がGeth内で完全にテストされていないと主張しました。最終的に会議ではBerlinアップグレードにEIP-2696を追加しないことが決定され、将来の議論に留めることになりました。

第99回の会議は、EIP-2537をYOLO v3テストネットおよびBerlinアップグレードから除外することを決定しました。その主な理由は、EIP-2537がコア開発者に過度な時間を費やさせ、Berlinアップグレードの他のEIPの開発を妨げたことです。副次的な要因は、イーサリアム財団がEIP-2537の代替としてEVM384を提案し、より汎用的な楕円曲線計算ソリューションを提供したことです。しかし、コア開発者たちはセキュリティの問題に懸念を示しています。

これがEIP-2537の初期の経緯です。EIP-2537は最初、Berlinアップグレードの最も重要なEIPの一つでしたが、実装の問題から最終的に廃止されました。2021年4月、イーサリアムはBerlinアップグレードを完了しましたが、コアEIPであるEIP-2565は実際には複雑ではなく、アップグレードはやや薄っぺらに見えました。これは、最も核心的で複雑なEIP-2537が除外されたためです。

! イーサリアムガバナンスウォッチ:EIP-2537プレアッセンブルジャーニー

フォローアップ開発

誰もが知っているように、イーサリアムの各アップグレードにはコア提案があります。ベルリン後のロンドンアップグレードは、イーサリアムの歴史の中で最も重要な手数料提案EIP-1559を導入しました。かつてのコア提案EIP-2537にとって、その後のアップグレードで再び取り入れるのは難しいでしょう。

ベルリン後のロンドンアップグレード中、開発者はissues#369でEIP-2537の追加を検討しています。第109回コア開発者会議では、EIP-2537の開発状況が同期されました。他のライブラリを使用して実装されたため、ガス使用に関する議論が引き起こされました。ある開発者はEIP-2537をEVM384で置き換えることを提案しました。しかし、2021年4月の第111回会議では、EIP-2537は複雑性のためロンドンアップグレードから除外されました。主な理由は、EIP-2537の標準実装が依存ライブラリを変更し、ガスの価格が変わる可能性があるため、異なるクライアントの実装がガス消費を再評価するのに多くの時間を要するからです。

2021年6月、issues#343は正式にEIP-2537をShanghaiアップグレードに組み込むことを提案しました。しかし、Londonアップグレード後、The Mergeは開発者の多くの時間を占有し、実行層の開発者はPoSアップグレードを実現するために大量のコードを書く必要がありました。2022年9月、The Mergeが完了した後、実行層の開発者はようやくShanghaiアップグレードの目標について議論を続ける機会を得ました。

2022年11月、第150回コア開発者会議ではEIP-2537をShanghaiに組み込むべきか簡単に議論されましたが、開発者は延期すべきだと考え、Shanghaiの核心はPoSの引き出しをサポートすることです。最終的にEIP-2537は引き出しを核心としたShanghaiアップグレードに組み込まれませんでした。

さらに不幸なことに、CancunのアップグレードではEIP-2537について議論されていません。なぜなら、Cancunの焦点はEIP-4844をサポートすることであり、イーサリアムの第2層にBlobを提供し、第2層がイーサリアムをデータ可用性レイヤーとして使用できるようにするためです。

2024年2月の第181回コア開発者会議まで、開発者はPectraアップグレードにEIP-2537を含めることについて議論しませんでした。この時点で、開発者はEIP-2537の実装は問題ではないと考え、解決すべきは一部のガス消費価格設定の問題だけだとしました。

2024年12月19日の第202回会議で、Nethermindの開発者はEIP-2537の価格モデルを最終決定しました。注目すべきは、EIP-2537の初期提案者であるMatter Labsがこの時点でほぼ議論から撤退していることです。2025年1月の第203回会議では、BLSプリコンパイルの再価格設定について議論され、Gethの開発者Jared Wasingerはガスコストを20%引き上げることを提案し、Besuチームのベンチマークテストの支持を得ました。

! イーサリアムガバナンスウォッチ:EIP-2537コンパイル前の旅

まとめ

EIP-2537は提案から最終的に採用されるまで長く曲折したプロセスを経ました:

• 2020年2月: EIP-1962から分割され、正式にEIP-2537が提案されました
• 2020年4月-10月:実現の問題について何度も議論したが、最終的に実現不可のためBerlinアップグレードを断念した
• 2021年3月-4月:gasコストの問題について議論し、複雑さのためにロンドンアップグレードで放棄された
• 2022年11月:上海アップグレードを含めるかどうかの議論、未果
• 2024年2月:実現することはもはや問題ではないと思われるが、一部のガスコストの問題は依然として存在し、Pectraのアップグレードに組み込むことができる。
• 2024年12月-2025年1月:具体的なコスト計算モデルについて議論し、ガスコストを正式に解決する