クライアント

ブロックスペースインフラストラクチャ会社Gattacaは、オープンソースのEthereumコンセンサスクライアントSilverを発表しました。同社はEthereumブロックビルダーTitan BuilderとリレーTitan Relayを運営しています。Gattacaは、Silverはゼロから構築されており、分散化、検閲耐性、プライバシーとセキュリティを維持しながら、より短いタイムスロットとポスト量子セキュリティをサポートすることを目指していると述べています。現在、Silverはアルファ段階にあり、監査と最終テストはまだ完了していません。Gattacaによると、Silverの状態遷移関数のp99遅延は10ミリ秒未満であり、他のクライアントより約10倍速いとのことです。2026年10月17日から20日のメインネットウィンドウでは、Silver、Prysm、Lighthouse、Grandineが同じ20300の規範ブロックを処理しました。Silverのブロック処理遅延の中央値は6.5ミリ秒、p99は9.5ミリ秒で、サンプル中で最も遅いブロックは17.8ミリ秒でした。次に低い中央値は33.5ミリ秒、次に低いp99は91ミリ秒です。4つのクライアントはすべてスーパー ノードとして動作し、すべての64の証明サブネットを購読し、すべての128のデータ列をホストし、実行クライアントはethrex v29.0.1です。上記の比較は、各クライアントで利用可能なコンセンサス処理指標を使用しており、実行クライアントの処理時間は含まれていません。SilverはGattacaのFluxフレームワークに基づいており、6つのバインドされたCPUコアのスレッドで並行処理を行い、低遅延のピアツーピアネットワーク、状態ハッシュライブラリ、形式的検証のBLSおよびKZG暗号ライブラリ、ならびに罰金保護のためのノードクラスターを備えています。別の比較では、スーパー ノードはデフォルト設定に対して約32倍の証明と約16倍のKZGユニット証明を検証する必要があり、ブロック処理遅延と常駐メモリは依然として近い範囲にあります。

インドの証明書発行機関eMudhraの暗号セキュリティの脆弱性が、EthereumクライアントTekuとBesuに影響を及ぼしています。研究者は、eMudhra傘下の8つの中間証明書発行機関の秘密鍵がランダム性不足のために推測される可能性があることを発見しました。攻撃者はこれにより証明書を偽造し、修正されていないソフトウェアを利用して悪意のあるサービスを信頼させることができます。Tekuは26.1.3バージョンをリリースし、Besuは26.1.2バージョンをリリースしました。どちらもDockerイメージ内で関連証明書への信頼を削除しました。攻撃者が中間者攻撃を実施した場合、一部のバリデーターがブロック手数料の報酬を攻撃者のアドレスに送信するよう誘導される可能性があります。外部署名器を使用する特定の構成では、リスクがさらに高まる可能性があります。Tekuチームは、デフォルト構成のEthereumメインネットTekuノードは影響を受けず、行動を取る必要はないと述べており、現在のところ脆弱性が悪用されたという報告はありません。ホスト上で直接TekuまたはBesuを実行し、Dockerを使用していないオペレーターは、クライアントを更新するだけでは不十分な場合があり、Javaおよびその信頼された証明書リストを手動で更新する必要があります。サポートが終了したJava 26を使用しているオペレーターは、Java 25に移行する必要があります。

Olaoluwa Osuntokun の監視によると、Lightning Labs の最高技術責任者は、CVE-2026-111943 脆弱性の影響を受けて、すべての lnd、btcd、tapd、litd ユーザーにバイナリファイルを更新するか、Go 1.27.3 を使用して再構築することを強く推奨しています。この脆弱性は、証明書発行機関が侵害されることに関連しており、関連ソフトウェアのセキュリティに影響を与える可能性があります。

英伟达のCEO、黄仁勋は、会社が安全でない人工知能を開発している顧客との協力を断つと述べました。

SolanaFloor の報告によると、Jump Crypto の Firedancer チームは、Alpenglow が Solana メインネットでアクティブになった後、Solana の移行型検証クライアント Frankendancer のサポートを停止する予定であり、このアップグレードは v4.3 と共に 10 月に行われる見込みです。チームは、この決定を下した理由はメンテナンスとセキュリティの負担であり、今後はリソースを完全な Firedancer クライアントに集中させると述べています。

オンチェーン分析プラットフォームのArkhamは、インベスコがどのETFよりも長いETH保有の連続記録を持っていると発表しました。インベスコの顧客は、過去6ヶ月間ETHを純売却しておらず、最後の売却は2026年3月19日に行われました。

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 個のブロックを成功裏に生成したことを発表しました。