ニュース暗号資産ジョセフ・ルビン氏:セキュリティインシデントによるMetaMaskウォレットや顧客資金への影響はなし

ジョセフ・ルビン氏:セキュリティインシデントによるMetaMaskウォレットや顧客資金への影響はなし

著者: Blockonomi·

重要ポイント

  • •セキュリティインシデントによりConsensysのインフラの一部が影響を受けたが、これまでの調査ではMetaMaskウォレットや顧客資金への影響を示す兆候は見られていない。
  • •MetaMaskはユーザーが自身の鍵を管理するセルフカストディモデルで運用されているため、ユーザーのシークレットリカバリーフレーズや秘密鍵は本インシデントに関与していない。
  • •Consensysとそのパートナーは予防措置としてバリデータ鍵をローテーションした。バリデータはステーキングキューから退出し再参加する必要があるため、ルビン氏はこのプロセスを運用上不便だと述べた。
  • •イーサリアムのアーキテクチャはバリデータ鍵と引き出し鍵を分離しているため、本インシデントがステークされたETHの不正送金につながることはなかった。
  • •Consensysは本件の技術的な性質を公表していないが、問題が十分に把握された時点でパートナーおよび関係ステークホルダーに速やかに開示するとしている。
ジョセフ・ルビン氏:セキュリティインシデントによるMetaMaskウォレットや顧客資金への影響はなし

イーサリアムの共同創設者でありConsensysの創設者であるジョセフ・ルビン氏は、セキュリティインシデントにより同社インフラの一部が影響を受けたものの、これまでの調査ではMetaMaskウォレットや顧客資金への影響を示す兆候は見られなかったと述べた。ルビン氏によれば、ユーザーのシークレットリカバリーフレーズや秘密鍵は本インシデントに関与していないという。Consensysが広く利用されているセルフカストディ型ウォレットとして提供するMetaMaskは、ユーザーが鍵を仲介者に委ねるのではなく自身で管理することを可能にしており、この違いはセキュリティ上直接的な意味を持つ。カストディ型の仕組みではプロバイダーがユーザーの鍵を保管するため、プロバイダー側の侵害が顧客資金を直接危険に晒す可能性があるからだ。

予防措置として、Consensysとそのパートナーはインシデント後にバリデータ鍵をローテーションした。ルビン氏はまた、イーサリアムの設計ではバリデータ鍵と引き出し鍵が分離されているため、本インシデントによってステークされたETHが不正に送金されることはあり得ないと強調した。

ルビン氏が明かしたインシデントの影響範囲

2026年10月2日にXへ投稿した内容の中で、ルビン氏は、韓国ブロックチェーンウィーク(KBW)という年次業界イベントのためソウルで過ごした充実した1週間を終えて帰国したばかりであり、その間も同社のセキュリティイベントへの対応を注視し続けていたと述べた。この投稿はConsensysがインシデントを公表した後のものであり、ルビン氏は、何が影響を受け、何が影響を受けていないかについての質問や憶測に今後答えと書いた。

Coming up for air now after a very dense excellent week in Seoul at KBW, while staying on top of our response to a security affecting part of our infrastructure. I can now respond to queries and speculation regarding what is impacted and what is not affected. Based on…

— Joseph Lubin (@ethereumJoseph) October 2, 2026

出典:X上の@ethereumJoseph

この投稿の中でルビン氏は、「MetaMaskウォレットやウォレット内の顧客資金が影響を受けたことを示す兆候は存在しない」と述べた。続いてユーザーの鍵に直接言及し、シークレットリカバリーフレーズとウォレット資産は「そもそも影響を受けることが構造上あり得ないため、本インシデントの一部ではなかった」とし、「ユーザー自身が鍵を保管し管理する。それがセルフカストディの仕組みだ」と付け加えた。

ルビン氏はさらに、Consensysはさまざまな脅威アクターからの攻撃の試みに直面しており、多くのプロバイダーと同様に定期的にセキュリティ問題に遭遇すると述べた。同社は「進行中のインシデントの詳細については公に議論しない」とし、本件の技術的な性質についても詳細を明らかにしていないが、「問題が十分に把握された時点で、パートナーおよび関係ステークホルダーに速やかに開示する」と説明した。同社がさらなる情報を共有するまで、何が起きたのかの技術的詳細が読者が注視すべき主な未解明の点となっている。

今回のケースでは、Consensysはパートナーと詳細を共有し、双方が対応戦略で合意した上で共同で実施し、その後同社がインシデントを公に開示した。この一連の流れは、ルビン氏が説明したアプローチと一致している。

バリデータ鍵のローテーションとイーサリアムのステーキング設計

Consensysとそのパートナーによる予防的なバリデータ鍵のローテーションは、ルビン氏の言葉を借りれば「運用上不便」であり、遺憾な措置だったという。バリデータはステーキングキューから退出し、再ステーキングのために再度参加する必要があり、このプロセスには時間がかかる。また、この変更にはパートナーとの調整も必要だった。

ルビン氏は、イーサリアムのバリデータアーキテクチャでは2つの鍵が分離されていると説明した。一方の鍵がブロックの提案とアテステーションを行い、もう一方の鍵がステークの引き出しを行う。この分離により、「バリデータインフラの問題によって基盤となるETHが不適切に移動されることは構造上あり得ない」と同氏は述べた。そして、この分離はイーサリアムのプロトコル自体に組み込まれているため、この保護はConsensys固有のものではなく、あらゆるバリデータ運用者に適用される。

カストディについては、ルビン氏は「イーサリアムのセルフカストディの原則に従、当社は顧客の引き出し鍵を保管していない」と述べた。その結果、本インシデントがステークされたETHの不正送金につながることはなく、鍵のローテーションにより残存する運用リスクはさらに低減された。

中核的原則としてのセルフカストディ

ルビン氏は、セルフカストディとユーザーによる管理をConsensysの中核的な設計原則であると述べ、同社のMetaMaskウォレット、ステーキングサービス、バリデーション運営のすべてを導いていると説明した。さらに、同じ原則がイーサリアム全体により広く当てはまると主張した。

同氏は「セルフカストディと厳格な分散化の組み合わせは、セキュリティにおけるパラダイムシフトである」と結論づけ、世界がこのアーキテクチャの利点にますます気づきつつあると述べた。