イーサリアム コンセンサス レイヤー コール #99 ライトアップ

https://www.galaxy.com/research/insights/ethereum-consensus-layer-call-99-writeup/

2022 年 12 月 1 日、イーサリアムの開発者が集まり、第 99 コンセンサス層 (CL) 電話。イーサリアム財団のダニー・ライアンが議長を務めるCLコールは、イーサリアム開発者がイーサリアムのプロトコルの変更について話し合い、調整する隔週の2つのミーティングシリーズの1つです。今週、開発者は、先週の All Core Developers (ACD) の電話会議で下された決定を再確認しました。つまり、開発者は、上海後の別のアップグレードでアクティブ化される可能性が高いプロトダンクシャーディング (EIP 4844) の作業とは別に、イーサリアムの次のアップグレードである上海でステークされた ETH の引き出しを有効にすることに取り組むことに同意しました。開発者は、イーサリアムのコンセンサスレイヤー仕様に関連する進行中の研究トピックやイニシアチブについても議論しました。最後に、通話の終わり近くに、開発者は 2020 年 12 月 1 日に開始されたイーサリアム ビーコン チェーンの 2 周年を祝いました。

ステーキングされた ETH の引き出しと EIP 4844

通話を開始するために、Danny Ryan は ACD 通話 #150 での議論を繰り返しました。ここで、CL クライアント チームは、上海でのステークされた ETH の引き出しのみに集中することについて合意に達しました。 「コンセンサスレイヤーチームによって明確にされた重要なことは、EIP 4844は[ステークされたETH]引き出しとほぼ同じ準備ができておらず、それらを結合すると引き出しが大幅に遅れると考えていることです.それらを結合しません。私たちは現在の形でカペラに全力で取り組みます」とライアンは電話で語った。 Capella は、コア開発者がステークされた ETH 引き出しのコード変更をテストしている専用テスト ネットワークの名前です。

Ethereum Foundation の Devops エンジニアである Barnabas Busa 氏は、ステーキングされた ETH の引き出しを有効にするための進捗状況について最新情報を提供しました。ブサ氏は、引き出しをテストする 2 つのマルチクライアント開発者ネットワークがあり、1 つはマージ前の環境を模倣し、もう 1 つはマージ後の環境を模倣していると述べました。現在、これらの devnet はいずれも、すべての EL および CL クライアントをサポートしていません。マージ後の環境で引き出しをテストしている新しいものは、Prysm、Lighthouse、および Teku CL クライアントと、Geth および Nethermind EL クライアントをサポートしています。 Nethermind (EL) や Besu (EL) などの他のクライアントからの実装の準備が整うと、開発者は出金用に寿命の長いマルチクライアント テストネットを起動します。

次に、Ethereum Foundation の研究者である Alex Stokes が、バウンド スイープを実装するプル リクエストについて簡単な最新情報を提供しました。要するに、これはプロトコルが部分的および完全な引き出しのためにバリデーターセット全体をスキャンする必要があるというエッジケースシナリオを防ぐためのメカニズムです。 Stokes の提案は、スキャンを次のように制限します。最大 1,024 個のバリデーター . Stokes の提案に異議はなく、開発者は、来週末までに制限されたスイープに関するより多くの引き出しテスト ケースを進めることに同意しました。

EIP 4844 の開発は、上海やステーク ETH の出金に向けた開発作業とは別に行われますが、開発者は、proto-danksharding の実装に関連する未解決の議論項目のいくつかについて議論しました。 Lighthouse (CL) クライアントを構築する Sigma Prime のソフトウェア エンジニアである Sean Anderson 氏は、ネットワークが同期ブロブをどのように処理するかについて未解決の問題があると述べました。 BLOB は、EIP 4844 で導入される新しいタイプのトランザクションであり、レイヤー 2 ロールアップからのトランザクション データを Ethereum のベース レイヤーに排他的にコミットします。 Ryan は、blob 同期のエッジ ケースに関するさらなる議論を行うことを推奨しました。オープンな GitHub の問題。

Ethereum Foundation のエコシステム担当者である Trent Van Epps は、EIP 4844 の実装に必要な信頼できるセットアップセレモニーの進捗状況について最新情報を提供しました。 EIP 4844 で使用される安全なコードを生成するように設計されたセレモニーは、公募期間の準備が整いつつあります。 Van Epps 氏は、8,000 から 10,000 の寄付が集まり、式典が暗号空間でこれまでに行われた最大のものの 1 つになることを望んでいると語った。セレモニーの公募期間は、12 月頃から約 2 か月間です。詳細については、このウェブサイト 参加するこの Twitter Spaces セッション 2022 年 12 月 2 日。

リサーチ・ディスカッション

開発者は、潜在的な最適化と Ethereum CL 仕様の変更に関連するいくつかのディスカッション アイテムを実行しました。最初に、Sigma Prime の共同創設者である Adrian Manning が 2 つの提案を強調しました。どちらも下位互換性があり、実装するためにシステム全体のハード フォーク アップグレードを必要としないことを意味します。最初の詳細ここ Ethereum 上のステーキング ノード間のピア検出を改善することを目的としています。 2 つ目は、IPv6 として知られる最新のインターネット通信プロトコルを実行している CL ノードのサポートを有効にします。この後者の議論項目は、5 月に Sigma Prime チームによって提起されました。その前の CL 通話の通話メモを見つけることができますここ .

チェックポイント同期とは、信頼できるノードから最新のブロック状態を取得することにより、ビーコン チェーンに接続する新しいノードがチェーンの先頭にすばやく同期できるようにする操作を指します。 Checkpointz は、信頼できるノードがチェックポイント同期エンドポイントを簡単に公開できるようにするために、Ethereum Foundation DevOps チームが構築したツールです。電話で、ConsenSys の主任研究員である Mikhail Kalinin 氏は、Checkpointz がノードの障害の中心点になることに懸念があると説明し、次のように指摘しました。いくつかの提案 Checkpointz から他のツールへの依存を多様化するのに役立ちます。

次に、分散型バリデーター技術 (DVT) ソリューションを構築する会社である Obol Technologies の共同創設者である Oisin Kyne 氏は、バリデーターのアグリゲーション業務の割り当てに関する問題を強調しました。 Kyne 氏は、職務は分散型バリデーターセットによって実行されるようには設計されていないと説明しました。そのため、分散バリデーターの操作をより適切にサポートするために、CL クライアントに 2 つの新しいエンドポイントを提案しました。カインズの提案に関する詳細情報ここ および DVT に関するハイレベルなバックグラウンドここ .

最後に、Kalinin は Ethereum Engine API 仕様に関して 2 つの質問を提起しました。 1 つ目は、EL クライアントでサポートされている機能を取得するための「engine_getCapabilities 」開発者は、GitHub で非同期的にこの提案に関するフィードバックを提供することに同意しました。 Kalinin による 2 番目の質問は、Engine API 仕様ドキュメントに使用する構造に関するものでした。アプローチの 1 つは、システム レベルのハード フォーク アップグレードを意味する、フォークによるエンジン API への変更を文書化します。その他の構造ドキュメントは、エンジン API 機能によって変更されます。各アプローチの長所と短所をより詳細に説明しますここ .通話中の開発者はいずれにも強い偏見を持っていませんでしたが、Ryan は fork アプローチの方が快適であると述べ、Kalinin は機能性アプローチを採用する利点が強いと考えていると述べました。

その他のアイテム

開発者は、GitHub での議論を確認することに同意しました。engine_getCapabilities また、上海に向けてエンジン API の変更を文書化するための構造についても考えてください。通話を終了する前に、独立した Ethereum 開発者の Micah Zoltu 氏は、ウェブサイトの背後にあるデータについて簡単な質問をしました。clientdiversity.org . Zoltu は、この Web サイトは 2 つの異なるソースからデータを取得しているため、結果が大きく異なると説明しています。 Ryan は、これらの方法の 1 つは、ステークされた ETH によってクライアントの分布を計算すると答えました。もう 1 つは、ノードとそのピアを識別するクローラーを使用して、クライアントの分布に関するデータを記録します。ライアンの知る限り、ノード クローラーによって収集されたデータは不正確であり、ブロック プリントとステークされた ETH 配布に依存する方法は、完全ではありませんが、はるかに信頼性が高くなります。

Nimbus (CL) クライアントを構築している Status の研究開発責任者であり、「Arnetheduck」としても知られる Jacek Sieka 氏は、彼のチームが新しいクライアント リリースをプッシュしたと述べました。このリリースにより、Nimbus クライアントは正式にベータ版から製品版の状態に移行します。このリリースでの改善点の詳細については、こちらをご覧くださいここ .通話を終了する前に、Ryan は 2022 年 12 月 15 日の次の CL 通話が今年最後の通話になることを指摘します。開発者は、新年の 1 月に通話を再開します。