クライアント

CryptoSlateによると、Polygon Labsは緊急通知を発表し、AustinとKyotoのハードフォークがアクティブ化された後、旧版のBorまたはHeimdallに留まっているPolygon PoSノードはコンセンサスから外れ、アップグレードしてネットワークの進捗に追いつく必要があるとしています。Austinはメインネットブロック91,949,700でアクティブ化され、Bor v2.1.0以上が必要です；Kyotoは高さ51,533,000でアクティブ化され、Heimdall v0.11.0以上が必要です。Austinは2種類のBorリソース枯渇リスクを修正しました：L1からL2へのブリッジ状態同期イベントがGas上限にカウントされないことがブロック処理を遅くする可能性があります；TxDependencyフィールドにサイズ制限がないため、ピアノードがクラッシュする可能性があります。Kyotoは深いネストされたメッセージ攻撃、費用通貨スキャン、チェックポイント署名の復元などの脆弱性を修正しました。2回のハードフォークは純粋なバイナリアップグレードであり、状態移行は不要で、フォークしないノードは再同期する必要はありません。旧クライアントの運営者はアップグレードし、必要に応じてPolygonの指導の下で再同期を回復する必要があります。

イーサリアム開発者 kevaundray が EIP-12188 提案を提出し、コンセンサス層のブロック保持ウィンドウを短縮することを提案し、ノードのストレージ負担を軽減することを目的としています。この提案は現在公開レビュー段階にあり、一部のイーサリアムクライアント開発者の支持を得ています。開発者 DApplion はこの提案を支持すると表明し、Lighthouse クライアントの貢献者 michaelsproul はこの調整が Lighthouse の運用に明らかな影響を与えないと考えています。提案では、イーサリアムの歴史データの需要の変化に伴い、コンセンサス層の歴史ブロック保持時間を短縮することでノードのリソース使用を最適化できると指摘しています。議論の中で、実行層の歴史データの裁剪が一部の長期間運用されているノードが古いブロックデータを提供することに影響を与える可能性があると述べられていますが、開発者はこれがネットワークの安全性やノードの正常な運用を脅かすことはないと考えています。現在、EIP-12188 はまだマージされておらず、さらなる審査とコミュニティの議論が必要です。

CoinDesk の報道によると、Runestone の共同創設者 Leonidas は、BIP 110 の非金融データに対する制限を回避することを目的とした、DOG Mode という名前のオープンソースビットコインクライアントを立ち上げることを発表しました。DOG Mode は、標準取引の最大重量単位を 400,000 から 3,900,000 に引き上げ、ブロック全体の容量に近づけ、粉塵制限を 294 から 546 サトシに引き下げて 1 サトシにします。Leonidas は、粉塵制限を解除することで約 2,500 万ドルの遊休資金が解放されると述べています。BIP 110 提案は、ユーザーによるアクティブなソフトフォークを通じて任意のデータを制限し、55% のマイナーの支持が必要ですが、現在の支持率はほぼゼロです。DOG Mode は、合意や投票を必要とせず、単一のノードの転送ルールを変更するだけで、十分なノードが稼働し、マイナーが受け入れれば取引が確認されます。Leonidas は、DOG Mode が Core から逸脱する程度は Knots よりもはるかに小さいと述べており、現在はコードベースやバージョンは存在せず、開発者にコードの貢献やマイナーのサポートを呼びかけています。DOG トークンの価格は 24 時間で 1.2% 下落しました。

RetoSwapはXプラットフォームで発表し、チームは今日の午前2時02分（北京時間）にHaveno取引プロトコルが攻撃を受けているとの報告を受け、すぐにフィルター機能を使って最低クライアントバージョンを2.0に設定し、取引を一時停止し、攻撃者のonionアドレスを禁止しました。RetoSwapは、チームは攻撃を受けていないと述べており、脆弱性はHavenoプロトコルのレイヤーにあります。損失は大口暗号資産の注文に限られているようで、法定通貨のトレーダーには影響がありませんでした。チームは影響を受けたトレーダーの回復を支援するためのプランを評価しています。取引はプロトコルの修正後に再開されます。以前の5月21日の報道によると、Havenoプロトコルに脆弱性が発生したため、RetoSwapは約270万ドルの資金を盗まれました。

Coinbaseは2026年第1四半期のSolanaバリデーター性能レポートを発表し、そのステーキング規模、インフラストラクチャのアップグレードおよびネットワーク最適化の進捗を明らかにしました。その中で、CoinbaseはSolanaネットワーク上で約4048万枚のSOLをステーキングしており、全体のステーキング比率は9.52%で、バリデーターは6か国/地域に分布しています。レポートでは、Coinbaseがほぼゼロダウンタイム（ZDD）アップグレードメカニズムを実現したことも指摘されており、ホットスワップと二重署名保護を通じて、バリデーターの更新プロセスがネットワークの安全性と安定性に影響を与えないようにしています。また、Harmonic、Jito、JitoBAM、Firedancer、Rakuraiなどの複数のクライアントシステムをサポートし、Solanaバリデーションエコシステムの多様性とレジリエンスを強化し、単一のスケジューリング戦略による集中化リスクを回避しています。

CoinDesk の報道によると、高頻取引会社 Jump Trading の暗号部門 Jump Crypto が開発した Solana バリデータークライアント Firedancer が Solana メインネットで稼働を開始し、ブロックの生成を始めました。Firedancer の創設エンジニア Ritchie Patel は、このクライアントが生産環境で数千万件の取引をパッケージ化していると述べましたが、チームは依然として段階的な展開を行い、バリデーターがセキュリティ監査が完全に完了する前に大規模に切り替えることを望んでいないとしています。さらに、Patel は、Firedancer のアーキテクチャが伝統的な金融の高頻取引システムを大いに参考にしていると述べ、チームは最近、100 万ドルの脆弱性報奨金プールを含む公開セキュリティ監査コンペを完了したと報告しました。

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 フォークを間もなく実施するためです。チームは関連するテストネットノードがフォークに適応するために早急にアップグレードすることを推奨しています。