一、⭐ 资料的优先级
同一起事故，不同来源的可信度差很多。按这个顺序读：
① ⭐⭐ 链上交易本身
攻击交易的 calldata、内部调用树、状态变更
⟹ 唯一不会撒谎的来源
② ⭐ 项目方的官方事后复盘（post-mortem）
有具体代码行、有时间线的那种
⚠️ 注意：早期公告常常不准确，要看最终版
③ 安全公司的技术分析
通常有攻击交易的逐步解读
④ ⚠️ 新闻报道
金额经常有出入、机制经常被简化到失真
⭐ 只用来定位事件，不用来理解机制
⭐ 本档案的金额都标注为"约数"，且区分了「涉案」与「最终损失」——因为公开来源之间的差异常常达到数倍（第 10 篇的 $5.7 亿 vs $1 亿就是一例）。
二、自己动手复现
⭐ 读十遍复盘，不如把攻击在本地跑一遍。
【环境】
Foundry —— forge test --fork-url <RPC> --fork-block-number <N>
⭐ 分叉到攻击【之前】的那个区块，
然后自己写一份攻击合约，看它能不能成功
【为什么这件事值得做】
□ 你会发现复盘里省略的细节
□ ⭐ 你会知道"这个漏洞在我的代码里长什么样"
□ 修好之后再跑一遍 ⟹ 验证修复真的有效
适合动手复现的几篇（机制清晰、依赖少）：
[第 1 篇](https://blog.ifcalm.org/posts/security/blockchain/01-the-dao/) 重入 —— 二十行就能写出最小复现
[第 9 篇](https://blog.ifcalm.org/posts/security/blockchain/09-bec-batch-overflow/) batchOverflow —— 一行乘法，手算即可验证
[第 19 篇](https://blog.ifcalm.org/posts/security/blockchain/19-erc4626-inflation/) 第一存款人 —— ⭐ 最适合入门，纯算术
[第 12 篇](https://blog.ifcalm.org/posts/security/blockchain/12-bzx/) 闪电贷操纵 —— 需要分叉主网，但路径清晰
[第 18 篇](https://blog.ifcalm.org/posts/security/blockchain/18-euler-finance/) 自我清算 —— 逻辑精巧，值得完整实现一遍
三、工具
【静态分析】
Slither —— ⭐ 免费、快、误报可控。至少跑一遍
Semgrep —— 自己写规则，扫"我们团队特有的坏味道"
⭐ 用法：写一条规则扫出所有【裸算术】、
所有【无修饰符的 external 函数】、
所有【未检查的返回值】
⟹ 让"漏掉一处"变成机器能发现的事（[第 9 篇](https://blog.ifcalm.org/posts/security/blockchain/09-bec-batch-overflow/)）
【测试】
Foundry fuzz —— ⭐ 让工具替你找边界值（[第 8 篇](https://blog.ifcalm.org/posts/security/blockchain/08-bitcoin-value-overflow/)、[第 11 篇](https://blog.ifcalm.org/posts/security/blockchain/11-cetus-mask/)）
Foundry invariant —— ⭐⭐ 本档案反复推荐的那几条不变量
Echidna —— 属性测试，适合复杂状态机
【形式化验证】
Certora / Move Prover / Halmos
⚠️ 记住它的边界：⭐ 证明的是"实现符合规约"，
不是"规约是对的"（[第 11 篇](https://blog.ifcalm.org/posts/security/blockchain/11-cetus-mask/)）
【链上分析】
区块浏览器的内部调用树 —— 看攻击交易到底调了什么
⭐ Tenderly 一类的模拟器 —— 逐步执行、看每一步的状态变更
Foundry 的 cast run —— 命令行重放一笔交易
【监控】
⭐⭐ 一个每分钟读余额的脚本 ——
几十行，是本档案投入产出比最高的一条（[第 22 篇](https://blog.ifcalm.org/posts/security/blockchain/22-ronin-bridge/)）
四、⭐ 读一份新复盘时该问什么
这是一份可以直接用的流程（对应第 24 篇的"把同行的复盘当作自己的待办"）：
① 失效的是哪一条假设？
⭐ 不要停在"这是重入"，
要说出"它默认了什么，而那个默认为什么不成立"
② 它属于哪一类？（C1–C7）
⟹ 归类是为了知道"我该去检查我的哪部分代码"
③ ⭐ 我的系统里有没有同一条假设？
逐条对照，不确定的就去读代码
④ 如果有，我现在的防御是什么层次的？
结构性（不依赖人）？还是程序性（依赖人）？
⑤ ⭐ 这份复盘里，有没有提到"某个信号被忽略了"？
⟹ 那个信号在我这里对应什么？
⑥ ⚠️ 把"有问题"的那几条变成工单，
把"没问题"的那几条写下理由 ——
⭐ 因为半年后情况可能变了
五、⭐ 本档案刻意没有覆盖的
① 中心化交易所的【运营失败】
挪用客户资产、资不抵债、欺诈
⭐ 理由：那不是安全问题，是治理和监管问题。
本档案只收录有【技术复盘】的事故。
② 诈骗、拉盘砸盘、"跑路"
⭐ 理由：它们不涉及任何被绕过的技术防线。
③ 单纯的前端钓鱼 / 假网站
⚠️ 除非它构成了对签名流程的攻击（[第 23 篇](https://blog.ifcalm.org/posts/security/blockchain/23-wazirx/)、[第 25 篇](https://blog.ifcalm.org/posts/security/blockchain/25-bybit/)）
⭐ 理由：那是终端安全问题，有更成熟的资料。
④ 具体审计公司的方法论与报告模板
⭐ 理由：变化快，且与"理解漏洞"这个目标无关。
⑤ ⚠️ 2026 年年中之后的事故
资料截止于此。⭐ 如果你在更晚的时间读到这里，
请自行补上这段空白 —— 并按第四节的流程处理它们。
六、怎么继续
⭐ 三条不同方向的路：
① 想理解机制为什么这样设计
⟹ [CS 251：区块链系统原理](https://blog.ifcalm.org/posts/blockchain/)
尤其第 35 讲（漏洞的结构分类）、
第 31 讲（预言机）、第 24 讲（调用语义）
② 想动手
⟹ 按第二节挑一篇，在 Foundry 里复现一遍
⟹ 然后把[检查清单](https://blog.ifcalm.org/posts/security/blockchain/90-checklist/)里对应的那几条
应用到自己的代码上
③ ⭐ 想建立长期的习惯
⟹ 把[检查清单](https://blog.ifcalm.org/posts/security/blockchain/90-checklist/)做成季度例行事项
⟹ 订阅几个安全团队的复盘，按第四节的流程处理
⟹ ⭐ 每季度演练一次应急响应
⭐ 最后一句：这个档案里 29 起事故，没有一起是因为攻击者比防守方聪明。 每一起的根因，在事后看都简单得令人难受——而这正是它们值得被逐条读一遍的原因。