イーサリアムコア開発者会議の最新情報の要点を簡単にまとめます
著者: ティム・ベイコ
元のソース: AllCoreDevs アップデート
著者: ティム・ベイコ
元のソース: AllCoreDevs アップデート
最初のレベルのタイトル
まとめ
1月から色々なことがあったので、それをすべて書き留める時間を見つけるのに苦労していました。このアップデートのハイライトは次のとおりです。
イーサリアム実行層の実行可能仕様の策定は順調に進んでいます。次のステップ: EL+CL のアップグレード プロセスを調整します。
テストネット
クライアントの開発者や研究者向けのトークンベースの報酬イニシアチブである Protocol Guild には、現在 100 名を超えるメンバーがおり、間もなく試験運用を開始します。
最初のレベルのタイトル
テストネット
金継ぎに続き、最近ではKilnテストネットも立ち上げられました。 Kiln は、Kintsugi テストネットで見つかった重要性に基づいて、マージ仕様にいくつかの変更を追加し、名前を変更しました。マージされた仕様は現在ほぼ最終版に見えていますが、Kiln での実行への移行により、さまざまなクライアントで実装上の問題が発生しています。チームは現在、すべての実装が安全で安定していることを確認するためにテストを強化しています。ダニーは、最新の Finalized アップデートでこれについて話しました。
すべてのアップグレードと同様に、アップグレード後のテストネットを監視して、テストネットが安定していることを確認します。テストネットが意図したとおりに機能していると確信できたら、イーサリアム メインネットへの移行を計画します。
私たちは合併に非常に近づいており、コミュニティ全体にとって非常に興奮している時期ではありますが、移行が安全に行われるという事実はどの目標日よりも重要であり、合併の最優先事項です。これは、イーサリアムが行ったアップグレードの中で最も複雑です。私たちは間違いを犯したくないのです。
決定されたら、テストネットとメインネットのアップグレード タイムラインは、「今週のイーサリアム」、「Eth2 の新着情報」、「イーサリアム財団ブログ (EF ブログ)」などのさまざまなコミュニティ チャネルで発表されます。現時点で目標日を設定するという主張は誤りです。なぜなら、その日をまだ設定していないからです。今後数か月間、詐欺や虚偽の発表が行われる可能性があるので、特に注意してください。
副題
難易度ボムについて
ディフィシティボムは昨年のアロー氷河アップグレードで遅れており、その影響は今年 6 月にネットワークに現れると予想されます。この投稿ではその進捗状況を追跡しています。難易度ボムを延期する必要がある前に PoS 移行を行うことが最善ですが、注目に値することが 3 つあります。
1. 爆弾のブロック時間への影響は段階的です。これは、それが感じられ始めると、ブロックの生成が遅くなる期間が 4 ～ 8 週間あることを意味しますが、劇的には遅くなりません (おそらく 14 ～ 17 秒)。
3. 同様に、安全なマージ >>> 高速マージ。私たちは移行がスムーズに進むことを願っており、イーサリアムの安定性とセキュリティが私たちの最大の関心事です。
上海アップグレード
前回の更新で述べたように、統合された仕様がほぼ凍結されたため、上海のアップグレードの計画を開始しました。アップグレードの仕様は次のとおりです。このアップグレードには暫定的に 3 つの大きな変更と、いくつかの小さな変更があります。以下、一つずつ徹底解説！
副題
EVMオブジェクト形式
ロンドンのアップグレードでは、0xEF バイトで始まる新しいコントラクトの展開を拒否することで、識別子のこの部分を保持します。 London アップグレードがアクティブ化される前は、このバイトで始まるいくつかのコントラクトがデプロイされていましたが、これはもう不可能です。プレフィックス 0xEF に 2 番目のバイト (マジック バイトと呼ばれます) を追加して、シーケンスが保証されないことを保証できます。あらゆる契約で使用できます。
EIP-3540 ではこれについて詳しく説明しており、このアプローチの最初の実際的な利点、つまりコードとデータの分離により、オンチェーン コード検証が容易になることを強調しています。また、新しいコントラクト コード パーツ タイプの導入への道も開かれ、アカウントの抽象化、EVM の制御フロー、EIP-3074 など、現在では複雑に見える機能の実装に役立ちます。
EIP-3670 は、展開時に EOF コントラクトのコード検証を導入する 3540 のコンパニオン EIP です。
副題
上海アップグレードのもう 1 つの大きな特徴は、ビーコン チェーン引き出しの有効化です。いくつかの提案の後、私たちはクライアント チームが満足する設計を考え出しました。 EIP-4895: 操作としてのビーコン チェーン プッシュの引き出し (システム操作としてのビーコン チェーン プッシュの引き出し)。
このメタ仕様は、運用プロセス全体の概要を示します。高いレベルでは、各スロット内で、ビーコン チェーンは特定の数の完全または部分的な引き出しを処理します。これらの出金は、金額、宛先アドレス、および各出金の一意のインデックスを含む領収書で追跡されます。これらの出金は、ブロックの作成および検証プロセスの一部として、今日のマイナーにプルーフ・オブ・ワークが配布されるのと同じ方法で、実行層に配布されます。
現在 consensus-specs リポジトリにあるコンセンサス レイヤーで行う必要がある複数の変更には追跡の問題があります。部分引き出しオプションにより、バリデーターは、オンチェーンでバリデーターとして必要な 32 ETH を維持し、報酬を獲得し続けながら、獲得した報酬を引き出すことができます。
L2料金の削減
上海のアップグレードに含めたい最後の大きなことは、2 階のコストを削減することです。レイヤ 2 はレイヤ 1 でトランザクション データ (および/またはプルーフ) を公開するため、エンドユーザーのトランザクション料金の大部分はレイヤ 1 のデータ ストレージから発生します。シャーディングは、第 2 レイヤーでデータを公開するより安価な代替手段を提供します。ただし、この提案は決着したように見えますが、完全なシャーディングの実装はまだ準備ができていません。
それまでのところ、これらのオーバーヘッドを削減するために現在 2 つのオプションが利用可能です。メインネット上の CALLDATA オーバーヘッドを削減すること、またはシャード BLOB トランザクション (シャード BLOB トランザクション) と呼ばれる新しいタイプのトランザクションをイーサリアム上に導入する「プロトシャーディング」実装です。 。
副題
L2 でのトランザクション手数料を削減する最も簡単な方法は、L1 でのデータ保存のオーバーヘッドを削減することです。 EIP-4488 では、CALLDATA のオーバーヘッドを 1 バイトあたり 16 ガスから 3 ガスに下げることを提案しています。ストレージのオーバーヘッドの削減により、レイヤー 2 の料金が下がります [1]。
ガスのオーバーヘッドを減らすこと自体は単純な変更ですが、いくつかの副次的な効果があります。まず、ブロック内の CALLDATA を増やすと、ブロック サイズが大きくなります。これのバランスをとるために、この EIP は、ブロック内の CALLDATA の最大数に上限を設ける必要があることを提案しています。第 2 に、この上限があっても、この EIP は実行層上の履歴チェーン データの増加速度を加速します。この問題を解決するには、帯域外のデータ取得を開発する必要があり、EIP-4444 で提案されているように、イーサリアム P2P ネットワーク内の履歴データ ストレージの保証を変更する必要があります [1]。
履歴チェーン データの追加は段階的に行われるはずですが、この EIP が含まれるということは、展開後、この問題にさらに緊急に対処する必要があることを意味します。さらに、この EIP には基本的に、完全なシャードで再利用できるものは何もありません。それはほとんどが一時的な解決策です。とはいえ、この EIP は比較的単純な実装変更であり、L2 コストを大幅に削減します。
副題
シャード BLOB トランザクション
もう 1 つの提案は EIP-4844 [2] で、これにより完全なシャーディング展開に近づくことができます。ビーコンチェーンの撤回と同様に、この提案にもコンセンサス層の仕様やその他のリソースにリンクするメタ仕様が含まれています。
大まかに言えば、この新しいトランザクション タイプには、ビーコン チェーン上でブロードキャストされるデータ BLOB へのコミットメントが含まれます。この提案は、データの可用性に依存しない「ミニシャーディング」の提案と考えることができ、ネットワークの各ノードは BLOB 内のデータを検証する必要があります。フル シャーディングと同様、これらのデータ BLOB はネットワーク上で一定期間のみ利用できることが保証されており、永久に保存されるわけではありません。ノード要件を管理しやすくするために、BLOB データはフル シャードの場合は 16 MB/スロットではなく 1 MB/スロットに制限されます。
この EIP に取り組んでいる Optimism チームは、この EIP の概要を提供し、さまざまな正規リンクを集約し、この EIP に対するコミュニティの肯定的な反応を示す Web サイトを立ち上げました。
[1] L2 トランザクションの価格設定には他のコンポーネントが関係するため、この削減は完全な 5 倍にはなりません。この Optimisim の記事には、L2 料金の構成要素が詳しく説明されています。さらに、ZK ロールアップは、オプティミスティック ロールアップのようなこの EIP の恩恵を受けません。
[2] EIP-4488 (CALLDATA オーバーヘッドの削減) と EIP-4844 (シャード BLOB トランザクション) は競合する提案であり、それらの EIP 番号は非常に似ています。
副題
マイナーな改善
これら 3 つの大きな変更に加えて、Shanghai Upgrade ではいくつかの小さな改善も検討しています。
EIP-3651 は、COINBASE アドレスにアクセスするためのガス オーバーヘッドを削減することを提案し、EIP-2929 の過失を修正します。
EIP-3855 は、EVM スタックに 0 をプッシュする新しいオペコード PUSH0 を提案しています。
さらに、アップグレードが提案されている他の EIP もいくつかあります (この大まかなリストを参照してください)。 EOF、出金、Tier 2 手数料の引き下げにより、上海はこれまでで最大のアップグレードの 1 つとなっているため、何を含めるかを慎重に優先順位を付ける必要があります。
さまざまな EIP の実装とテストを開始すると、他の提案を実装するための追加機能があるかどうかがより明確になります。もちろん、最初にマージを完了する必要があります。
最初のレベルのタイトル
イーサリアム実行層仕様 (EELS)
お気づきかもしれませんが、上海のいくつかの提案は現在、執行層とコンセンサス層の両方にまたがっています。以前は、異なるレイヤーで異なる手順を使用して変更を導入していました。
エグゼクティブ レベルでは、コア EIP に変更された仕様が含まれています。 「イーサリアム イエロー ペーパー」はネットワークの参照仕様ですが、イエロー ペーパーはアップグレードの展開後に更新されることが多く、場合によっては大幅に遅れる場合があります。これは、実行層の有効な仕様が「イエローブック + EIP X、Y、Z」であることが多いことを意味します。
したがって、コミュニティは実行レベルのフローをよく理解しています (また、参照しやすい変更の説明を提供しています) が、技術的な観点から見ると理想的ではありません。逆に、コンセンサス層のプロセスは技術的にはより簡潔ですが、より広範なコミュニティにとっては理解が困難です。幸いなことに、EELS: イーサリアム実行層の実行可能仕様に関する作業はすでに開始されています。
実行層とコンセンサス層の両方に強制力のある仕様を持たせることで、2 つの層の間で変更プロセスを調整できるようになります。解決すべき問題はまだたくさんありますが、最適な移行方法についての議論は始まっています。 Ethereum Magicians フォーラムでのディスカッションは、このトピックに特化しています。 EELS はまだ開発中ですが、現在のプロセスと並行して上海アップグレードで使用できる可能性があります。
実行プロセスとコンセンサスプロセスのマージが、実際の実行プロセスとコンセンサスプロセスのマージよりも簡単になることを願っています。
最初のレベルのタイトル
プロトコルギルド
最後になりましたが、重要なこととして、プロトコル ギルド (PG) についてお話したいと思います。PG については、完全に説明された Web サイトが開設されました。プロトコル管理者への報酬が最近話題になっており、PG はこの問題の解決に関与したいと考えています。完全開示: 私は PG メンバーであり、PG から資金を受け取る予定です。
報酬には、基本給、インセンティブ、潜在的なアップサイドの 3 つのカテゴリがあると考えることができます。現在、クライアントの開発者と研究者の基本給は、それぞれの雇用主によって決定されます。それらの中には株式の形でインセンティブを提供するものもありますが、イーサリアム財団は昨年、すべてのクライアントチームがイーサリアムに多額の株式を保有することを保証するために、39,000 ETH のクライアントインセンティブ計画を発表しました。
簡単に言うと、ギルドではスポンサーがトークンを寄付することができ、トークンは時間をかけて受取人に与えられます。レシーバー セットは更新可能であるため、新しい投稿者を定期的に追加したり、飽きた投稿者を定期的に削除したりできます。
このギルドは初期の実験だが、成功すれば、Gitcoinや遡及的な公共財への資金提供など、基礎に焦点を当てた取り組みを補完するものになる可能性がある。
Gitcoin 助成金の成功後、PG の次のステップはスマート コントラクト アーキテクチャをテストすることです。同時に、最初のドナーの探索も始まります。私たちの計画は、技術面とガバナンス面の両方がスムーズに進むように、限られた寄付で 1 年間 PG を運営することです。このパイロットによって、公共財とお金を調整するための新しいメカニズムをイーサリアム上に作成できることが証明されることを願っています。
フォローアップ
