Ethereum Shanghai アップグレードの潜在的なアップデートについて 1 つの記事で説明します
原題：「Ethereum All Core Developers Call #149 Writeup》
著者: クリスティーン・キム
原文編纂：一夜粥
原題：「
著者: クリスティーン・キム
2022 年 11 月 10 日、イーサリアム開発者は第 149 回オール コア デベロッパー (ACD) カンファレンス コールに集まりました。この ACD カンファレンス コールは、イーサリアム財団のティム ベイコ氏が司会を務めました。オブジェクト フォーマット (EOF) およびプロト ダンクシャーディング関連のコード変更は、有効化に向けて進捗しています。統合されたイーサリアム ネットワーク (上海と呼ばれる) の最初のメジャー アップグレード。この通話中に、開発者は上海のアップグレードに含まれる可能性のある他の 4 つの EIP についても話し合いました。各提案は確かにイーサリアムにいくつかの独自の利点とメリットをもたらしますが、どの EIP を優先的に含めるべきかについては開発者の間で依然としてかなりの議論があります。上海のアップグレードの議論に加えて、開発者らは検閲耐性の話題と、ネットワークのスケーラビリティに対するイーサリアムの検閲耐性機能の潜在的なトレードオフについても簡単に触れた。ここ上海アップグレード計画
以前の ACD の電話会議で、イーサリアム開発者は上海のアップグレードに EIP のコア リストを含めることに同意しました。 ACD Call #148 からの通話の完全な記録は次のとおりです。
ここ
。このコアEIPのリストから、開発者らは約束されたETH引き出し提案を上海アップグレードに含めることに同意したが、後の2つの提案まで同じアップグレードにEOFまたはプロトダンクシャーディングを含めることを約束しなかったことは注目に値する。さらに肉付けされました。特に EOF の話題に関して、開発者は上海アップグレードの EIP 部分のごく一部を通じて EOF を実装するか、それとも EOF のビジョン全体を上海後のイーサリアム アップグレードにバンドルしようとするか迷っています。
Proto-danksharding
EOFの実装EIP 4844Hedera の主任ソフトウェア エンジニアである Danno Ferrin 氏は、今週の電話会議で上海での EOF 実装の進捗状況について最新情報を提供しました。同氏は、開発者は EOF 実装に関連する EIP のほとんどをできるだけ早い段階で 1 つの大規模なアップグレードにバンドルする傾向があると説明しました。上海アップグレードで開発者が検討した EOF 実装に関連する EIP には、EIP 3540、EIP 3670、EIP 4200、および EIP 4750 が含まれます。 EIP 5450 を EOF に関連するコード変更のリストに含めるべきかどうかについては、開発者の間で依然として意見の相違があります。GithubErigon Execution Layer (EL) クライアント チームの Andrew Ashkhmin 氏も、Solidity スマート コントラクト言語チームが 4 つ (またはおそらく 5 つ) の EIP をすべて完全にサポートおよび実装できるかどうかについて懸念を表明しました。アシクミン氏は、上海でこれらの EIP のアップグレードとアクティブ化に取り組む前に、まず Solidity チームがこれらの EIP を実装する準備ができているかどうかを確認する必要があると強調しました。アシクミン氏は電話会議で、これは「必要な健全性チェック」であると述べ、ゲスELクライアントチームのマリウス・ファン・デル・ワイデン氏もこれに同調した。
開発者たちはその後、プロトダンクシャーディングの最新の開発について話し合いました。 EOF 実装とは異なり、プロト ダンクシャーディング コード変更に関連付けられる EIP は 1 つだけです。
。 OP Labs の研究者である Diederik Loerakker (しばしば「Protolambda」と呼ばれる) によると、EIP 4844 に関連してまだ議論中の事項がいくつかあります。イーサリアム財団のアンスガー・ディートリヒス氏は、これらの問題の一部は、BLOB トランザクションの最低価格の設定と、上海アップグレードに伴う BLOB トランザクションのスループットの削減に関係していると付け加えた。これらの To-Do は次のとおりです
1、EIP 4758概要があります。
2、EIP 1153Self-Destruct オペコードおよびその他の潜在的な EIP を無効にする
3、EIP 2537開発者は上海アップグレードに向けて EOF とプロトダンクシャーディング作業の準備を進めていますが、開発者はイーサリアムの次のアップグレードに含めるために他の 4 つの EIP の作業を続けることに暫定的に同意しました。
4、EIP 2294、イーサリアムの「selfdestruct」オペコードを無効にする：開発者は、スマートコントラクトと分散型アプリケーション（dapps）で役立つと開発者によって広く考えられているオペコードの無効化についての最後のACDコールの会話を再考します で使用されている悪い慣行。このオペコードは、導入に固定のガスコストがかかるものの、ネットワークのストレージコストが無制限になる可能性がある数少ないレガシーオペコードの 1 つです。独立系開発者のMicah Zoltu氏は、イーサリアム上でアクティブなスマートコントラクトの一部が依然として自己破壊オペコードを使用しており、これを無効にすると機能が停止すると繰り返し述べた。こうした特別なエッジケースについては、イーサリアム財団によるいくつかの回避策とコミュニティへのさらなる支援がある可能性があるとティム・ベイコ氏は述べた。
、一時ストレージ オペコードの追加: Uniswap チームとオプティミズム チームの代表者は、これら 2 つの新しいオペコードを除き、イーサリアム上の通常のストレージ オペコードと同じように動作する一時ストレージ オペコードを導入するという説得力のある主張を行いました。TLOAD と TSTORE の値は、各トランザクション後に破棄されます。一時ストレージには多くの動機がありますが、Optimism の Mark Tyneway 氏が説明するように、その 1 つはガスコストの節約です。 Uniswap だけでも、この EIP はユーザーの年間ガス費用を 300 万ドル節約できる可能性があります。さらに、通常のストレージの代わりに一時ストレージを使用すると、イーサリアムの技術的負債の削減に役立ちます。 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 のテストを継続することに同意しました。
, BLS プリコンパイルの追加: イーサリアム財団の Alex Stokes が、イーサリアムに BLS プリコンパイルを追加する利点について説明しています。これには、より安全な暗号証明を作成できる機能、イーサリアムビーコンチェーンとの相互運用性の向上、分散型ステーキングプールの追加機能など、多くの理由があるとストークス氏は説明しました。 Van der Wijden 氏は、BLS プリコンパイルの追加は、EOF 実装や EIP 1153 よりも優先される可能性がある重要なコード変更であることに同意しています。しかし、EIP 2537 の実装には大規模なテストが必要であるため、このコード変更を追加すると上海のアップグレードが遅れるのではないかと van der Wijden 氏は懸念を表明しました。イーサリアム財団の Jared Wasinger 氏は、EIP 2537 よりも簡単な実装パスを提供できる並列 EIP に取り組んでいると述べました。開発者は EIP 2537 に取り組むことに同意し、Shanghai アップグレードを組み込む可能性があるため、さまざまな BLS プリコンパイルの数を削減し始めました。
: 最後に、Google のソフトウェア エンジニアである Zainan Victor Zhou 氏は、EIP 2294 を紹介しました。この EIP 2294 のコード変更は比較的単純ですが、ハード フォーク後のノード検出を支援するために伝統的に使用されているイーサリアムのチェーン ID フィールドのバイト サイズを制限するだけです。 Victor Zhou氏は電話会議で、将来的にはイーサリアムにおけるシャーディングとマルチチェーンの可能性により、チェーンIDのユースケースはより大きく、より重要になるだろうと述べた。他の種類のデータをチェーン ID フィールドに保存してチェーン ID フィールドを悪用しようとするのを防ぐために、Victor Zhou 氏はチェーン ID サイズを明示的にバインドするよう求めました。すべての開発者は、この変更が重要であり、実装が簡単であることに同意します。 Micah Zoltu 氏は、そのようなコード変更にはソフト フォークのみが必要であり、イーサリアム クライアント チームは、変更の特定のブロックの高さを調整する必要がなく、独自のタイムラインで変更を実装できることを意味すると強調しました。開発者の間では、呼び出しの終了時にチェーン ID サイズを 64 ビットに制限するか 256 ビットに制限するかについても議論がありました。 Tim Beiko 氏は、開発者に対し、Discord チャットでオフラインで議論し、非同期で数値を計算することを推奨しています。
上海のアップグレードに含めることが計画されている EIP のリストが増えていることに基づいて、コア リストの外にどの EIP を優先的に含めるかについて開発者の間で意見が分かれています。 「lightclient」という仮名を持つイーサリアム財団の開発者は、オープンな引き出しを堅持し、プロトダンクシャーディング、EOF実装、または電話会議で提案された4つのうちの1つである別の主要なEIPのみを優先することを提案しました。 Tim Beiko 氏は、次のアップグレードで EOF 実装、プロトダンクシャーディング、BLS プリコンパイル、および一時ストレージ オペコードの追加をバンドルしようとするのは非現実的だと考えています。会議時間がなかったため、北光氏は上海アップグレード計画についての議論を持ち出し、次回のACD電話会議で約束されたETHの出金以外に上海アップグレードの最優先事項について議論する準備をするよう開発者に奨励した。
イーサリアムノードの運用コストを削減する（検閲耐性を高める）にはどうすればよいですか?
上海のアップグレードに関する講演の中で、独立系イーサリアム開発者のミカ・ゾルトゥ氏は、イーサリアムの検閲耐性に関する重要な議論項目を取り上げた。ゾルトゥ氏の説明によると、トランザクションを実行するために独自のノードを実行しているイーサリアム ユーザーはほとんどおらず、特定の国からのユーザーを積極的に検閲し、Tornado Cash などのイーサリアム アプリケーション (dapps) の分散化を検閲する Infura や Alchemy のような集中型サービスに依存していると説明しました。開発者は EIP 4844 を通じてイーサリアムのスケーラビリティの向上に取り組んでいますが、イーサリアム ノードの実行コストを削減し、イーサリアムの検閲耐性をより確実にするための努力は不足していました。 Ethereum Teku (CL) クライアント チームの開発者である Mikhail Kalinin 氏は、EIP 4844 の実装後、Ethereum ノードの実行コストの削減に重点を置くことを提案しました。 Erigon の Andrew Ashkhmin 氏は、イーサリアム開発者は両方に同時に集中できると信じています。そしてアンスガー・ディートリヒス氏は、現実的な理由から、イーサリアム開発者は短期的にはスケーラビリティのために検閲耐性を犠牲にし、長期的には検閲耐性に注力すべきだと述べた。
イーサリアム財団の研究者ダンクラッド・ファイスト氏の見解は、EIP 4844 によるノードオペレーターの運用コストの増加は無視できる程度であり、イーサリアムの反検閲特性に重大な損害を与えることはない、というものです。 Feist氏はまた、ほとんどのイーサリアムユーザーはコストのためではなく、ユーザーエクスペリエンスが劣悪なため、独自のノードを実行していない、と付け加えた。 Diederik Loerakker氏は、EIP 4844のようなコード変更によりイーサリアムの使用コストが下がり、世界中のより多くの人がイーサリアムにアクセスできるようになるため、より高いレベルの分散化を実現するためには、イーサリアム開発者にとってスケーリングが優先されるべきであると述べた。エントリ。
上記に加えて、イーサリアム開発者がこの電話会議で議論していないことがいくつかあります。エンジンAPI仕様改善提案
: Teku 開発者 Mikhail Kalinin は、イーサリアムのエンジン API 仕様を改善するための提案を作成しました。背景として、エンジン API は、イーサリアム ノードの EL クライアントと CL クライアント間の簡単な通信を可能にするソフトウェアです。 Engine API に対する提案された変更は、来週木曜日の Ethereum CL カンファレンスで議論される可能性があります。上海の「コア」対プロトタイプ開発者のテストネット
