イーサリアムコア開発者会議ノート: 上海アップグレードに関する最新情報
原題：「原題：「》
#152 イーサリアムコア開発者会議メモ
元の編集者: Stephanie、ECN
編集された言葉
ECN が毎週更新する「イーサリアム 7 日間トーク」を視聴していた友人は、「7 日間トーク」が 1 か月近く中断されていることに気づくかもしれません。少し前に編集者が新型コロナウイルスに感染したため更新を続けることができなくなったことに加え、ECNは「セブンデイトーク」の編集を継続すべきかどうかも検討している。新年には、ECNは「セブンデイトーク」を含むコンテンツ運営の調整を行う予定だ。
イーサリアムコア開発者会議のメモを編集することは常に「Seven Day Talk」の重要な部分であり、今回、それを独立して更新することにしました。
前回の「7日間トーク」の内容を継続的に更新してほしい場合は、各種ソーシャルメディアでお気軽にプライベートメッセージをお送りください。コンテンツの質を向上させるために、皆様からのフィードバックをお待ちしております。
以下は詳細なメモです👇
最初のレベルのタイトル
上海のアップグレードの進捗
(https://t.co/HBkcidHvMq)
最初のレベルのタイトル
EOF 関連の EIP は上海で削除およびアップグレードされました
EOF 関連の EIP は上海で削除およびアップグレードされました
続いて、会議では主にEOF関連の議題が議論されました。
Geth チームの開発者 @lightclients が、12 月の EOF グループ ミーティングに関する最新情報を提供しました。 (EOF は EVM オブジェクト形式であり、イーサリアムのコード環境にいくつかの変更を導入します。これに関連する EIP はスマート コントラクトのコードとデータをより明確に区別し、将来的に EVM をアップグレードしやすくします。) , この仕様は、JUMPF の削除と、データ セクションを含めるためのデータ EOF コントラクトの必須化という 2 つの小さな変更を加えて最終化されました。
テスト側では、Geth チームの @mhswende が実装のファジングを開始し、バグを見つけてすべてのクライアントで修正しました。現在のファズ テストは主にクライアント上の EOF コンテナ/構造の実装を目的としていますが、デプロイされた EOF コードは含まれません。イーサリアム財団のテストチームの Mario Vega@elbuenmayini 氏は、EOF の複雑さのため、実装では正確なテスト ケースが発生する前に別のエラーが発生する可能性があるため、エラー ケースに対する静的テスト ケースを作成するのは難しいかもしれないと付け加えました。
クライアント側では、Geth と Besu は完全な実装を備えており、ほとんどのテストに合格しています。 Nethermind にも実装がありますが、どのテスト スイートを使用するのが最適かはわかりません。そして Erigon は Geth の EOF 実装を使用します。
EOF の実装とテストに基づいて、Vitalik 氏は EOF の性急な実装についても懸念を表明し、EOF アカウントのコード イントロスペクションを無効にするという EOF 提案を公開しました: https://ethereum-magicians.org/t/eof-proposal-ban -eof-アカウントのコードイントロスペクション/12113
Vitalik 氏は会議でこの提案の背後にある考え方を説明し、EVM の変更が一般に他のプロトコルの変更よりも難しい理由を説明しました。同氏は、イーサリアムからプルーフ・オブ・ワークを削除することは、オペコードを非推奨にするよりも簡単だと指摘した。これは、イーサリアム アプリケーション/コントラクトが EVM の特定の動作に依存しているため、変更には下位互換性がなければ、デプロイされたコントラクトが壊れてしまいます。プロトコルの他の側面を変更する場合は、特定の時間に全員が更新するだけで済み、それ以外の場合はネットワーク上の何も中断されません。
これは、EVM を改善したり、EOF などの新しいバージョンを導入したりする場合、以前のバージョンを非推奨にすることができないため、EVM を永久に使用し続ける必要がある可能性が高いことを意味します。理想的には、EVM をよりクリーン/シンプルにしたいと考えていますが、EVM に要素を追加することしかできず、要素を削除できない場合は、それは困難になります。削除の最大の課題の 1 つは、EVM でのコードのイントロスペクションです。
したがって、Vitalik の提案は、EOF v1 にさらに多くのコンテンツを追加することです。これにより、EOF 契約におけるコードのイントロスペクションが大幅に制限され、将来的にはアップグレードが容易になる可能性があります。 Ipsilon チームの @alexberegszaszi 氏は、EOF 提案の作成者は実際に以前にも同様の機能を検討していましたが、EOF v1 をシンプルに保ちたかったために断念したと述べました。彼はまた、Vitalik の提案を EOF v2 に組み込む代替案も提案しています: https://ethereum-magicians.org/t/eof v2-aka-what-evm-2-0-could-look-like/12442
しかし、EOF v1 にコンテンツを追加するというこの提案では、クライアント チームは全体の改訂が大きすぎるのではないかと懸念していました。 @lightclients はまた、EOF テストの現在の進捗状況に基づいて、上海のアップグレードに含めるのが約 1 か月遅れる可能性があると述べました。 2 月初旬にメインネットのテストネットのアップグレードを開始したい場合は、EOF 部分の準備ができていないはずです。また、EVM への変更は展開後に変更できないため、これは重要な決定です。
上海のアップグレードは他の EIP を補足する必要がありますか?議論の結果、開発者は上海のアップグレードを遅らせないために、他の EIP を追加しないことを決定しました。
最初のレベルのタイトル
他の EIP についての議論
その後、開発者は、Nimbus チームの Etan Kissling の提案、つまり ExecutionPayloadHeader のトランザクション リストに 16 進ルートを追加することについても議論しました。 https://github.com/ethereum/consensus-specs/pull/3078
簡単に言うと、実行層のブロックヘッダーとコンセンサス層の実行ペイロードヘッダー（ExecutionPayloadHeader）の間で、異なるシリアル化形式でエンコードされたフィールドが使用されます。これら 2 つのフィールドのエンコード形式が異なるため、ウォレットとイーサリアム ライト クライアントの構築に追加のオーバーヘッドと複雑さが生じます。 Kissling は、CL の SSZ シリアル化形式を実行層、またはコンセンサス層クライアントに追加して、実行層の RLP シリアル化形式をさまざまな方法でサポートすることを提案しています。この提案は上海アップグレードの撤退に関連するものであり、比較的緊急性が高い。この問題は、今週 1 月 12 日に開催されるコンセンサス レイヤー カンファレンス (ACDC) で再び議論されます。
ソースを次のようにコンパイルします@TimBeikoそして@christine_dkimそして
