しかし、暗号学の進展に伴い、2017年11月にzcash開発チームはBLS12-381: New zk-SNARK Elliptic Curve Constructionで初めてBLS12-381曲線を示しました。alt_bn128と比較して、BLS12-381はより高い安全性とより良い性能を持っています。その後、かなりの数のブロックチェーンプロトコルがBLS12-381曲線を使用し、alt_bn128曲線を廃止しました。
2018年5月、Justin Drakeはethresear内で「Pragmatic signature aggregation with 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」という記事の中で、BerlinハードフォークにEIP-2537を組み込むことを呼びかけています。
イーサリアムガバナンスの観察：EIP-2537 プレアセンブリの経緯｜GCCリサーチ
言葉:シュー
概要
EIP-2537は最新のPectraフォークアップグレードで追加されることが決定されたEVMプリアセンブリ命令です。この命令はEVMにBLS12-381曲線のさまざまな計算機能を追加し、曲線領域でのペアリング計算などを含みます。
EIP-2573は2020年に最初に提案され、2025年にようやくイーサリアムのアップグレードに追加されることが確認されました。本記事では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月のビザンチウムのアップグレードでは、alt_bn128曲線が正式に含まれました。 簡単に言うと、alt_bn128 は EVM 内で初めて曲線領域ペア計算を実装したため、EVM 内での ZK-Snarks 証明検証が可能になりました。
しかし、暗号学の進展に伴い、2017年11月にzcash開発チームはBLS12-381: New zk-SNARK Elliptic Curve Constructionで初めてBLS12-381曲線を示しました。alt_bn128と比較して、BLS12-381はより高い安全性とより良い性能を持っています。その後、かなりの数のブロックチェーンプロトコルがBLS12-381曲線を使用し、alt_bn128曲線を廃止しました。
2018年5月、Justin Drakeはethresear内で「Pragmatic signature aggregation with 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」という記事の中で、BerlinハードフォークにEIP-2537を組み込むことを呼びかけています。
興味深いことに、EIP-2537の著者は、ZKSyncという製品で最もよく知られているMatter Labsの共同設立者でもあります
ベルリンの動乱
本題に入る前に、まずEIP-1962についてお話しする必要があります。 EIP-1962は、2019年4月にMatter Labsが提案した、以下の3つの曲線をサポートする楕円曲線ドメインペアの事前アセンブリに関する最初の提案です。
このEIPは、異なる曲線を処理するために、一度に10個のプリコンパイル命令を追加する準備をしています。しかし、この提案が誕生した後、かなり多くの開発者が提案が複雑すぎて、開発者が実装するのが難しいと疑問を呈しました。また、EIP1962は非常に汎用的であるため、スマートコントラクトエンジニアにとっても呼び出しが非常に面倒です。もちろん、EIP-1962の提案者であるMatter Labsは、実質的に楕円曲線アルゴリズムの開発作業を完了しており、Rust / Go / C++のリファレンス実装を提供しています。
EIP-1962の問題を解決するために、Matter Labsは2020年2月に複数のEIPを提案し、EIP-1962を分割しました。これらのEIPはすべて、EIP-1962のインターフェースを部分的に継承しています。これらのEIPには、
このいくつかのEIPの中で最も重要なのはEIP-2537です。なぜなら、コンセンサス層でもBLS12-381曲線が使用されているからです。EIP-1962とEIP-2537の核心的な目的は、メインネット内でコンセンサス層のBLS署名の検証を実現することです。その当時、ETH2はコンセンサス層の預金契約設計を開発中でした。預金契約の最初の設計時、実行層にはBLS検証アルゴリズムが含まれていなかったため、預金契約は署名を検証しませんでした。具体的なBLS署名は、ユーザーが預金した後にコンセンサス層によって検証され、不正が発覚した場合（新しい検証者に対して）、預金は失敗し、ユーザーが入金したETHは失われます。
この背景の下、コア開発者はBLS12-381プリアセンブリを導入し、預金契約内で署名検証を実現することを望んでおり、ユーザーがETH2資金を預ける際の損失の可能性を避けることを目指しています。これが当時、大量の開発者が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をできるだけ早く実装することに同意し、Berlinアップグレード前にすべての開発を完了する予定です。
その後、EIP-2537の優先度が高くなりました。 2020年3月20日、Ethereum Core Devs Meeting #83では、EIP-2537が議論された最初の提案でした。 会議では、EIP-2537がEIP-1962に取って代わり、BLSのコア提案となり、ベルリンのアップグレード(、すなわちEligibility for Inclusion (EFI))の事前選択されたEIPリストになったことを確認しました。
2020年4月のEthereum Core Devs Meeting #84で、会議は正式にEIP-2537をBerlinハードフォークアップグレードに組み込み、4月に実現し、5月から6月にかけてテストを行うBerlinアップグレードのタイムラインを確定しました。注目すべきは、この議論の中で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 の機能をほぼ実装したと宣言しましたが、Geth 側は現在 EIP-2537 の実装に従事している人はいないと述べました。
Ethereum Core Devs Meeting #86では、EIP-2537の実装が異なるイーサリアムノードの実装によって再び同期され、Geth氏はいくつかの作業は完了したが、まだやるべきことがたくさんあることを示しました。
!
Ethereum Core Devs Meeting #87 の中で、今回の開発者会議の最も重要な内容は EIP-2537 の実装問題です。Geth の開発者は現在 EIP-2537 を実装した 16000 行の PR が存在するが、Geth の開発者はその PR が安全かつ有効に EIP-2537 を実装しているかどうかを確定できないため、開発者は最も単純で粗暴なファジングテストを通じてコードの状況を判断するしかないと述べました。
「ですから、私の直感では、ゲスが7月のメインネット立ち上げに向けてBLSカーブの運用を準備する可能性はないということです。」
ハドソン・ジェイモソンは、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 が Berlin アップグレード前に実現する可能性が非常に低いと考えています。EIP-2537 が Berlin アップグレードに受け入れられないことは、もはや確定的なようです。
Ethereum Core Devs Meeting #88で、Gethの開発者はEIP-2537の実装PRに多くの問題があり、開発者はさらなるテストと修正が必要であると述べました。 現時点では、Geth システムには EIP-2537 の 2 つの実装があり、そのうちの 1 つはアセンブリの最適化を含み、もう 1 つは完全に go で記述されています。
Ethereum Core Devs Meeting #89 の中で、より深刻な問題が発生しました。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-2537 と同時に提案された EIP-2539 も YOLO v2 テストネットでテストし、Berlin アップグレードに入れることを望んでいました。しかし、Geth 開発者は反対し、現在の EIP-2537 はまだ Geth 内で完全にテストされていないと考えました。最終的に会議は Berlin アップグレードに 2696 を追加しないことを決定し、将来の議論に留めることになりました。
Ethereum Core Devs Meeting #99 において、今回の会議で EIP-2537 を YOLO v3 テストネットおよび Berlin アップグレードから除外することが決定されました。最も重要な理由は、EIP-2537 がコア開発者に多くの時間を浪費させ、Berlin アップグレード内の他の EIP 開発に支障をきたしたためです。副次的な要因として、イーサリアム財団が EIP-2537 の代替として EVM384 を提案しました。EVM 384 は、より汎用的な楕円曲線計算ソリューションを提供します。しかし、コア開発者は会議でセキュリティ問題に対する懸念を表明しました。
上述内容は EIP-2537 の初期の経緯を示しています。EIP-2537 は初期の Berlin アップグレードにおいて最も重要な EIP の一つでしたが、実装の問題から最終的に廃止されました。最後に、2021 年 4 月にイーサリアムは Berlin アップグレードを完了しました。アップグレードの中核に含まれる EIP-2565 などの実際の実装はそれほど複雑ではなく、Berlin アップグレードはやや薄っぺらに見えるかもしれません。これは、最も核心的で複雑な EIP-2537 が Berlin アップグレードから除外されたためです。
!
フォローアップ開発
ご存知のように、イーサリアムのすべてのアップグレードには、イーサリアムの歴史の中で最も重要な手数料の提案である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は、Ethereumの第2層にBlobを提供し、第2層がEthereumをデータ可用性層として利用しやすくするものである。
ついに、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チームのベンチマークテストの支持を得ました。
まとめ
!
見ての通り、EIPがイーサリアムのアップグレードに取り入れられるかどうかは「もちろん自己努力に依存しますが、歴史の進程も考慮する必要があります」。イーサリアムのアップグレードごとに独自のテーマがあり、EIP-2537は一度ベルリンアップグレードで最も重要なEIPとなりましたが、その実現の難しさと複雑さから廃止されました。その後、イーサリアムはPoSの歴史的進程に入っていき、複雑な純実行層EIPは重視されず、大量のPoS関連の実行EIPが核心アップグレード目標と見なされ、EIP-2537が長期間受け入れられない原因となりました。