テクノロジーインサイト一覧へ戻る
2026.08.30

Cronos が Tectonic 攻撃を受けチェーンを停止し、状態を攻撃前へ巻き戻して再起動 ― 巻き戻せなかった600万ドルが残す問題

Cronos が Tectonic 攻撃を受けチェーンを停止し、状態を攻撃前へ巻き戻して再起動 ― 巻き戻せなかった600万ドルが残す問題

何が起きたか

Cronos Network は2026年8月30日、Tectonic で攻撃を検知したとしてチェーンを停止した。Tectonic は Cronos 上で最大のレンディングプロトコルで、攻撃前の預かり資産はおよそ1億2,170万ドル(約193.5億円、1米ドル=159円、2026年9月2日時点)、Cronos の DeFi 全体のおよそ46%を占めていたと報じられている。

オンチェーン調査を最初に公開した研究者 Weilin Li によれば、攻撃者は Tectonic のガバナンストークン TONIC の市場価格を吊り上げ、その水増しされたポジションを担保として差し入れて、プールから他の資産を借り出した。価格操作はおよそ20分の間に完了し、TONIC は約100倍まで上昇したとされる。Tectonic のドキュメントに掲載されている2025年5月付のパラメータ表では、TONIC の担保掛目は20%と定められている。

借り出された額の推計は幅がある。約74百万ドル(約117.7億円)とする報道が最も多いが、6,600万ドルから1億1,950万ドルまでの推計が並存する。攻撃者が Ethereum へ渡せたのは、チェーン停止までにおよそ600万ドル(約9.5億円)にとどまる。ある集計では、この攻撃に伴って871万ドルの清算が発生し、3,260万ドルが不良債権として残ったとされるが、これは第三者集計であり Cronos・Tectonic いずれの公式発表にも基づいていない。

チェーンは10時間以上にわたってブロックを生成しなかった。その後バリデータは、攻撃前に取得したスナップショットからチェーンを再起動する判断を下した。再開ブロックは 90,896,189 で、そのタイムスタンプは2026年8月30日 23:49:01 UTC。ノード運用者には、当日朝に公開されたスナップショットを用いて Cronos v1.7.8 で復旧するよう案内された。Cronos は8月31日に「バリデータ合意による緊急措置であり、チェーン状態は当日朝の Tectonic 攻撃以前に復元された」と説明し、ネットワークは完全に復旧したとした。ただし、その上に構築されたプロトコル、RPC プロバイダ、エクスプローラ、ブリッジの復旧には基盤層より時間がかかるとも述べている。破棄されたブロック数について Cronos は数値を公表しておらず、およそ11,000ブロックとする報道推計がある。

Crypto.com の CEO である Kris Marszalek は8月30日、同社のアプリと取引所は侵害されておらず顧客資産は安全であると述べた。正式なポストモーテムは約束されているが、本稿執筆時点では公開されていない。

成立条件と、同種事例との距離

攻撃の構造そのものに新規性はない。薄い市場で価格を作り、その価格を参照するオラクルを経由して、担保価値を実態から乖離させ、借り入れる。2022年10月の Mango Markets(およそ1億ドル)と同じ型で、研究者もそう指摘している。8月にはこの型が繰り返されており、前週には Base 上の Moonwell が MAMO の価格操作で約870万ドルを失っている。Weilin Li は Tectonic の件を数週間で三件目だと述べた。

繰り返される理由は、防御側の設計判断が分かりやすい形で残っているからである。担保掛目20%という設定は、「価格が5倍に外れても元本は守れる」という想定に立つ。100倍の操作に対しては意味をなさない。掛目は価格の正確さを前提としたパラメータであって、価格が壊れたときの防御にはならない。防御になるのは、担保に採用するトークンの流動性の下限、単一資産あたりの借入上限、そして価格更新の急変時に借り入れを止める回路である。

より重要なのは、Cronos が選んだ対応のほうである。Cronos は Cosmos SDK 系のチェーンで、Tendermint 系のコンセンサスは即時ファイナリティを謳う。にもかかわらず、バリデータ合意によって確定済みの履歴が破棄された。これは「ファイナリティ」という言葉が、暗号的な保証ではなく、バリデータ集合の社会的合意によって上書きされうる保証であることを、本番環境で実証した事例である。

判断としては、預金者のおよそ6,900万ドルを守ったという意味で実利的だったという評価が成り立つ。同時に、十分な数のバリデータが合意すれば履歴は交渉可能である、という前例も残った。この二つは両立する。

想定される落とし穴

第一に、巻き戻しはチェーンをまたがない。停止前に Ethereum へ渡ったおよそ600万ドルは、Cronos 側の状態が戻っても戻らない。したがって、この期間にブリッジを通ったメッセージは、送信側では「なかったこと」に、受信側では「あったこと」になっている。両側の台帳が恒久的に食い違う。ブリッジ運用者は、破棄された区間に処理した送金を個別に突き合わせる必要がある。自動整合処理は、片側の履歴が消えている前提で書かれていない。

第二に、公表された説明どおりであれば、ブロック高が再利用されている。攻撃前のスナップショットから 90,896,189 で再開したということは、それ以降の高さは以前にも存在し、中身が違うということである。ブロック高だけをキーにして結果をキャッシュしている実装――インデクサ、会計システム、取引所の入金確認――は、同じ高さに別の内容が入っていることを検知できない。ブロックハッシュまで含めて照合していなければ、誤ったデータを正常なものとして保持し続ける。

第三に、これは通常の再編成(reorg)ではない。フォークチョイスによって短い鎖が長い鎖に置き換わったのではなく、スナップショットからの再起動である。したがって、reorg 検知のロジックは発火しない可能性が高い。「深さ N の再編成を検知したらアラート」という監視は、この事象を素通りする。

第四に、Cronos 自身が述べているとおり、RPC プロバイダやエクスプローラの復旧は基盤層より遅れる。復旧直後に RPC から取得したブロック高やトランザクション履歴は、破棄された枝のものである可能性がある。復旧確認を RPC の応答だけで行うと、消えたはずの状態を正としてしまう。

第五に、同じ8月には Cosmos EVM の共有モジュール脆弱性によって MANTRA・TAC・KiiChain が停止しており、これは Tectonic の件とは無関係である。「8月に Cosmos 系チェーンが複数止まった」という粒度で社内共有すると、原因の異なる二つの事象が一つに見える。停止の理由は分けて記録する必要がある。

【技術インサイトとアクション】

  1. 停止可能なチェーンにおける「ファイナリティ」は、暗号的保証ではなくバリデータ集合の合意によって上書きされうる。したがって確認数(confirmations)をいくら増やしても、この種の巻き戻しは防げない。防げるのは「巻き戻しがありうる前提で待つ」ことだけであり、それはチェーンごとの停止権限の所在を把握していなければ設計できない。 [取引所・カストディ・インテグレーター] 9月末までに、接続している各チェーンについて「誰が停止を決定できるか」「過去に状態復元を実施したか」を棚卸しし、該当するチェーンの入金確定ポリシーを確認数ではなく待機時間ベースへ改める。
  2. ロールバックの効果はチェーン内で閉じるが、被害はチェーンをまたいで漏れる。クロスチェーンで接続している限り、片側の巻き戻しは必ず両側の台帳を食い違わせる。これは Cronos 固有ではなく、停止・復元を選択肢として持つすべてのチェーンとブリッジの組み合わせに当てはまる。 [ブリッジ運用者・プロトコル開発者] 復旧アナウンスから2週間以内に、破棄区間に処理したクロスチェーンメッセージを送信側・受信側で突き合わせ、片側のみ成立している送金を洗い出して手動で確定させる手順を文書化する。
  3. スナップショットからの再起動は、フォークチョイスによる再編成とは検知経路が異なる。ブロック高を一意の識別子として扱っている実装は、内容が入れ替わったことを構造的に検知できない。 [データ基盤・インデクサ開発者] 次のスプリントまでに、ブロック高だけをキーにしている永続化・キャッシュ層をすべて洗い出し、ブロックハッシュを併せて保持して不一致時に再取り込みする形へ変更する。

【引用:出典】

本記事は公開情報に基づく技術解説であり、投資助言を目的としたものではありません。