イーサリアムガバナンス観察: EIP-2537 事前組み立てプロセス

著者: ショー

概要

EIP-2537は、最新の Pectra フォーク アップグレードで追加されることが確認された EVM プリアセンブラ命令です。この命令は、曲線ドメインでのペアリング計算など、BLS12-381 曲線のさまざまな計算機能を EVM に追加します。

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月、ジャスティン・ドレイクは、 etheresearで「BLSを使用した実用的な署名集約」と題した記事を公開し、イーサリアムの将来のPoSとシャーディングのアップグレードでは、 BLS12-381曲線に基づくBLSマルチ署名アルゴリズムを使用できると指摘しました。当時、イーサリアムの研究者はコンセンサス層の問題を解決するためにEIP-1011を使用することを望んでいましたが、EIP-1011 ソリューションは最大 900 のバリデーターに対応できるため、バリデーターごとに 1,500 ETH という巨大なステーキング スケールが設定されました。 BLS マルチ署名ソリューションの導入により、EIP-1011 は歴史の舞台から退きました。結局、その後の ETH2 アップグレードでもBLS12-381曲線が使用されることになりました。

ETH2の開発に伴い、 ETH2で使用されているBLS12-381 ETH実行層に導入する動きが出始めています。 2020年2月、一部の研究者がEIP-2537を提案し、その提案がETH2テストネットで一緒にテストされることを期待しました。 EIP-2537 の作者 Alex Stokes 氏は、記事「 今後 6 か月間で eth2 が eth1 に求めるもの」の中で、ベルリン ハードフォークに EIP-2537 を含めるよう求めました。

興味深いことに、EIP-2537の作者はMatter Labsの共同設立者でもあり、Matter Labsの最も有名な製品はZKSyncです。

ベルリンの騒乱

以降のコンテンツを紹介する前に、まずEIP-1962を紹介する必要があります。 EIP-1962 は、2019 年 4 月に Matter Labs によって提案された楕円曲線ドメイン ペアリング プレアセンブリの最初の提案です。この提案では、次の 3 つの曲線がサポートされています。

• BLS12
• BN
• MNT4/6 (アテペアリング)

この EIP は、さまざまな曲線を処理するために、一度に 10 個の事前組み立てられた命令を追加するように準備されています。しかし、この提案が生まれた後、多くの開発者から、この提案は複雑すぎて開発者が実装するには難しいのではないかと疑問が投げかけられました。同時に、EIP1962 の一般化度が高いため、スマート コントラクト エンジニアがそれを呼び出すのも非常に面倒です。もちろん、EIP-1962 の提案者として、Matter Labs は楕円曲線アルゴリズムの開発を本質的に完了し、Rust/Go/C++ リファレンス実装を提供しました。

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

• EIP-2537はBLS12-381のサポートを提供します
• EIP-2539はBLS12-377をサポートします。
• PR#2541 はBLS12-377 (Zexe 曲線) のサポートを提供しますが、この提案には EIP 番号が付与されておらず、EIP ドキュメントの Web サイトには掲載されていないことに注意してください。

これらの 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 ドキュメントの内容に焦点を当てており、EIP の作成者がそれに応答して議論しました。その後、2020年3月6日に開催されたEthereum Core Devs Meeting #82で、Ethereumコア開発者がEIP-2537について議論しました。会議中、Vitalik 氏は、EIP-2537 などの EIP は再帰的 SNARK 証明に非常に効果的であり、長期的には Ethereum に害を及ぼさないと信じていました。同時に、会議ではEIP-2537の優先順位も確認されました。すべてのクライアントは、EIP-2537 をできるだけ早く実装することに同意し、ベルリンのアップグレード前にすべての開発を完了する予定でした。

その後、EIP-2537 は優先度の高いタスクになりました。 2020 年 3 月 20 日、 Ethereum Core Devs Meeting #83では、EIP-2537 が依然として最初に議論された提案でした。会議では、EIP-2537 が EIP-1962 に代わるコア BLS 提案となり、ベルリン アップグレードの事前選択された EIP リスト (つまり、包含資格 (EFI)) の一部になることが確認されました。

2020年4月に開催されたEthereum Core Devs Meeting #84では、EIP-2537が正式にベルリンハードフォークアップグレードに含まれ、ベルリンアップグレードのタイムラインが4月に実装され、5月から6月にテストされることが決定されました。この議論では、EIP-2537 が最優先事項として挙げられていることは注目に値します。

その後、EIP-2537は大規模な開発およびテスト段階に入りました。その後の約 20 回のコア開発者会議では、ほぼすべての会議で EIP-2537 に関する議論が行われました。次に、各会議で EIP-2537 に関するどのような問題が議論されたかを見てみましょう。

Ethereum Core Devs Meeting #85で、Danno と Axic が EIP-2537 の ABI エンコーディングの問題について議論しました。その後、コア開発者は現在の実装状況を同期しました。 EIP-2537の提案者であるMatter LabsがRust版の実装を基本的に完了していたため、BesuクライアントはEIP-2537の機能を基本的に実装したと宣言しました。しかし、ゲス氏は、現在 EIP-2537 の実装に取り​​組んでいる人はいないと述べています。

Ethereum Core Devs Meeting #86では、さまざまな Ethereum ノード実装が再び EIP-2537 の実装を同期し、Geth は一部の作業は完了したが、まだやるべき作業はたくさんあると述べました。

Ethereum Core Devs Meeting #87では、この開発者会議の中心的な内容は EIP-2537 の実装でした。 Geth 開発者によると、現在 EIP-2537 を実装した 16,000 行の PR があるが、Geth 開発者は PR が EIP-2537 を安全かつ効果的に実装しているかどうか確信が持てないため、開発者は最も単純で粗いファズ テストを通じてのみコードの状況を判断できるとのことです。

Geth 開発者は、「私の直感では、7 月のメインネット ローンチまでに Geth が BLS カーブ操作の準備を整えられる可能性はない」と述べています。つまり、Geth がベルリンでの予定時刻までに EIP-2537 の開発を完了する可能性は低いということです。

Hudson Jameson は、PR レビューを支援するために Geth の暗号化エンジニアを見つけることを提案し、テスト ネットワークを使用して EIP-2537 の実装セキュリティをテストすることを提案しました。現時点では、ETH2 開発チームも BLS 署名検証を実装しているため、ETH2 チームはテストに参加できます。

ここで、いくつかの背景知識を追加する必要があります。つまり、Geth の EIP-2537 実装 PR では、効率を確保するためにアセンブリ コードを大量に使用しています。アセンブリ コードのこの部分は、読みにくく、理解しにくいです。そこで Alex Vlasov は、レビューの難易度を軽減するために、PR 内の複雑なアセンブリ最適化を削除することを提案しました。

EIP-2537 の中心的な目標の 1 つは、ETH2 デポジット契約を支援することであることはすでに上で紹介しました。しかし、今回の会議では、デポジット契約開発者は、EIP-2537 を使用しないデポジット契約は監査済みであると述べており、一部の開発者は、EIP-2537 を使用した別のデポジット契約を開始しない方がよいと提案しました。

最終的に、会議では、EIP-2537 をテストすることを中核とする YOLO テスト ネットワークを追加することが決定されました。実際、今回の会議では、預託契約の完了により、EIP-2537 の重要性が大幅に低下したことがわかります。同時に、Geth 開発者は、この EIP がベルリン アップグレード前に実装される可能性は非常に低いとすでに考えています。 EIP-2537 がベルリン アップグレードで受け入れられないのは当然のようです。

Ethereum Core Devs Meeting #88で、Geth 開発者は EIP-2537 の実装 PR に一連の問題を発見し、さらなるテストと修正が必要であると開発者は述べました。現時点では、Geth システムには 2 つの EIP-2537 実装があり、1 つはアセンブリ最適化を含み、もう 1 つは完全に go 言語で記述されています。一部の開発者は、コードレビューの難易度を軽減するために、go 言語バージョンを直接使用することを提案しています。

Ethereum Core Devs Meeting #89では、さらに深刻な問題が発生しました。 YOLO テストでいくつかの問題が発生しました。開発者は、この問題は BLS 署名によって発生したのではないかと疑っていましたが、EIP2537 開発者はこれを否定し、テスト ネットワークの問題は BLS 署名によって発生したものではないと考えました。 EIP-2537 にとって良いニュースは、EIP-2537 に基づく預託契約が基本的に開発され、契約監査を待っていることです。

Ethereum Core Devs Meeting #90では、7 月に開始されるベルリン アップグレードの DDL が確定しました。もちろん、この会議でのもう一つの興味深い議論のポイントは、クライアントの多様性の問題でした。この会議では、開発者は主に Geth の優位性について議論し、一部の開発者は他のクライアントの開発コストを削減するために現在の EIP 実装を凍結することを提案しました。さらに興味深いのは、会議 #91 で、一部の開発者が開発コストを削減し、クライアントの多様性を高めるためにモジュール式ソリューションの使用を提案したことです。読者が Ethereum クライアントの多様性に興味がある場合は、これら 2 つの会議の記録を読むことができます。

Ethereum Core Devs Meeting #92では、ベルリン アップグレードに必要な EIP として 2537 が依然として確認されています。

Ethereum Core Devs Meeting #96では、Celo がすでに EIP-2537 と EIP-2539 の両方をネットワーク ハードフォーク アップグレードに含めているため、Matter Labs は、EIP-2537 と同時に提案された EIP-2539 を YOLO v2 テストネットにテスト用に配置し、ベルリン アップグレードに参加したいと考えています。しかし、Geth 開発者は、現在の EIP-2537 はまだ Geth 内で十分にテストされていないと主張して反対しました。最終会議では、ベルリンのアップグレードに 2696 を追加しないことが決定され、今後の議論に残されました。

Ethereum Core Devs Meeting #99では、YOLO v3 テストネットとベルリン アップグレードから EIP-2537 を削除することが決定されました。主な理由は、EIP-2537 がコア開発者の時間を無駄にしすぎて、ベルリン アップグレードにおける他の EIP 開発の妨げになったことです。 2 番目の要因は、Ethereum Foundation がEIP-2537 の代替としてEVM384 を提案したことです。 EVM 384 は、より一般的な楕円曲線計算ソリューションを提供します。しかし、コア開発者は会議の議論の中でセキュリティ問題について懸念を表明した。

上記内容はEIP-2537の初期の歴史です。 EIP-2537 は初期のベルリン アップグレードで最も重要な EIP の 1 つであったことがわかりますが、実装上の問題により最終的には放棄されました。ついに、2021年4月にイーサリアムはベルリンアップグレードを完了しました。アップグレードに含まれるコア EIP-2565 の実際の実装は複雑ではありませんでした。ベルリンのアップグレードは少し薄っぺらいようでした。これは、最もコアかつ複雑な EIP-2537 がベルリン アップグレードから除外されたためです。

その後の発展

ご存知のとおり、Ethereum のすべてのアップグレードにはコア提案が伴います。たとえば、ベルリンのアップグレード後のロンドンのアップグレードでは、イーサリアムの歴史上最も重要な取引手数料提案 EIP-1559 が導入されました。かつては中核提案であった EIP-2537 については、この提案をその後のアップグレードに組み込むことは困難です。

ベルリンの後のロンドンのアップグレードでは、開発者は問題#369でロンドンのアップグレードに 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 を含めることが正式に提案されました。ただし、ロンドンのアップグレード後、The Merge とも呼ばれる Pairs のアップグレードは実際には多くの開発者の時間を費やし、実行レイヤーの開発者は PoS アップグレードを実装するために大量のコードを記述する必要があったことに注意する必要があります。 2022年9月、Pairsのアップグレードが完了し、エグゼクティブレベルの開発者はようやく上海アップグレードの目標のいくつかについて引き続き議論する機会を得ました。

2022年11月、 Ethereum Core Devs Meeting #150では、EIP-2537を上海アップグレードに含めるべきかどうかについて簡単に議論されましたが、開発者はEIP-2537を延期する必要があると考えていました。上海のアップグレードの中核は、PoS 引き出しをサポートすることでした。結局、EIP-2537は撤退機能の実装に重点が置かれた上海アップグレードには組み込まれなかった。

さらに悲劇的なのは、カンクン アップグレードでは EIP-2537 について議論されていないことです。これは、カンクン アップグレードの中核が、実行層ノードが EIP-4844 をサポートすることにあるためです。 EIP-4844 は、レイヤー 2 のデータ可用性レイヤーとして Ethereum を使用できるようにするために、Ethereum レイヤー 2 用の Blob を提供します。

最後に、 2024年2月のEthereum Core Devs Meeting #181で、開発者はEIP-2537をPectraアップグレードに組み込むことについて議論し、この時点で開発者はEIP-2537の実装はもはや問題ではなく、問題の一部はガス消費の価格設定にあると信じていました。

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は、Besuチームのベンチマークに基づいてガスコストを20%引き上げることを提案しました。

要約する

EIP がイーサリアムのアップグレードに含まれるかどうかは、「もちろん自身の努力次第だが、歴史の流れも考慮する必要がある」ことがわかります。すべての Ethereum アップグレードには独自のテーマがあります。EIP-2537 はかつてベルリン アップグレードで最も重要な EIP になりましたが、実装の難しさや複雑さのために放棄されました。その後、イーサリアムは PoS の歴史的なプロセスに入りました。複雑な純粋実行層 EIP は真剣に受け止められず、一方で多数の PoS 関連実行 EIP がコアアップグレード目標とみなされたため、EIP-2537 は長い間受け入れられませんでした。