<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>链上安全事故档案 on 我在栀南镇的日子</title>
    <link>https://blog.ifcalm.org/posts/security/blockchain/</link>
    <description>Recent content in 链上安全事故档案 on 我在栀南镇的日子</description>
    <generator>Hugo -- 0.147.7</generator>
    <language>zh-cn</language>
    <lastBuildDate>Mon, 31 Aug 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.ifcalm.org/posts/security/blockchain/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>第 1 篇：The DAO——重入的原型</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/01-the-dao/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/01-the-dao/</guid>
      <description>2016 年 6 月，约 360 万 ETH 从 The DAO 流出，直接导致以太坊硬分叉与 ETH/ETC 分裂。漏洞只是一个语句顺序问题：转账写在了余额清零之前。这一篇拆开它的完整调用栈，说明为什么「转账」在 EVM 里等于「交出控制权」，并把重入的六个变体逐一列出——其中至少三个在今天仍然被写错。</description>
    </item>
    <item>
      <title>第 2 篇：Lendf.Me——当代币标准自带回调</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/02-lendfme-erc777/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/02-lendfme-erc777/</guid>
      <description>2020 年 4 月，Lendf.Me 被重入掏空约 2500 万美元。它的代码 fork 自当时被认为安全的 Compound，一行没改错——问题是团队自己上架了一个 ERC-777 代币，而这个标准在转账时会回调转出方。这一篇讲清楚「代码正确」和「前提成立」的区别，并列出十种会打破 ERC-20 心智模型的代币。</description>
    </item>
    <item>
      <title>第 3 篇：只读重入——没有写操作也能被打穿</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/03-readonly-reentrancy/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/03-readonly-reentrancy/</guid>
      <description>一个只读的 view 函数，不改任何状态，却让一批协议在 2022–2023 年间连续损失数千万美元。原因是：被读的那个协议在自己的函数执行到一半时，把控制权交了出去，于是外部读到了一个「中间状态」。最反直觉的是受害者——出事的从来不是被读的那个协议，而是读它的人。</description>
    </item>
    <item>
      <title>第 4 篇：Parity 多签（一）——没人锁的初始化函数</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/04-parity-multisig-1/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/04-parity-multisig-1/</guid>
      <description>2017 年 7 月，约 15 万 ETH 从 Parity 多签钱包被取走。漏洞是一个本该只被调用一次的初始化函数，没有任何访问控制——任何人都能把自己设成钱包的 owner。这一篇拆解 delegatecall 的存储语义为什么让这个错误变得致命，并给出「代理模式下哪些函数必须被锁死」的完整清单。</description>
    </item>
    <item>
      <title>第 5 篇：Parity 多签（二）——51.3 万 ETH 被永久锁死</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/05-parity-multisig-2/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/05-parity-multisig-2/</guid>
      <description>2017 年 11 月，有人在无意中把 Parity 的新版钱包库据为己有，然后销毁了它。所有依赖这个库的钱包同时变砖，约 51.3 万 ETH 至今取不出来。这一篇讲三件事：实现合约本身也是一个活合约、可用性失效比资金失窃更不可逆，以及 Cancun 之后这个攻击为什么打不成了——而它的教训为什么仍然成立。</description>
    </item>
    <item>
      <title>第 6 篇：Poly Network——把自己变成签发方</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/06-poly-network/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/06-poly-network/</guid>
      <description>2021 年 8 月，约 6.11 亿美元从 Poly Network 跨链桥流出，当时是史上最大。攻击者没有偷任何私钥，也没有破解任何密码学——他让桥的管理合约「自己」把签名者名单改成了他的公钥。这一篇讲混淆代理人攻击、四字节函数选择器可以被暴力碰撞，以及为什么「持有权限的合约不能同时是通用调用转发器」。</description>
    </item>
    <item>
      <title>第 7 篇：Nomad——一个零值引发的公开哄抢</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/07-nomad-bridge/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/07-nomad-bridge/</guid>
      <description>2022 年 8 月，Nomad 桥被掏空约 1.9 亿美元。技术原因只有一行：一次例行升级把可信根初始化成了 0，而未经证明的消息查表也返回 0，于是「任何消息」都通过了验证。更值得研究的是它的第二重灾难——攻击交易公开在链上后，数百个地址复制粘贴、只改收款地址，把它变成了一场公开哄抢。</description>
    </item>
    <item>
      <title>第 8 篇：比特币值溢出——唯一一次凭空造币</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/08-bitcoin-value-overflow/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/08-bitcoin-value-overflow/</guid>
      <description>2010 年 8 月 15 日，区块 74638 里出现了一笔凭空产生 1844 亿枚比特币的交易——总量的八千多倍。漏洞不在业务逻辑里，而在验证代码本身：检查「输出之和不超过输入」时，那个加法自己溢出了。这一篇讲为什么「校验代码里的算术」是最危险的一类算术，以及为什么必须同时校验单项和总和。</description>
    </item>
    <item>
      <title>第 9 篇：BEC batchOverflow——一个乘法毁掉一个代币</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/09-bec-batch-overflow/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/09-bec-batch-overflow/</guid>
      <description>2018 年 4 月，BEC 代币被凭空铸出 2×2²⁵⁵ 枚，交易所紧急下架，价格归零。最讽刺的是：这个合约通篇都在用 SafeMath，唯独出问题的那一行乘法是裸的。这一篇讲「防护措施用得不一致等于没用」，以及 Solidity 0.8 之后仍然会静默溢出的三个地方。</description>
    </item>
    <item>
      <title>第 10 篇：BNB 桥——证明验证里的实现缺陷</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/10-bnb-bridge-iavl/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/10-bnb-bridge-iavl/</guid>
      <description>2022 年 10 月，攻击者伪造了一份 Merkle 证明，让 BNB Chain 的跨链桥凭空增发约 200 万 BNB。密码学本身没有问题，出问题的是那份证明验证代码的实现——它没有完整约束证明的结构。这一篇讲 Merkle 证明必须绑定的三样东西，以及「暂停整条链」这个止损手段暴露了什么。</description>
    </item>
    <item>
      <title>第 11 篇：Cetus——2025 年的溢出仍值两亿美元</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/11-cetus-mask/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/11-cetus-mask/</guid>
      <description>2025 年 5 月，Sui 上的 Cetus 被掏空约 2.2 亿美元。原因是一个手写的溢出检查用错了位掩码，导致本该被拒绝的输入通过了检查、随后被静默截断——攻击者用约一个单位的代币换到了天文数量的流动性份额。这一篇讲手写溢出检查为什么比裸算术更危险，以及 Move/Rust 这类「更安全的语言」为什么并不豁免。</description>
    </item>
    <item>
      <title>第 12 篇：bZx——闪电贷时代的开场</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/12-bzx/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/12-bzx/</guid>
      <description>2020 年 2 月两起 bZx 攻击，金额只有约一百万美元，却是此后所有价格操纵攻击的模板。它第一次公开演示了三件事：闪电贷让「临时拥有巨额资金」变成一次函数调用、链上现货价格可以在一个区块内被推到任意位置、以及组合多个协议可以造出没人单独设计过的攻击路径。</description>
    </item>
    <item>
      <title>第 13 篇：Harvest Finance——在存取之间套走差额</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/13-harvest-finance/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/13-harvest-finance/</guid>
      <description>2020 年 10 月，Harvest Finance 损失约 3400 万美元。它和 bZx 的区别在于攻击的对象：不是借贷协议的抵押品估值，而是一个金库的「份额价格」。攻击者在同一个区块里以低价存入、以高价取出，重复三十多次。这一篇给出一条应该刻在每个金库合约上的不变量：存入再立即取出，必须永远亏钱。</description>
    </item>
    <item>
      <title>第 14 篇：Compound DAI——预言机没坏，钱没了</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/14-compound-dai/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/14-compound-dai/</guid>
      <description>2020 年 11 月，Compound 清算了约 8900 万美元的仓位。没有人攻击它，没有节点撒谎，没有任何代码有 bug——预言机忠实地报告了一个真实发生过的价格，而那个价格来自一次流动性不足的短时脱锚。这一篇讲整个档案里最重要的一类失效：每个组件都符合规范，而系统整体是错的。</description>
    </item>
    <item>
      <title>第 15 篇：Cream Finance——不需要池子的价格操纵</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/15-cream-finance/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/15-cream-finance/</guid>
      <description>2021 年 10 月，Cream Finance 损失约 1.3 亿美元。这次的价格操纵没有动用任何 DEX——攻击者直接往一个金库里「捐」了一笔钱，金库的份额价格立刻翻倍，而 Cream 正是按这个份额价格给抵押品估值的。这一篇讲「捐赠攻击」：一次没有任何函数被调用的状态变更，如何让一个正确的除法算出错误的答案。</description>
    </item>
    <item>
      <title>第 16 篇：Mango Markets——薄盘就是攻击面</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/16-mango-markets/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/16-mango-markets/</guid>
      <description>2022 年 10 月，Mango Markets 被掏空约 1.14 亿美元。攻击者做的事在协议规则内每一步都合法：他先在自家平台开一个巨大的多头，再去外部薄盘市场把标的价格拉起来，让「未实现盈利」变成可借贷的抵押品。这一篇讲三件事：把浮盈当抵押品的危险、协议自身代币做抵押的循环依赖，以及攻击者用赃款投票决定是否归还的荒诞结局。</description>
    </item>
    <item>
      <title>第 17 篇：Beanstalk——闪电贷借来的绝对多数</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/17-beanstalk/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/17-beanstalk/</guid>
      <description>2022 年 4 月，攻击者用一笔约十亿美元的闪电贷，在同一笔交易里买到治理代币、投票、通过提案、执行提案、把协议资产转给自己、还清贷款。整个过程完全符合协议规则。这一篇讲治理攻击的标准形态，以及为什么「提案有 24 小时等待期」这句话在这里毫无作用。</description>
    </item>
    <item>
      <title>第 18 篇：Euler——把自己变成可清算的</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/18-euler-finance/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/18-euler-finance/</guid>
      <description>2023 年 3 月，Euler Finance 损失约 1.97 亿美元。漏洞是一个「捐赠」函数少了一次健康度检查——它能减少调用者自己的余额，而开发者认为「只减少自己的东西不可能有害」。攻击者用它把自己变成严重资不抵债，再自己清算自己，吃掉最高档的清算折扣。这一篇讲一条应该无条件执行的规则：任何可能让账户变差的操作，结束前必须检查健康度。</description>
    </item>
    <item>
      <title>第 19 篇：ERC-4626 第一存款人——一个还在反复出现的模式</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/19-erc4626-inflation/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/19-erc4626-inflation/</guid>
      <description>这一篇不是单一事故，而是一个从 2021 年至今仍在造成损失的模式：往一个空金库里存 1 wei，再直接捐入一万个代币，下一个存款人无论存多少都会因为向下取整而拿到 0 份额。它把捐赠攻击、舍入方向、除法精度三个问题压缩在同一个公式里，是检验一个人是否真正理解份额数学的最好例子。</description>
    </item>
    <item>
      <title>第 20 篇：Curve / Vyper——源码没错，编译器错了</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/20-curve-vyper/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/20-curve-vyper/</guid>
      <description>2023 年 7 月，几个 Curve 池被重入攻击，损失约 7000 万美元。这些池子的源码里写着重入锁，逐行读挑不出任何毛病——问题是编译它们的那几个 Vyper 版本生成的锁不起作用。这一篇讲编译器是你信任基础的一部分，以及一个已经部署的、不可变的合约踩了编译器 bug 之后能做什么。</description>
    </item>
    <item>
      <title>第 21 篇：Wormhole——没被验证的那个账户</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/21-wormhole/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/21-wormhole/</guid>
      <description>2022 年 2 月，攻击者伪造了一组守护者签名，从 Wormhole 桥凭空铸出 12 万枚 wETH，约 3.26 亿美元。签名验证的代码是有的，密码学也是对的——缺的是一步：它没有确认「用来验证签名的那个系统账户」是不是真的。这一篇讲一条容易被漏掉的规则：作为地址传进来的东西，也是需要被验证的输入。</description>
    </item>
    <item>
      <title>第 22 篇：Ronin——四把钓来的钥匙和一把忘了收回的</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/22-ronin-bridge/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/22-ronin-bridge/</guid>
      <description>2022 年 3 月，约 6.25 亿美元从 Ronin 桥流出。攻击者没有碰任何一行合约代码：他通过一份伪装成工作邀约的文件拿到了四把验证者私钥，第五把来自一项几个月前为应付流量高峰临时授予、事后从未撤销的代签权限。事故发生六天后才被发现——因为有用户提不出钱。</description>
    </item>
    <item>
      <title>第 23 篇：WazirX——你签的不是你看到的</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/23-wazirx/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/23-wazirx/</guid>
      <description>2024 年 7 月，约 2.35 亿美元从 WazirX 的多签钱包被转走。多签正常工作、硬件钱包正常工作、签名者本人也确实按了确认——问题是他们在屏幕上看到的交易内容，和他们实际签署的字节不是同一个东西。这一篇讲盲签：一个多签钱包在什么条件下会退化成一个单签钱包。</description>
    </item>
    <item>
      <title>第 24 篇：Radiant Capital——同一模式的第三次</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/24-radiant-capital/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/24-radiant-capital/</guid>
      <description>2024 年 10 月，Radiant Capital 损失约 5000 万美元。攻击手法和三个月前的 WazirX 几乎一样：多个签名者的设备被植入恶意软件，前端显示正常而签出的是攻击载荷。真正值得研究的是它的复盘里那句话——签名失败需要重签，在团队看来是「多签钱包的常见现象」。这一篇讲异常的常态化：安全事故最可靠的前兆，是一个被大家习惯了的小毛病。</description>
    </item>
    <item>
      <title>第 25 篇：Bybit——史上最大，且全程合规</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/25-bybit/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/25-bybit/</guid>
      <description>2025 年 2 月，约 14.6 亿美元从 Bybit 的冷钱包被转走，是有记录以来单笔最大的加密资产盗窃。攻击者入侵的不是 Bybit，而是它使用的多签钱包服务的一台开发者机器，然后给特定的签名者推送了篡改过的前端。签名者批准的是一个替换钱包实现的 delegatecall。合约、密码学、多签门槛、硬件钱包——全部正常工作。</description>
    </item>
    <item>
      <title>第 26 篇：密钥失窃的六个变体</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/26-key-theft-variants/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/26-key-theft-variants/</guid>
      <description>把六起「私钥没了」的事故放在一起看：Mt. Gox、Bitfinex、Harmony、Mixin、HTX/Heco、DMM。它们没有精巧的技术细节可讲，正因为如此更值得研究——它们合计的损失超过了这个档案里所有合约漏洞的总和，而每一起的根因都写不满三行。</description>
    </item>
    <item>
      <title>上线前检查清单</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/90-checklist/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/90-checklist/</guid>
      <description>把这个档案里 29 起事故压缩成一份可以逐条打勾的表。每一条后面都标着它对应哪一起事故——不是通用建议，是有人为它付过钱的教训。按「写代码时 / 部署前 / 上线后」三个阶段组织。</description>
    </item>
    <item>
      <title>术语表</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/95-glossary/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/95-glossary/</guid>
      <description>档案里用到的攻击手法、防御机制与安全概念，按七个漏洞类别组织，每条标注出处篇号。</description>
    </item>
    <item>
      <title>复盘来源与工具</title>
      <link>https://blog.ifcalm.org/posts/security/blockchain/96-resources/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.ifcalm.org/posts/security/blockchain/96-resources/</guid>
      <description>写这个档案时用到的资料类型、可以自己动手复现的工具链，以及一份「读一份新复盘时该问什么」的流程。附本档案刻意没有覆盖的方向。</description>
    </item>
  </channel>
</rss>
