イーサリアム上海アップグレードの潜在的なアップデートについて1つの記事で学ぶ

元のタイトル: 《 Ethereum All Core Developers Call #149 のレポート》

原作者: クリスティン・キム

原文翻訳: 一晩おかゆ

2022年11月10日、イーサリアム開発者が第149回全コア開発者会議（ACD）に集まりました。 ACD コールは、Ethereum Foundation の Tim Beiko 氏が主催しました。今週、開発者は、統合された Ethereum ネットワーク (上海と呼ばれる) の最初のメジャー アップグレードを実現するために、EVM オブジェクト フォーマット (EOF) とプロトダンクシャーディングに関連するコード変更の進捗状況について話し合いました。電話会議中、開発者らは上海のアップグレードに含まれる可能性のある他の 4 つの EIP についても議論しました。それぞれの提案は確かに Ethereum に独自の利点とメリットをもたらしますが、どの EIP を優先して組み込むかについては開発者の間で依然として多くの論争があります。上海での議論に加えて、開発者たちは検閲耐性という話題や、ネットワークのスケーラビリティのためにイーサリアムの検閲耐性機能がとらなければならない潜在的なトレードオフについても簡単に触れた。

上海アップグレード計画

以前のACDコールで、イーサリアム開発者は上海アップグレードにEIPのコアリストを含めることに同意しました。 ACD コール #148 の完全な通話記録はここにあります。注目すべきは、このコア EIP のリストから、開発者は上海アップグレードに約束された ETH 引き出し提案を含めることに同意しましたが、後者の 2 つの提案のコード変更がさらに具体化されるまで、同じアップグレードに EOF またはプロトダンクシャーディングを含めることを約束しなかったことです。特にEOFに関しては、開発者は上海アップグレードで少数のEIPを通じてEOFを部分的に実装するか、上海後のEthereumアップグレードにEOFのビジョン全体を組み込むかについて躊躇しています。

EOF 実装

Hedera のチーフ ソフトウェア エンジニアである Danno Ferrin 氏は、今週の電話会議で上海 EOF 実装の進捗状況に関する最新情報を提供しました。彼は、開発者は EOF 実装に関連する EIP のほとんどをできるだけ早く 1 つの大きなアップグレードにまとめる傾向があると説明しました。開発者が上海アップグレードに含めることを検討している EOF 実装に関連する EIP は、EIP 3540、EIP 3670、EIP 4200、および EIP 4750 です。EIP 5450 を EOF に関連するコード変更のリストに含めるべきかどうかについては、開発者の間でまだ意見の相違があります。

Erigon Execution Layer (EL) クライアント チームの Andrew Ashikhmin 氏も、Solidity スマート コントラクト言語チームが 4 つ (または 5 つ) の EIP すべてを完全にサポートして実装できるかどうかについて懸念を表明しました。アシクミン氏は、上海アップグレードでこれらの EIP を有効にすることを約束する前に、まず Solidity チームがこれらの EIP の実装の準備ができていることを確認する必要があることを強調しました。アシフミン氏は電話会議で、これは「必要な健全性チェック」だと述べ、ゲスELのクライアントチームのマリウス・ファン・デル・ワイデン氏も同じ意見を述べた。

プロトダンクシャーディング

その後、開発者たちはプロトダンクシャーディングの最新の開発について議論を続けました。 EOF 実装とは異なり、proto-danksharding コード変更に関連付けられている EIP は 1 つだけ、つまりEIP 4844です。 OP Labsの研究者である「Protolambda」の愛称で知られるDiederik Loerakker氏によると、EIP 4844に関連してまだ議論中の事項がいくつかあるという。Ethereum FoundationのAnsgar Dietrichs氏は、これらの項目の一部は、BLOBトランザクションの最低価格の設定と、上海アップグレードのBLOBトランザクションスループットの削減に関連していると付け加えた。これらの TODO はGithubにまとめられています。

自己破壊オペコードとその他のEIPを無効にする

開発者は上海アップグレードのためのEOFとプロトダンクシャーディングの作業を準備する一方で、イーサリアムの次のアップグレードに組み込むために他の4つのEIPの作業を継続することに暫定的に合意した。

1. EIP 4758 、イーサリアムの「自己破壊」オペコードの無効化: 開発者は、スマート コントラクトや分散型アプリケーション (dapps) で使用するのはよくない習慣であると広く考えられているオペコードの無効化に関する前回の ACD 通話での会話を再検討しました。このオペコードは、展開するためのガスコストは固定ですが、ネットワークへのストレージコストは潜在的に無制限である数少ないレガシーオペコードの 1 つです。独立系開発者の Micah Zoltu 氏は、Ethereum 上の一部のアクティブなスマート コントラクトは依然として自己破壊オペコードを使用しており、これを無効にすると機能が損なわれると改めて強調しました。ティム・ベイコ氏は、これらの特殊なエッジケースには何らかの回避策があるかもしれないが、イーサリアム財団からのさらなるコミュニティへの働きかけが必要になるだろうと述べた。

2. EIP 1153 、一時ストレージ オペコードの追加: Uniswap チームと Optimism チームの代表者は、一時ストレージ オペコードの導入を説得力のある形で主張しました。このオペコードは、Ethereum 上の通常のストレージ オペコードと同じように動作しますが、2 つの新しいオペコード TLOAD と TSTORE の値は各トランザクションの後に破棄されます。一時保管にはさまざまな動機があるが、その 1 つはガスコストの節約だと、Optimism の Mark Tyneway 氏は説明する。 Uniswap だけでも、この EIP によりユーザーはガスコストを年間 300 万ドル節約できる可能性があります。さらに、通常のストレージの代わりに一時ストレージを使用すると、Ethereum の技術的負債を削減するのに役立ちます。 Uniswap チームと Optimism チームは、複数の異なる Ethereum ソフトウェア クライアントでこのコード変更の実装を作成するために多大な作業を行い、EIP 用の包括的なテスト スイートを構築しました。 Besu (EL) クライアント チームの Daniel Lehrner 氏は、EIP 1153 の実装に備えるよう外部開発者に呼びかけたことに感謝の意を表しました。しかし、すべての開発者が EIP 1153 の組み込みに伴う追加のテスト負荷に価値があると考えているわけではありません。 Geth 開発者の Marius van der Wijden 氏は、EIP 1153 が EOF 関連の EIP の進行中の準備に支障をきたし、複雑な問題を引き起こす可能性があると警告しました。それでも、ファン・デル・ワイデン氏は、コード変更のテスト強化については「様子見の姿勢」を取っていると述べた。開発者たちは、上海アップグレードに組み込むために、Uniswap および Optimism チームの外部開発者の協力を得て、EIP 1153 のテストを継続することに合意しました。

3. EIP 2537 、BLS プリコンパイルの追加: Ethereum Foundation の Alex Stokes 氏は、Ethereum に BLS プリコンパイルを追加する利点を紹介しました。ストークス氏は、より安全な暗号証明を作成できること、イーサリアムビーコンチェーンとの相互運用性が向上すること、分散型ステーキングプールの機能が追加されることなど、いくつかの理由があると説明した。 Van der Wijden 氏は、BLS プリコンパイルの追加は、EOF 実装や EIP 1153 よりも優先される可能性のある重要なコード変更であることに同意しています。ただし、EIP 2537 の実装には広範なテストが必要であるため、van der Wijden 氏は、このコード変更を追加すると Shanghai のアップグレードが遅れるのではないかと懸念を表明しました。 Ethereum Foundation の Jared Wasinger 氏は、EIP 2537 よりもシンプルな実装パスを提供できる並列 EIP に取り組んでいると述べました。開発者は EIP 2537 に取り組み、上海アップグレードに組み込む可能性のあるさまざまな BLS プリコンパイルの数を削減し始めることに同意しました。

4. EIP 2294 : 最後に、Google のソフトウェア エンジニアである Zainan Victor Zhou 氏が EIP 2294 を発表しました。これは、ハード フォーク後のノード検出を支援するために従来使用されてきた Ethereum のチェーン ID フィールドのバイト サイズを制限するだけの比較的シンプルなコード変更です。ビクター・チョウ氏は電話会議で、イーサリアムは将来的にシャーディングや複数のチェーンを導入する可能性があるため、チェーンIDの使用事例はより大きく、より重要になるだろうと述べた。チェーン ID フィールドに他の種類のデータを保存して悪用しようとする人々を防ぐために、Victor Zhou はチェーン ID のサイズを明示的にバインドすることを要求しました。すべての開発者は、この変更は重要であり、実装も簡単であることに同意しました。ミカ・ゾルトゥ氏は、このようなコード変更にはソフトフォークのみが必要であると強調した。つまり、イーサリアムのクライアントチームは、変更のために特定のブロックの高さを調整する必要なく、独自のタイムラインで変更を実装できるということだ。開発者の間では、呼び出しの終了時にチェーン ID のサイズを 64 ビットに制限するか 256 ビットに制限するかについても議論がありました。 Tim Beiko 氏は、開発者にオフラインで議論し、Discord チャットで非同期的に数字を計算することを奨励しました。

上海アップグレードに含める予定の EIP のリストが拡大し続けるにつれて、コア リスト以外に含める EIP を優先するかどうかについて開発者の間で意見が分かれています。 「lightclient」という仮名で知られるイーサリアム財団の開発者は、オープンな引き出しに固執し、プロトダンクシャーディング、EOF実装、または電話会議で提起された4つのEIPのいずれかなど、他の主要なEIPを1つだけ優先することを提案しました。 Tim Beiko 氏は、EOF 実装、プロトダンクシャーディング、BLS プリコンパイル、および一時ストレージ オペコードの追加を次のアップグレードにバンドルすることは非現実的であると考えています。会議時間が足りなかったため、Beiko 氏は上海アップグレード計画について議論し、次回の ACD コールで、ステークされた ETH の引き出し以外に上海アップグレードの最優先事項について議論する準備をするよう開発者に促しました。

Ethereum ノードの運用コストを削減する方法（検閲耐性を高める方法）

上海のアップグレードに関する講演中に、独立系イーサリアム開発者の Micah Zoltu 氏が、イーサリアムの検閲耐性に関する重要な議論項目を提起しました。ゾルトゥ氏は、イーサリアムユーザーのほとんどはトランザクションを実行するために独自のノードを実行しておらず、人々は特定の国のユーザーを積極的に検閲し、イーサリアム上の分散型アプリケーション（dapps）、例えばTornado Cashを検閲するInfuraやAlchemyなどの中央集権型サービスに依存していると説明した。開発者はEIP 4844を通じてイーサリアムのスケーラビリティを向上させる取り組みを行っていますが、イーサリアムノードの実行コストを削減し、イーサリアムの検閲耐性をより確実にするための取り組みが不足しています。 Ethereum Teku (CL) クライアント チームの開発者である Mikhail Kalinin 氏は、EIP 4844 の実装後に Ethereum ノードの実行コストを削減することに重点を置くことを提案しました。Erigon の Andrew Ashikhmin 氏は、Ethereum 開発者は両方に重点を置くことができると考えています。アンスガー・ディートリッヒス氏は、実用的な理由から、イーサリアムの開発者は短期的にはスケーラビリティのために検閲耐性を犠牲にし、長期的には検閲耐性に重点を置くべきだと述べた。

イーサリアム財団の研究者であるダンクラッド・ファイスト氏は、EIP 4844 によってノードオペレーターの運用コストがわずかに増加する程度であり、イーサリアムの検閲防止機能に大きな損害を与えることはないと考えています。ファイスト氏はまた、イーサリアムユーザーのほとんどはコストの問題ではなく、ユーザーエクスペリエンスが悪いために独自のノードを運用していないと付け加えた。ディデリック・ロエラッカー氏は、より高いレベルの分散化を実現するためには、EIP 4844のようなコード変更によってEthereumの利用コストが下がり、世界中のより多くの人々にとって参入障壁が低くなるため、Ethereum開発者はスケーリングを優先すべきだと述べた。

Nethermind ELクライアントチームのLukasz Rozmej氏も、理論的には多くのトランザクションがL2ロールアップで実行されるため、EIP 4844がイーサリアムの検閲耐性に悪影響を与えるかどうか疑問視した。ゾルトゥ氏は、EIP 4844 により、将来的にはバリデーターが個々のトランザクションを検閲することがより困難になる可能性があるが、現在は L2 ロールアップ操作が集中化されているため、検閲可能であると説明した。議論の締めくくりとして、ティム・ベイコ氏は、イーサリアムノードを実行する際のユーザーエクスペリエンスの向上が、今後のコミュニティにとって重要な焦点となるべきだと述べた。ベイコ氏は、イーサリアムのコア開発者に近い開発チームがイーサリアムノードの実行を簡素化し、一般ユーザーがよりアクセスしやすいように取り組むべきだと提案した。

その他

上記に加えて、イーサリアム開発者がこの電話会議でまだ議論していない問題がいくつかあります。これらには以下が含まれます:

• エンジン API 仕様改善提案: Teku 開発者の Mikhail Kalinin が、Ethereum のエンジン API 仕様を改善するための提案を作成しました。背景として、Engine API は、Ethereum ノードの EL クライアントと CL クライアント間の通信を容易にするソフトウェアです。エンジン API への提案された変更は、来週木曜日の Ethereum CL 会議で議論される可能性があります。

• 上海「コア」対プロトタイプ開発者テストネット: 上海アップグレードの EIP をテストするには、複数の専用テストネットを作成する必要があります。 Shandong は、Ethereum Foundation JavaScript チームによって立ち上げられたテスト ネットワークです。 EOF 実装に関連するいくつかの EIP に加えて、EIP 4895、EIP 3860、EIP 3651、および EIP 3855 が実装されています。今後数回の ACD 電話会議で、開発者はクライアント チームが上海アップグレード EIP をテストするための、より専用のテスト ネットワークの作成を調整します。

• Ropsten テストネット終了日: Ethereum テストネット Goerli を保守している開発者の 1 人である Afri Schoeden 氏は、計画されたタイムラインに従って Ethereum テストネットを開始および廃止する提案を発表しました。これは、複数のイーサリアム テスト ネットワークの廃止に対してアプリケーション開発者とインフラストラクチャ プロバイダーが表明した不満に応えたものです。開発者は、この EthereumMagic フォーラムのスレッドで、Ropsten のようなパブリック Ethereum テストネットを責任を持って廃止する方法についてのアイデアを共有することが推奨されています。