第24章 · なぜ Crypto では全損や攻撃が繰り返されるのか

現実の問題

同じ年、三人がそれぞれお金をすべて失った。

第一の人は借入プロトコルへステーブルコインを預けた。ある朝、価格操作で大量の不良債権が生じたと告知される。操作を誤っていないのに、預金が比例して削られた。

第二の人はプラットフォームへコインを置き、良い固定利回りを得ていた。ある日出金が停止され、三か月後に破産手続きへ入る。コインはまだあるが、債権者リストの上に載っている。

第三の人はウォレットを空にされた。秘密鍵もシードフレーズも失わず、偽サイトも開いていない。調べると、数か月前にサイトへ一度承認を署名し、その後サイトがコントラクトを変更していた。

事後には同じことを言う。Cryptoは安全でない。

間違いではないが、役に立たない。まったく異なる三つであり、一つを防ぐ方法は、ほかの二つにはまったく効かないからだ。第一には担保の価格源の理解、第二には「自分のコイン」と「プラットフォームが返す義務のあるコイン」の区別、第三には過去の承認の定期検査が必要だ。共通の防御行動はない。

だから、この章は事故リストではなく分類法だ。 名前も言えないものは防げない。「安全でない」を、名前、対応する問い、検査行動のある十種類に分けて初めて、できることが生まれる。

Part Aの最初の四ステージのリスクをまとめる章でもある。各章が仕組みを説明しながら残した「ここで問題が起きる」という伏線を、一枚の表へ集める。

思考実験

チェーンを離れ、倉庫の警備隊長に雇われたとしよう。

他人の品物を預かる倉庫だ。初日にすべきことは巡回ではなく、品物が出入りできるすべての経路のリストを作ることだ。

一周して、次を挙げた。

• 正面入口。誰でも入って業務を行え、壁のルールに従えばよい。
• 壁の秤。外の市場価格で品物を評価し、担保、引渡し、差押えすべてが依存する。
• 裏の運送経路。一部は別倉庫にあり、ここには証書しかない。
• 管理者の鍵束。正面のルールすべてを迂回できる。誰が持つか？
• 週一回の所有者会議。壁のルールを、どんな形にも変えられる。
• 床の耐荷重。品物のどれだけが借入やレバレッジによるものか？
• 出荷経路の幅。全員が同日に取りに来たら、入口はどれだけ広いか？
• 鍵を預かる隣の会社。その会社自体は信頼できるか？
• 自分の数え間違い。最後の棚卸しはいつか？

九つとも、品物が出ていく経路だ。「倉庫は安全か」よりずっと役立つ。

本当に重要なのは次だ。二つずつつなぎ、「これが壊れたら、あれも壊れるか」と問う。 驚くほど多い線ができる。任意の一本をたどろう。

秤を細工 → 品物が大幅に過小評価 → ルール上、安く持ち出せる → 出荷経路へ積んで売る → 経路が詰まる → 普通の引取人が受け取れない → 埋められない不足が残る → 所有者が緊急会議でルールを変える → 誰が会議に参加できるかが新しいリスクになる。

一本の連鎖、五つの経路、一つの事故だ。

最重要の一文の源になる。実事故はほぼ常に、扉一つが壊れることではなく、その後ほかの扉も続いて壊れることだ。

あなたが決める

プロジェクト報告の「リスク」を書く。どうするか？

結果を観察する

固定リストは次だ。コース全体で共通の統一リスクモデルで、卒業制作まで使う。

三点を明確にしよう。

第一に、網羅ではなく分類だ。 十種類はすべての可能性ではなく、重複せず、大半の実事故を覆うことを目指す。どれにも入らないリスクを見つければ、それ自体が記録すべき発見だ。

第二に、実際に働くのは右の列だ。 各種類が、調査して確定した答えを得られる問いになっている。監査の有無、アップグレード権限、価格の出所には答えがある。リスク管理が、予感ではなく資料を調べる作業になる。

第三に、核心として、実事故では十種類が同時に起きやすい。

次は仮定ではなく、近年何度も起きた同じ脚本だ。

表と一つずつ照合しよう。

各欄は制御可能でも、つなげると全損になる。

単一障害と複合事故の根本的な違いだ。

最後の行が追加の作業だ。十項目へのチェックは第一歩で、第二歩は、その間に矢印を描くことだ。

モデルを作る

コード、経済、人の三層

どの層で起きるかによって再分類すると、有用な分布が見える。

直感に反する推論がある。最も検査しやすい層は、最も損失が集中する層ではない。 監査はコードの誤りを見ても、数十万しか厚みのないプールを価格源にする判断の良し悪しを教えない。コードの誤りではなく設計の選択だ。チェーンで完璧に実行し、資金を抜く。

第16章の最後を補える。コードが完璧でも損失は出る。コードは三層の一つだけだからだ。

お金が出る五経路

複雑でも、最後は五つのどれかで出ていく。五十の事故名より、この五つを覚えよう。

第五は、唯一完全に自分側で起きるため強調する。誰かがプロトコルを破る必要はない。 数か月前の承認が無制限、永久、更新可能なコントラクト向けなら足りる。個人の総損失では最大かもしれず、唯一、自分だけで閉じられる経路だ。

リスクは足し算ではない

第17章では、収益は足し算、リスクは掛け算とした。後半をより正確にしよう。掛け算だけでなく、相関もある。

三プロトコルにまたがり、各々の一年無事故確率が97%とする。

独立なら：0.97 × 0.97 × 0.97 = 91.3%

通常は独立でない。同じオラクル、担保、ブリッジなら、一事故が三層を同時に破る。実際の結合リスクは91.3%よりずっと悪い。

評価へ一作業を加えよう。各層の依存先を列挙し、重なりを探す。

重なるほど、分散は偽物だ。 第18章の「場所を分けても分散でない」が一般法則となる。

各種類を調べられる問いへ

最後に行動へ変える。確定した答えを得られる記録にしよう。

種類：Oracle Risk
問い：価格源はどこか？ 操作可能か？
判明：A源とB源の中央値、30分の時間加重
出典：公式文書第X節 + コントラクト0x…（エクスプローラーで照合済み）
結論：単独プール操作の費用は上がるが、極端な相場では両源が同時にゆがみうる
不確実：価格更新停止時の縮退動作が見つからない → 未評価

六行を十件埋めれば終わる。鍵は最後だ。

リストの質は項目数ではなく、未評価を正直に示した項目数で決まる。

十項目すべて緑なのは無リスクより、調べていないためであることが多い。分析ツール箱では、十八問とProject Canvasと並べてある。研究時に直接使おう。

何と呼ぶか

実践

利用者の預金 → プロトコルのプール → ？ → ？ → 攻撃者アドレス → ？

AI Lab

[事故名とおおよその時期]を振り返ってください。

第一部：時間線。各行に、時刻（時区も明示）、出来事、
対応する取引ハッシュまたはブロック高、情報源リンクを付ける。

第二部：攻撃経路。どのコントラクトのどの関数を呼び、何を達成し、
なぜ設計がそれを許したか、一段階ずつ明示する。

第三部：次の十種類を「発動 / 未発動 / 判別不能」で評価し、
公開資料に基づく根拠一文を各項目に付ける。
Smart Contract / Liquidity / Oracle / Bridge / Custody /
Counterparty / Governance / Leverage / Token / Operational

第四部：損失。総額、どの時点の価格か、最終負担者
（トレジャリー / 預金者 / 保有者 / 保険基金 / その他）。

第五部：別に列挙する。
- 明確な出典のある内容と、その出典
- 同種の事故から推定した内容
- 見つからない内容

ルール：不確かなものはすべて「見つからない」とする。完全にするために、
もっともらしいハッシュ、アドレス、数字を補わない。

実例

変数を一つ変える

持ち帰る問い

章末チェック