DEXX リベレーション：トレーディングボットのセキュリティジレンマを乗り越えるためのオンチェーン生存法則
TechFlow厳選深潮セレクト
DEXX リベレーション：トレーディングボットのセキュリティジレンマを乗り越えるためのオンチェーン生存法則
高収益と絶対的な安全性の間には常に妥協が伴う。
Web3業界の深掘り報道に専念し潮流を洞察執筆：SafePal
「ダークフォレスト」——『三体』に由来する宇宙社会学の法則であり、現在のWeb3セキュリティ分野を最も率直に表した比喩でもある。ブロックチェーン上には無限の可能性と革新的なゲーム性がある一方で、まさに「ダークフォレスト」のように、血なまぐさいゼロサムゲームが渦巻いており、一般投資家は情報非対称の中で「狩られる側」として立たされている。
11月16日、複数のコミュニティユーザーから、DEXXというオンチェーン取引端末がハッキングされたとの報告があった。事後の分析により、DEXXの秘密鍵管理に明らかな脆弱性があり、平文での送信・保存さえ行われていたことが判明。現時点で不完全な統計によると、被害総額は2000万ドル以上にのぼる。
こうした状況下、一般ユーザーがどのようにオンチェーンでの自己防衛メカニズムを強化すべきかは、多くの人々が注目する重要な課題となっている。SafePal共同設立者兼CEOのVeronicaも、137Labs主催の𝕏 Spaceイベント「DEXX事件から考えるセキュリティ：暗号資産投資における“落とし穴”をどう回避するか？」に参加し、BlockSec創業者のAndy、ベテラントレーダー会所哥（ホイソーガー）、137Labs研究員OneOneらとともに、DEXXのセキュリティインシデントについて議論し、暗号資産投資家向けの実用的なセキュリティアドバイスを提供した。
本稿は、当該Twitter Spaceにおける各ゲストの発言を文字起こし・要約したものである。
フロントランBotツールの「許容できないリスク」
暗号資産投資において、高収益と絶対的安全性の両立はしばしば困難である。DEXXやUnibotなどのトレーディングBotツールは、ワンクリックでポジションをコピーできたり、資金移動が迅速だったりする点から人気を集めているが、こうした利便性は中央集権的なアーキテクチャに基づいている。つまり、ユーザーが資産の権限を委譲したり、ウォレットへのアクセスを許可したりする必要があり、その結果として資産リスクが著しく高まる。
しかしユーザーの多くは、こうした取引ツールが要求するセキュリティレベルを過小評価しており、大手取引所には慣れているものの、中小規模のツールプラットフォームのリスクには無頓着になりがちだ。今回のDEXX事件は、一部の取引ツールにおける秘密鍵管理の致命的な欠陥を露呈した——真の「ノンカストディウォレット」は、秘密鍵をユーザーの端末内にのみ保持すべきであり、中央サーバーに依存してはならない。仮に秘密鍵が暗号化されていても、TEE（Trusted Execution Environment）やenclaveなど、メモリレベルでのセキュリティ保護技術がなければ、盗難リスクを回避することは不可能である。
同時に、今回の攻撃手法は非常に巧妙で、ハッカーは資金を分散させて追跡を困難にしている。これにより資金回収が極めて難しくなっているだけでなく、今後同様のインシデントがさらに複雑かつ防御不能になる可能性を示唆している。このことから二つの可能性が浮上する：一つは技術的脆弱性によるプラットフォームの突破、もう一つは内部犯行または深層的な侵入である。特に後者の場合、将来のリスクはさらに深刻となるだろう。
Duneのデータによると、現在取引量トップ5のBotはTrojan、BonkBot、Maestro、Banana Gun、Sol Trading Botであり、いずれも7日間の取引量が1億ドルを超え、累計ユーザー数も30万人を超える。こうした背景もあり、「一攫千金か、ゼロになるか」というマインドセットが広がり、多くのユーザーが潜在的な巨大リスクを軽視している。
画像出典：Dune
Veronicaは、このような「フロントラン」型取引ツールのほとんどが同様のセキュリティリスクを抱えていると考えている。これらのBotが超高速のオンチェーン取引を可能にするのは、毎回手動で署名を行う必要がないためだが、これは安全性とノンカストディ特性の一部を犠牲にしている。
ハードウェアウォレット、アプリウォレット、ブラウザ拡張ウォレットを問わず、通常ユーザーは数秒かけて手動で署名確認を行うが、取引速度とユーザーエクスペリエンスを最適化するために、これらのBotは妥協する傾向にある。つまり、より迅速な取引成立のために、秘密鍵の安全性を最小限まで下げるのである。
こうした設計が根本的に誤っているとは言えないし、すべてのプロジェクトが危険であるとも単純に断じられない。しかし、これは開発チームのセキュリティ防御能力に対して極めて高い要求を突きつける。スムーズな体験を追求するあまり、開発チームが強固なセキュリティ体制を確保できていない場合、一度攻撃を受けたら甚大な被害が発生し、ユーザーもプロジェクト側も巨額の損失を被ることになる。
さらに、現在の大多数の取引Botは、自動化取引を実現するために顕著なセキュリティ上の懸念を抱えている。すなわち、各ユーザーに対して秘密鍵を生成し、それを自らが保管する方式を採用している。この方法はユーザーにとって自動コピーが便利ではあるが、極めて高いセキュリティリスクを伴う。もし攻撃者がプラットフォームを突破すれば、保存されたすべてのユーザー秘密鍵が漏洩し、資産損失につながる。
画像出典：DEXX「ウォレット管理」ページ
しかし実際には、ユーザーの秘密鍵を使わずとも自動取引を実現できるより安全なアーキテクチャが存在する。
それはスマートコントラクトに依拠するもので、ユーザーのアカウントに関連付けられた「PDAアカウント」を作成し、ユーザーの秘密鍵署名なしに取引を完了させる。プラットフォームは制限された「操作アカウント」を通じて取引命令を実行できるが、この操作アカウントの権限は厳密に制御されており、取引操作のみ可能で、ユーザー資産を自由に移動することはできない。
このスマートコントラクト駆動型の設計は、安全性を大幅に向上させることができる。なぜなら、ユーザーの秘密鍵は常に本人の手元にあり、中央サーバーに保存されることはないからだ。確かにこの設計はより複雑であり、開発チームの工学的能力とセキュリティ技術に対する要求も高くなるが、完全に実現可能であり、より安全である。
現在、ユーザーの多くはこうした二種類の設計の違いを理解していないか、あるいは利便性を優先して安全性を軽視している。しかし、セキュリティインシデントが頻発するにつれて、ユーザーと開発チーム双方がより安全なアーキテクチャの重要性に気づくようになり、このような先進的な設計が将来的に普及することで、DEXXのような事件の発生を減らせるだろう。
取引承認から秘密鍵保護までのWeb3セキュリティチェーン
OneOneは、現時点でのオンチェーンセキュリティリスクは大きく二つに分けられ、取引承認から秘密鍵保護まで含むと指摘する。
一つ目の一般的な攻撃方法は「Approve詐欺」である。例えば、「ダスト攻撃」によって少量の暗号資産やエアドロップNFTを送信し、ユーザーを誘導してクリック・承認操作を行わせる。この操作により、攻撃者はユーザーのウォレット権限を得て、暗号通貨やNFTを含むすべての資産を盗むことができる。ユーザーは不明な出所のトークンやエアドロップには注意深く対応し、安易に承認しないことが重要である。
秘密鍵の盗難は、主に以下の方法で発生する：
-
第一に「マルウェア攻撃」。例えば、攻撃者が新プロジェクトのテスト招待を装い、トロイの木馬を含む実行ファイルをダウンロードさせる。一度感染すると、ユーザーの秘密鍵やアカウントパスワードが簡単に盗まれる。
-
第二に「クリップボード攻撃」。攻撃者はフィッシングサイトを通じてユーザーのクリップボードアクセス権を取得。ユーザーが秘密鍵をコピー＆ペーストする際に、その情報を傍受して悪用する。
-
第三に「リモートコントロール攻撃」のケースもある。悪意のあるリモートソフトを使ってユーザーのPCを操作し、休憩中に直接秘密鍵を盗む例がある。例えば、エアドロップユーザーがよく使う「フィンガープリントブラウザ」などはクラウドストレージ機能を伴うことが多く、これが突破されれば資産は簡単に盗まれる。多くのユーザーがこうしたツールを使う際に二段階認証（2FA）を設定しておらず、リスクをさらに高めている。
-
最後に「入力法の脆弱性」。多くのユーザーがスマート入力法を好むが、これらの入力法はユーザーの入力データを収集しクラウドに保存する可能性があるため、秘密鍵漏洩のリスクが高まる。可能な限りOS標準の入力法を使用することを推奨する。機能は少ないが、セキュリティ面では遥かに優れている。
総合的に見ると、ユーザーはDeFiアプリや取引ツールを利用する際、追加のセキュリティ対策を講じる必要がある。特に「承認管理」は極めて重要である。イーサリアムの仕組み上、ユーザーはスマートコントラクトにトークンの使用権を付与する必要があるが、攻撃者はこの承認メカニズムを悪用して悪意ある操作を行うことができる。そのためユーザーは定期的にウォレットの承認リストを確認し、不要な承認は速やかに取り消すべきである。特に忘れ去られた初期の承認ほどリスクが高い。
また、DeFiプラットフォームを選ぶ際は、そのセキュリティ対策を検討すべきだ。包括的な監査レポートの有無、継続的な自動セキュリティ監視、定期的なアップデートや脆弱性修正の実施状況などを確認するべきである。トレーディングBotを使う際は、資産を分散管理することが推奨される。大きな資金をトレーディングBotが管理するアカウントに長期間置かないこと。利益が出たらすぐに、より安全なウォレットへ移動させることで、被害を最小限に抑えることができる。
会所哥は、トレーダーとして取引ツールやプラットフォームのメカニズムを理解することが極めて重要だと述べる。現在の投機的取引環境では、多くの人が価格の急騰・急落にばかり注目し、取引ツールのセキュリティリスクを無視している。ユーザーはプール枯渇や清算警告といった「セキュリティアラート」を設定すべきであり、常にリスクを把握しておくべきだ。
Veronicaは、シンプルながら極めて重要な原則を強調する：「効率的な利益追求」と「完全な安全」の間には常に妥協が存在する。最も重要なアドバイスは「資金の分離」である。もし投資ポジションが大きすぎて夜も眠れず、スマホを頻繁にチェックしてしまうようなら、それはあなたの資金配分がリスク耐性を超えている証拠だ。
使えるオンチェーンセキュリティ照会ツールは？
Veronicaは、SafePalなどのノンカストディウォレットに内蔵されたセキュリティツールの利用を推奨する。例えば、定期的に承認状況をチェックする機能がある。ユーザーは複数チェーンにわたるすべての承認記録をスキャンし、不要な承認をワンクリックで取り消すことができ、ハッカーに悪用されるリスクを低減できる。
画像出典：SafePal「Approval Manager」機能
また、現在の詐欺師はしばしば少量の送金を行い、ユーザー自身の送金アドレスと偽って資金を騙し取る。OKX Web3ウォレットやSafePalなどの主要ウォレットはすでに「先頭・末尾攻撃（First-Last Attack）」に対するリスク取引ブロッカー機能を搭載している。また、ハードウェアウォレット＋パスフレーズ（Passphrase）の組み合わせも、知られていないが非常に実用的な機能である。特に複数の取引アカウントを持つユーザーに適している。
パスフレーズは第13番目の単語として、従来の12語のリカバリーフレーズと組み合わせて、まったく新しいウォレットアドレスを生成する。誰かがあなたのリカバリーフレーズを入手しても、パスフレーズがなければ資産にアクセスできない。つまり、ユーザーはこの方法で複数のウォレットアカウントを作成でき、安全性を確保できる。
この方法は秘密鍵の安全性を高めるだけでなく、複数アカウント間での資産管理を柔軟に可能にする。また、パスフレーズはユーザーの頭の中だけで管理でき、セキュリティをさらに高められる。
Andyも指摘するように、ユーザーがセキュリティインシデントに遭う原因は、プロジェクト自体のリスクだけでなく、ユーザー自身のセキュリティ習慣の不足にもある。たとえ自分が持つ暗号資産が多く、投資取引にリスクがあることを理解していても、悪い習慣により資産を危険にさらしてしまうことが多い。
隔離されたセキュリティ意識と習慣を持つことを推奨する。例えば、大口資産はコールドウォレットに保管し、インタラクションはできても直接の資金移動はできないようにする。また、暗号資産管理専用のスマートフォン（iPhoneなど）を用意し、それだけを暗号資産取引や秘密鍵管理に使用する。この端末には取引関連以外のアプリをインストールせず、他の活動も行わない。こうすることで、秘密鍵漏洩のリスクを大幅に低減できる。
結び
DEXXのセキュリティ事件は、オンチェーン取引ツール分野における根本的なジレンマを明らかにした：利便性と安全性の間にいかにバランスを取るか？
効率的な取引とユーザーエクスペリエンスを追求する中で、プラットフォームのセキュリティ設計が犠牲になってはならない。秘密鍵の中央集権的保管、あるいはメモリレベルの保護技術の不足などは、ユーザー資産を極めて高いリスクにさらすことになる。
「高収益と絶対的安全の間には常に妥協が存在する」。投資家にとっては、取引ツールの背後にあるリスク構造を理解し、健全なセキュリティ習慣を身につけることが、オンチェーンの「ダークフォレスト」を生き抜くための基礎である。この非中央集権的で不確実性に満ちたエコシステムにおいて、自分の秘密鍵を握ることが、真に自分の資産を支配する唯一の道であり、それが健全なオンチェーンエコシステムの発展を促すのである。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
