prysm

CoinDesk の報道によると、イーサリアムの開発者は月曜日の夜に Prysm クライアントの 7.2.1 バージョンをリリースし、2 億 Gas 上限を組み込み、火曜日の Glamsterdam アップグレードの Sepolia テストネットのテスト前にデプロイを完了しました。Glamsterdam はイーサリアムの次の大規模アップグレードであり、最初に Sepolia テストネットでアクティブになります。開発者はこのテストネットで実際の価値のないトークンを使用して変更をリハーサルします。火曜日のテストの一部は、Sepolia の Gas 上限を約 6000 万から 2 億に引き上げることです。Gas はイーサリアムが単一のブロックにどれだけの計算作業を収容できるかを測る単位であり、より高い上限はネットワークが同時により多くの取引やより複雑な活動を処理できることを意味しますが、イーサリアムを運営するコンピュータに対してもより高い要求を課します。Prysm はイーサリアムのバリデーターが使用するクライアントソフトウェアであり、その前のバージョンはこの設定が Sepolia 構成に追加される前に完了しているため、古いバージョンのバリデーターは手動でパラメータを変更しない限り、6000 万 Gas 上限でブロックを生成し、この容量テストの効果を弱めることになります。最新バージョンを実行しているバリデーターは、Glamsterdam が UTC 時間 10 月 6 日 13:53:36 に Sepolia でアクティブになると、自動的に 2 億 Gas のブロックを提案し始めます。イーサリアムは段階的にブロック容量を増加させており、バリデーターの運営が過度に厳しくまたは高価になる前にどこまで進めるかをテストしています。2 億の設定は Sepolia のみに適用され、Glamsterdam はまだイーサリアムのメインネットではアクティブになっていません。

Prysm チームは、12 月 4 日のイーサリアムメインネット Fusaka 時間帯において、ほぼすべての Prysm ビーコーンノードが特定のアテステーションを処理する際にリソース枯渇が発生し、バリデーターのリクエストに迅速に応答できなくなり、ブロックと証人が大量に欠落したとの事故復盤報告を発表しました。事故の影響範囲はエポック 411439 から 411480 までで、合計 42 エポックにわたり、1344 スロット中 248 ブロックが欠落し、欠落率は約 18.5% でした。ネットワーク参加率は一時 75% に低下し、バリデーターは約 382 ETH の証人報酬を失いました。根本原因は、Prysm がメインネットと同期していない可能性のあるノードからのアテステーションを受信し、これらのアテステーションが前のエポックのブロックルートを参照していたことにあります。その合法性を検証するために、Prysm は古いエポックの状態を繰り返し再生し、高コストのエポックトランジションを実行したため、ノードは高い同時実行下でリソース枯渇を引き起こしました。関連する欠陥は Prysm PR 15965 に起因し、1 ヶ月前にテストネットにデプロイされていましたが、同じシナリオは発生しませんでした。公式が提示した一時的な解決策は、v7.0 バージョンで --disable-last-epoch-target パラメータを有効にすることです。その後リリースされた v7.1 および v7.1.0 には、アテステーションをヘッドステートを使用して検証することで、履歴状態の再生を避ける長期的な修正策が含まれています。Prysm は、問題は 12 月 4 日 UTC 4:45 以降徐々に緩和され、エポック 411480 時にはネットワーク参加率が 95% 以上に回復したと述べています。Prysm チームは、今回の事件がクライアントの多様性の重要性を浮き彫りにしたと指摘しています。もし単一のクライアントの割合が 3 分の 1 を超えると、一時的に終局できなくなる可能性があります。3 分の 2 を超えると、終局無効チェーンのリスクが存在します。また、機能スイッチのコミュニケーション不足やテスト環境が大規模な非同期ノードを模擬できなかった問題についても反省し、今後はテスト戦略と構成管理を改善する予定です。

Cointelegraph の監視によると、Fusaka ネットワークのアップグレード後まもなく、Prysm コンセンサスクライアントにバグが発生し、Ethereum ネットワークのバリデーターの参加率が急激に低下し、多くの投票ノードがオフラインになりました。Prysm の公式は木曜日に、v7.0 バージョンのクライアントが古い Attestations（証明）を処理する際に不必要に古い状態を生成し、ノードが正常に動作しなくなることを発表しました。開発者は、ユーザーに一時的な解決策としてクライアントを起動する際に "--disable-last-epoch-targets" フラグを使用することを推奨しています。Beaconcha.in のデータによると、Epoch 411,448 では、ネットワークの同期参加率（Sync Participation）と投票参加率（Voting Participation）がそれぞれ 75% と 74.7% に低下しました。投票参加率は 25% 減少し、ネットワークが最終的な確定性を維持するために必要な三分の二の多数（66.6%）のスーパー多数まであと 9% 未満となっています。今回の投票参加率の低下幅は、Prysm コンセンサスクライアントのバリデーターシェアと大体一致しており、Attestation の失敗が Prysm バリデーターに集中している可能性が高いことを示しています。以前、Prysm のシェアは一時 68.1% に達していました。執筆時点で、Ethereum ネットワークの現在の Epoch (411,712) の投票参加率は 99% に近づき、同期参加率は 97% に達しており、ネットワークが回復したことを示しています。現在の MigaLabs のデータによると、Lighthouse は依然としてコンセンサスノードの 52.55% を占め、Prysm は 18% で2位に位置しています。Ethereum 教育者の Anthony Sassano は、Lighthouse にこのバグが発生した場合、ネットワークは最終的な確定性を失うと述べています。

Ethereum クライアント Prysm は、問題の所在を特定し、迅速な一時的解決策を提供したと述べています。すべてのノードは、Prysm で不必要に古い状態を生成して期限切れの証明を処理することを無効にする必要があります。信号ノードにフラグ "--disable-last-epoch-targets" を追加するだけで済みます。このパラメータは v7.0 バージョンに適用されるため、信号ノードをさらにアップグレードする必要はなく、このパラメータを追加するだけで大丈夫です。バリデーター クライアントは何も変更する必要はありません。

Lido 公式発表によると、イーサリアムのFusakaハードフォークが順調に完了した後、Prysmコンセンサスレイヤークライアントに脆弱性が発生し、ネットワークの参加度に問題が生じました。Lidoプロトコルは正常に稼働しており、ステーキング者は心配する必要はありません。プロトコルの基盤となる検証ノードの集まりが分散型で非中央集権的な特性を持っているため、Lidoはこの事件の影響を比較的小さく受けており、Prysmクライアントチームとノードオペレーターの迅速な対応が問題の緩和に寄与しました。LidoチームはPrysmチームと密接に協力し、夜間に事件の進展を監視し、影響を受けたノードオペレーターが推奨された一時的な解決策を講じるのを支援しました。現在、ほとんどのLidoが運営するPrysm設定は復旧しており、一部のノードは一時的に他のクライアント設定に切り替えて修正を完了しました。

Ethereum財団はXプラットフォームで、メインネットのPrysmコンセンサスクライアントに現在問題があると発表しました。Prysmを使用している場合は、CLノードを再構成する必要があります。他のクライアントを使用している場合は影響を受けず、特に操作は必要ありません。以前の情報では、EthereumメインネットはFusakaアップグレードを成功裏にアクティブ化し、データ処理能力を大幅に向上させました。

ChainCatcher のメッセージ、Galaxy の研究副社長 Christine Kim が第 123 回イーサリアムコア開発者コンセンサス（ACDC）電話会議をまとめました。Cancun/Deneb アップグレードは 11 月 30 日に Devnet #12 でアクティブ化され、Teku、Lodestar、Lighthouse クライアントソフトウェアおよびすべての実行層（EL）クライアントソフトウェアは現在 Devnet #12 でテスト中です。さらに、開発者は Devnet #11 でのバリデーターの退出問題を発見し、Nimbus クライアントチームがその問題を解決しています。Devnet #11 は問題が解決されるまで通常通り運用されます。CL クライアント Prysm がまだ Devnet #12 に参加していないため、開発者は Prysm クライアントソフトウェアがテストの準備が整うまで Goerli シャドーフォークの計画を延期することに同意しました。Tim Beiko は、今年の年末前のどこかで Goerli シャドーフォークをリリースすることを提案しました。さらに、開発者は "BlockByRoot" および "BlobSidecarsByRoot" リクエストの仕様を明確にするために、CL ノードがこれらのリクエストに特定の順序で応答すべきかどうかを明記することについて議論しました。

ChainCatcher メッセージ、イーサリアムクライアント Prysm が v4.1.0 バージョンを発表しました。このバージョンはイーサリアムテストネット Deneb のサポートの基盤を築き、2024年第4四半期に後方同期やファイルシステムベースの blob ストレージなどの機能を導入する予定です。このバージョンの新機能には以下が含まれています：Deneb/Cancun 基本サポートの提供、Multi-Value Slices によるメモリ削減、ブロック処理の最適化のための EIP-4881、BLST0.3.11 によるポータブルビルド性能の向上、Multiarch Containers のリアルタイムプレビューなど。

ChainCatcher メッセージ、イーサリアムクライアント Prysm のリリース通知："一時的にイーサリアムクライアント Geth を V1.13.0 バージョンにアップグレードしないでください。Prysm のブロック生成に影響を与えるバグが見つかりました。ほとんどのクライアントは mev-boost を使用してローカルでブロックを生成する必要はありませんが、Prysm は依然としてローカルブロックを検証します。後ほど、Prysm はさらに多くの更新をリリースします。Geth のメンテナンス担当者 Péter Szilágyi は、このバグが master ブランチで修正されたことを確認しました。"

ChainCatcher のメッセージ、イーサリアムクライアント Prysm が v4.0.5 バージョンを発表しました。このバージョンには v4.0.4 以来の多くの重要な改善とバグ修正が含まれており、証明の集約に対する大幅な改善が含まれています。（出典リンク）

ChainCatcher メッセージ、イーサリアムクライアント Prysm が v4.0.3 ホットフィックスパッチをリリースしました。このパッチには、ビーコンサインノードがネットワークの不安定な時に大量のリソースを使用するのを防ぐための必要な最適化が含まれています。ユーザーのノードの使用率が非常に高い場合は、アップグレードをお勧めします。また、Prysm は来週の早い段階で正式な単一バージョンをリリースする予定です。(出典リンク)

ChainCatcher のメッセージによると、Ethereum のコア開発者 prestonvanloon.eth がツイートしたところによれば、Prysm チームは新しいバージョンを開発し、Prysm に存在する問題を改善しています。今朝早くに発生した Ethereum のコンセンサス層の短時間の異常事態において、Prysm のパフォーマンスは良くありませんでしたが、他のクライアントも同様でした。しかし、Lighthouse はこの期間中に非常に優れたパフォーマンスを発揮しました。prestonvanloon.eth は、Prysm クライアントが最近の状態をリプレイする際に高い割合のキャッシュミスイベントに直面したと述べています。このイベントでは、いくつかのリプレイされた差異が最大で 2 つの完全なブロックに達し、速度は毎分 65 回に達しました。（出典リンク）

ChainCatcher メッセージ、イーサリアムクライアント Prysm が v4.0.3 バージョンをリリースしました。このバージョンには、外部ブロックビルダーのコードパスやキー管理者のエラー修正など、いくつかの重要な修正が含まれています。すべてのユーザーにアップグレードを推奨します。(ソースリンク)

ChainCatcher メッセージ、イーサリアムクライアント Prysm が Shapella アップグレードの V4.0.0 バージョンをリリースしました。このバージョンはすべてのメインネットビーコノードとバリデーターに対して必須であり、4 月 12 日までにアップグレードする必要があります。（ソースリンク）

ChainCatcher のメッセージ、イーサリアムの第2層ネットワーク Arbitrum の開発チーム Offchain Labs が、イーサリアムのコア開発チームの一つである Prysmatic Labs を買収した。Prysmatic Labs は、イーサリアムネットワークの維持、アップグレード、革新を担当するコアソフトウェア開発チームの一つであり、イーサリアムクライアント Prysm の開発チームでもある。Prysm は現在、ユーザー規模が最も大きいイーサリアムクライアントであり、現在41.5%の検証ノードが Prysm を使用して取引を検証している。(出典リンク)