EIP-2537:2020年から2025年までの長い旅

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

EIP-2537は2020年に最初に提案され、2025年になってようやくイーサリアムのアップグレードに組み込まれることが確認されました。本稿ではEIP-2537のガバナンスの経緯を紹介し、この提案が5年かけて最終的に採用された理由について考察します。

提案の背景

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

2017年10月のByzantiumアップグレードはalt_bn128曲線を正式に取り入れ、EVM内での曲線領域ペアリング計算を実現し、ZK-Snarks証明の検証がEVM内で完了できるようになりました。

しかし、暗号学の発展に伴い、2017年11月にzcashチームがBLS12-381曲線を提案しました。これはalt_bn128に比べてより高いセキュリティと優れた性能を持っています。その後、多くのブロックチェーンプロトコルがalt_bn128の代わりにBLS12-381曲線を採用しました。

2018年5月、ジャスティン・ドレイクは、イーサリアムの将来のPoSとシャーディングのアップグレードにBLS12-381に基づくBLSマルチシグアルゴリズムを使用できると発表しました。これは後のETH2アップグレードの基礎を築きました。

ETH2の開発が進む中、BLS12-381を実行層に導入する声が高まっています。2020年2月、研究者たちはEIP-2537を提案し、ETH2テストネットと共にテストすることを希望しました。EIP-2537の著者であるAlex Stokesは、これをBerlinハードフォークに組み込むよう呼びかけました。

EIP-2537の著者はMatter Labsの共同創設者でもあり、同社の最も有名な製品はZKSyncであることは言及する価値があります。

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

ベルリンの動乱

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

EIP-1962は、一度に10個のプリコンパイル命令を異なる曲線に追加する計画です。しかし、多くの開発者は、実装が複雑すぎて難しいと考えており、スマートコントラクトエンジニアにとって使いにくいと感じています。しかし、Matter Labsはアルゴリズムの開発を完了し、多言語のリファレンス実装を提供しています。

EIP-1962の問題を解決するために、Matter Labsは2020年2月にいくつかのEIP分割スキームを提案しました。

• 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検証がないため、元の設計ではデポジット契約は署名を検証せず、コンセンサス層で検証されます。もし正しくない場合、デポジットは失敗し、資金損失が発生します。

そのため、コア開発者はBLS12-381のプリコンパイルを導入し、資金リスクを回避するためにデポジットコントラクト内で署名を検証することを望んでいます。これが当時の開発者がEIP-1962とEIP-2537に注目していた理由でもあります。

EIP-2537が提案された後、Vitalikはすぐに一連の問題を指摘し、主に文書の内容に集中しました。著者はその後、応答と議論を行いました。

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

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

4月の会議84は正式にEIP-2537をBerlinハードフォークに組み込み、4月の実施、5-6月のテストのタイムラインを確定しました。EIP-2537は最優先事項として位置付けられています。

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

会議85でABIエンコーディングの問題が議論されました。Matter LabsはRustの実装をほぼ完了しており、BesuクライアントはEIP-2537機能をほぼ実装したと述べていますが、Gethはまだ実装作業を開始していないと報告しています。

会議86の各ノードが再度同期の実現状況を報告し、Gethは一部の作業が完了したが、まだ大量のタスクが残っていると述べています。

会議87の核心内容はEIP-2537実装の問題です。Gethの開発者は、EIP-2537を実装するための16000行のPRが存在すると述べていますが、それが安全かつ有効であるかどうかは不明であり、簡単なファジーテストを通じてのみ判断できるとしています。Gethは、ベルリンの予定時間前に関連する開発を完了することはほぼ不可能であると考えています。

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

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

EIP-2537の主要な目的の一つはETH2のデポジット契約を支援することですが、今回の会議でデポジット契約の開発者はEIP-2537のバージョンを使わないことが監査を通過したと述べ、一部の開発者はEIP-2537を使用した新しいバージョンをリリースしないことを提案しました。

最後の会議では、YOLOテストネットでEIP-2537を専用にテストすることが決定されました。この時点で、預金契約が完了するにつれて、EIP-2537の重要性が大幅に低下していることがわかります。また、Gethの開発者は、Berlinアップグレード前に実現できない可能性が高いと考えています。EIP-2537がBerlinに含まれないことは、ほぼ確定的なようです。

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

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

会議90は7月にBerlinアップグレードの期限を設定しました。会議ではクライアントの多様性問題についても議論され、他のクライアントの開発コストを削減するために現在のEIP実装を凍結することを提案する声がありました。会議91では、モジュラー方式を使用してクライアントの多様性を増やすことすら提案されました。

会議92は再びEIP-2537がBerlinアップグレードに必要なEIPであることを確認しました。

会議96では、CeloがEIP-2537およびEIP-2539をネットワークアップグレードに組み込んだため、EIP-2539をBerlinテストに含めるかどうかが議論されました。しかし、Gethの開発者は反対し、EIP-2537自体がまだ完全にテストされていないと考えました。最終的に、BerlinにEIP-2696を追加しないことが決定されました。

会議99はEIP-2537をYOLO v3テストネットとBerlinアップグレードから除外することを決定しました。主な理由は、これが開発者に過剰な時間を費やさせ、他のEIPの開発に影響を与えたためです。副次的な要因は、イーサリアム財団がEVM384を代替案として提案したことですが、開発者はその安全性に懸念を示しています。

これがEIP-2537の初期の経緯です。これはベルリンアップグレードの最も重要なEIPの一つでしたが、実装上の問題から最終的に廃止されました。2021年4月にイーサリアムはベルリンアップグレードを完了し、コアEIPのEIP-2565の実装は比較的簡単で、やや薄っぺらに感じられました。最も複雑なEIP-2537が除外されたためです。

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

フォローアップ開発

皆が知っているように、イーサリアムの各アップグレードにはコアプロポーザルがあります。ベルリンの後のロンドンではEIP-1559が導入されました。かつてコアプロポーザルであったEIP-2537に関しては、その後のアップグレードで再び採用されるのは難しいでしょう。

ロンドンのアップグレード時、開発者はEIP-2537の追加を検討しました。会議109でその開発状況が同期され、新しいライブラリの使用によってgasに関する議論が引き起こされました。誰かがEVM384の代替を提案しました。しかし、会議111ではその複雑性からロンドンのアップグレードから外されました。主にライブラリの変更がgasの価格設定の変化を引き起こし、再評価が必要となります。

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

2022年11月の会議で150の短い議論が上海の導入について行われましたが、開発者は延期すべきだと考えました。上海の核心はPoSの引き出しをサポートすることです。最終的にEIP-2537は引き出しを中心とした上海のアップグレードには含まれませんでした。

さらに悪いことに、CancunアップグレードではEIP-2537がまだ議論されておらず、その核心はEIP-4844をサポートすることであり、第二層にBlobデータの可用性を提供しています。

ついに、2024年2月の会議181でPectraのアップグレードにEIP-2537が組み込まれることが議論され、開発者たちは実現はもはや問題ではなく、ガスの価格設定にのみ問題が存在すると考えています。

2024年12月19日の会議202では、Nethermindの開発者がEIP-2537の価格モデルを最終決定しました。元提案者のMatter Labsはこの時点でほぼ議論から撤退しています。2025年1月の会議203では再価格設定について議論され、Gethの開発者はガスコストを20%引き上げることを提案し、Besuチームの支持を得ました。

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

まとめ

EIP-2537は提案から採用されるまでに長い5年を要しました。これはBerlinアップグレードの核心であり、実現の困難から放棄されました。その後、イーサリアムはPoSの歴史的プロセスに入り、複雑な純実行層EIPは重視されず、多くのPoS関連EIPが核心目標となり、EIP-2537は長期間受け入れられませんでした。2025年までに、主要な技術的課題が解決されると、EIP-2537はついにPectraアップグレードで実現する見込みです。

この過程は、EIPがイーサリアムのアップグレードに組み込まれるかどうかは、その技術的価値だけでなく、イーサリアム全体の発展段階と優先事項も考慮する必要があることを示しています。各アップグレードにはテーマがあり、現在のニーズに合致し、技術的に成熟したEIPのみが最終的に採用されることができます。

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