著者: Christine Kim、galaxy、翻訳: Huohuo/Vernacular Blockchain8 月 31 日、イーサリアム開発者はコア開発者ユーション (ACDE) の電話会議のために Zoom に集まりました。イーサリアム財団のティム・ベイコ氏が主催する ACDE コールは、イーサリアム クライアント チームがイーサリアム実行層 (EL) への変更について話し合い、調整する隔週の一連の会議です。今週、開発者たちは次の点について開発とテストの進捗状況について話し合いました。1) カンクン/デネブ (デンクン) のアップグレード2) バークルトライ変換3) SSZ シリアル化の更新## 1. カンクンのアップグレードDevnet #8 は 2 週間前の 8 月 16 日にローンチされました。イーサリアム財団の DevOps エンジニアである Barnabas Busa 氏は、開発者に焦点を当てたカンクンのアップグレード テストネットはうまく機能しているようだと語った。 Busa 氏は、Nethermind (EL) クライアント ソフトウェアを実行しているノードにいくつかの問題があるようだと述べました。 Nethermind クライアントの開発者である Lukasz Rozmej 氏は、問題の性質は Blob トランザクション プール実装の構成ミスによるものであると説明しました。 **(翻訳者注: Devnet 8 は最初の専用テスト ネットワークであり、カンクン/デネブ アップグレードの最終的な EIP がすべて含まれています)**EIP 4788**** に関して、開発者はコード変更に対する新しい展開戦略を簡単に再確認しました**。 EL 上のビーコン チェーン データを公開するコントラクトは、通常のスマート コントラクトと同様に展開され、アップグレードが有効になる前に誰かがコントラクト アドレスに資金を提供する必要があります。カンクン アップグレードの次のテストネットである Devnet #9 は、このワークフローを採用し、開発者が確実にそれに慣れるようにします。**開発者は、Devnet #9 のリリース日を遅らせる代わりに、クライアント実装に関するすべての問題が解決されるまで Devnet #8 でのテストを続けることに同意しました**。 「私は、これらのことを機能させたいと言うよりも、Devnet #9 を信頼したいと思っています。...むしろ、私たちが知っている問題を修正したいと思っています。そうでない場合、Devnet #9 に難しい問題がある場合は、間違いなく解決します」 「また Devnet #10 を使用します。Devnet #10 を使用すべきではないと言っているわけではありません。意味のある数の Devnet を持つ必要があります。これで、Devnet #9 を本当に信頼できるものにすることができると思います。」と Ether 氏 (フェローの Danny Ryan 氏) は述べています。ファン財団で、ACDC カンファレンスコールの議長を務めました。**Tim Beiko、Marius Van Der Wijden、Justin Florentine を含む他の参加者は、Devnet #8 のテストにより多くの時間を費やし、その後 Devnet #9 で EIP 4788 の変更をテストすることに賛成でした。* * Beiko 氏は、次回の ACDE 電話会議中に開発者が Devnet #9 のために再集結することを提案しました。テストネットの展開戦略に関して、Beiko は次の順序を推奨します。1) Devnet #9: Dencun 仕様が凍結された別の Devnet。ネットワークにストレス テストを行い、開発者がそれに満足していると仮定してから、パブリック テストネットに移行します。それ以外の場合は、Devnet #10 を開始します。2) Holesky: 新しく起動された Holeksy テストネットをフォークし、Dencun アップグレードをその上にデプロイします。3) Goerli: 次に、Dencun を Goerli に配置します。メインネットの前に最後から 2 番目のテストネットが開始されるため、現時点でのアップグレード仕様は最終的なものであり、メインネットのアップグレードがアクティブになる前にユーザーとアプリケーションがソフトウェアをテストするのに十分な時間を提供する必要があります。 Dencun は、Goerli が廃止され、Holesky に置き換えられる前の、Goerli の最後のフォークとなる可能性があります。 **(訳者注: Dencun という言葉は、Cancun (カンクン) と Deneb からなる合成語です。Cancun はイーサリアム実行層のアップグレードの名前であり、Deneb はプロトコル層のアップグレードの名前です。したがって、Cancun upgrade Together はDeneb アップグレードと合わせて、Dencun アップグレードと呼ばれます。)**4) セポリア: 最後に、デンクンはセポリアに配備され、良い結果を達成しました。Devnet #9 の後にテストネットをリリースするという Beiko の提案に反対する人は誰もいませんでした。 Beiko氏は、Holeskyテストネットが9月15日に正式に開始されたら、前述のタイムラインがより広範なイーサリアムコミュニティとブログ投稿で共有されるだろうと述べた。さらに、Beiko氏は、Ephemeryと呼ばれるテストネットも開発中であると述べた。 Ehemery は、1 ～ 2 週間後に初期状態にリセットされるバリデーターオペレーター用の Ethereum テストネットです。 Ephemery ネットワークの詳細については、ここでプロジェクトの GitHub ページを参照してください。Verkle Tries の議論に移る前に、Busa 氏は、Holesky テストネットの GitHub 上のオープンなプル リクエスト (PR) を強調しました。 Erigon (EL) チームの要請により、PR は、Holesky での Dencun アップグレードの特定のアクティベーション時間を削除することを提案しています。開発者は、既存の値を上書きするのではなく、Holesky で Dencun アクティベーションの値を後で設定します。 Busa はまた、2/4 制限の代わりに 3/6 ブロブ ターゲット/最大値をテストすることについても質問しました。 ** このトピックについて、ベイコ氏は来週の ACDC の電話会議でこの件を再度取り上げることを提案し、そこでライアン氏は、大きなブロック サイズを使用した最近の実験が新たな洞察をもたらすだろうと述べました。 **## 2. バークルトライ変換次に、開発者らは、Verkle Trie と State Expiry のロードマップを組み合わせて Verkle Trie の実装の複雑さを軽減し、イーサリアム上での State Expiry のメリットを加速するという Vitalik Buterin の提案について議論しました。背景として、Verkle Trie または Verkle Tree は、ユーザーが単一の暗号証明に基づいて大量のデータを簡単に検証できるようにするデータ構造です。 **これらは、イーサリアムの状態を保存するために使用されるデータ構造であるマークル パトリシア トライ (MPT) と何ら変わりません。ただし、Verkle ツリーの証明効率は MPT よりも比較的高いため、開発者は MPT を Verkle に移行することに取り組んでいます。**状態の有効期限は、無制限の状態の増加の問題に対処するために設計された別の取り組みです。 **状態の有効期限の目標は、ユーザーが一定期間 (365 日など) アクセスしなかった Ethereum 状態の部分を削除することで、状態のサイズを 100 GB 以上から 50 GB 未満に減らすことです。 Erigon (EL) アカウント チームの Andrew Ashkhmin 氏は、State Expiry と組み合わせると Verkle Trie の変換が大幅に簡素化されると仮定して、2 つのアップグレードをバンドルすることを支持しました。 Verkle Trie プロジェクトの先頭に立ってきた Geth (EL) クライアント チームの Guillaume Ballet 氏は、研究テーマが過去 2 年間「放棄」されてきたため、国家の有効期限が切れて以来、カップリングにより Verkle Trie が遅れるのではないかと懸念しています。ブテリン氏は、提案の動機についてさらに背景を付け加え、次のように述べた。 [Verkle] 移行プロセス、問題は基本的に 50 GB 以上の Merkle Patricia Trie を…ライブ ネットワークでの Verkle Trie に変換することですが、非常に複雑です。これは実際、研究チームが1年以上にわたって取り組んできたことです。昨年の Devconnect でのことは、基本的に研究イベントの主題であり、基本的には Verkle ロードマップの残りの部分全体と同じくらい多くの研究開発作業が行われ、最後の移行をどのように行うかというプロセスに過ぎなかったのを覚えています。ある意味では、その複雑さは確かに合併の複雑さに匹敵します。 」**Buterin 氏は続けて、State Expiry によって Verkle への移行の複雑さがどのように大幅に軽減されるかについて説明します。ただし、州の有効期限には、1 年あたりの新しい「アドレス期間」**** をサポートするためにアドレス空間を追加する必要があるなど、複雑な前提条件があるとも述べています。** したがって、Verkle の実装はそれほど複雑ではありませんが、開発者は両方を実現するにはまだ難しい問題を解決する必要があります。また、Verkle Trys が State Expiry 前に実装された場合、State Expiry の緊急性は低くなるため、開発者は移行に Verkle の使用を検討するか、State Expiry が導入されるまで数年待つ必要があります。開発者は 2 つのアップグレードをバンドルすることの付加価値を認識しておらず、Discord と Verkle Trie 実装者向けの呼びかけで非同期にこのトピックについて議論し続けることに同意しました。## 3. SSZ シリアル化次に、Nimbus (CL) クライアントの開発者である Etan Kissling が、イーサリアム データ構造を SSZ シリアル化形式にアップグレードする進捗状況に関する最新情報を発表しました。この問題の詳細な背景については、ここで以前の Ethereum 開発者との通話の記録をお読みください。 **Kissling 氏は、SSZ「PartialContainer」ベースの形式を使用してイーサリアム データのシリアル化を更新する新しいアプローチを強調しました。 **Kissling 氏は今週の電話会議の議題のコメントに次のように書いています** 「この [形式] は基本的に [以前の形式] のすべての利点を組み合わせており、他の目的にも再利用でき、現在使用されていない SSZ Union と SSZ のオプション タイプを排除します。 ."** (翻訳者注: シンプル シリアル化 (SSZ) は、ビーコン チェーンで使用されるシリアル化メソッドです。このメソッドは、ピア検出プロトコルを除くコンセンサス層のすべての側面を置き換えます。実行層で使用される再帰的な長さプレフィックス シリアル化。シンプルなシリアル化設計により決定的であり、効果的にマークル化することもできます。)更新後、Beiko は Python で新しく作成された EL リファレンス実装 (EELS と呼ばれます) をすぐに賞賛しました。最近のイーサリアム財団のブログ投稿で、EIP 編集者兼イーサリアム財団研究者のサム・ウィルソン氏は次のように書いています。「EELS はイーサリアム実行クライアントのコア コンポーネントの Python リファレンス実装であり、読みやすさと明瞭さに重点を置いています。EELS は、EELS の精神的な後継者となるように設計されています。」イエロー ペーパーは、よりプログラマーにとって使いやすく、マージ後のフォークと同期しているため、EELS はステートフル テストを記入して実行でき、メインネットに準拠しており、新しい EIP のプロトタイプを作成するのに最適な場所です。」一部の開発者はすでに EELS を使用して EIP を再実装しており、イーサリアム財団は、EELS を補完するためにロンドンやパリなど、欠落しているマージ前のネットワーク アップグレードを含めてイエロー ペーパーを更新することに関心のある人に助成金を提供しています。
イーサリアムの最新のコア開発者幹部会議の概要
著者: Christine Kim、galaxy、翻訳: Huohuo/Vernacular Blockchain
8 月 31 日、イーサリアム開発者はコア開発者ユーション (ACDE) の電話会議のために Zoom に集まりました。イーサリアム財団のティム・ベイコ氏が主催する ACDE コールは、イーサリアム クライアント チームがイーサリアム実行層 (EL) への変更について話し合い、調整する隔週の一連の会議です。今週、開発者たちは次の点について開発とテストの進捗状況について話し合いました。
カンクン/デネブ (デンクン) のアップグレード
バークルトライ変換
SSZ シリアル化の更新
1. カンクンのアップグレード
Devnet #8 は 2 週間前の 8 月 16 日にローンチされました。イーサリアム財団の DevOps エンジニアである Barnabas Busa 氏は、開発者に焦点を当てたカンクンのアップグレード テストネットはうまく機能しているようだと語った。 Busa 氏は、Nethermind (EL) クライアント ソフトウェアを実行しているノードにいくつかの問題があるようだと述べました。 Nethermind クライアントの開発者である Lukasz Rozmej 氏は、問題の性質は Blob トランザクション プール実装の構成ミスによるものであると説明しました。 **(翻訳者注: Devnet 8 は最初の専用テスト ネットワークであり、カンクン/デネブ アップグレードの最終的な EIP がすべて含まれています)
EIP 4788** に関して、開発者はコード変更に対する新しい展開戦略を簡単に再確認しました**。 EL 上のビーコン チェーン データを公開するコントラクトは、通常のスマート コントラクトと同様に展開され、アップグレードが有効になる前に誰かがコントラクト アドレスに資金を提供する必要があります。カンクン アップグレードの次のテストネットである Devnet #9 は、このワークフローを採用し、開発者が確実にそれに慣れるようにします。
開発者は、Devnet #9 のリリース日を遅らせる代わりに、クライアント実装に関するすべての問題が解決されるまで Devnet #8 でのテストを続けることに同意しました。 「私は、これらのことを機能させたいと言うよりも、Devnet #9 を信頼したいと思っています。...むしろ、私たちが知っている問題を修正したいと思っています。そうでない場合、Devnet #9 に難しい問題がある場合は、間違いなく解決します」 「また Devnet #10 を使用します。Devnet #10 を使用すべきではないと言っているわけではありません。意味のある数の Devnet を持つ必要があります。これで、Devnet #9 を本当に信頼できるものにすることができると思います。」と Ether 氏 (フェローの Danny Ryan 氏) は述べています。ファン財団で、ACDC カンファレンスコールの議長を務めました。
*Tim Beiko、Marius Van Der Wijden、Justin Florentine を含む他の参加者は、Devnet #8 のテストにより多くの時間を費やし、その後 Devnet #9 で EIP 4788 の変更をテストすることに賛成でした。 * Beiko 氏は、次回の ACDE 電話会議中に開発者が Devnet #9 のために再集結することを提案しました。テストネットの展開戦略に関して、Beiko は次の順序を推奨します。
Devnet #9: Dencun 仕様が凍結された別の Devnet。ネットワークにストレス テストを行い、開発者がそれに満足していると仮定してから、パブリック テストネットに移行します。それ以外の場合は、Devnet #10 を開始します。
Holesky: 新しく起動された Holeksy テストネットをフォークし、Dencun アップグレードをその上にデプロイします。
Goerli: 次に、Dencun を Goerli に配置します。メインネットの前に最後から 2 番目のテストネットが開始されるため、現時点でのアップグレード仕様は最終的なものであり、メインネットのアップグレードがアクティブになる前にユーザーとアプリケーションがソフトウェアをテストするのに十分な時間を提供する必要があります。 Dencun は、Goerli が廃止され、Holesky に置き換えられる前の、Goerli の最後のフォークとなる可能性があります。 (訳者注: Dencun という言葉は、Cancun (カンクン) と Deneb からなる合成語です。Cancun はイーサリアム実行層のアップグレードの名前であり、Deneb はプロトコル層のアップグレードの名前です。したがって、Cancun upgrade Together はDeneb アップグレードと合わせて、Dencun アップグレードと呼ばれます。)
セポリア: 最後に、デンクンはセポリアに配備され、良い結果を達成しました。
Devnet #9 の後にテストネットをリリースするという Beiko の提案に反対する人は誰もいませんでした。 Beiko氏は、Holeskyテストネットが9月15日に正式に開始されたら、前述のタイムラインがより広範なイーサリアムコミュニティとブログ投稿で共有されるだろうと述べた。さらに、Beiko氏は、Ephemeryと呼ばれるテストネットも開発中であると述べた。 Ehemery は、1 ～ 2 週間後に初期状態にリセットされるバリデーターオペレーター用の Ethereum テストネットです。 Ephemery ネットワークの詳細については、ここでプロジェクトの GitHub ページを参照してください。
Verkle Tries の議論に移る前に、Busa 氏は、Holesky テストネットの GitHub 上のオープンなプル リクエスト (PR) を強調しました。 Erigon (EL) チームの要請により、PR は、Holesky での Dencun アップグレードの特定のアクティベーション時間を削除することを提案しています。開発者は、既存の値を上書きするのではなく、Holesky で Dencun アクティベーションの値を後で設定します。 Busa はまた、2/4 制限の代わりに 3/6 ブロブ ターゲット/最大値をテストすることについても質問しました。 ** このトピックについて、ベイコ氏は来週の ACDC の電話会議でこの件を再度取り上げることを提案し、そこでライアン氏は、大きなブロック サイズを使用した最近の実験が新たな洞察をもたらすだろうと述べました。 **
2. バークルトライ変換
次に、開発者らは、Verkle Trie と State Expiry のロードマップを組み合わせて Verkle Trie の実装の複雑さを軽減し、イーサリアム上での State Expiry のメリットを加速するという Vitalik Buterin の提案について議論しました。背景として、Verkle Trie または Verkle Tree は、ユーザーが単一の暗号証明に基づいて大量のデータを簡単に検証できるようにするデータ構造です。 **これらは、イーサリアムの状態を保存するために使用されるデータ構造であるマークル パトリシア トライ (MPT) と何ら変わりません。ただし、Verkle ツリーの証明効率は MPT よりも比較的高いため、開発者は MPT を Verkle に移行することに取り組んでいます。
**状態の有効期限は、無制限の状態の増加の問題に対処するために設計された別の取り組みです。 **状態の有効期限の目標は、ユーザーが一定期間 (365 日など) アクセスしなかった Ethereum 状態の部分を削除することで、状態のサイズを 100 GB 以上から 50 GB 未満に減らすことです。 Erigon (EL) アカウント チームの Andrew Ashkhmin 氏は、State Expiry と組み合わせると Verkle Trie の変換が大幅に簡素化されると仮定して、2 つのアップグレードをバンドルすることを支持しました。 Verkle Trie プロジェクトの先頭に立ってきた Geth (EL) クライアント チームの Guillaume Ballet 氏は、研究テーマが過去 2 年間「放棄」されてきたため、国家の有効期限が切れて以来、カップリングにより Verkle Trie が遅れるのではないかと懸念しています。
ブテリン氏は、提案の動機についてさらに背景を付け加え、次のように述べた。 [Verkle] 移行プロセス、問題は基本的に 50 GB 以上の Merkle Patricia Trie を…ライブ ネットワークでの Verkle Trie に変換することですが、非常に複雑です。これは実際、研究チームが1年以上にわたって取り組んできたことです。昨年の Devconnect でのことは、基本的に研究イベントの主題であり、基本的には Verkle ロードマップの残りの部分全体と同じくらい多くの研究開発作業が行われ、最後の移行をどのように行うかというプロセスに過ぎなかったのを覚えています。ある意味では、その複雑さは確かに合併の複雑さに匹敵します。 」
Buterin 氏は続けて、State Expiry によって Verkle への移行の複雑さがどのように大幅に軽減されるかについて説明します。ただし、州の有効期限には、1 年あたりの新しい「アドレス期間」** をサポートするためにアドレス空間を追加する必要があるなど、複雑な前提条件があるとも述べています。** したがって、Verkle の実装はそれほど複雑ではありませんが、開発者は両方を実現するにはまだ難しい問題を解決する必要があります。また、Verkle Trys が State Expiry 前に実装された場合、State Expiry の緊急性は低くなるため、開発者は移行に Verkle の使用を検討するか、State Expiry が導入されるまで数年待つ必要があります。開発者は 2 つのアップグレードをバンドルすることの付加価値を認識しておらず、Discord と Verkle Trie 実装者向けの呼びかけで非同期にこのトピックについて議論し続けることに同意しました。
3. SSZ シリアル化
次に、Nimbus (CL) クライアントの開発者である Etan Kissling が、イーサリアム データ構造を SSZ シリアル化形式にアップグレードする進捗状況に関する最新情報を発表しました。この問題の詳細な背景については、ここで以前の Ethereum 開発者との通話の記録をお読みください。 Kissling 氏は、SSZ「PartialContainer」ベースの形式を使用してイーサリアム データのシリアル化を更新する新しいアプローチを強調しました。 Kissling 氏は今週の電話会議の議題のコメントに次のように書いています 「この [形式] は基本的に [以前の形式] のすべての利点を組み合わせており、他の目的にも再利用でき、現在使用されていない SSZ Union と SSZ のオプション タイプを排除します。 ." (翻訳者注: シンプル シリアル化 (SSZ) は、ビーコン チェーンで使用されるシリアル化メソッドです。このメソッドは、ピア検出プロトコルを除くコンセンサス層のすべての側面を置き換えます。実行層で使用される再帰的な長さプレフィックス シリアル化。シンプルなシリアル化設計により決定的であり、効果的にマークル化することもできます。)
更新後、Beiko は Python で新しく作成された EL リファレンス実装 (EELS と呼ばれます) をすぐに賞賛しました。最近のイーサリアム財団のブログ投稿で、EIP 編集者兼イーサリアム財団研究者のサム・ウィルソン氏は次のように書いています。「EELS はイーサリアム実行クライアントのコア コンポーネントの Python リファレンス実装であり、読みやすさと明瞭さに重点を置いています。EELS は、EELS の精神的な後継者となるように設計されています。」イエロー ペーパーは、よりプログラマーにとって使いやすく、マージ後のフォークと同期しているため、EELS はステートフル テストを記入して実行でき、メインネットに準拠しており、新しい EIP のプロトタイプを作成するのに最適な場所です。」
一部の開発者はすでに EELS を使用して EIP を再実装しており、イーサリアム財団は、EELS を補完するためにロンドンやパリなど、欠落しているマージ前のネットワーク アップグレードを含めてイエロー ペーパーを更新することに関心のある人に助成金を提供しています。