クライアント

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

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 のペッグ回復を促進しています。