クライアント

Zcash財団はツイートで、Zebra 4.3.1バージョンをリリースしたと発表しました。このバージョンにはいくつかの重要なセキュリティ修正が含まれており、すべてのノードオペレーターに即座のアップグレードを推奨します。さらに、このバージョンにはDocker化されたマイニング環境、自動チェックポイント管理、およびいくつかのCI強化改善が追加されています。

慢雾の監視によると、Apifox デスクトップクライアントはサプライチェーン攻撃に遭い、その公式 CDN がホスティングするフロントエンドスクリプトファイルに高度に難読化された悪意のある JavaScript コードが注入されました。影響を受けたユーザーは、認証情報の盗難、機密データの漏洩、リモートコマンドの実行などのリスクに直面する可能性があり、悪意のあるコードは自動的に実行され、高度に隠蔽されています。慢雾はユーザーに対し、すべてのトークンを直ちに取り消し、パスワードをリセットし、ログアウトして再ログインしてセッションを無効にし、*.apifox.it.com ドメインをブロックし、ローカルストレージをクリアし、API ログと異常な活動を確認することを推奨しています。

VitalikはXプラットフォームで、イーサリアムの現在のビーコンクレインと実行クライアントの分離されたアーキテクチャに対してオープンな態度を持つべきだと述べ、2つのデーモンを実行し、それらが相互に通信する複雑さは単一のデーモンを実行するよりも明らかに高いと考えています。Vitalikは、イーサリアムの目標はユーザーが自己管理方式でネットワークを利用し、良好なユーザー体験を得ることであり、多くの場合、これは自分のノードを運営する必要があることを意味すると指摘しましたが、現在のノードの運営方法は不必要な複雑さを増加させています。彼は短期的には、より標準化された基盤のパッケージングソリューションを通じて、ユーザーが異なるクライアントのDockerイメージをインストールし、より便利な通信を実現できるようにすることを提案しました。同時に、LeanEthereumのコンセンサススキームが徐々に成熟するにつれて、将来的には全体のアーキテクチャ設計を再検討することも考慮すべきだと述べています。

ビットコインクライアント Bitcoin Core の開発メインブランチは、Cluster Mempool の更新（PR #34616）をマージしました。これは今後の Bitcoin Core 31 バージョンに含まれる予定です。このアップグレードは、ノードが未処理の取引（mempool）を管理する方法を再設計し、関連する取引をグループ化して処理することで、ブロックのパッキング効率を向上させ、RBF と CPFP 取引の手数料計算を最適化します。Bitcoin Core 31 は 2026 年下半期にリリースされる可能性があります。

Neynar の共同創設者 Rishav Mukherji が Farcaster に対するビジョンを発表しました：Neynar は Farcaster プロトコルを維持し、Farcaster クライアントを運営し、Clanker の運営を担当します。一部の Clanker チームメンバーが Neynar に参加します。Neynar はこれまで Farcaster エコシステムの重要なインフラ提供者であり、今回の統合は長年のコミュニティへの深い関与の自然な進化です。ビジョンは、ビルダーがアイデアから持続可能な収入に至るようにし、「ビルダー優先」のネットワークを構築することです。Farcaster の核心的な価値は、長期にわたって形成されたビルダーコミュニティにあります。このグループは、Frames、Degen、Warpcast などの重要な革新を推進してきました。Farcaster の価値は製品だけでなく、実験し、知識を共有し、公開で構築する人々にあります。Neynar が Farcaster を買収した核心的な使命は、ソフトウェアの構築をより簡単にすることです。製品レベルでは、Farcaster、Neynar、または Clanker に対して重大な調整は行われず、プロトコルやクライアントの停止に関する噂は事実ではありません。Neynar 開発者プラットフォームは引き続き存在し、金融および取引関連機能も現状を維持します。次の段階では、製品の優先順位に基づいて評価が行われ、ネットワークのオープン性を保ちながら、段階的にロードマップを進めていきます。ソフトウェア構築のハードルが継続的に低下する中、暗号ネイティブ金融トラックとオープンな配信メカニズムを組み合わせることで、Farcaster はクリエイターと開発者が実験し、協力し、スケール化に向かう重要な出発点となることが期待されています。

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 を超えると、終局無効チェーンのリスクが存在します。また、機能スイッチのコミュニケーション不足やテスト環境が大規模な非同期ノードを模擬できなかった問題についても反省し、今後はテスト戦略と構成管理を改善する予定です。

Jump Crypto が開発した Solana 独立検証クライアント Firedancer は、3 年間の開発を経て、Solana メインネットに正式にローンチされ、少数の検証ノードで 100 日間安定して稼働し、50,000 個のブロックを成功裏に生成したことを発表しました。

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 のメッセージ、イーサリアムクライアント Nimbus がツイッターで v25.9.1 バージョンがリリースされたと発表しました。このバージョンはメインネットでは低緊急レベルですが、Hoodi、Sepolia、Holesky テストネットでは高緊急レベルです。その理由は、上記のネットワークが Fusaka フォークを間もなく実施するためです。チームは関連するテストネットノードがフォークに適応するために早急にアップグレードすることを推奨しています。

ChainCatcher のメッセージによると、市場の情報では、Paradigm の最高技術責任者 Georgios Konstantopoulos が、イーサリアムの実行層クライアント Reth がブロック 2327426 で脆弱性を示し、そのクライアントに依存するノードが中断したことを明らかにしました。影響を受けたバージョンには Reth 1.6.0 と 1.4.8 が含まれます。Paradigm は GitHub ページでノードを復旧するための指示を公開しましたが、脆弱性の根本原因はまだ調査中です。Reth は Paradigm によって開発されたイーサリアムの実行層クライアントで、Rust 言語を使用しており、性能とモジュール性の向上を目指しています。現在のデータによれば、Reth はイーサリアムの実行層クライアント全体の 5.4% に過ぎないため、今回の脆弱性の影響範囲は限られています。実行層クライアントは取引や状態の更新を処理し、状態のルートを計算してブロックチェーンのグローバルな状態の完全性を確保します。この脆弱性により、一部のノードがブロックを検証できず、ネットワークと同期できなくなる可能性があります。

ChainCatcher のメッセージ、Synthetix の創設者 kain.avax が X プラットフォームで投稿し、Cursor を使用して開発環境を構築し、新しいクライアントプロジェクトを設計したことを示しています。その後、サーバー/データベースを追加してプロジェクトをより堅牢にする予定です。Claude Opus は 1 万行のコードを含むプルリクエストを提出し、彼自身は 40 分でプロジェクト全体を再構築しました。現在、このプロジェクトはほぼ稼働可能です。以前、Synthetix が発表したステーブルコイン sUSD はペッグを外れ、現在 SCCP-409 提案が承認され、sUSD のペッグをサポートするための追加支援が提供されました。債務免除（jubilee）参加者の sUSD ステーキング要件は 10% から 20% に引き上げられ、sUSD のペッグ回復を促進しています。

ChainCatcher のメッセージによると、Tim Beiko のまとめで、第 209 回イーサリアム実行層コア開発者会議（ACDE）では、今後の Pectra と Fusaka アップグレードについて重点的に議論されました。Pectra クライアントは 4 月 21 日にリリースされる予定で、EIP-7702 の委任状態が JSON-RPC に追加されます。Fusaka に関しては、EIP-7823（MODEXP の複雑さの制限）、EIP-7825（トランザクションのガス上限）、および EIP-7907（契約コードサイズの測定と制限の引き上げ）が明確に含まれることになります。EIP-7762 と EIP-7918 は、リソースの利用と市場の需給のバランスを取るために、blob 料金メカニズムの中でいずれか一方を採用する予定です。

ChainCatcher のメッセージによると、Tim Beiko のまとめで、第 209 回イーサリアム実行層コア開発者会議（ACDE）では、今後の Pectra と Fusaka アップグレードについて重点的に議論されました。Pectra クライアントは 4 月 21 日にリリースされる予定で、新たに EIP-7702 委託状態が JSON-RPC に追加されます。Fusaka に関しては、EIP-7823（MODEXP の複雑さの制限）、EIP-7825（取引のガス上限）、および EIP-7907（契約コードのサイズ測定と制限の引き上げ）が明確に含まれることが示されています。EIP-7762 と EIP-7918 は、blob 料金メカニズムの中でいずれか一方を採用し、リソースの利用と市場の需給のバランスを取ることになります。

ChainCatcher のメッセージによると、イーサリアムクライアント Nethermind の責任者 Marek Moraczyński が X プラットフォームで発表したところによれば、80% 以上のイーサリアムフルノードのディスクスペースが履歴によって占有されているため、新しいブロックを検証するためのデータは必要ないとのことです。新しいバージョン 1.3.1 では、Nethermind は ERA ファイルを通じてマージ前の履歴を削除する準備が整っており、すべてのチームは 5 月 1 日に関連操作を実行することに同意しています。すべてのブロックとすべてのレシートを削除し、最新のブロックを検証するために必要なデータのみを保持すれば、フルノードの容量は 200 GB 未満になります。

ChainCatcher メッセージ、イーサリアム財団が公式ブログで発表しました。Pectra ネットワークのアップグレードは以前に Sepolia テストネットで実施されましたが、その後、Sepolia の許可されたデポジット契約に問題があることが判明し、多くの実行層クライアントがトランザクションをブロックに取り込むことができなくなりました。問題の原因は迅速に特定され、クライアントチームはすぐに修正作業に取り掛かりました。この問題は Sepolia のテストネット構成に特有であり、イーサリアムメインネットでは発生しないとされています。現在、バリデーターは修正プログラムを展開し、ネットワークを正常なスループットに戻しました。すべての Sepolia ノードオペレーターは、ネットワークの互換性を維持するために、実行層クライアントをアップグレードする必要があります。