EIP-2537:イーサリアムBLS12-381プリコンパイル命令の長い道のり

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

EIP-2573は2020年に最初に提案され、2025年にイーサリアムのアップグレードに追加されることが確認されました。本稿ではEIP-2537のガバナンスの経緯を紹介し、この提案が5年かけて最終的にアップグレードに組み込まれた理由を探ります。

提案の背景

2017年1月、ヴィタリック・ブテリンは初めてペアリングアルゴリズムとalt_bn128曲線を紹介しました。その後、ヴィタリックとクリスチャン・ライトウィスナーはEIP-196とEIP-197を提案し、EVMにalt_bn128曲線計算のサポートを追加しました。これらの提案は2017年10月のビザンチウムアップグレードで正式に採用され、EVM内部での曲線域ペアリング計算を実現し、ZK-Snarks証明の検証がEVM内で行えるようになりました。

暗号学の発展に伴い、zcashチームは2017年11月にBLS12-381曲線を提案しました。alt_bn128と比較して、BLS12-381はより高い安全性とより良いパフォーマンスを持っています。多くのブロックチェーンプロトコルがalt_bn128曲線の代わりにBLS12-381曲線を使用し始めています。

2018年5月、ジャスティン・ドレイクはイーサリアムの将来のPoSとシャーディングのアップグレードがBLS12-381曲線に基づくBLSマルチシグアルゴリズムを使用できると指摘しました。これにより、元のEIP-1011案は歴史の舞台から退場しました。事実、後のETH2アップグレードは確かにBLS12-381曲線を採用しました。

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

注目すべきは、EIP-2537の作者もZKSyncの開発者Matter Labsの共同創設者であるということです。

! イーサリアムガバナンスウォッチ: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-1962を提案し、そのインターフェースの一部を継承しました。これらの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検証アルゴリズムがないため、デポジット契約は署名を検証しません。具体的なBLS署名はユーザーのデポジット後にコンセンサス層によって検証され、不正が発見された場合、ユーザーの資金損失を引き起こす可能性があります。

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

EIP-2537が提案された後、Vitalikはすぐに一連の問題を指摘し、主にEIP文書の内容に集中しました。EIPの作者はその後、返信と議論を行いました。2020年3月6日のコア開発者会議で、VitalikはEIP-2537などのEIPが再帰SNARK証明に非常に効果的であり、長期的にはイーサリアムに損害を与えることはないと考えました。会議ではEIP-2537の優先地位が確認され、すべてのクライアントはできるだけ早く実装することに同意し、Berlinアップグレード前に開発を完了する計画を立てました。

その後、EIP-2537は高優先度のタスクとなりました。3月20日の会議で、EIP-2537がEIP-1962の代わりにコアBLS提案として確認され、Berlinアップグレードの予備リストに入りました。4月の会議で正式にEIP-2537がBerlinハードフォークアップグレードに組み込まれ、4月の実施、5-6月のテストのタイムラインが確定され、最優先事項としてリストされました。

その後、EIP-2537は大量の開発とテストの段階に入り、以降の約20回のコア開発者会議で議論されました。

第85回会議では、開発者たちがEIP-2537のABIエンコーディングの問題について議論しました。Besuクライアントは基本的な機能を実装したと述べていますが、Gethの方はまだ関連する作業を行っていないと述べています。

第86回の会議で、Gethは一部の作業が完了したが、まだ多くの作業が残っていると述べました。

第87回会議ではEIP-2537の実装問題が重点的に議論されました。Gethの開発者は、EIP-2537を実装した16000行のPRが存在するが、その安全性と有効性を確定できず、単純なファジーテストによってのみ判断できると述べました。Gethの開発者は、ベルリンの予定された時間内にEIP-2537の開発を完了することはできないと考えています。

会議はYOLOテストネットでEIP-2537を専用にテストすることを決定しました。この時点でEIP-2537の重要性は大幅に低下しており、Gethの開発者はこのEIPがベルリンアップグレードに組み込まれる可能性が非常に低いと考えています。

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

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

第90回の会議では、7月にBerlinアップグレードを上线する期限が確定しました。会議では、Gethの主導的地位に関する問題も議論され、他のクライアントの開発コストを削減するために現在のEIPの実装を凍結する提案がありました。

第92回会議は依然としてEIP-2537をベルリンアップグレードに必要なEIPとして確認しました。

第96回会議で、Matter LabsはEIP-2539をYOLO v2テストに組み込み、Berlinアップグレードに含めることを望んでいました。しかし、Gethの開発者は反対し、EIP-2537はまだGeth内で完全にテストされていないと考えました。最終的に、Berlinアップグレードに2696を追加しないことが決定されました。

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

2021年4月、イーサリアムはベルリンアップグレードを完了しました。核心に含まれるEIP-2565などの実際の実装はそれほど複雑ではなく、アップグレードは薄っぺらに見えます。これは、最も核心的で複雑なEIP-2537が除外されたためです。

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

フォローアップ開発

ベルリンアップグレード後のロンドンアップグレードはEIP-1559を導入しました。かつてコア提案として存在したEIP-2537については、その後のアップグレードに組み込むことが困難です。

ロンドンアップグレード中、開発者はEIP-2537の追加を検討していました。第109回会議ではEIP-2537の開発状況が同期され、ガス使用に関する問題が議論されました。誰かがEIP-2537をEVM384に置き換えることを提案しました。しかし、第111回会議では複雑性のためEIP-2537がロンドンアップグレードから外されました。主な理由はEIP-2537の標準実装が依存ライブラリを変更したため、ガスの価格が変動する可能性があり、各クライアントはガス消費を再評価する必要があるためです。

2021年6月にEIP-2537を上海アップグレードに組み込む正式な提案が行われました。しかし、マージアップグレードは開発者の多くの時間を占めました。2022年9月にマージが完了した後、実行層の開発者は上海アップグレードの目標について再び議論する機会を得ました。

2022年11月、第150回会議ではEIP-2537をShanghaiアップグレードに組み込むかどうかが短期間議論されましたが、延期する必要があると判断されました。Shanghaiアップグレードの核心はPoSの引き出しをサポートすることです。最終的にEIP-2537は引き出し機能を核心としたShanghaiアップグレードには組み込まれませんでした。

カンクンのアップグレードはEIP-2537について議論されていない、なぜならその核心はEIP-4844をサポートし、二層にBlobデータの可用性を提供するからである。

2024年2月、第181回会議ではPectraのアップグレードにEIP-2537を組み込むことについて議論し、実現はもはや問題ではなく、ただgas消費の価格設定に問題があると考えられています。

2024年12月19日、第202回会議でNethermindの開発者はEIP-2537の価格モデルを決定しました。最初の提案者であるMatter Labsはこの時点でほぼ議論から退出していました。2025年1月の第203回会議ではBLSプリコンパイルの再価格設定について議論され、Gethの開発者はガスコストを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月:具体的なコストモデルについて議論し、コスト問題を正式に解決する

EIPがイーサリアムのアップグレードに組み込まれるかどうかは、自らの努力だけでなく、歴史的経緯も考慮する必要があります。アップグレードごとにテーマがありますが、EIP-2537はBerlinアップグレードの核心でしたが、その複雑さから廃止されました。その後、イーサリアムはPoSに焦点を当て、純粋な実行層のEIPは重視されず、EIP-2537は長い間受け入れられませんでした。最近になって、開発者は再びその残された問題に注目し、解決に取り組みました。

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