著者: クリスティーン・キム / 出典:翻訳: Huohuo/現地語でのブロックチェーン8 月 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は今回のEthereum実行層のアップグレードの名前で、Denebはプロトコル層のアップグレードの名前です。したがって、カンクンのアップグレードは、 Deneb アップグレードは総称して Dencun アップグレードと呼ばれます。)4) セポリア: 最後に、デンクンはセポリアに配備され、良い結果を達成しました。Devnet #9 の後にテストネットをリリースするという Beiko の提案には誰も反対しませんでした。 Beiko氏は、Holeskyテストネットが9月15日に正式に開始されたら、上記のタイムラインがより広範なイーサリアムコミュニティとブログ投稿で共有されるだろうと述べた。さらに、Beiko氏は、Ephemeryと呼ばれるテストネットも開発中であると述べた。 Ehemery は、1 ～ 2 週間後に初期状態にリセットされる検証ノード オペレーター向けの Ethereum テストネットです。 Ephemery Network の詳細については、ここでプロジェクトの 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 日など) アクセスしなかったイーサリアム状態の部分を削除し、それによって状態サイズを 100 GB 以上から 50 GB 未満に減らすことです。 Erigon (EL) Account Team の 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 への移行の複雑さがどのように大幅に軽減されるかについて説明しました。ただし、状態の有効期限には、毎年新しい「アドレス期間」をサポートするためにアドレス空間を追加する必要があるなど、複雑な前提条件があるとも述べました。また、Verkle Trys が State Expiry 前に実装された場合、State Expiry の緊急性は低くなるため、開発者は移行に Verkle を使用することを検討するか、Verkle の後に State Expiry を導入するまで数年待つ必要があります。 2 つのアップグレードをバンドルすることの付加価値を評価し、Discord と Verkle Trie 実装者向けの呼びかけでこのトピックについて非同期的に議論し続けることに同意しました。### 3. SSZ のシリアル化次に、Nimbus (CL) クライアントの開発者である Etan Kissling が、イーサリアム データ構造を SSZ シリアル化形式にアップグレードする進捗状況に関する最新情報を発表しました。この問題の詳細な背景については、ここで以前の Ethereum 開発者との通話の記録をお読みください。 Kissling 氏は、SSZ「PartialContainer」ベースの形式を使用してイーサリアム データのシリアル化を更新する新しいアプローチを強調しました。今週の電話会議の議題のコメントの中でキスリング氏は、「この[形式]は基本的に[以前の形式]のすべての利点を組み合わせており、他の目的にも再利用できるため、現在使用されていないSSZ UnionとSSZのオプションタイプは段階的に廃止されます。」 " (翻訳者注: シンプル シリアル化 (SSZ) は、ビーコン チェーンで使用されるシリアル化方法です。この方法は、ピア検出プロトコルを除くコンセンサス層のあらゆる場所で使用される実装層を置き換えます。再帰的な長さプレフィックスのシリアル化。シンプルなシリアル化の設計は決定的であり、効率的にマークル化することもできます。)更新後、Beiko は Python で新しく作成された EL リファレンス実装 (EELS と呼ばれます) をすぐに賞賛しました。最近のイーサリアム財団のブログ投稿で、EIP 編集者兼イーサリアム財団研究者のサム・ウィルソン氏は次のように書いています。「EELS は、読みやすさと明瞭さに重点を置いた、イーサリアム実行クライアントのコア コンポーネントの Python リファレンス実装です。EELS は精神的な後継者になることを目指しています」イエロー ペーパーに準拠しており、よりプログラマーにとって使いやすく、マージ後のフォークと同期しているため、EELS は状態テストを入力して実行でき、メインネットに準拠しており、新しい EIP のプロトタイプを作成するのに最適な場所です。」一部の開発者はすでに EELS を使用して EIP を再実装しており、イーサリアム財団は、EELS を補完するためにロンドンやパリなど、不足しているマージ前のネットワーク アップグレードを含めてイエロー ペーパーを更新することに関心のある人に助成金を提供しています。
第 116 回イーサリアム コア開発者エグゼクティブ ミーティングの概要: カンクン アップグレード、Verkle Trie Conversion、および SSZ シリアル化
著者: クリスティーン・キム / 出典:
翻訳: Huohuo/現地語でのブロックチェーン
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は今回のEthereum実行層のアップグレードの名前で、Denebはプロトコル層のアップグレードの名前です。したがって、カンクンのアップグレードは、 Deneb アップグレードは総称して Dencun アップグレードと呼ばれます。)
セポリア: 最後に、デンクンはセポリアに配備され、良い結果を達成しました。
Devnet #9 の後にテストネットをリリースするという Beiko の提案には誰も反対しませんでした。 Beiko氏は、Holeskyテストネットが9月15日に正式に開始されたら、上記のタイムラインがより広範なイーサリアムコミュニティとブログ投稿で共有されるだろうと述べた。さらに、Beiko氏は、Ephemeryと呼ばれるテストネットも開発中であると述べた。 Ehemery は、1 ～ 2 週間後に初期状態にリセットされる検証ノード オペレーター向けの Ethereum テストネットです。 Ephemery Network の詳細については、ここでプロジェクトの 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 日など) アクセスしなかったイーサリアム状態の部分を削除し、それによって状態サイズを 100 GB 以上から 50 GB 未満に減らすことです。 Erigon (EL) Account Team の 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 への移行の複雑さがどのように大幅に軽減されるかについて説明しました。ただし、状態の有効期限には、毎年新しい「アドレス期間」をサポートするためにアドレス空間を追加する必要があるなど、複雑な前提条件があるとも述べました。また、Verkle Trys が State Expiry 前に実装された場合、State Expiry の緊急性は低くなるため、開発者は移行に Verkle を使用することを検討するか、Verkle の後に State Expiry を導入するまで数年待つ必要があります。 2 つのアップグレードをバンドルすることの付加価値を評価し、Discord と Verkle Trie 実装者向けの呼びかけでこのトピックについて非同期的に議論し続けることに同意しました。
3. SSZ のシリアル化
次に、Nimbus (CL) クライアントの開発者である Etan Kissling が、イーサリアム データ構造を SSZ シリアル化形式にアップグレードする進捗状況に関する最新情報を発表しました。この問題の詳細な背景については、ここで以前の Ethereum 開発者との通話の記録をお読みください。 Kissling 氏は、SSZ「PartialContainer」ベースの形式を使用してイーサリアム データのシリアル化を更新する新しいアプローチを強調しました。今週の電話会議の議題のコメントの中でキスリング氏は、「この[形式]は基本的に[以前の形式]のすべての利点を組み合わせており、他の目的にも再利用できるため、現在使用されていないSSZ UnionとSSZのオプションタイプは段階的に廃止されます。」 " (翻訳者注: シンプル シリアル化 (SSZ) は、ビーコン チェーンで使用されるシリアル化方法です。この方法は、ピア検出プロトコルを除くコンセンサス層のあらゆる場所で使用される実装層を置き換えます。再帰的な長さプレフィックスのシリアル化。シンプルなシリアル化の設計は決定的であり、効率的にマークル化することもできます。)
更新後、Beiko は Python で新しく作成された EL リファレンス実装 (EELS と呼ばれます) をすぐに賞賛しました。最近のイーサリアム財団のブログ投稿で、EIP 編集者兼イーサリアム財団研究者のサム・ウィルソン氏は次のように書いています。「EELS は、読みやすさと明瞭さに重点を置いた、イーサリアム実行クライアントのコア コンポーネントの Python リファレンス実装です。EELS は精神的な後継者になることを目指しています」イエロー ペーパーに準拠しており、よりプログラマーにとって使いやすく、マージ後のフォークと同期しているため、EELS は状態テストを入力して実行でき、メインネットに準拠しており、新しい EIP のプロトタイプを作成するのに最適な場所です。」
一部の開発者はすでに EELS を使用して EIP を再実装しており、イーサリアム財団は、EELS を補完するためにロンドンやパリなど、不足しているマージ前のネットワーク アップグレードを含めてイエロー ペーパーを更新することに関心のある人に助成金を提供しています。