第 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

第四部分，损失：总金额是多少、按哪个时点的价格计算、
最终由谁承担（协议金库 / 存款人 / 代币持有人 / 保险基金 / 其他）。

第五部分，单独列出：
- 哪些内容你有明确来源，来源是什么
- 哪些内容你是根据同类事故推断的
- 哪些内容你查不到

规则：不确定的一律写「查不到」。不要为了完整而补一个看起来合理的
交易哈希、地址或数字。

真实案例

改一个变量

带走的问题

本章自测