**著者:shew**###の概要EIP-2537は、最新のPectraフォークアップグレードで追加されることが決定されたEVMプリアセンブリ命令です。この命令により、EVMはBLS12-381曲線に関するさまざまな計算機能を追加し、曲線の領域でのペアリング計算などが可能になります。EIP-2573は2020年に最初に提案され、2025年にようやくEthereumアップグレードに追加されることが確認されました。本記事ではEIP-2537のガバナンスの歴史を主に紹介し、なぜ5年もかかってこの提案がアップグレードに組み込まれたのかを探ります。### 提案の背景2017 年 1 月、Vitalik Buterin は Exploring Elliptic Curve Pairings でペアリング アルゴリズムと 'alt_bn128' 曲線を初めて紹介しました。 その後、2017 年 2 月に Vitalik Buterin と Christian Reitwiessner が EIP-196 と EIP-197 を提案し、EVM に「alt_bn128」曲線計算のサポートを追加しました。2017年10月のByzantiumアップグレードにおいて、正式に`alt_bn128`曲線が導入されました。簡単に言うと、`alt_bn128`はEVM内部での曲線領域ペアリング計算を初めて実現し、これによりZK-Snarksの証明検証がEVM内で行えるようになりました。しかし、暗号技術の発展に伴い、2017年11月にzcash開発チームはBLS12-381: New zk-SNARK Elliptic Curve Constructionで初めて`BLS12-381`曲線を示しました。`alt_bn128`と比較して、`BLS12-381`はより高い安全性とより良い性能を持っています。その後、多くのブロックチェーンプロトコルが`BLS12-381`曲線を使用し、`alt_bn128`曲線を廃止しました。2018年5月、ジャスティン・ドレイクはethresearにおいて「BLSによる実用的な署名集約」という論文を発表し、イーサリアムの将来のPoSおよびシャーディングのアップグレードで、`BLS12-381`曲線に基づくBLSマルチシグアルゴリズムが使用できることを指摘しました。当時、イーサリアムの研究者たちはEIP-1011を用いてコンセンサス層の問題を解決したいと考えていましたが、EIP-1011の提案は最大900人の検証者しか受け入れられず、各検証者に1500 ETHという巨額のステーキング規模が設定されていました。BLSマルチシグの提案が出ると、EIP-1011は歴史の舞台から退きました。後に、ETH2のアップグレードも最終的に`BLS12-381`曲線を使用することが証明されました。ETH2の開発に伴い、ETH2で使用される`BLS12-381`がETH実行層に導入されることが呼びかけられています。2020年2月、一部の研究者がEIP-2537を提案し、この提案がETH2テストネットでテストされることを望んでいます。EIP-2537の著者であるAlex Stokesは、What eth2 needs from eth1 over the next six monthsという記事の中で、ベルリンのハードフォークにEIP-2537を組み入れるよう呼びかけています。興味深いことに、EIP-2537の著者は、ZKSyncという製品で最もよく知られているMatter Labsの共同設立者でもあります### ベルリンの動乱私たちは今後の内容を紹介する前に、まずEIP-1962について説明する必要があります。EIP-1962は、Matter Labsが2019年4月に提案した、楕円曲線領域ペアリングの事前アセンブリに関する最初の提案であり、この提案は次の3つの曲線をサポートしています：* BLS12の* BNの* MNT4/6 (Ateペアリング)このEIPは、異なる曲線を処理するために、一度に10個のプリプロセッサ命令を追加する準備をしています。しかし、この提案が誕生した後、相当数の開発者が提案が複雑すぎて開発者が実装するのが難しいと疑問を呈しました。また、EIP1962は高度に汎用化されているため、スマートコントラクトエンジニアにとっても呼び出しが非常に面倒です。もちろん、EIP-1962の提案者であるMatter Labsは、実質的に楕円曲線アルゴリズムの開発作業を完了しており、Rust / Go / C++の参考実装を提供しています。EIP-1962の問題を解決するために、Matter Labsは2020年2月に複数のEIPを提案しました。これらのEIPは、EIP-1962のインターフェースを部分的に継承しています。これらのEIPには、* EIP-2537はBLS12-381のサポートを提供します* EIP-2539はBLS12-377をサポートしています* PR#2541はBLS12-377 (Zexe曲線)のサポートを提供しますが、この提案は最終的にEIP番号を取得できなかったため、EIP文書の公式ウェブサイトでは見つかりません。これらのEIPの中で最も重要なのはEIP-2537であり、なぜならコンセンサス層もBLS12-381曲線を使用しているからです。EIP-1962とEIP-2537の核心目的は、メインネット内でコンセンサス層のBLS署名の検証を実現することです。当時、ETH2はコンセンサス層のデポジット契約設計を開発中でした。デポジット契約の最初の設計では、実行層にBLS検証アルゴリズムが含まれていなかったため、デポジット契約は署名を検証しませんでした。具体的なBLS署名は、ユーザーがデポジットした後にコンセンサス層によって検証され、不正が発見された場合（新しいバリデーターに対して）、デポジットは失敗し、ユーザーが預けたETHは失われます。この背景の下、コア開発者は、ユーザーが ETH2 資金を預け入れる際の損失を回避するために、BLS12-381 プリコンパイルをデポジット契約に導入し、署名検証を実現することを希望しています。これが当時、多くの開発者が EIP-1962 および EIP-2537 に関心を持った理由でもあります。EIP-2537が提案されたとき、VitalikはすぐにEIPに存在する一連の問題を発見しました:! [イーサリアムガバナンスウォッチ:EIP-2537プリコンパイルジャーニー](https://img.gateio.im/social/moments-1f78fbf1beee46a4a213a7c20c0ddd84)これらの疑問はEIP文書の内容に集中しており、その後EIPの作者がこれに対して返信と議論を行いました。その後、2020年3月6日にEthereum Core Devs Meeting #82で、Ethereumのコア開発者がEIP-2537について議論しました。この会議では、VitalikはEIP-2537などのEIPが再帰的SNARK証明に非常に効果的であり、長期的にはEthereumに損害を与えないと考えました。また、会議ではEIP-2537の優先順位が確認され、すべてのクライアントがEIP-2537をできるだけ早く実装することに同意し、Berlinアップグレード前にすべての開発を完了する計画を立てました。その後、EIP-2537は優先度の高いタスクとなりました。2020年3月20日、Ethereum Core Devs Meeting #83において、EIP-2537は依然として最初に議論された提案です。この会議では、EIP-2537がEIP-1962に代わってコアBLS提案として確認され、Berlinアップグレードの予備EIPリストに含まれることが決まりました(即 Eligibility for Inclusion (EFI))。2020年4月のEthereum Core Devs Meeting #84において、会議は正式にEIP-2537をBerlinハードフォークアップグレードに組み込み、4月に実施し、5月から6月にかけてテストを行うBerlinアップグレードのタイムラインを決定しました。注目すべきは、この討論の中でEIP-2537が最優先事項として挙げられたことです。! [イーサリアムガバナンスウォッチ:EIP-2537プリコンパイルジャーニー](https://img.gateio.im/social/moments-3198079b11f21298df05682606409838)その後、EIP-2537は大量の開発とテストの段階に入り、その後の約20回のコア開発者会議では、ほぼすべての会議でEIP-2537に関する議論が行われました。次に、各会議でEIP-2537についてどのような問題が議論されたのかを見てみましょう。Ethereumコア開発者会議#85では、DannoとAxicがEIP-2537のABIエンコーディングの問題について議論しました。その後、コア開発者たちは現在の実装状況を同期しました。この中で、EIP-2537の提案者であるMatter LabsがRustバージョンの実装をほぼ完了しているため、BesuクライアントはEIP-2537の機能をほぼ実装したと宣言していますが、Geth側は現在EIP-2537の実装に取り組んでいる人はいないと述べています。Ethereum Core Devs Meeting #86では、異なるEthereumノードの実装が再びEIP-2537の実装状況を同期しました。その中でGethは一部の作業を完了したと述べましたが、まだ多くの作業が残っています。! [イーサリアムガバナンスウォッチ:EIP-2537プリコンパイルジャーニー](https://img.gateio.im/social/moments-75338d7a495f20ef25a70cca21a48381)Ethereum Core Devs Meeting #87 において、今回の開発者会議の最も重要な内容は EIP-2537 の実装問題です。Geth 開発者は現在 16000 行の PR で EIP-2537 を実装しているが、Geth 開発者は PR が EIP-2537 を安全かつ有効に実装しているかどうかを確認できないため、開発者は最も単純で粗暴なファジングテストを通じてコードの状態を判断するしかありません。Gethの開発者は言いました:"私の直感的な反応は、Gethが7月のメインネットローンチに向けてBLS曲線操作の準備ができる可能性はないということです。" つまり、Gethはベルリンの予定時間前にEIP-2537に関する開発を完了する可能性が高くありません。ハドソン・ジェイモンは、GethのPRレビューを支援するために暗号エンジニアを探すことを提案し、EIP-2537の実装の安全性をテストネットでテストすることを提案しました。この時、ETH2開発チームもBLS署名検証を実装しているため、ちょうどETH2チームがテストに参加できることになります。ここで、Geth の EIP-2537 実装 PR についての背景知識を補足する必要があります。効率を保証するために、大量のアセンブリコードが使用されており、このアセンブリコードは非常に読みづらく理解しにくいです。そこで、アレックス・ヴラスオフは、審査の難易度を下げるために、PR 内部の複雑なアセンブリ最適化を削除することを提案しました。私たちは前述の中で、EIP-2537 の核心的な目的の一つが ETH2 の預金契約を支援することであると紹介しましたが、今回の会議では預金契約の開発者が EIP-2537 を使用しない預金契約がすでに監査を通過していると述べました。そのため、一部の開発者は EIP-2537 を使用する預金契約を新たに導入しない方が良いと提案しました。最後に、会議はYOLOテストネットの追加を決定しました。このテストネットの核心はEIP-2537のテストです。実際、この会議では、預金契約の完成に伴いEIP-2537の重要性が大幅に低下しているのが見て取れ、Gethの開発者たちはこのEIPがベルリンのアップグレード前に実現する可能性は極めて低いと考えています。EIP-2537がベルリンのアップグレードに受け入れられないことは既に定局となっているようです。Ethereum Core Devs Meeting #88では、Gethの開発者がEIP-2537の実装PRに一連の問題があることを発見し、開発者はさらにテストと修正が必要だと述べました。この時点でGethシステム内には2つのEIP-2537の実装が存在し、そのうちの1つはアセンブリ最適化を含み、もう1つは完全にGo言語で書かれています。ある開発者は、コードレビューの難易度を下げるために、Go言語で書かれたバージョンを直接使用することを提案しました。イーサリアムコア開発者会議 #89内In、より深刻な問題が発生し、YOLOテストにいくつかの問題があり、開発者はBLS署名が原因ではないかと疑っていましたが、EIP2537開発者はテストネットの問題はBLS署名が原因ではないと主張して反論しました。 EIP-2537にとって朗報なのは、EIP-2537ベースの預金契約が基本的に開発されており、契約の監査を待っていることです。Ethereum Core Devs Meeting #90内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91の会議で、開発者はモジュール化の提案をして開発コストを削減し、クライアントの多様性を増やすことを提案しました。もし読者がイーサリアムクライアントの多様性に興味があれば、これら二回の会議の記録を読むことができます。Ethereum Core Devs Meeting #92において、2537は依然としてBerlinアップグレードに必要なEIPとして確認されています。Ethereum Core Devs Meeting #96の中で、CeloはEIP-2537とEIP-2539を同時にそのネットワークのハードフォークアップグレードに組み込んだため、Matter LabsはEIP-2539をYOLO v2テストネットでテストし、Berlinアップグレードに組み込むことを希望しています。しかし、Gethの開発者は反対し、現在のEIP-2537はGeth内部で完全にテストされていないと考えています。最終的に会議はBerlinアップグレードに2696を追加しないことを決定し、将来の議論に留めることになりました。Ethereumコア開発者会議#99では、EIP-2537をYOLO v3テストネットとBerlinアップグレードから除外することが決定されました。最も重要な理由は、EIP-2537がコア開発者の時間を無駄にし、Berlinアップグレード内の他のEIPの開発を妨げたためです。副次的な要因は、イーサリアム財団がEIP-2537の代替としてEVM384を提案したことです。EVM384は、より汎用的な楕円曲線計算ソリューションを提供します。しかし、コア開発者は会議の討論の中でセキュリティ問題に対する懸念を表明しました。上記の内容はEIP-2537の初期の経緯です。EIP-2537は初期のベルリンアップグレードで最も重要なEIPの一つでしたが、実装の問題により最終的に廃止されました。2021年4月にイーサリアムはベルリンアップグレードを完了し、アップグレードの中核を成すEIP-2565などの実際の実装はそれほど複雑ではありませんでした。ベルリンアップグレードはやや薄っぺらに見えるかもしれませんが、これは最も核心的で複雑なEIP-2537がベルリンアップグレードから排除されたためです。! [イーサリアムガバナンスウォッチ:EIP-2537プリコンパイルジャーニー](https://img.gateio.im/social/moments-55d3bb1142078f459d3a41ead42cd599)### フォローアップ開発誰もが知っているように、イーサリアムのアップグレードごとにコア提案が存在します。例えば、ベルリンアップグレードの後のロンドンアップグレードでは、イーサリアムの歴史の中で最も重要な手数料提案であるEIP-1559が導入されました。かつてコア提案として存在していたEIP-2537に関しては、その後のアップグレードでこの提案を取り入れることは非常に難しいです。ベルリン後のロンドンアップグレードでは、開発者がissues#369曾考虑在 London 升级中增加 EIP-2537。在Ethereum Core Devs Meeting #109で現在のEIP-2537の開発状況を同期しました。この時、他のライブラリを使用してEIP-2537を実装しているため、EIP-2537のガス使用に関する議論が持ち上がりました。同時に、開発者はEIP-2537の代わりにEVM384を使用することを提案しました。しかし、2021年4月のEthereum Core Devs Meeting #111では、EIP-2537はその複雑性ゆえにロンドンアップグレードから外されました。核心的な複雑性は、EIP-2537の標準実装が依存ライブラリを変更したため、ガス価格が変動する可能性があることにあります。異なるクライアントの実装は、ガス消費を再評価するためにかなりの時間を要する必要があります。2021年6月に、issues#343内で正式にEIP-2537をShanghaiアップグレードに組み込むことが提案されました。しかし、Londonアップグレード後、実際にはPairsアップグレード、またはThe Mergeと呼ばれるものが開発者の多くの時間を占めていたことに注意が必要です。実行層の開発者は、PoSアップグレードを実現するために多くのコードを書く必要がありました。2022年9月にPairsアップグレードが完了し、実行層の開発者はついにShanghaiアップグレードのいくつかの目標について議論を続ける機会を得ました。2022年11月、Ethereum Core Devs Meeting #150ではEIP-2537をShanghaiアップグレードに含めるかどうかが短時間議論されましたが、開発者はEIP-2537を後回しにする必要があると考えました。Shanghaiアップグレードの核心はPoSの引き出しをサポートすることです。最終的に、EIP-2537は引き出し機能を核心としたShanghaiアップグレードには含まれませんでした。さらに悲惨なことに、CancunアップグレードはEIP-2537についての議論をまったく行っていません。なぜなら、Cancunアップグレードの核心は、実行層ノードがEIP-4844をサポートすることだからです。EIP-4844は、イーサリアムの第2層にBlobを提供し、第2層がイーサリアムをデータ利用可能層として使用することを容易にします。ついに、2024年2月のEthereum Core Devs Meeting #181で、開発者はPectraアップグレードにEIP-2537を組み込むことについて議論しました。この時点で、開発者はEIP-2537の実装は問題ではないと考え、Gas消費の価格設定に関してのみ一部の問題が残っていると考えています。2024年12月19日のEthereum Core Devs Meeting #202内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的Ethereum Core Devs Meeting #203では、開発者たちはBLSプリコンパイルの再価格設定を含む議論を行い、Gethの開発者であるJared Wasingerはガスコストを20%引き上げることを提案し、Besuチームのベンチマークテストの支持を受けました。### まとめ| 日付 | イベント || --- | --- || 2020年2月号 | スプリットEIP-1962が正式に提案 EIP-2537|| 2020年4月 - 2020年10月 | 開発者会議でEIP-2537の実装問題が何度も議論され、最終的には実現不可能なためベルリンアップグレードで放棄された || 2021年3月 - 2021年4月 | 開発者会議でEIP-2537のガスコスト問題について議論し、最終的には複雑性のためにロンドンアップグレードで放棄されました || 2022年11月 | 開発者会議でShanghaiアップグレードを含めるかどうかが議論されましたが、結果は得られませんでした || 2024年2月 | 開発者はEIP-2537に実装上の問題がないと考えているが、一部のガスコストの問題が残っており、Pectraアップグレードに組み込むことができると考えている || 2024年12月 - 2025年1月 | 開発者会議で具体的なコスト計算モデルについて議論し、正式にEIP-2537のコスト問題を解決する |見ての通り、EIPがイーサリアムのアップグレードに組み込まれるかどうかは、「もちろん自分自身の努力に依存するが、歴史の流れも考慮に入れる必要がある」。イーサリアムのアップグレードはそれぞれテーマを持っており、EIP-2537は一度ベルリンアップグレードで最も重要なEIPとなったが、その実装の難しさと複雑さから廃止された。その後のイーサリアムはPoSの歴史的過程に入り、複雑な純実行層EIPは重視されず、PoSに関連する多数の実行EIPが核心的なアップグレード目標と見なされ、このため長い間EIP-2537は受け入れられなかった。
イーサリアムガバナンス観察：EIP-2537プレアセンブリの経過
著者:shew
###の概要
EIP-2537は、最新のPectraフォークアップグレードで追加されることが決定されたEVMプリアセンブリ命令です。この命令により、EVMはBLS12-381曲線に関するさまざまな計算機能を追加し、曲線の領域でのペアリング計算などが可能になります。
EIP-2573は2020年に最初に提案され、2025年にようやくEthereumアップグレードに追加されることが確認されました。本記事ではEIP-2537のガバナンスの歴史を主に紹介し、なぜ5年もかかってこの提案がアップグレードに組み込まれたのかを探ります。
提案の背景
2017 年 1 月、Vitalik Buterin は Exploring Elliptic Curve Pairings でペアリング アルゴリズムと 'alt_bn128' 曲線を初めて紹介しました。 その後、2017 年 2 月に Vitalik Buterin と Christian Reitwiessner が EIP-196 と EIP-197 を提案し、EVM に「alt_bn128」曲線計算のサポートを追加しました。
2017年10月のByzantiumアップグレードにおいて、正式に
alt_bn128曲線が導入されました。簡単に言うと、alt_bn128はEVM内部での曲線領域ペアリング計算を初めて実現し、これによりZK-Snarksの証明検証がEVM内で行えるようになりました。しかし、暗号技術の発展に伴い、2017年11月にzcash開発チームはBLS12-381: New zk-SNARK Elliptic Curve Constructionで初めて
BLS12-381曲線を示しました。alt_bn128と比較して、BLS12-381はより高い安全性とより良い性能を持っています。その後、多くのブロックチェーンプロトコルがBLS12-381曲線を使用し、alt_bn128曲線を廃止しました。2018年5月、ジャスティン・ドレイクはethresearにおいて「BLSによる実用的な署名集約」という論文を発表し、イーサリアムの将来のPoSおよびシャーディングのアップグレードで、
BLS12-381曲線に基づくBLSマルチシグアルゴリズムが使用できることを指摘しました。当時、イーサリアムの研究者たちはEIP-1011を用いてコンセンサス層の問題を解決したいと考えていましたが、EIP-1011の提案は最大900人の検証者しか受け入れられず、各検証者に1500 ETHという巨額のステーキング規模が設定されていました。BLSマルチシグの提案が出ると、EIP-1011は歴史の舞台から退きました。後に、ETH2のアップグレードも最終的にBLS12-381曲線を使用することが証明されました。ETH2の開発に伴い、ETH2で使用される
BLS12-381がETH実行層に導入されることが呼びかけられています。2020年2月、一部の研究者がEIP-2537を提案し、この提案がETH2テストネットでテストされることを望んでいます。EIP-2537の著者であるAlex Stokesは、What eth2 needs from eth1 over the next six monthsという記事の中で、ベルリンのハードフォークにEIP-2537を組み入れるよう呼びかけています。興味深いことに、EIP-2537の著者は、ZKSyncという製品で最もよく知られているMatter Labsの共同設立者でもあります
ベルリンの動乱
私たちは今後の内容を紹介する前に、まずEIP-1962について説明する必要があります。EIP-1962は、Matter Labsが2019年4月に提案した、楕円曲線領域ペアリングの事前アセンブリに関する最初の提案であり、この提案は次の3つの曲線をサポートしています：
このEIPは、異なる曲線を処理するために、一度に10個のプリプロセッサ命令を追加する準備をしています。しかし、この提案が誕生した後、相当数の開発者が提案が複雑すぎて開発者が実装するのが難しいと疑問を呈しました。また、EIP1962は高度に汎用化されているため、スマートコントラクトエンジニアにとっても呼び出しが非常に面倒です。もちろん、EIP-1962の提案者であるMatter Labsは、実質的に楕円曲線アルゴリズムの開発作業を完了しており、Rust / Go / C++の参考実装を提供しています。
EIP-1962の問題を解決するために、Matter Labsは2020年2月に複数のEIPを提案しました。これらのEIPは、EIP-1962のインターフェースを部分的に継承しています。これらのEIPには、
これらのEIPの中で最も重要なのはEIP-2537であり、なぜならコンセンサス層もBLS12-381曲線を使用しているからです。EIP-1962とEIP-2537の核心目的は、メインネット内でコンセンサス層のBLS署名の検証を実現することです。当時、ETH2はコンセンサス層のデポジット契約設計を開発中でした。デポジット契約の最初の設計では、実行層にBLS検証アルゴリズムが含まれていなかったため、デポジット契約は署名を検証しませんでした。具体的なBLS署名は、ユーザーがデポジットした後にコンセンサス層によって検証され、不正が発見された場合（新しいバリデーターに対して）、デポジットは失敗し、ユーザーが預けたETHは失われます。
この背景の下、コア開発者は、ユーザーが ETH2 資金を預け入れる際の損失を回避するために、BLS12-381 プリコンパイルをデポジット契約に導入し、署名検証を実現することを希望しています。これが当時、多くの開発者が EIP-1962 および EIP-2537 に関心を持った理由でもあります。
EIP-2537が提案されたとき、VitalikはすぐにEIPに存在する一連の問題を発見しました:
! イーサリアムガバナンスウォッチ:EIP-2537プリコンパイルジャーニー
これらの疑問はEIP文書の内容に集中しており、その後EIPの作者がこれに対して返信と議論を行いました。その後、2020年3月6日にEthereum Core Devs Meeting #82で、Ethereumのコア開発者がEIP-2537について議論しました。この会議では、VitalikはEIP-2537などのEIPが再帰的SNARK証明に非常に効果的であり、長期的にはEthereumに損害を与えないと考えました。また、会議ではEIP-2537の優先順位が確認され、すべてのクライアントがEIP-2537をできるだけ早く実装することに同意し、Berlinアップグレード前にすべての開発を完了する計画を立てました。
その後、EIP-2537は優先度の高いタスクとなりました。2020年3月20日、Ethereum Core Devs Meeting #83において、EIP-2537は依然として最初に議論された提案です。この会議では、EIP-2537がEIP-1962に代わってコアBLS提案として確認され、Berlinアップグレードの予備EIPリストに含まれることが決まりました(即 Eligibility for Inclusion (EFI))。
2020年4月のEthereum Core Devs Meeting #84において、会議は正式にEIP-2537をBerlinハードフォークアップグレードに組み込み、4月に実施し、5月から6月にかけてテストを行うBerlinアップグレードのタイムラインを決定しました。注目すべきは、この討論の中でEIP-2537が最優先事項として挙げられたことです。
! イーサリアムガバナンスウォッチ:EIP-2537プリコンパイルジャーニー
その後、EIP-2537は大量の開発とテストの段階に入り、その後の約20回のコア開発者会議では、ほぼすべての会議でEIP-2537に関する議論が行われました。次に、各会議でEIP-2537についてどのような問題が議論されたのかを見てみましょう。
Ethereumコア開発者会議#85では、DannoとAxicがEIP-2537のABIエンコーディングの問題について議論しました。その後、コア開発者たちは現在の実装状況を同期しました。この中で、EIP-2537の提案者であるMatter LabsがRustバージョンの実装をほぼ完了しているため、BesuクライアントはEIP-2537の機能をほぼ実装したと宣言していますが、Geth側は現在EIP-2537の実装に取り組んでいる人はいないと述べています。
Ethereum Core Devs Meeting #86では、異なるEthereumノードの実装が再びEIP-2537の実装状況を同期しました。その中でGethは一部の作業を完了したと述べましたが、まだ多くの作業が残っています。
! イーサリアムガバナンスウォッチ:EIP-2537プリコンパイルジャーニー
Ethereum Core Devs Meeting #87 において、今回の開発者会議の最も重要な内容は EIP-2537 の実装問題です。Geth 開発者は現在 16000 行の PR で EIP-2537 を実装しているが、Geth 開発者は PR が EIP-2537 を安全かつ有効に実装しているかどうかを確認できないため、開発者は最も単純で粗暴なファジングテストを通じてコードの状態を判断するしかありません。
Gethの開発者は言いました:"私の直感的な反応は、Gethが7月のメインネットローンチに向けてBLS曲線操作の準備ができる可能性はないということです。" つまり、Gethはベルリンの予定時間前にEIP-2537に関する開発を完了する可能性が高くありません。
ハドソン・ジェイモンは、GethのPRレビューを支援するために暗号エンジニアを探すことを提案し、EIP-2537の実装の安全性をテストネットでテストすることを提案しました。この時、ETH2開発チームもBLS署名検証を実装しているため、ちょうどETH2チームがテストに参加できることになります。
ここで、Geth の EIP-2537 実装 PR についての背景知識を補足する必要があります。効率を保証するために、大量のアセンブリコードが使用されており、このアセンブリコードは非常に読みづらく理解しにくいです。そこで、アレックス・ヴラスオフは、審査の難易度を下げるために、PR 内部の複雑なアセンブリ最適化を削除することを提案しました。
私たちは前述の中で、EIP-2537 の核心的な目的の一つが ETH2 の預金契約を支援することであると紹介しましたが、今回の会議では預金契約の開発者が EIP-2537 を使用しない預金契約がすでに監査を通過していると述べました。そのため、一部の開発者は EIP-2537 を使用する預金契約を新たに導入しない方が良いと提案しました。
最後に、会議はYOLOテストネットの追加を決定しました。このテストネットの核心はEIP-2537のテストです。実際、この会議では、預金契約の完成に伴いEIP-2537の重要性が大幅に低下しているのが見て取れ、Gethの開発者たちはこのEIPがベルリンのアップグレード前に実現する可能性は極めて低いと考えています。EIP-2537がベルリンのアップグレードに受け入れられないことは既に定局となっているようです。
Ethereum Core Devs Meeting #88では、Gethの開発者がEIP-2537の実装PRに一連の問題があることを発見し、開発者はさらにテストと修正が必要だと述べました。この時点でGethシステム内には2つのEIP-2537の実装が存在し、そのうちの1つはアセンブリ最適化を含み、もう1つは完全にGo言語で書かれています。ある開発者は、コードレビューの難易度を下げるために、Go言語で書かれたバージョンを直接使用することを提案しました。
イーサリアムコア開発者会議 #89内In、より深刻な問題が発生し、YOLOテストにいくつかの問題があり、開発者はBLS署名が原因ではないかと疑っていましたが、EIP2537開発者はテストネットの問題はBLS署名が原因ではないと主張して反論しました。 EIP-2537にとって朗報なのは、EIP-2537ベースの預金契約が基本的に開発されており、契約の監査を待っていることです。
Ethereum Core Devs Meeting #90内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91の会議で、開発者はモジュール化の提案をして開発コストを削減し、クライアントの多様性を増やすことを提案しました。もし読者がイーサリアムクライアントの多様性に興味があれば、これら二回の会議の記録を読むことができます。
Ethereum Core Devs Meeting #92において、2537は依然としてBerlinアップグレードに必要なEIPとして確認されています。
Ethereum Core Devs Meeting #96の中で、CeloはEIP-2537とEIP-2539を同時にそのネットワークのハードフォークアップグレードに組み込んだため、Matter LabsはEIP-2539をYOLO v2テストネットでテストし、Berlinアップグレードに組み込むことを希望しています。しかし、Gethの開発者は反対し、現在のEIP-2537はGeth内部で完全にテストされていないと考えています。最終的に会議はBerlinアップグレードに2696を追加しないことを決定し、将来の議論に留めることになりました。
Ethereumコア開発者会議#99では、EIP-2537をYOLO v3テストネットとBerlinアップグレードから除外することが決定されました。最も重要な理由は、EIP-2537がコア開発者の時間を無駄にし、Berlinアップグレード内の他のEIPの開発を妨げたためです。副次的な要因は、イーサリアム財団がEIP-2537の代替としてEVM384を提案したことです。EVM384は、より汎用的な楕円曲線計算ソリューションを提供します。しかし、コア開発者は会議の討論の中でセキュリティ問題に対する懸念を表明しました。
上記の内容はEIP-2537の初期の経緯です。EIP-2537は初期のベルリンアップグレードで最も重要なEIPの一つでしたが、実装の問題により最終的に廃止されました。2021年4月にイーサリアムはベルリンアップグレードを完了し、アップグレードの中核を成すEIP-2565などの実際の実装はそれほど複雑ではありませんでした。ベルリンアップグレードはやや薄っぺらに見えるかもしれませんが、これは最も核心的で複雑なEIP-2537がベルリンアップグレードから排除されたためです。
! イーサリアムガバナンスウォッチ:EIP-2537プリコンパイルジャーニー
フォローアップ開発
誰もが知っているように、イーサリアムのアップグレードごとにコア提案が存在します。例えば、ベルリンアップグレードの後のロンドンアップグレードでは、イーサリアムの歴史の中で最も重要な手数料提案であるEIP-1559が導入されました。かつてコア提案として存在していたEIP-2537に関しては、その後のアップグレードでこの提案を取り入れることは非常に難しいです。
ベルリン後のロンドンアップグレードでは、開発者がissues#369曾考虑在 London 升级中增加 EIP-2537。在Ethereum Core Devs Meeting #109で現在のEIP-2537の開発状況を同期しました。この時、他のライブラリを使用してEIP-2537を実装しているため、EIP-2537のガス使用に関する議論が持ち上がりました。同時に、開発者はEIP-2537の代わりにEVM384を使用することを提案しました。しかし、2021年4月のEthereum Core Devs Meeting #111では、EIP-2537はその複雑性ゆえにロンドンアップグレードから外されました。核心的な複雑性は、EIP-2537の標準実装が依存ライブラリを変更したため、ガス価格が変動する可能性があることにあります。異なるクライアントの実装は、ガス消費を再評価するためにかなりの時間を要する必要があります。
2021年6月に、issues#343内で正式にEIP-2537をShanghaiアップグレードに組み込むことが提案されました。しかし、Londonアップグレード後、実際にはPairsアップグレード、またはThe Mergeと呼ばれるものが開発者の多くの時間を占めていたことに注意が必要です。実行層の開発者は、PoSアップグレードを実現するために多くのコードを書く必要がありました。2022年9月にPairsアップグレードが完了し、実行層の開発者はついにShanghaiアップグレードのいくつかの目標について議論を続ける機会を得ました。
2022年11月、Ethereum Core Devs Meeting #150ではEIP-2537をShanghaiアップグレードに含めるかどうかが短時間議論されましたが、開発者はEIP-2537を後回しにする必要があると考えました。Shanghaiアップグレードの核心はPoSの引き出しをサポートすることです。最終的に、EIP-2537は引き出し機能を核心としたShanghaiアップグレードには含まれませんでした。
さらに悲惨なことに、CancunアップグレードはEIP-2537についての議論をまったく行っていません。なぜなら、Cancunアップグレードの核心は、実行層ノードがEIP-4844をサポートすることだからです。EIP-4844は、イーサリアムの第2層にBlobを提供し、第2層がイーサリアムをデータ利用可能層として使用することを容易にします。
ついに、2024年2月のEthereum Core Devs Meeting #181で、開発者はPectraアップグレードにEIP-2537を組み込むことについて議論しました。この時点で、開発者はEIP-2537の実装は問題ではないと考え、Gas消費の価格設定に関してのみ一部の問題が残っていると考えています。
2024年12月19日のEthereum Core Devs Meeting #202内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的Ethereum Core Devs Meeting #203では、開発者たちはBLSプリコンパイルの再価格設定を含む議論を行い、Gethの開発者であるJared Wasingerはガスコストを20%引き上げることを提案し、Besuチームのベンチマークテストの支持を受けました。
まとめ
| 日付 | イベント | | --- | --- | | 2020年2月号 | スプリットEIP-1962が正式に提案 EIP-2537| | 2020年4月 - 2020年10月 | 開発者会議でEIP-2537の実装問題が何度も議論され、最終的には実現不可能なためベルリンアップグレードで放棄された | | 2021年3月 - 2021年4月 | 開発者会議でEIP-2537のガスコスト問題について議論し、最終的には複雑性のためにロンドンアップグレードで放棄されました | | 2022年11月 | 開発者会議でShanghaiアップグレードを含めるかどうかが議論されましたが、結果は得られませんでした | | 2024年2月 | 開発者はEIP-2537に実装上の問題がないと考えているが、一部のガスコストの問題が残っており、Pectraアップグレードに組み込むことができると考えている | | 2024年12月 - 2025年1月 | 開発者会議で具体的なコスト計算モデルについて議論し、正式にEIP-2537のコスト問題を解決する |
見ての通り、EIPがイーサリアムのアップグレードに組み込まれるかどうかは、「もちろん自分自身の努力に依存するが、歴史の流れも考慮に入れる必要がある」。イーサリアムのアップグレードはそれぞれテーマを持っており、EIP-2537は一度ベルリンアップグレードで最も重要なEIPとなったが、その実装の難しさと複雑さから廃止された。その後のイーサリアムはPoSの歴史的過程に入り、複雑な純実行層EIPは重視されず、PoSに関連する多数の実行EIPが核心的なアップグレード目標と見なされ、このため長い間EIP-2537は受け入れられなかった。