THORChainは、攪拌（churning）プロセス中に特異的に表面化するコンセンサス問題を発見した後、すべてのバルブローテーション（vault rotation）処理を停止しました。ネットワークの開発チームは、セキュリティパッチ、モネロ統合、ルーターV6のデプロイを1つの協調的なアップグレードとして統合する単一のリリース――v3.20アップデート――を軸にロードマップを再構成しました。これは、翌週にデプロイを狙うものです。停止の理由は、ポイントリリースでは持ち運べない、Thornodeの奥深くに変更が必要な脆弱性によります。統合により重要なセキュリティの穴を塞ぎつつ、ネットワークが実行しなければならない「高リスクなアップグレード手順」の回数を制限します。とりわけ、開発チーム内でレビュー担当者の帯域が逼迫していることを踏まえると重要です。
THORChain、v3.20デプロイまでバルブローテーションを停止
バルブローテーションは、THORChainの基本的なセキュリティ機構の1つであり、現在は稼働していません。コンセンサス問題は攪拌プロセスの最中に特異的に表面化し、ポイントリリースでは対応できないほどThornodeの深い部分にまで踏み込んだ変更が必要になります。そのため、チームが同日議論していた当初予定のv3.19.4パッチは見送られました。
チームは同様に、翌週に向けたアップグレードの到達点（アップグレード高さ）を目標に、v3.20を切ることにしました。リリースが入ったら、まずSolanaを再有効化し、その後攪拌を復旧する計画です。元々v3.19.4に含める予定だった内容――モネロの作業を含む――は、すでに段階的にデプロイが進んでいる新しいルーターV6のコードとともに、より大きな1つのリリースにまとめて投入されます。ユーザー体験としては、アップグレード後も変わりません。スワップは通常どおりTHORChain Swapを経由します。
この統合は単なる受け身ではありません。複数の改善を1つの協調的なリリースにまとめることで、ネットワークが高リスクなアップグレード手順を踏む回数を減らせます。これは、レビュー担当者の帯域がすでに逼迫している状況で意味があります。
3つの連鎖バグが最近の悪用を可能に
最近の悪用は、単一の壊滅的な欠陥から生じたわけではありません。Maya Protocolの共同創設者で、現在はTHORChainのシニア開発者であるAaluxxによると、脆弱性は3つの古いバグの組み合わせであり、誰か――または何か――がそれらを順番に発動できると見つけるまでは、コードベース上で害なく共存していました。
「それは3つのバグで、つなぎ合わせることで悪用可能になりました。どれも単体では無害でした」とAaluxxは述べています。
彼は、悪用が壊れた（発生した）朝の状況を「冷え切ったように」感じていたと語りました。チームは最近、プライベートリポジトリからTSSのパッチを統合しており、彼の直後の懸念は、その統合のエラーが脆弱性を持ち込んだのではないかという点でした。素早い確認でそれは否定されました。コミットはそのままで、根本原因はさらに昔のコードに遡れたのです。チームは実際に、数か月前に同様の「連鎖バグ」（潜在的なダブルスペンド）も見つけていました。つまり、そのパターンはすでに監視対象として意識されていたということになります。
チームは暗号パラメータ解析により侵害されたバルブを検知
検知は技術的に洗練されていました。TSSセットアップの暗号パラメータの1つを因数分解し、存在してはならない小さな素数を探索することで、任意のバルブが汚染されているかどうかを特定できたのです。THORChainでは5つのバルブのうち1つが侵害されていることが判明しました。これが、TVLの約20%が流出した一方で全額ではなかった理由を説明します。この方法は、トリアージの速度が極めて重要な状況において、チームに信頼できる診断手段を与えました。
Aaluxxは、AIが今後果たす役割に関するより広い教訓について、率直に述べています。小規模なチームでも、より多くの角度から同時にコードベースを探索できるようになり、防御上の優位になります――ただし、同じ能力は外部から脆弱性を探そうとする誰にでも利用可能です。彼は、産業がその新しい現実に適応するまで、あと数か月は難しい時期になるだろうと見ています。
Maya Protocolは1か月の停止期間中もスワップを維持
THORChainが停止していた約1か月の間、Maya Protocolはスワップを続けていました。同じ潜在バグがMayaのコードベースにも存在していましたが、発動されることはありませんでした。さらに重要なのは、チームが独立して健全性を検証できる単一のバルブをMayaが運用していたことです。そのため、予防策として攪拌を止めていました。攪拌が同じ悪用経路を開いてしまう可能性があったからです。
実際の影響は確かにありました。問題の期間中、THORChainではネイティブのBTC-to-ETHスワップは利用できませんでしたが、Mayaでは利用できました。これは「冗長性」の主張を具体的に裏づけるものです。
「ジェット機を2つのエンジンで飛ばす必要があるんだ」とAaluxxは述べました。
悪用の後、そしてそれより前のTCY期間中には、THORChainとMayaを統合し、RUNEでCACAOを買い取り、1つのより大きなDEXに統合するべきだと主張する声もありました。Aaluxxは、それが妥当なビジネス判断になり得ることは認めつつも、それでも却下しました。同じ理想を共有する2つの独立した許可不要のDEXを並立させるのは、最適化して消し去るべき非効率ではなく、意図的な設計です。冗長性のコストは確かにありますが、「単一障害点（single point of failure）」のコストもまた確実にあります。
レビュ―体制が開発スピードを制約
THORChainのリリース速度を落としているのはコード不足ではありません。レビューでき、かつデプロイできる有資格者の不足です。
「私たちの制約要因は、コード作成ではなく、レビューとデプロイです」とAaluxxは述べています。
現在、THORChainの変更をレビューしデプロイするのに必要な深い専門性を持つのは、およそ3人程度に限られています。開発者を増やしたりプルリクエストを増やしたりしても、自動的に納期が加速するわけではありません。すでに狭いボトルネックに対して、レビュー負荷が増えるだけになります。チームは意図的に2対1の比率で運用しています。書かれたあらゆるコードには、前進する前に少なくとも2回のレビューが必要だということです。
チームは「アイデア段階」と「ADRプロセス」を分離する案を提示
ガバナンス面では構造的な問題が浮上しています。提案が、Nine Realmsのような単一の調整主体からではなく、多くの貢献者から寄せられるようになったことで、ADR番号が衝突し、準備ができていないラフなアイデアが、ADRとして形式的に提出されてしまっています。
提案されている解決策は、アイデア段階とADR段階を完全に切り離すことです。Aaluxxが示したように、ADRはすでに完成したレシピであるべきです。つまり簡潔で技術的で、利用可能なリソースで構築できること。欠けているのは、上流側の空間――いわば戦場のような領域――で、ADRとしての資格が付く前に、未加工のアイデアが挑戦され、洗練され、または却下される場です。
「『パスタが欲しい』というのをADRだと思う人がいる。でもそれはADRじゃない、問題だよ。レシピを持ってきてくれ」とAaluxxは述べています。
さらに先の段階では、ADR番号をノードリレー経由でオンチェーン上で要求・割り当てすることも可能かもしれません。最初の承認ノードが、次の連番を付与します。そうすれば、提案の所有権が曖昧にならず、中央集権的な門番を作ることもありません。繰り返しになりますが、ADRはコードを出荷するための前提条件ではありません。誰でも今日、GitLabでイシューやプルリクエストを開けます。ADRはノードオペレーターに対して、「支払いが発生する開発者の時間を、それに費やしたいかどうか」の温度感を測るものです。
ShapeShiftは統合拡大に伴い動的フィー・モデルに参加
停止していても、エコシステム内の統合は動き続けました。ShapeShiftは今、動的フィー・モデルにおけるライブ参加者としてSymbiosisに加わりました。そして、双方から戻ってきているデータが役に立つことが分かっています。さらに3〜4社のアフィリエイトが、Chad Barrafordが統合を完了できるかどうかによりますが、1週間以内にオンライン化される見込みです。
コミュニティのヒントによって、2つの大きな統合に関する会話が再燃しました。Randy Bechtold宛ての冷たいDMでRobinhood Chainが潜在的なターゲットとして浮上し、調べてみるとそれはArbitrum上に構築されたネットワークでした。THORChainがすでに追求していたネットワークです。これにより、2つで1つの機会が生まれました。BechtoldにはArbitrumチームとの通話が予定されており、そこでRobinhoodへのウォーム・イントロ（あたたかな紹介）を求める計画です。
AaluxxはArbitrumについて技術的な注意点も提示しました。Arbitrumはおおむね1秒あたり4ブロックで動いており、これはSolanaのようにノードにメッセージ量が洪水のように流れ込む状態を招きます。Mayaは自身のArbitrumサポートを安定化させるのに約1年を費やしました。利点は、大変な作業の大部分がMaya側でほぼ終わっているため、THORChainにはより短い道筋があることです。
モネロ統合は最小特権の監査段階へ進む
XMR統合は、出荷（実装）に最も近い主要機能です。Aaluxxは、セキュリティ監査についてLeast Authorityと協議中です。彼は、プライバシーチェーンの仕事においてトップクラスの事務所だと評価しています。前例もあります。ZcashはZEC-into-Maya integrationのLeast Authority監査を資金提供しており、最近、重大なバグはなく軽微なDoS（サービス拒否）とクオリティ・オブ・ライフの指摘のみで完了しています。モネロの作業は、すでにチェーン・ネットテストと開発者レビューを通過しています。
プロトコルの通常のアプローチに忠実に、XMR poolは、浅い（プロトコルが保有する）流動性と小規模なテストスワップから先に開始されます。これによりユーザーの資金は当面の間、対象外に保たれ、チェーンクライアントが本番環境で自信を持って機能することを証明するまで待つわけです。
「壊すなら、小さく壊せ」とAaluxxは述べました。
ZEC on the THORChain sideにはタイムラインがありません。ボトルネックは帯域（bandwidth）です。返金、セキュリティ作業、ネットワークの再起動、そしてモネロのローンチはすべて、同じ狭い「レビュー＆デプロイの窓」を奪い合っており、攪拌（churn）は先に行われます。
MocaはMayaとTHORChain経由で暗号ポスβ版（ポイント・オブ・セール）をローンチ
決済面は、エコシステムとして別のアップデートが用意されました。Mocaは暗号のポイント・オブ・セール（販売時点）および決済ネットワークで、Maya Protocol、THORChain、そしていくつかの他のバックエンドを通じて取引を決済します。目標は、一般の加盟店が暗号を受け取り、暗号のまま摩擦なく決済できるようにすることです。結果として、現実世界の取引量がそのプロトコル群に戻ってくることを狙っています。
β版は意図的に控えめで、当初は宣伝をせず、次々の月曜の後の月曜にローンチすることを狙っています。事業用アカウントを開設し、フィードバックを集め、実際のテスト決済を行い、より広い展開の前にバグを潰す計画です。
「Mayaの決済側が、私たちの手元に来たんだ」とMocaのEricOnchainは述べました。
早期のAPIアクセスに関心があるビルダーは、EricOnchainまたはMoca accountに直接連絡できます。
FAQ
なぜTHORChainのバルブローテーションは現在停止しているのですか？
攪拌プロセスに特に紐づいたコンセンサス問題には、Thornodeレベルでの修正が必要です。これらの変更はポイントリリースでの出荷では対応できないため、v3.20の完全なアップデートがデプロイされるまでバルブローテーションは停止したままとなります。
最近のTHORChainの悪用の原因は何でしたか？
それぞれ単体では無害だった3つの古いバグが、順番に発動されたときに悪用可能になりました。その組み合わせにより、THORChainの5つのバルブのうちの1つが侵害され、TVLの約20%が流出する結果となりました。
THORChainの稼働停止中、Maya Protocolはどのようにスワップを維持しましたか？
Mayaは、チームが独立して侵害されていないと検証できる単一のバルブを運用していました。そのバルブを稼働させ続け――予防として攪拌を停止したうえで――THORChainが1か月にわたって停止している間ずっと、スワップの処理を継続しました。
