元のソース: AllCoreDevs アップデート
元のソース: AllCoreDevs アップデート
著者: ティム・ベイコ
元の編集: Ethereum.cn
新しい AllCoreDevs (イーサリアム コア開発者カンファレンス) アップデートへようこそ - 2022 年最後のアップデートです。
これらの更新は月次シリーズとして始まりましたが、徐々に四半期更新に移行してきました。読者は、これらのアップデートを AllCoreDevs を取り巻く主要なイベントの概要と考えることができます。さらに詳しく知りたい場合は、Christine Kim の記録、Ben Edginton のコンセンサス層会議の記録、および私の ACD の長いツイートを読むことをお勧めします。これらはより頻繁に更新されます。
まとめ
まとめ
上海/カペラアップグレードの内容が最終決定しました: 撤退、EOF、およびいくつかのマイナー修正...撤退を遅らせない限り
BLOB スペースが登場: EIP-4844 がイーサリアムの次のアップグレードの中心となり、その召喚の儀式が間もなく始まります
技術面では、実行層とコンセンサス層のアップグレードプロセスを調整する取り組みが進行中です。また、コミュニティからの意見をプロセスにうまく組み込むことについての活発な議論も見られます。
最初のレベルのタイトル
上海/カペラアップグレード
最近の AllCoreDevs で、クライアント チームは、Shanghai/Capella アップグレードの最終範囲について合意に達しました。アップグレードの名前については議論の余地があるかもしれませんが、チームはその範囲については明確です。アップグレードの主な機能は、ステーカーにビーコンチェーン引き出しを導入することです。この機能をできるだけ早くリリースすることは、クライアント チームにとって妥協したくないことであるため、アップグレードの他の機能も同時に準備する必要があり、そうしないと削除される可能性があります。
上海エグゼクティブ仕様には、組み込まれているすべての EIP がリストされています。
EIP-3540: EVM オブジェクト フォーマット (EOF) v1
EIP-3651: COINBASE アドレスにアクセスするためのガス オーバーヘッドを削減する
EIP-3670: EOF - コード検証
EIP-3855: 新しいオペコード PUSH 0
EIP-3860: initcode サイズを制限し、ガス メータリングを導入する
EIP-4200: EOF - 静的相対ジャンプ
EIP-4750: EOF - インポート関数
EIP-4895: システム操作としてのビーコン チェーン プッシュ引き出し
EIP-5450: EOF - スタック検証
副題
マイナーな改善
EIP-3651: COINBASE をウォーム化 (COINBASE アドレスにアクセスする際のガス オーバーヘッドを削減)
この EIP は、特定のデータ フィールド アクセスのガス コストの変更が、データがすでにクライアント メモリ内にあるか (WARM)、ディスクから取得する必要があるか (COLD) に基づいているという EIP-2929 の見落としを修正します。
EIP-2929 は、各トランザクションの開始時にクライアント メモリ内の 2 つのデータ (送信アドレスと受信アドレス) を WARM に設定します。 EIP-3651 は、このリストに 3 番目のアドレスである COINBASE アドレス (つまり、feeRecipient) を追加します。これは、ブロック トランザクションを処理するときにクライアントがメモリ内に持つアドレスでもあるためです。
EIP-3855: PUSH 0 命令 (オペコード `PUSH 0 を追加)
名前が示すように、EIP-3855 では値 0 をスタックにプッシュするオペコードが導入されています。 0 のプッシュは、EVM に値を埋めるためによく使用されます。このオペコードは、これを行うためのより効率的で安価な方法を提供します。
EIP-3860: initcode の制限と計測 (initcode のサイズに制限を設定し、ガス計測を導入)
この EIP では、initcode のサイズに上限が追加され、その長さに基づいてガス メータリングが導入されます。サイズの上限により EVM に不変条件が追加されるため、変更の理解と提案が容易になります。
副題
オブジェクト形式
Shanghai アップグレードに含まれる EIP のほとんどは、実際には単一の機能である EVM Object Format (EOF) の一部です。この作業は、クライアントの開発者が個々の変更を理解できるように 5 つの異なる EIP に分類されましたが、より高いレベルの概要を提供するために、開発者は統合された仕様を公開しました。 5 つの EOF の EIP は次のとおりです。
EIP-3540: EVM オブジェクト フォーマット バージョン 1
EIP-3670: EOF - コード検証
EIP-4200: EOF - 静的相対ジャンプ
EIP-4750: EOF - インポート関数
EIP-5450: EOF - スタック検証
EOF の最初のステップは、EOF 契約用に 0xEF 00 プレフィックスを予約したロンドンのアップグレードされた EIP-3541 で行われたことは注目に値します。上海アップグレードの EOF 範囲も、過去数か月間で変更されました。
2 月に、クライアント チームは、2 つの最小の EOF EIP、EIP 3540 および 3670 を組み込むために上海でアップグレードを検討することに同意しました。これらはすべてビルディング ブロックとして機能しますが、EIP 4200、4750、および 5450 を導入しないと完全な機能は提供されません。 EOF を拡張することは可能ですが、下位互換性がないため、新しいバージョンが必要になる場合があります。 EOF より前のコントラクト、または EOF の特定のバージョンを使用したコントラクトは常に実行可能である必要があるため、新しい EOF バージョンごとに、クライアント開発者は古い EVM 実行ルールと並行して新しい EVM 実行ルールのセットを維持する必要があります。
EOF の前に、クライアントは一度に 1 セットの EVM ルールのみを維持します。コード ベースは、ネットワークのアップグレードごとに変更される以前の EVM ルールもサポートしていますが、ブロックチェーンの先頭に達すると、最新のルールのみを適用する必要があります。 EOF のデプロイ後、クライアントは EVM ルールの 2 つの並列セットを維持するため、EOF コントラクトと非 EOF コントラクトのコードを実行できます。つまり、EOF のバージョンが増加すると、維持する必要がある逐次的ではなく並列的な EVM ルールセットの数が増加します。
このため、過去数か月の間に、クライアント チームは「大きな EOF」を支持し始めました。"方法。こうすることで、より大きなリビジョン セットを実装する必要がありますが、EOF バージョンの存続期間が長くなり、維持する必要がある「並列 EVM」が削減されます。"番号。したがって、開発者は「大きな EOF」を検討し、最終的に上海アップグレードに組み入れました。
とはいえ、機能が大きくなると実装とテストが明らかに難しくなり、チームは EOF によってビーコン チェーンの撤退が大幅に遅れることを望んでいません。したがって、EOF の実装が 1 月までに完了しておらず、相互運用を迅速に行うことができない場合、クライアント チームはアップグレードのために EOF を上海から移動することに同意します。
EIP-3540: EVM オブジェクト フォーマット (EOF) v1 (EVM オブジェクト フォーマット バージョン 1)
EIP-3540: EVM オブジェクト フォーマット (EOF) v1 (EVM オブジェクト フォーマット バージョン 1)
この EIP では、EOF 契約の「コンテナ」が導入されます。マーカーを追加してコントラクトのコード部分とデータ部分を区別し、形式に準拠していない EOF コントラクトがデプロイされるのを防ぎます。これにより、オンチェーン上のすべての EOF コントラクトが有効な形式に従うことが保証され、これらのコントラクトとの対話や静的分析が簡素化されます。
EIP-3670: EOF - コード検証 (EOF - コード検証)
EIP-3670 は、3540 によって導入されたコンテナ上に構築されており、EOF コントラクト内のコードが有効であることを保証するか、コードがデプロイされないようにします。
これは、未定義のオペコードを EOF コントラクトにデプロイできないことを意味し、追加する必要がある EOF バージョンの数が減るという利点もあります。新しいオペコードが追加された場合、検証ルールを変更するだけでそれが有効になり、デプロイされた EOF コントラクトがそのコード セクションでそのオペコードを参照しないようにすることができます。
EIP-4200: EOF - 静的相対ジャンプ (EOF - 静的相対ジャンプ)
EIP-4200 では、最初の EOF 固有のオペコードである RJUMP、RJUMPI、および RJUMPV が導入されました。これらは、宛先を符号付き即値としてエンコードします。これらの新しい JUMP オペコードは、既存の JUMP および JUMPI オペコードで必要とされるランタイム Jumpdest 解析の必要性を排除するため、コンパイラでガス オーバーヘッドを最適化するために使用できます。
EIP-4750: EOF - 関数 (EOF インポートされた関数)
EIP-4750 は 4200 をさらに一歩進めて構築されています。JUMP および JUMPI オペコードを禁止し、複製できない RJUMP、RJUMPI、および RJUMPV 関数の代替機能を追加します。これは、それぞれ新しい JUMPF、CALLF、RETF オペコードを使用してジャンプしたり、呼び出したり、返したりできる特定の関数のセクションを EOF バイトコードに導入することによって行われます。
EIP-5450: EOF - スタック検証 (EOF スタック検証)
最後に、EIP-5450 は、EOF コントラクトに別の検証チェックを追加します。今回はスタックに関してです。この EIP は、EOF コントラクトのデプロイメントによってスタック アンダーフローが発生したり、場合によってはコードがオーバーフローしたりする可能性を防ぎます。この EIP を使用すると、スタック関連の例外に関する保証が強化されるため、クライアントは EOF コントラクトを実行する際の検証チェックの数を減らすことができます。
副題
ビーコンチェーンの撤回
最後になりますが、『シャペラ』（訳者注：上海/カペラの総称）のメインはビーコンチェーンの撤退です。変更のこの部分は、コンセンサス層仕様と EIP-4895 で説明されています。現在、これらの変更を結び付ける少し古いメタ仕様が存在します。
大まかに言うと、出金のメカニズムは次のとおりです。
ブロックを提案するとき、バリデーターはバリデーター インデックスを線形にスキャンして、0x01 証明書を持つ最初の 16 個のバリデーターを見つけます。これらのバリデーターは、次のいずれかの条件を満たす必要があります。
Have a balance above 32 ETH (i.e. have accrued validator rewards)
Are withdrawable (i.e. have fully exited the validator set)
残高が 32 ETH を超えている (つまり、バリデーターの報酬が得られている)
撤回可能です (撤回可能、つまりバリデーターセットから完全に撤回されています)
From these, the validator will create a list of withdrawals to be included in their ExecutionPayload. Each item in that list contains the following:
バリデーターは、これらのバリデーターからの出金のリストを作成し、ExecutionPayload にパッケージ化します。リストの各項目には次のものが含まれます。
WithdrawalIndex: 行われたすべての出金トランザクションのインデックス - これは、同じアドレス、同じバリデータからの同じ金額の出金を区別するのに役立ちます
ValidatorIndex: 残高が引き上げられたバリデーター インデックス
ExecutionAddress: 出金の送信先となる実行層の ETH アドレス
Amount: ExecutionAddress に送信される金額。この金額は (wei ではなく) gwei で測定されます。
ブロックを構築または処理する場合、実行層クライアントはトランザクションの実行後にこれらの出金操作を実行します。言い換えれば、出金はプルーフ・オブ・ワークの報酬が入金される方法と同様に処理され、ブロック領域をめぐってユーザーのトランザクションと競合しません。
注目すべき詳細もいくつかあります。
出金を処理する際、「全額資金」を提出する場合と「一部資金」を提出する場合とで、優先順位やランキングに違いはありません。バリデーターが終了チームを離れると全額が引き出されますが、バリデーターセットのリニアスキャンが実行され、特定のバリデーターのインデックス番号がスキャンされると、部分的な引き出しが定期的に行われます。
出金を処理するには、バリデーターは ETH アドレスで表される 0x01 トークンを使用する必要があります。ビーコン チェーンがライブになると、BLS キー ペア 0x00 認証情報のみが許可されます。引き出しを開始するには、0x00 資格情報を持つバリデーターが BLSToExecutionChange メッセージに署名する必要があります。これらは Capella アップグレードで有効になります。このメッセージの署名にはさまざまなツールが使用され、検証者はこれらのツールのサポートとチュートリアルを期待できます。
バリデータはブロックごとにスキャンされます。バリデーター・セットのサブセットをスキャンした後に処理する出金が 16 件以下の場合、バリデーターはスキャンを停止し、次のバリデーターは最後にスキャンされたバリデーター・インデックスから開始します。
いつものように、メインネットが稼働する前に、バリデーターが問題を調べて問題を解決するために、いくつかの開発者テストネットとテストネット (おそらく新しいテストネットも!) が存在します。
最初のレベルのタイトル
カンクンのアップグレード
上海でのアップグレード内容がすでに満杯であるため、アップグレードを検討していた多くのEIP（CFI）が上海でのアップグレードに参加できていない。クライアント チームは、次のアップグレードでどの EIP を検討すべきかについて議論を開始しました: カンクンのアップグレード (コンセンサス レイヤー名は未定)
コンセンサス層に関しては、EIP-4844 は、Capella アップグレード後に仕様に書き込まれた最初の EIP となりました。エグゼクティブ層には、このレイアウトを実装する仕様が (まだ) ありませんが、エグゼクティブ層チームは、EIP-4844 を次のアップグレードの中心として、同様の道をたどることに同意しました。
Devcon が開催された都市の名前を使用するアップグレードの慣例に従って、cancun.md が作成され、EIP-4844 が正式にアップグレードに含まれます。
副題
KZG式典
カンクンのアップグレードに関連して期待できるもう 1 つのことは、EIP-4844 の要件である KZG セレモニーです。
この儀式は、BLOB データの有効性を検証するために必要なランダム性を生成します。安全であるとみなされるためには、参加者の 1 人だけが正直である必要があります。言い換えれば、1 人を除く全員が共謀した場合、プロセス全体は暗号的に安全になります。
最初のレベルのタイトル
合併後のアップグレードプロセス
前回の更新で述べたように、合併後は、実行層とコンセンサス層でのイーサリアムのアップグレード プロセスの調整が重要なバックログとなります。大まかに言うと、実行層はイエロー ペーパーと EIP を使用して変更を指定し、コンセンサス層は実行可能な Python 仕様を使用します。
エグゼクティブレベルのプロセスの利点は、EIP がコミュニティによく知られており、提案の背後にある理由を明確に示す方法でフォーマットされていることです。数学を多用した黄色の論文と EIP が組み合わされており、仕様を各 EIP のコンテキストに戻す必要があるため、実装レベルの仕様の理解と拡張が困難になりました。
コンセンサス層の問題はその逆です。単一のリポジトリ内に明確でわかりやすい仕様がありますが、変更は特に認識できず、提案はリポジトリ内の他の公開 PR に埋もれてしまいます。
Ethereum 実行層仕様の導入により、私たちは実行層の観点からこのギャップを埋めたいと考えています。そして、プロセスのラングリングをいくつか行うことで、EIP をコンセンサス層のプロセスに取り込むことができるかもしれません。
とはいえ、上海のアップグレードの範囲が議論され最終決定されるにつれて、プロセスの別の部分が欠けている可能性があることが明らかになりました。それは、コミュニティに変更に対する相対的な好みを表明してもらい、アップグレードの全体的な範囲についての議論に参加してもらうことです。 (個々の EIP ではなく) それがどこにあるのかを議論し、AllCoreDevs およびコンセンサス層の会議での決定の一部にします。
それがどのようなものになるかは明らかではありませんが、提案をお待ちしています。 — しかし、プロトコルの変更に積極的に参加する利害関係者の数と、レイヤーの変更によって影響を受けるドメインの数の両方が増加しているため、明らかに何かが必要です。
幸いなことに、最初から始める必要はありません。 Ethereum Magicians は何年も前から存在しており、そのミートアップ、専用のグループ ミーティング、またはコミュニティ ミーティングは、スケーリングの良い出発点となる可能性があります。
最初のレベルのタイトル
プロトコルギルドのアップデート
Protocol Guild (PG) のパイロットが半ばを迎え、進捗状況を調査し、プロジェクトの次の展開について検討するレポートをリリースしました。
PG は、イーサリアム レイヤ 1 クライアント開発者、プロトコル研究者、およびあなたのようなサポート貢献者のための、許可のない資金提供メカニズムであることを思い出してください。
このメカニズムは組織ではなく個人を中心としています。つまり、各メンバーは、イーサリアムに貢献した期間によって重み付けされた、ギルドのトークンのシェアを受け取る権利があります。メンバーの追加と削除は、PG 内で一般的な合意に達した一連の標準に基づいて、イーサリアムの本来の方法で実行されます。このリストは、0xSplit の分割コントラクトを使用してオンチェーンに配置されます。寄付者は、受取人の住所に直接資金を送金することも、受取人の住所に資金を発行する権利確定契約に資金を送金することもできます。
パイロット中間報告書はこちらのツイートにまとめてあります。ここにいくつかのハイライトがあります
このパイロットでは、Lido、Uniswap、ENS、NounsDAO、MolochDAO などの組織、および定期的に寄付を行っている個人 (Tetranode に感謝) から 970 万ドルを集めました。これを可能にしてくれた皆さんに感謝します。
PG のメンバーは発足時に 90 名でしたが、現在は 128 名となり、メンバー間で 500 万ドルが分配されています。
平均すると、各メンバーは 39,000 ドルを受け取り、最低額は 13,000 ドル、最高額は 79,000 ドルでした。
PG のアーキテクチャが変更され、L2 がサポートされ、重みを更新するためのマルチシグネチャの必要性がなくなりました。
これらの初期の結果は、PG が計画どおりに機能していることを示しています。つまり、自己インキュベートし、成長を続けるプロトコル貢献者のセットにトークンのバスケットを配布するメカニズムです。このプロジェクトは、試験的寄付者の寛大な支援がなければ今日の形にはなりませんでした。
今後を見据えて、今こそ PG の範囲を拡大し、イーサリアム保守者に対する競争力のあるリスク調整済みの報酬というその可能性を最大限に実現するときです。ここで行う最も簡単な方法は、ダニー ライアンが PG を開始したツイートで述べたように、プロジェクトの最初から PG に寄付することです。
パイロットでの寄付のほとんどは、多額の資金を備えた大規模プロジェクトからのものでした。プロトコル ギルドが、トークンがまだ本当に「無価値」である初日から、これらのプロジェクトに PG に寄付するよう説得できれば、イーサリアムのメンテナーは、これらの成功したプロジェクトの全体的な上昇軌道から恩恵を受けることができます。
十分な数のプロジェクトが関与している場合、インセンティブによって優秀な人材を引き離すのではなく、保守契約に留めておくことができます。
これや他の多くの寄付タイプをサポートするには、PG には技術的な見直しが必要です。次のバージョンでは L1 と L2 がサポートされ、オンチェーン ガバナンスのフットプリントがさらに削減されます。
最初のレベルのタイトル
フォローアップ
これで 2022 年は終わります... 何と素晴らしい年でしょう! 3 か月前、私たちはまだ合併していませんでした。イーサリアムでは Proof of Stake がバックグラウンドで静かに実行されているため、焦点は将来のトランザクションに移っています。
1 月に戻ってくると、次のことが期待できます。
上海/Capella のアップグレードされた開発者テストネットとシャドウ フォーク
KZGセレモニー開始
カンクンに関するディスカッション、およびコミュニティの好みをより適切に把握するためにネットワーク アップグレード プロセスをどのように進化させるべきか
プロトコルギルドのパイロットは終了します、パイロット終了後に体制を発表します
読んでくれてありがとう！そして、昨年イーサリアムの改善に時間を割いてくださった皆様のおかげで、私たちは多くのことを達成できました。
元のリンク
