元のタイトル: 「イーサリアム コア開発者ミーティング アップデート 014」

元のソース: AllCoreDevs アップデート

原作者：ティム・ベイコ

元の編集: Ethereum.cn

 

AllCoreDevs (イーサリアム コア開発者カンファレンス) アップデートの新版へようこそ – 2022 年最後のアップデートです。

 

概要

  1. 上海/カペラのアップグレードの内容は最終決定しました: 撤退、EOF、およびいくつかの軽微な変更…撤退を遅らせない限り。

  2. BLOB スペースが到来します。EIP-4844 はイーサリアムの次のアップグレードの中心となり、その召喚の儀式が間もなく始まります。

  3. 技術面では、実行層とコンセンサス層のアップグレードプロセスを調整する取り組みが進行中です。また、コミュニティからの意見をプロセスにうまく組み込むことについての活発な議論も見られます。

  4. Protocol Guild は、2023 年に第 1 層メンテナーの規模を拡大し、サポートを強化するための中期パイロット レポートと大まかな計画をリリースしました。

 

上海/カペラアップグレード

最近の AllCoreDevs で、クライアント チームは Shanghai/Capella アップグレードの最終範囲について合意に達しました。アップグレードの名前については議論の余地があるかもしれませんが、チームはその範囲については明確です。アップグレードの主な特徴は、ステーカー向けのビーコンチェーン引き出しの導入です。この機能をできるだけ早く展開することは、クライアント チームが妥協したくないことであるため、アップグレードの他の機能も同時に準備する必要があり、そうしないと放棄される危険があります。

Shanghai Executive Layer の仕様には、含まれるすべての EIP がリストされています。

  1. EIP-3540: EVM オブジェクト フォーマット (EOF) v1

  2. EIP-3651: COINBASE アドレスにアクセスするためのガスコストを削減する

  3. EIP-3670: EOF - コード検証

  4. EIP-3855: オペコード PUSH 0 を追加しました

  5. EIP-3860: initcode サイズを制限し、ガス メータリングを導入する

  6. EIP-4200: EOF - 静的相対ジャンプ

  7. EIP-4750: EOF - 関数のインポート

  8. EIP-4895: システム操作としてのビーコン チェーン プッシュの引き出し

  9. EIP-5450: EOF - スタック検証

リストは長いですが、マイナーな改善、EVM オブジェクト形式、および廃止の 3 つの異なる部分に分けることができます。次に、それらを 1 つずつ紹介します。

 

マイナーな改善

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 に不変条件が追加され、変更の理解と提案が容易になります。

initcode には 32 バイトあたり 2 ガスのオーバーヘッドが発生します。これは、クライアントが実行前に実行する必要があるジャンプデスト分析の支払いに使用されますが、ガス メーターにはリストされていません。

 

オブジェクト形式

Shanghai アップグレードに含まれる EIP のほとんどは、実際には単一の機能である EVM Object Format (EOF) の一部です。クライアント開発者が個々の変更を理解できるように、作業は 5 つの異なる EIP に分類されましたが、より高いレベルの概要を提供するために、開発者は統一仕様をリリースしました。これら 5 つの EOF の EIP は次のとおりです。

  1. EIP-3540: EVM オブジェクト フォーマット バージョン 1

  2. EIP-3670: EOF - コード検証

  3. EIP-4200: EOF - 静的相対ジャンプ

  4. EIP-4750: EOF - 関数のインポート

  5. 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 実行ルールのセットを維持する必要があります。

EOF より前は、クライアントは一度に 1 セットの EVM ルールのみを維持していました。コード ベースは、ネットワークのアップグレードごとに変更される以前の EVM ルールもサポートしていますが、ブロックチェーンの先頭に達すると、最新のルールのみを適用する必要があります。 EOF のデプロイ後、クライアントは EVM ルールの 2 つの並列セットを維持するため、EOF コントラクトと非 EOF コントラクトのコードを実行できます。言い換えれば、EOF のバージョンが増えると、維持する必要がある連続した EVM ルール セットではなく、並列した EVM ルール セットの数が増加します。

この目的を達成するために、過去数か月にわたって、クライアント チームは「大きな EOF」アプローチを支持し始めています。こうすることで、より大きな変更セットを実装する必要がありますが、EOF バージョンの存続期間が長くなり、維持する必要がある「並列 EVM」の数が減ります。したがって、開発者は「大きな EOF」を検討し、最終的に上海アップグレードに含めました。

とはいえ、機能が大きくなるほど実装とテストは明らかに難しくなり、チームは EOF によってビーコン チェーンの撤退が大幅に遅れることを望んでいません。したがって、EOF の実装が 1 月までに完了しておらず、相互運用を迅速に行うことができない場合、クライアント チームはアップグレードのために EOF を上海から移動することに同意します。

 

これらのコンテキストを念頭に置いて、各 EOF EIP を簡単に紹介しましょう。

EIP-3540: EVM オブジェクト フォーマット (EOF) v1 (EVM オブジェクト フォーマット バージョン 1)

この EIP は、EOF 契約に「コンテナ」を導入します。タグを追加してコントラクトのコード部分とデータ部分を区別し、形式に準拠していない EOF コントラクトがデプロイされるのを防ぎます。これにより、チェーン上のすべての EOF コントラクトが有効な形式に従うことが保証され、これらのコントラクトとの対話や静的分析が簡素化されます。

 

EIP-3670: EOF - コード検証 (EOF - コード検証)

3540 によって導入されたコンテナ上に構築された EIP-3670 は、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 オペコードの使用を禁止し、コピーできない関数の代替を追加します。これは、EOF バイトコードに特定の関数セクションを導入することによって実装されます。これらの関数は、それぞれ新しい JUMPF、CALLF、および RETF オペコードからジャンプし、それらを呼び出して返すことができます。

 

EIP-5450: EOF - スタック検証 (EOF スタック検証)

最後に、EIP-5450 は、EOF コントラクトに別の検証チェックを追加します。今回はスタックに関してです。この EIP は、EOF コントラクトがスタックのアンダーフローや、場合によってはオーバーフローを引き起こす可能性のあるコードをデプロイすることを防ぎます。この EIP を使用すると、スタック関連の例外に関する保証が強化されるため、クライアントは EOF コントラクトを実行する際の検証チェックの数を減らすことができます。

EIP 自体に重点を置いている EVM の専門家ではない私が、これについて言えることはあまりありません。読者が EOF についてさらに詳しく知りたい場合は、Geth チームの lightclient と Solidity チームの Leo によって投稿された関連ツイートをお勧めします。

 

ビーコンチェーンの撤回

最後になりますが、『シャペラ』（訳者注：上海/カペラの総称）のメインはビーコンチェーンの撤退です。変更のこの部分は、コンセンサス層仕様と EIP-4895 で説明されています。現在、これらの変更を結び付ける少し古いメタ仕様が存在します。

大まかに言うと、出金のメカニズムは次のとおりです。

ブロックを提案するとき、バリデーターはバリデーター インデックスを線形にスキャンして、0x01 資格情報を持つ最初の 16 個のバリデーターを見つけます。これらのバリデーターは、次のいずれかの条件を満たす必要があります。

  1. 残高が 32 ETH を超える (つまり、バリデーター報酬を獲得している)

  2. 引き出し可能である（つまり、バリデータセットから完全に退出している）

残高が 32 ETH を超えている (つまり、バリデーターの報酬が得られている)

撤回可能です (撤回可能、つまりバリデーター・セットから完全に抜け出ています)

これらを基に、バリデータは ExecutionPayload に含める引き出しのリストを作成します。リストの各項目には次のものが含まれます。

バリデーターは、これらのバリデーターから出金リストを作成し、それを ExecutionPayload にパッケージ化します。リストの各項目には次のものが含まれます。

  1. WithdrawalIndex: 行われたすべての出金トランザクションのインデックス - これは、同じアドレス、同じバリデータからの同じ金額の出金を区別するのに役立ちます。

  2. ValidatorIndex: 残高が引き上げられたバリデーター インデックス

  3. ExecutionAddress: 出金の送信先となる実行層の ETH アドレス

  4. Amount: ExecutionAddress に送信される金額。この金額は (wei ではなく) gwei で測定されます。

実行層クライアントは、ブロックの構築または処理時にトランザクションが実行された後にこれらの出金を行います。言い換えれば、出金は、Proof-of-Work 報酬が記録されるのと同様の方法で処理され、ブロックスペースをめぐってユーザートランザクションと競合しません。

他にも注目に値する詳細がいくつかあります。

  1. 出金処理の際、「資金全額」と「資金の一部」で優先順位・順序に違いはありません。完全な引き出しはバリデーターが終了チームを離れるときに発生しますが、部分的な引き出しは定期的に、つまりバリデーターセットの線形スキャンが実行され、特定のバリデーターのインデックス番号がスキャンされたときに発生します。

  2. 出金を処理するには、バリデーターは ETH アドレスで表される 0x01 認証情報を使用する必要があります。ビーコン チェーンがオンラインになると、BLS キー ペア 0x00 認証情報のみが許可されます。出金を開始するには、0x00 資格情報を持つバリデーターが BLSToExecutionChange メッセージに署名する必要があります。これらは Capella アップグレードで有効になります。このメッセージの署名にはさまざまなツールが使用され、検証者はこれらのツールのサポートとチュートリアルを期待できます。

  3. バリデーターのスキャンはブロックごとに行われます。バリデーター セットのサブセットをスキャンした後に処理する 16 件の出金がない場合、バリデーターはスキャンを停止し、次のバリデーターは最後にスキャンされたバリデーター インデックスから開始します。

いつものように、メインネットが稼働する前にバリデーターがプロセス全体を実行して問題を解決するために、いくつかの開発者テストネットとテストネット (おそらく新しいテストネットもあるでしょう!) が存在します。

アップグレードが進んでいるのは上海/カペラだけではありません!開発者チームはまだ次のアップグレードを見据えています。

 

カンクンのアップグレード

上海アップグレードの内容はすでに充実しているため、アップグレードを検討していた多くのEIP（CFI）が上海アップグレードに参加できていない。クライアント チームは、次のアップグレードでどの EIP を検討する必要があるかについて議論を開始します: カンクン アップグレード (コンセンサス レイヤー名は未定)

コンセンサス層に関しては、EIP-4844 は、Capella アップグレード後に仕様に書き込まれた最初の EIP となりました。このレイアウトを実装できるエグゼクティブ層の仕様は (まだ) ありませんが、エグゼクティブ層チームは同様の道をたどり、次のアップグレードでは EIP-4844 を中心にすることに同意しました。

Devcon が開催された都市の名前を使用したアップグレードの慣例に従って、cancun.md が作成され、EIP-4844 が正式にアップグレードに含まれています。

この決定は、2022 年の最後の AllCoreDevs 会議の土壇場で行われたため、他の提案に取り組む時間がありませんでした。上海で CFI アップグレードに参加したが、最終的には含まれなかった EIP は、カンクンの EIP 候補について議論するための投稿がイーサリアム マジシャンズ フォーラムにも開設されました。カンクンでのアップグレードの範囲に関する議論は、来年初めに本格的に始まるはずだ。

 

KZGセレモニー

カンクンのアップグレードに関連して楽しみにしているもう 1 つのことは、EIP-4844 の要件である KZG セレモニーです。

この儀式は、BLOB データの有効性を検証するために必要なランダム性を生成します。安全であるとみなされるためには、参加者の 1 人だけが正直である必要があります。言い換えれば、1 人を除くすべての参加者が共謀した場合、プロセス全体は暗号的に安全になります。

式典は1月に始まり、数か月間誰でも参加できる予定です。参加者は10,000名を目標としており、この種の式典としては過去最大規模となる予定です！見逃さないようにしたい場合は、Twitter でトレント ヴァン エップスをフォローしてください。

 

合併後のアップグレードプロセス

前回の更新で述べたように、合併後、実行層とコンセンサス層でのイーサリアムのアップグレード プロセスを調整することが重要な To-Do 項目です。高レベルの観点から見ると、実行層はイエロー ペーパーと EIP を使用して変更を記述し、コンセンサス層は実行可能な Python 仕様を使用します。

エグゼクティブ層プロセスの利点は、EIP がコミュニティによく知られており、提案の背後にある理由を明確に示す方法でフォーマットされていることです。 EIP と組み合わされた多くの数学的内容を含む黄色の本は、仕様を各 EIP のコンテキストに戻す必要があるため、実行層の仕様の理解と拡張が困難になります。

コンセンサス層の問題はその逆です。コンセンサス層には単一のリポジトリ内に明確でわかりやすい仕様がありますが、変更は目に見えず、提案はリポジトリ内の他の公開 PR に埋もれてしまいます。

イーサリアム実行層仕様の導入により、実行層側からのこのギャップを短縮したいと考えています。そして、プロセスのラングリングをいくつか行うことで、EIP をコンセンサス層プロセスに導入できる可能性があります。

とはいえ、上海のアップグレードの範囲が議論され最終決定されるにつれて、プロセスの別の部分が欠けている可能性があることが明らかになりました。それは、コミュニティが変更に対する相対的な好みを表明し、アップグレードの範囲全体についての議論に参加できるようにすることです。個々の EIP) これを適切な場所で議論し、AllCoreDev とコンセンサス層の会議の決定の一部にします。

それがどのようなものになるかはまだ明らかではありません。提案をお待ちしています。 — しかし、プロトコルの変更に積極的に関与する利害関係者の数が増加し、レイヤー 1 の変更によって影響を受ける領域の数が増加するにつれて、何かが必要であることは明らかでした。

幸いなことに、最初から始める必要はありません。 Ethereum Magicians は何年も前から存在しており、そのオフライン ミートアップ、専用のグループ ミーティング、またはコミュニティ ミーティングは、拡張の良い出発点となる可能性があります。

2023 年初頭には、この面でさらなる進展が期待されます。

 

協定ギルドの更新

Protocol Guild (PG) のパイロットは半ばを迎え、進捗状況を調査し、プロジェクトの次のステップについて検討するレポートをリリースしました。

 

思い出していただきたいのですが、PG はイーサリアム レイヤ 1 クライアント開発者、プロトコル研究者、および支援貢献者 (あなたのような) のための許可のない資金調達メカニズムです。

このメカニズムは組織ではなく個人を中心としています。つまり、各メンバーはイーサリアムに貢献した期間に基づいて重み付けされたギルドのトークンのシェアを受け取る資格があります。メンバーの追加と削除は、PG 内の一連の標準と大まかな合意に基づいて、真のイーサリアムの方法で行われます。このリストは、0xSplit スプリット コントラクトを使用してオンチェーンに配置されます。寄付者は、資金を受取人の住所に直接送金することも、資金を受取人の住所に放出する権利確定契約に送金することもできます。

パイロット中間報告書はこちらのツイートにまとめてあります。ここにいくつかのハイライトがあります

このパイロットでは、Lido、Uniswap、ENS、NounsDAO、MolochDAO などの組織から、また個人からの定期的な寄付者から 970 万ドルを集めました (Tetranode に感謝!) - これを可能にしてくれた皆さんに感謝します!

PG のメンバーは発足時に 90 名でしたが、現在は 128 名となり、メンバー間で 500 万ドルが分配されています。

平均すると、各メンバーは 39,000 ドルを受け取り、最低額は 13,000 ドル、最高額は 79,000 ドルに達しました。

PG のアーキテクチャが変更され、L2 がサポートされ、重みを更新するためのマルチシグの必要性がなくなりました。

これらの初期の結果は、PG が計画どおりに機能していることを示しています。つまり、自己インキュベーションを行い、成長を続けるプロトコル貢献者のグループにトークンのバスケットを配布するメカニズムです。このプロジェクトは、パイロット寄付者の寛大な支援がなければ、今日のようなものにはなりませんでした。

将来に目を向けると、今こそ PG の範囲を拡大し、イーサリアム保守者に競争力のあるリスク調整済みの報酬を提供するというその可能性を最大限に発揮するときです。ここで行う最も簡単な方法は、PG を立ち上げるツイートでダニー ライアンが述べたように、プロジェクトが最初から PG に寄付することです。

パイロットでの寄付のほとんどは、多額の資金を集めた大規模プロジェクトからのものでした。トークンがまだ本当に「無価値」である初日から、プロトコル ギルドがこれらのプロジェクトに PG に寄付するよう説得できれば、イーサリアムの保守者はこれらの成功したプロジェクトの全体的な上昇軌道から恩恵を受けることができます。

十分な数のプロジェクトが関与している場合、インセンティブによって優秀な人材を引き離すのではなく、保守契約に留めておくことができます。

これや他の多くの寄付タイプをサポートするには、PG には技術的な見直しが必要です。次のバージョンでは L1 と L2 がサポートされ、オンチェーン ガバナンスのフットプリントがさらに削減されます。

Protocol Guild に寄付したいプロジェクトがある場合は、私に連絡してください - 私の DM はオープンしています!

 

フォローアップ

これで 2022 年を締めくくります... 何と素晴らしい年でしょう! 3 か月前、私たちはまだ合併していませんでした。イーサリアムがバックグラウンドでプルーフ・オブ・ステークを静かに実行しているため、焦点は将来のトランザクションに移っています。

1 月には全員が戻ってくるため、次のことが期待できます。

  1. Shanghai/Capella が開発者テストネットとシャドウ フォークをアップグレード

  2. KZG式典がオンラインで開催

  3. カンクンに関する議論と、コミュニティの好みをよりよく反映するためにネットワーク アップグレード プロセスをどのように進化させるべきかについての議論

プロトコルギルドのパイロットは終了し、パイロット後の体制を発表します。