著者: @TimBeiko 翻訳: Huohuo/Vernacular Blockchain別の @ethereum #AllCoreDevs ミーティングは 9 月 15 日に終了しました。開発ネットワークの更新、Dencun への追加、Reth の包括的な概要について議論されました。議題: ライブリンク:以下は @TimBeiko による会議の概要です。## 1. Devnet-8 ステータスの更新まず、devnet-8 のステータス更新です。ネットワークは最終開発中であり、多くのクライアントがすでに新しい更新をネットワークにプッシュしています。それまでの間、@KurtosisTech を使用して MEV/ブロック ビルド プロセスのテストを開始しました。 @NethermindEth は、BLOB トランザクション プールの準備が整い、単一ノードで数日間テストした後、それをすべての Dencun テスト ノードにデプロイしたと述べました。Geth の BLOB トランザクション プールもほぼ完成しました。 Besu は、トランザクション プール (BLOB トランザクションと非 BLOB トランザクションの合計サイズを制限する) を大幅に改善しており、次のリリースでリリースされる予定です。 Erigon はトランザクション プールの改善を続けており、devnet-9 に対応できるようにしたいと考えています。 Prysm はまた、BLOB サイドカーの受信には多少の遅延があることにも言及しており、通常、ブロブ サイドカーはブロックから約 500 ミリ秒遅れて到着すると言われています (ブロックの処理には約 15 ミリ秒かかります)。彼らはこの問題を調査し、BLOB とチャンクのインポート間の競合状態が原因であるかどうかを判断しています。ハード フォークの前にメモリ プールで BLOB トランザクションのサポートを許可するかどうかという問題に関しては、チームは満場一致で許可しないことに同意しました。##2、EIP-7514次に、バリデーターのアクティブ化キューに一定の上限を追加するかどうかについて、先週の ACDC コールからの議論を継続しました。この提案は正式に EIP-7514 として形成されました。つまり、最悪のシナリオでは、これによりETHステーキングの割合の増加が鈍化することになります。ダンクラッド氏は電話会議中にこの提案への支持を表明し、バリデーターの報酬に対して潜在的により複雑な変更を加える時間を稼ぐことになると述べた。すべての CL チームはこの変更に賛成ですが、これは入金キューにのみ適用され、出金キューには適用されないことに注意してください。さらに議論した結果、制限を 8 に設定することにしました。したがって、EIP-7514 は Dencun アップグレードの一部となります。今後数日以内に、この変更を反映するために EIP および関連する CL 仕様 PR が更新されることが予想されます。## 3. EVM と BLOB次に、別の暫定提案について議論しました。それは、Blob の基本料金を公開するために、イーサリアム仮想マシン (EVM) にオペコードを追加するというものです。この提案は、Arbitrum の @PlasmaPower0 によって提案されたもので、今週初めに R&D Discord で、これが彼ら (および他のレイヤー 2 ソリューション) にとって役立つだろうと述べました。 EIP-1559 には、BASEFEE を公開する同様のオペコードがすでにあります。これは、EIP のアクティブ化と同時に導入されました。これにより、レイヤー 2 ソリューションは、L1 データ コストに基づいてユーザーに請求するための正しいガス価格を決定することが容易になります。Optimism の @protolambda も会議に出席し、ブロック ヘッダー (BLOB 基本料金の計算に使用される値が含まれている) を確認できるため、L2 の BLOB 基本料金を取得する唯一の方法ではないと提案しました。それらの値に対してマークルを提供して証明します。それでも、彼はそれが素晴らしい機能であることに同意します。 Arbitrum は現在、ブロック ヘッダーの解析を実行していません。ブロック ヘッダーの形式が最終的に変更された場合に問題が発生する可能性があるため、これに依存すると不変のレイヤー 2 ソリューションでは問題が発生する可能性があります。EIP-4844 作成者の 1 人である @adietrichs は、(1 回限りのオペコードを追加するのではなく) ブロック ヘッダー情報にアクセスするためのより一般的な方法を開発したいという要望があったため、このオペコードは元の仕様には含まれていなかったと述べました。それでも、このより野心的な変更を採用することは、このオペコードを導入するよりも野心的な作業となるでしょう。このオペコードによって公開される情報は、EL クライアントが計算する必要がある情報であり、意味的には BASEFEE オペコードとほぼ同じです。クライアント チームは、BASEFEE との一貫性を保つためにのみ、このオペコードを追加する必要があることに満場一致で同意しました。将来的に「より巧妙な」メカニズムを思いついた場合、この新しいオペコードの冗長な機能は、ブロック ヘッダー情報を使用する他のオペコードにとっても問題になるでしょう。また、これは非常に小さな変更であることを強調する価値があります。EIP が存在する前に @vdWijden が Geth に実装しましたが、所要時間はわずか 20 分程度で、Reth チームは ACD コールの PR 中にそれに関する変更をコミットしました。##4、EIP-4788次に、イーサリアムメインチェーン上のコントラクトにビーコンルートを保存する提案である EIP-4788 のいくつかの更新について説明しました。過去数週間にわたり、私たちは契約の監査とファジーテストを複数回実施し、その結果、この PR に記載されているいくつかの小さな変更が行われました。すべての監査が完了したわけではなく、レポートもまだ出ていませんが、@lightclients がこれまでに検討されている変更の概要を説明しました。最初の変更は、0 のタイムスタンプを明示的に処理して、0 を返すのではなく (他の無効なタイムスタンプと同様に) ロールバックを引き起こすようにすることです。 2 番目の変更はバッファ サイズに関するものです。スロット時間が変更されると仮定すると、モジュラー演算の仕組みにより、元の契約ではストレージが無駄になります。## 5. ガスの最適化最後に、CALLDATA のロード回数を減らすガスの最適化があります。監査人はこれらの変更を検討し、次回の ACDE 会議までに最終報告書が作成される予定です。ファジングのテストと実装作業を進めるために、私たちは提案されている変更を今すぐマージすることに同意しました。@shemnon は、これらの変更を実際の EIP に文書化する必要があるとも述べました。私たちはそのことに取り組んでいます。次に、システム コントラクト アドレスが状態の一部であるが、実行終了時には空である場合に、クライアントがこれをどのように処理する必要があるかについて説明しました。 (私の理解によれば、実際にはこれがメインネットで起こる可能性は低いですが)、これはジェネシス ブロックにアドレスを設定することによるテスト中に発生したエッジ ケースです。これはかなり特殊な特殊なケースであり、明確な正規の動作がないことを考慮して、私たちはこの問題についてより多くの時間を費やして検討し、来週のテスト会議で議論を続けることに同意しました。仕様変更は以上です！上記はすべて devnet-9 に含まれる予定です。クライアント チームは、来週の ACDC までにすべてを実装してテストする必要があることに同意します。その電話で、devnet-9 の発売日について合意します。次回の ACDE は 9 月 28 日の 14:00 UTC 時間に開催される予定です。それまでは、テスト会議の概要については @terencechain を、ACDC 会議の情報については @benjaminion\_xyz を、イベント全体の詳細については @christine\_dkim をフォローしてください。
EIP-7514 はイーサリアム Dencun アップグレードの一部となります
著者: @TimBeiko 翻訳: Huohuo/Vernacular Blockchain
別の @ethereum #AllCoreDevs ミーティングは 9 月 15 日に終了しました。開発ネットワークの更新、Dencun への追加、Reth の包括的な概要について議論されました。
議題: ライブリンク:
以下は @TimBeiko による会議の概要です。
1. Devnet-8 ステータスの更新
まず、devnet-8 のステータス更新です。ネットワークは最終開発中であり、多くのクライアントがすでに新しい更新をネットワークにプッシュしています。それまでの間、@KurtosisTech を使用して MEV/ブロック ビルド プロセスのテストを開始しました。 @NethermindEth は、BLOB トランザクション プールの準備が整い、単一ノードで数日間テストした後、それをすべての Dencun テスト ノードにデプロイしたと述べました。
Geth の BLOB トランザクション プールもほぼ完成しました。 Besu は、トランザクション プール (BLOB トランザクションと非 BLOB トランザクションの合計サイズを制限する) を大幅に改善しており、次のリリースでリリースされる予定です。 Erigon はトランザクション プールの改善を続けており、devnet-9 に対応できるようにしたいと考えています。 Prysm はまた、BLOB サイドカーの受信には多少の遅延があることにも言及しており、通常、ブロブ サイドカーはブロックから約 500 ミリ秒遅れて到着すると言われています (ブロックの処理には約 15 ミリ秒かかります)。
彼らはこの問題を調査し、BLOB とチャンクのインポート間の競合状態が原因であるかどうかを判断しています。ハード フォークの前にメモリ プールで BLOB トランザクションのサポートを許可するかどうかという問題に関しては、チームは満場一致で許可しないことに同意しました。
##2、EIP-7514
次に、バリデーターのアクティブ化キューに一定の上限を追加するかどうかについて、先週の ACDC コールからの議論を継続しました。この提案は正式に EIP-7514 として形成されました。つまり、最悪のシナリオでは、これによりETHステーキングの割合の増加が鈍化することになります。ダンクラッド氏は電話会議中にこの提案への支持を表明し、バリデーターの報酬に対して潜在的により複雑な変更を加える時間を稼ぐことになると述べた。
すべての CL チームはこの変更に賛成ですが、これは入金キューにのみ適用され、出金キューには適用されないことに注意してください。さらに議論した結果、制限を 8 に設定することにしました。したがって、EIP-7514 は Dencun アップグレードの一部となります。今後数日以内に、この変更を反映するために EIP および関連する CL 仕様 PR が更新されることが予想されます。
3. EVM と BLOB
次に、別の暫定提案について議論しました。それは、Blob の基本料金を公開するために、イーサリアム仮想マシン (EVM) にオペコードを追加するというものです。この提案は、Arbitrum の @PlasmaPower0 によって提案されたもので、今週初めに R&D Discord で、これが彼ら (および他のレイヤー 2 ソリューション) にとって役立つだろうと述べました。 EIP-1559 には、BASEFEE を公開する同様のオペコードがすでにあります。これは、EIP のアクティブ化と同時に導入されました。これにより、レイヤー 2 ソリューションは、L1 データ コストに基づいてユーザーに請求するための正しいガス価格を決定することが容易になります。
Optimism の @protolambda も会議に出席し、ブロック ヘッダー (BLOB 基本料金の計算に使用される値が含まれている) を確認できるため、L2 の BLOB 基本料金を取得する唯一の方法ではないと提案しました。それらの値に対してマークルを提供して証明します。それでも、彼はそれが素晴らしい機能であることに同意します。 Arbitrum は現在、ブロック ヘッダーの解析を実行していません。ブロック ヘッダーの形式が最終的に変更された場合に問題が発生する可能性があるため、これに依存すると不変のレイヤー 2 ソリューションでは問題が発生する可能性があります。
EIP-4844 作成者の 1 人である @adietrichs は、(1 回限りのオペコードを追加するのではなく) ブロック ヘッダー情報にアクセスするためのより一般的な方法を開発したいという要望があったため、このオペコードは元の仕様には含まれていなかったと述べました。それでも、このより野心的な変更を採用することは、このオペコードを導入するよりも野心的な作業となるでしょう。
このオペコードによって公開される情報は、EL クライアントが計算する必要がある情報であり、意味的には BASEFEE オペコードとほぼ同じです。クライアント チームは、BASEFEE との一貫性を保つためにのみ、このオペコードを追加する必要があることに満場一致で同意しました。将来的に「より巧妙な」メカニズムを思いついた場合、この新しいオペコードの冗長な機能は、ブロック ヘッダー情報を使用する他のオペコードにとっても問題になるでしょう。また、これは非常に小さな変更であることを強調する価値があります。EIP が存在する前に @vdWijden が Geth に実装しましたが、所要時間はわずか 20 分程度で、Reth チームは ACD コールの PR 中にそれに関する変更をコミットしました。
##4、EIP-4788
次に、イーサリアムメインチェーン上のコントラクトにビーコンルートを保存する提案である EIP-4788 のいくつかの更新について説明しました。過去数週間にわたり、私たちは契約の監査とファジーテストを複数回実施し、その結果、この PR に記載されているいくつかの小さな変更が行われました。すべての監査が完了したわけではなく、レポートもまだ出ていませんが、@lightclients がこれまでに検討されている変更の概要を説明しました。最初の変更は、0 のタイムスタンプを明示的に処理して、0 を返すのではなく (他の無効なタイムスタンプと同様に) ロールバックを引き起こすようにすることです。 2 番目の変更はバッファ サイズに関するものです。スロット時間が変更されると仮定すると、モジュラー演算の仕組みにより、元の契約ではストレージが無駄になります。
5. ガスの最適化
最後に、CALLDATA のロード回数を減らすガスの最適化があります。監査人はこれらの変更を検討し、次回の ACDE 会議までに最終報告書が作成される予定です。ファジングのテストと実装作業を進めるために、私たちは提案されている変更を今すぐマージすることに同意しました。
@shemnon は、これらの変更を実際の EIP に文書化する必要があるとも述べました。私たちはそのことに取り組んでいます。次に、システム コントラクト アドレスが状態の一部であるが、実行終了時には空である場合に、クライアントがこれをどのように処理する必要があるかについて説明しました。 (私の理解によれば、実際にはこれがメインネットで起こる可能性は低いですが)、これはジェネシス ブロックにアドレスを設定することによるテスト中に発生したエッジ ケースです。
これはかなり特殊な特殊なケースであり、明確な正規の動作がないことを考慮して、私たちはこの問題についてより多くの時間を費やして検討し、来週のテスト会議で議論を続けることに同意しました。仕様変更は以上です！上記はすべて devnet-9 に含まれる予定です。クライアント チームは、来週の ACDC までにすべてを実装してテストする必要があることに同意します。その電話で、devnet-9 の発売日について合意します。
次回の ACDE は 9 月 28 日の 14:00 UTC 時間に開催される予定です。それまでは、テスト会議の概要については @terencechain を、ACDC 会議の情報については @benjaminion_xyz を、イベント全体の詳細については @christine_dkim をフォローしてください。