一

先把那13秒摆在桌面上。

Beanstalk 是一个无抵押的算法稳定币协议，它的稳定币叫 Bean，目标锚定1美元。它的治理代币叫 Stalk。要拿到 Stalk，你得把资产存进协议的存款仓（Silo），存款会按时间累积 Seed，Seed 再每小时生成 Stalk——一套鼓励长期存款的设计1。问题出在另一条路径上：当你把流动性凭证（LP 代币）存进 Silo 的那一刻，与之对应的 Stalk 是即时记入的。投票权在存入的同一个区块里就生效，没有等待，没有快照，没有冷却。

攻击者地址是 0x1c5dCdd006EA78a7E4783f9e6021C32935a10fb42。这个地址在动手前一天，已经悄悄提交了一份编号 BIP-18 的提案。提案的措辞看上去像是给乌克兰捐款的善举（攻击者还另配了一份 BIP-19，真的写着向乌克兰捐25万美元的 Bean，作为障眼），但 BIP-18 的实际内容是：把 Beanstalk 金库里的全部资产，转到攻击者控制的合约。这份提案静静躺在那里，等待被通过。

Beanstalk 的治理有一个叫 emergencyCommit 的函数。正常提案要走完整的生命周期，但 emergencyCommit 允许：只要某份提案获得了三分之二的超级多数票，且提案已存在满24小时，任何人都可以立即执行它，跳过剩余流程1。这个函数检查的是当下这一刻的票数。攻击者要做的，就是在某一个区块里，凭空制造出三分之二的票。

13秒里发生的事，按顺序是这样的：借10亿美元的闪电贷，换成稳定币，存进 Silo 换成即时生效的 Stalk，凑过三分之二门槛，调用 emergencyCommit 执行 BIP-18，金库被掏空，赎回存款，还掉闪电贷。这一串动作全部在一笔原子交易里完成——要么整笔成功，要么整笔回滚。它成功了。

这一章要回答的问题只有一个：为什么一台号称“代码即法律”的机器，会允许有人用一笔借来的、十几秒后就归还的钱，合法地把自己买下来。

二

把上面那一幕抽象成一句话，可以得到一条贯穿本章所有案例的通用定律：

当一个 DAO 的法定票数门槛，低于市场上可借入或可租用的治理代币比例，并且投票权在执行的同一区块内即时结算时，这个 DAO 就能被一笔闪电贷的手续费买下。

这条定律的三个条件缺一不可，拆开看每一个都不复杂。

第一个条件是闪电贷的存在。闪电贷是 DeFi 独有的一种操作：你可以在一笔交易里借出巨额资金，只要在同一笔交易结束前归还（外加一点手续费），中间这笔钱怎么用都行；如果还不上，整笔交易回滚，等于没发生过，出借方零风险3。它把“拥有一大笔钱”这件事，从一种需要资本和时间的状态，变成了一种几乎免费的、瞬时的临时权限。对治理而言，这意味着任何在公开市场上能买到的治理代币，理论上都能在一个区块里被临时“租”来。

第二个条件是低门槛。如果一个 DAO 通过提案只需要全部代币的某个比例投赞成，而这个比例的代币恰好挂在某个借贷池、某个 AMM 池子里随时可借可换，那么门槛形同虚设。安全研究者把这类收益叫做“治理可提取价值”（governance extractable value）：借治理代币、投票、执行、还款，全在一个原子交易里完成，攻击者从头到尾不需要真正持有这些代币哪怕一秒钟之后45。

第三个条件是即时结算，也就是 Beanstalk 栽的地方。如果投票权是按“提案创建时”或“某个过去区块”的持仓快照来计算的，闪电贷就失效了——你借来的代币在那个历史快照里并不存在。Beanstalk 的致命之处，是它在执行的同一刻去问“现在谁有票”。

这条定律其实是一条更古老的暗线的极端形态。Vitalik Buterin 在2021年就指出过币投票治理的根本毛病：经济利益与投票权可以被拆开，通过包装、借贷、交易所托管等方式，一个人可以握有投票权却不承担相应的经济风险6。闪电贷只是把“拆开”这件事压缩到了13秒、压缩到了零成本。而代币分布的现实让门槛这一条更脆弱：对多个主流协议的测算显示，前十名投票者就能控制相当比例的票权7，这意味着可流通、可借入的代币占比往往远高于人们的直觉。门槛越低、流动性越深、结算越即时，买下一个 DAO 就越便宜。

接下来的几个案例，是这条定律在真实链上的不同变体。有的精确符合三个条件，有的绕过其中一条另辟蹊径，还有一个反过来证明：当门槛真的足够高时，攻击者会失败。

三

回到 Beanstalk，把13秒里的每一帧补全。这是本章的标本，因为它最干净——没有预言机操纵，没有重入，没有私钥泄露，纯粹是治理机制被按规则利用。

机制。 Beanstalk 用 Stalk 作为治理票，用 emergencyCommit 作为快速执行通道。执行紧急提案需要三分之二超级多数1。Stalk 通过把资产存入 Silo 获得，其中存入白名单内的 LP 代币可以立即换得大量 Stalk。整个系统对“投票权能不能被瞬间堆起来”这件事毫无防备。

步骤。 攻击者先在4月16日提交 BIP-18（恶意提案，掏空金库）和 BIP-19（捐款诱饵），让它们满足“存在满24小时”的条件。等到4月17日，攻击者发起那笔决定性交易：

从 Aave 闪电贷约10亿美元——这是当时链上规模罕见的一笔闪电贷1。具体构成是1.5亿 USDT、5亿 USDC、3.5亿 DAI，外加在 Uniswap V2 上换得的约3200万美元 Bean 和在 Sushiswap 上换得的约1100万美元 LUSD。

把这些稳定币注入 Curve 的 3pool，铸出约9.64亿个 3CRV，再换成约7.95亿个 BEAN3CRV-f LP 代币；另一边用3200万 Bean 加2.65亿 LUSD 铸出约5890万个 BEAN3LUSD-f LP 代币1。

把这两批 LP 代币存进 Silo。因为 LP 存入即时计入 Stalk，攻击者在这一瞬间获得了超过三分之二的总 Stalk——按事后测算约为79%的投票权4，稳稳越过66.7%的超级多数线。

调用 emergencyCommit 执行 BIP-18。这里是病灶的核心：BIP-18 的执行方式是 delegatecall 到提案指定的合约。delegatecall 会在 Beanstalk 自己的存储与权限上下文里运行目标合约的代码——也就是说，提案代码以协议本身的身份，对协议金库为所欲为8。BIP-18 指向的合约把金库资产悉数转出。

赎回 Silo 存款，归还 Aave 的闪电贷与手续费。一笔交易闭合。

原语。 三件 DeFi 原语被串在一起：闪电贷（瞬时巨额资金）、即时结算的治理票（Stalk 随 LP 存入生效）、delegatecall（让提案以协议身份执行任意逻辑）。任何一件单独都不致命，组合在一个原子交易里就成了致命的。

金额。 金库被转走的资产名义价值约1.82亿美元；扣除偿还闪电贷、市场滑点等成本后，攻击者实际净得约8000万美元13。攻击者随后把24,930.71枚 ETH（按当时价约7620万美元）分成270笔，全部送进 Tornado Cash 混币1。

结局。 Beanstalk 的 Bean 几乎瞬间脱锚归零，协议停摆。开发团队事后通过社区众筹和重新发行尝试重启。资金没有追回。多家审计与取证机构——Merkle Science、CertiK、Omniscia——分别复盘后给出了一致的结论：这不是一个 bug，而是机制设计允许的一次“合法”执行1910。

暴露的弱点。 Beanstalk 同时踩中通用定律的全部三个条件：门槛（三分之二）可被市场上可借的资金量覆盖；投票权（Stalk）随 LP 存入即时结算，无任何快照机制；emergencyCommit 提供了一条绕过正常时间锁的同区块执行通道，而它执行用的还是 delegatecall。三者叠加，使一份提前埋好、看似无害的提案，能在借来的钱还没捂热时就被自己批准并执行。CertiK 与多方复盘都把 emergencyCommit 这条快速通道点名为病根：它存在的理由是“紧急情况下要快”，但正是这个“快”，删掉了所有本可以拦住攻击者的等待时间9。

Beanstalk 是教科书式的样本。下一个案例则说明，即使一个 DAO 把上面三条都防住了——有快照、有真实持币者投票——攻击者仍可以从另一个更隐蔽的角度切入。

四

2023年5月20日，Tornado Cash 的治理被接管。这一次的精妙之处在于：攻击者拿到的票，绝大部分是真实投票产生的；漏洞不在“谁有票”，而在“投票批准的代码，和最终执行的代码，根本不是同一份”。

机制。 Tornado Cash 的治理是标准的提案-投票-执行结构。一份提案部署成一个逻辑合约，治理合约通过 delegatecall 执行该合约的代码。投票者在投票时看到的，是这个逻辑合约当时的字节码。整套信任建立在一个假设上：某个地址上的代码，从投票到执行之间不会变。攻击者要做的，就是打破这个假设。

步骤。 攻击者提交了 Proposal 20，提案创建的交易哈希为 0x34605f…e0d1112。表面上，这是一份看起来正常、值得通过的提案，社区据此投了约70万张真实赞成票。提案逻辑合约里藏着一个 emergencyStop() 函数，函数体是 selfdestruct(payable(0))——自毁。

投票通过、票数收集完毕之后，攻击者调用了这个自毁函数，把提案逻辑合约从链上抹掉。这笔自毁交易的哈希是 0xd3a570af795405e141988c48527a595434665089117473bc0389e83091391adb13。

合约自毁后，那个地址变成了空地址。攻击者利用 CREATE2 的特性，在同一个地址 0xc503893b3e3c0c6b909222b45f2a3a259a52752d 上，重新部署了一份完全不同的字节码1114。投票者批准的是旧代码，现在挂在那个地址上的是新代码。治理合约执行时认地址不认内容，于是 delegatecall 调用了攻击者新写的恶意逻辑。

新逻辑做了一件事：它通过 delegatecall 直接改写治理合约的存储，给大约100个攻击者预先部署的“僵尸合约”——每个里面锁仓为0——各自记上10000张票11。约100万张凭空捏造的票，加上提案本来收集到的约70万张真实票，攻击者一举掌握了治理。这笔执行兼造票的交易哈希为 0x3274b6…486d11。

原语。 selfdestruct（抹掉已批准的代码）、CREATE2（在同一地址重新部署不同字节码）、delegatecall（用恶意逻辑改写治理合约自身的存储）。三者组合实现了一次“批准和执行调包”。

金额。 攻击者随后掏空了治理金库，转走473,000枚 TORN11。其中约10万枚 TORN 被换成54枚 ETH，另有372枚 ETH 被送进 Tornado Cash 自身的混币池；这笔提币交易的哈希为 0x13e2b7…b941115。事件曝光后，TORN 价格两天内下跌约四成。

结局。 这里出现了全章最反常的一幕。约一周后的5月26日，攻击者主动提交了一份新提案，把此前被篡改的治理参数恢复原状，把控制权交还给社区11。为什么一个刚刚得手的攻击者要归还控制权，外界众说纷纭：有人认为是良心，有人认为是怕被追踪，有人认为他从一开始就只想证明这个漏洞存在。无论动机如何，它留下了一个事实：当治理逻辑可以被这样调包时，攻击者拿走的不只是金库，而是整套治理本身的解释权。

暴露的弱点。 Tornado Cash 没有踩中 Beanstalk 那三条——它的票来自真实投票，没有靠闪电贷瞬时堆票。它的弱点更底层：治理通过 delegatecall 执行一个地址上的代码，而这个地址上的字节码在投票之后可以被改变。投票者审查、批准、信任的是投票当时看到的那份代码；执行的却是一份在中途被 selfdestruct 加 CREATE2 替换过的代码11。“某地址上的代码不可变”这个被默认成立的前提，在以太坊上其实不成立。当一个系统把“代码即法律”当作信条，却没意识到法律条文本身可以在表决与生效之间被替换，“即法律”的那段代码就成了攻击面。

五

2022年7月23日，音乐流媒体平台 Audius 的治理被接管。这一次的入口既不是闪电贷，也不是代码调包，而是一个更经典的智能合约缺陷：可升级代理的存储槽碰撞。

机制。 Audius 用可升级代理模式部署治理与金库合约：一个代理合约持有存储和资产，逻辑合约负责执行，逻辑可以替换升级。这类合约通常有一个 initialize() 初始化函数，由一个 initializer 修饰符保护，保证它只能被调用一次——初始化时设定好管理员、权重等关键参数后就永久锁死。Audius 的代理在存储布局上发生了碰撞：保护 initialize() 的那个“是否已初始化”标志位，与另一个存储变量占用了重叠的槽，导致这个标志位实际上没能锁住函数1617。initialize() 可以被重新调用。

步骤。 攻击者重新调用了 initialize()，把自己写进了治理的关键参数，从而能够设定自己的投票权重16。第一次尝试提交的恶意提案（试图委托一笔天文数字的 AUDIO 投票权）没有通过，第二次成功18。通过的恶意治理提案，把社区金库里的1800万枚 AUDIO（按当时价约600万美元）转到了攻击者钱包，随后被抛售，套现约108万美元1617。

原语。 可升级代理的存储槽碰撞，使本应一次性的 initialize() 重新可调用——这把“谁有权设定投票权重”的钥匙交到了攻击者手里。

金额。 1800万枚 AUDIO 被转走，市值约600万美元，攻击者实际套现约108万美元16。

结局。 Audius 团队在攻击者第一次尝试约半小时后就收到警报，不到一小时定位了漏洞，部署补丁并夺回控制权16。响应速度在本章诸案例里算快的。事后，Audius 基金会对受影响的质押者进行了赔付19。

暴露的弱点。 Audius 的问题不在治理机制的票数门槛，而在治理合约的工程实现：可升级代理的存储布局没有被严格管理，一次存储槽碰撞让 initializer 形同虚设，攻击者得以重新初始化整个治理，给自己安排投票权重。它提醒人们，治理攻击的入口未必是经济学上的“门槛太低”，也可以是工程上的“初始化没锁住”。一个 DAO 的治理安全，最终取决于它最薄弱的那个存储槽。

六

如果说前几个案例都需要相当的技术含量，那么 Build Finance DAO 的覆灭则朴素得几乎令人难堪：没有闪电贷，没有调包，没有存储碰撞。攻击者只是把一份失败的提案，改个钱包、重新提交了一遍，而这一次没人在看。

机制。 Build Finance 是一个小型 DAO，治理用 BUILD 代币，提案通过即可执行，包括增发代币、动用金库这样的高权限操作。它的法定门槛低，没有时间锁，没有守护者（guardian）可以否决恶意提案，整个防线依赖社区成员盯着治理面板和 Discord 里的机器人提醒。

步骤。 2022年2月初，一个名为 Suho.eth 的地址先提交了第一份恶意提案，试图获得单方面增发 BUILD 的权力。这一次社区注意到了——一位叫 0xSHA2 的管理员在 Discord 里发出警告，提案被投票否决20。

攻击者没有放弃。他把治理代币转到一个全新的钱包，用新地址把同样的提案重新提交了一遍。这一次，本应自动播报新提案的 Discord 机器人没有捕捉到它；提案在低关注、低参与的状态下，于2月10日悄然通过2021。

拿到增发权后，攻击者分三笔增发了1,107,600枚 BUILD，砸向 Balancer 和 Uniswap 上的流动性池换走资产，又通过治理合约接管了 Balancer 池子，转走130,000枚 METRIC20。

原语。 这里没有花哨的原语，只有一个流程缺陷：失败的提案可以换个地址原样重投，而监控这件事的是一个会漏报的机器人和一群不可能24小时盯盘的志愿者。

金额。 约160枚 ETH、合约47万美元的资产被盗，经 Tornado Cash 转移20。更彻底的是，攻击者保留了对治理合约、增发私钥和金库的全部控制权，这个 DAO 实际上被杀死了20。

结局。 Build Finance 没能恢复。它不像 Beanstalk 那样有社区试图重启，也不像 Audius 那样有基金会赔付。一个治理代币、一个金库、一套合约，连同那个会漏报的机器人，一起归于沉寂。

暴露的弱点。 Build Finance 把治理速度两难的一端走到了尽头：它快、它轻、它依赖人的注意力。低法定门槛意味着一小撮代币就能通过提案；没有时间锁意味着提案通过即执行，社区即使事后发现也来不及阻止；没有守护者意味着没有任何一方有权在最后一刻按下暂停。当所有自动化和制度防线都缺席时，剩下的唯一防线是“有人正好醒着并且正好在看”——而攻击者只需要等到没人看的那个时刻。

七

前面五个案例里，治理的“快”是攻击者的帮凶：要么同区块即时执行，要么提案通过即生效。Compound 在2021年秋天的遭遇，把这件事翻到了反面——这一次，治理的“慢”，让一个本可以几分钟内堵住的窟窿，流了好几天的血。它不是一次攻击，而是一次 bug；但正因为它不是攻击，才更说明问题：同一个缺陷，快会被攻击者利用，慢则在出事时救不了自己。

机制。 Compound 是主流借贷协议，治理用 Governor 加 Timelock 的标准组合：提案要经过投票，通过后进入时间锁队列，等待数天延迟后才能执行22。这套设计的初衷，恰恰是防住前几节那种“提案通过即被恶意执行”的攻击——给社区留出反应时间。它在正常时候是优点。

步骤。 2021年9月底，一份名为“拆分 COMP 奖励分发并修复 bug”的 Proposal 62 通过并激活23。激活后人们发现，新代码里有一处单字符的错误，导致 Comptroller 合约错误地超额分发 COMP 奖励。

错误一旦上线，就开始持续向用户多发 COMP，而且这段代码已经不可变。约28万枚 COMP（按当时价约8000万美元）处于风险中；其中约24万枚（约7000万美元）已经被错误地发了出去，另有约4万枚（约1300万美元）随时可能继续泄漏，唯一拖慢出血速度的，是一个叫 Reservoir 的合约按固定速率滴出 COMP 的限制22。

要堵住它，得发新提案、投票、再等时间锁。Proposal 63 用来停止继续分发，Proposal 64 用来真正修复 COMP 累积的 bug2425。但每一份提案都得走完整的投票加时间锁周期——大约7天。在这7天里，代码明知有错，社区明知在漏钱，却没有任何人有权立即热修。创始人 Robert Leshner 只能公开呼吁那些收到多发 COMP 的人把钱退回来，还提醒他们这可能构成应税事件，最终只收回了一部分2226。

原语。 这里的“原语”是治理流程本身：强制的提案加时间锁周期，在紧急情况下变成了一种无法绕过的延迟。不可变的合约代码，意味着没有管理员能直接打补丁。

金额。 约8000万美元的 COMP 处于风险敞口，其中约7000万美元已被错误发放22。

结局。 多发出去的 COMP 部分被自愿退回，事件没有演变成攻击，但它清楚地展示了慢治理在急症面前的无力。

这是同一个缺陷的另一面。 Beanstalk 死于治理太快——快到攻击者能在13秒里走完借钱、夺权、掏空、还钱的全套动作。Compound 困于治理太慢——慢到一个已知的 bug 必须流血7天才能被合法地堵上。一个 DAO 如果设了时间锁，它就挡不住自己想快的时候；如果不设，它就拦不住别人想快的时候。快与慢之间没有一个对所有情况都正确的设定，只有针对不同威胁的不同妥协。把执行权交给一套不能临机决断的规则，意味着在紧急时刻，没有人能为这套规则负责，也没有人能推翻它。

八

把六个案例并排放在一起，弱点的清单是清楚的：可被瞬时堆起的投票权、同区块执行、低法定门槛、可被调包的执行代码、锁不住的初始化、漏报的监控、以及在急症前无法热修的流程。针对这些弱点，行业摸索出的缓解手段，几乎每一条都是在直接否定通用定律的某个条件。

提案创建时快照投票权。 这是针对“即时结算”那一条最直接的反制。把计票的依据，从“执行时谁有票”改成“提案创建那个区块（block N-1）谁有票”。闪电贷借来的代币在那个历史区块里并不存在，于是借票投票当场失效。Compound、Uniswap 等用 Governor 加快照机制的协议，正是靠这一条把 Beanstalk 式的同区块夺权挡在门外427。Beanstalk 缺的恰恰就是它——Stalk 随 LP 存入即时生效，从来没有快照。学界也在继续往这个方向推进，提出按时间加权的快照框架，让短暂持有的代币权重趋近于零，进一步压缩闪电贷的可乘之机28。

ve 锁仓让代币不可被闪电贷。 另一条路是从代币本身下手。投票托管（vote-escrow）模型要求：想要投票权，就得把代币锁仓一段时间（数周到数年），锁仓期间不可转让、不可赎回。闪电贷的前提是“借了能在同一笔交易里还回去”，而锁仓的代币根本动不了，借票这件事在物理上就不成立6。投票权和“愿意把资金锁住承担时间风险”被绑回了一起。

执行时间锁。 在提案通过和实际执行之间，强制插入一段延迟，给社区留出发现并反应的窗口——可以是触发紧急暂停，可以是用户提前撤资。这正是 Compound 设计 Timelock 的本意，它确实能挡住“提案通过即被恶意执行”那一类攻击。代价上一节已经说清楚：同样的延迟，在自己的代码出 bug 时，会变成拖累。

足够高的法定门槛。 这一条最朴素：把通过提案所需的票数门槛，设到高于攻击者能借到或买到的代币比例。门槛够高，通用定律的第一个条件就不成立。本章唯一一个用纯数学战胜攻击者的案例，靠的就是它。

Swerve Finance 是一个早已停止运营的 Curve 仿盘。创始人当年把控制权完全交给了社区，没有留下管理员，于是一个约130万美元、无人治理的金库就这样挂在链上，成了一个持续的靶子29。2023年3月，攻击者出手了：地址 A 持有348,000枚 SWRV，地址 B 持有102,000枚，合计45万张票，提交了两份要把金库所有权转走的提案2930。提案失败了。原因只有一个：Swerve 要求达到全部供应量51%的法定门槛，而攻击者凑不齐这个数。对峙僵持了一周多，金库分文未失2930。一个被所有人遗忘、没有任何团队守护的金库，最后是被一行“需要51%”的门槛规则守住的。它是本组案例里唯一一次，攻击者输给了纯粹的算术。

对比一种混合打法。 高门槛也不是万能。当攻击者能绕过“借票”这条路，转而操纵别的输入时，门槛就不一定够用。2022年5月，BSC 上的 Fortress Protocol 同时遭遇治理与预言机两路夹击：攻击者先用约11.4枚 ETH 在市场上买入约40万枚 FTS（约占供应量的4%），提交并自投通过了一份修改 FTS 抵押参数的提案，再去操纵 Fortress 所用的 Umbrella Network 预言机，把 FTS 的喂价拉到极高，用被高估的抵押品借空了协议里的各种资产，约300万美元被掏走3132。它提醒人们：治理攻击常常不单独出现，而是和预言机操纵、闪电贷、可升级合约缺陷搭配成组合拳，单一一条防线挡不住所有打法。

把这些手段并排看，会发现它们其实是在不同维度上反对同一件事：让投票权脱离时间、脱离风险、脱离真实的代码内容而被临时获取。快照让票绑定历史，锁仓让票绑定时间，时间锁让执行绑定窗口，高门槛让通过绑定真实的多数。每一条都在试图把被拆开的东西重新绑回去。

九

回头看这六个标本，会发现“治理攻击”这个词其实有点用词不当。除了 Audius 那次存储槽碰撞和 Compound 那处单字符 bug 算工程缺陷，Beanstalk、Tornado Cash、Build Finance 里没有一行代码被违反地执行。攻击者借了能借的钱，存了能存的款，投了能投的票，执行了能执行的提案，归还了该还的贷款。从虚拟机的视角看，这些交易和一笔普通转账没有任何区别——它们全部合法。

这把“代码即法律”这句口号推到了它最尴尬的位置。如果法律就是代码，那么 Beanstalk 攻击者完全守法：他做的每一步都是 Beanstalk 的合约明文允许的。被违反的不是代码，而是写代码的人脑子里那个没有写进合约的假设——“不会有人真的借10亿美元来投一次票”、“某个地址上的代码不会在投票后被换掉”、“提案通过总会有人在看”。这些假设从未被编译进字节码，于是它们不构成法律的一部分，攻击者也就没有义务遵守。

通用定律说到底是一句关于权力藏身处的话。当法定门槛低于可借的代币比例、且投票权即时结算时，一个 DAO 的控制权就沉淀在了闪电贷的可达性里——它不在任何一个持币者手上，而在“任何人只要付得起一笔手续费就能临时调用”的那片公共流动性里。Beanstalk 的开发者以为权力分散在 Stalk 持有者之间，实际上它一直挂在 Aave 的借贷池上，标价几百美元，随借随还。

那些有效的缓解手段，没有一个是在让 DAO 变得更去中心化或更“代码即法律”。快照、锁仓、时间锁、高门槛、守护者否决——它们都是在往代码里重新塞进时间、摩擦和人的判断，是在承认纯粹的、即时的、无摩擦的链上治理本身就是攻击面。最稳的那些设计，恰恰是最不像“自动机器”的那些：让票必须锁很久，让执行必须等几天，让某个多签有权在最后一刻喊停。

于是问题没有合上，而是被推得更远：如果防住治理攻击的办法，是不断往去中心化治理里加回时间锁、加回门槛、加回守护者这些带有中心化气味的摩擦，那么一个真正安全的 DAO，和一个装着代币投票界面的传统机构，差别还剩下多少？Swerve 那个被51%门槛守住的金库，到底是去中心化治理的胜利，还是它的让步？这些问题，下一章会从“治理剧场”的角度接着追问。

参考文献

  1. Merkle Science, “Hack Track: Analysis of Beanstalk Flash Loan Attack,” https://www.merklescience.com/blog/hack-track-analysis-of-beanstalk-flash-loan-attack, 2022。
  2. Etherscan, Beanstalk 攻击者地址 0x1c5dCdd006EA78a7E4783f9e6021C32935a10fb4 链上记录, https://etherscan.io/address/0x1c5dCdd006EA78a7E4783f9e6021C32935a10fb4, 2022。
  3. Aave, “Flash Loans” 官方文档, https://docs.aave.com, 2022。
  4. dacian, “Governance Attacks / Flash-Loan Voting”（治理可提取价值教学分析）, https://dacian.me, 2023。
  5. QuillAudits, “DAO Governance Attack Vectors”, https://www.quillaudits.com, 2023。
  6. Vitalik Buterin, “Moving beyond coin voting governance”, https://vitalik.eth.limo/general/2021/08/16/voting3.html, 2021-08-16。
  7. Fritsch, Müller, Wattenhofer, “Analyzing Voting Power in Decentralized Governance,” arXiv:2204.01176, https://arxiv.org/abs/2204.01176, 2022。
  8. dacian / QuillAudits 关于 delegatecall 在治理执行中风险的说明, https://dacian.me, 2023。
  9. CertiK, Beanstalk 事件安全分析, https://www.certik.com, 2022。
  10. Omniscia, Beanstalk Farms 攻击事后复盘（post-mortem）, https://omniscia.io, 2022。
  11. ZAN, “Unpacking the Tornado Cash Governance Attack,” https://medium.com/@zan.top/unpacking-the-tornado-cash-governance-attack-15b40691ca2e, 2023。
  12. Etherscan, Tornado Cash Proposal 20 创建交易 0x34605f…e0d, https://etherscan.io/tx/0x34605f, 2023。
  13. Etherscan, Tornado Cash 提案合约自毁交易 0xd3a570af795405e141988c48527a595434665089117473bc0389e83091391adb, https://etherscan.io/tx/0xd3a570af795405e141988c48527a595434665089117473bc0389e83091391adb, 2023。
  14. Etherscan, Tornado Cash 恶意逻辑合约地址 0xc503893b3e3c0c6b909222b45f2a3a259a52752d, https://etherscan.io/address/0xc503893b3e3c0c6b909222b45f2a3a259a52752d, 2023。
  15. Etherscan, Tornado Cash 治理攻击提币交易 0x13e2b7…b94, https://etherscan.io/tx/0x13e2b7, 2023。
  16. Cointelegraph, “Audius governance hack” 事件报道, https://cointelegraph.com, 2022。
  17. ChainLight, Audius 治理合约存储槽碰撞漏洞分析, https://chainlight.io, 2022。
  18. CryptoSlate, Audius 漏洞与 18M AUDIO 被盗报道, https://cryptoslate.com, 2022。
  19. Cointelegraph, Audius 基金会赔付受影响质押者的后续报道, https://cointelegraph.com, 2022。
  20. Decrypt, “Build Finance DAO Falls to Governance Takeover,” https://decrypt.co/92970/build-finance-dao-falls-to-governance-takeover, 2022。
  21. The Block, Build Finance DAO 治理夺权事件报道, https://www.theblock.co, 2022。
  22. The Block, “Compound bug puts COMP at risk / misreward,” https://www.theblock.co/amp/linked/119086/compound-bug-comp-risk-misreward, 2021。
  23. Compound Governance, Proposal 62 “Split COMP Rewards Distribution and Bug Fixes,” https://compound.finance/governance/proposals/62, 2021。
  24. Compound Governance, Proposal 63（停止继续分发）, https://compound.finance/governance/proposals/63, 2021。
  25. Compound Governance, Proposal 64 “Fix COMP Accrual Bug,” https://compound.finance/governance/proposals/64, 2021。
  26. Cointelegraph, Compound COMP 误分发与 Leshner 呼吁退还的报道, https://cointelegraph.com, 2021。
  27. Olympix, 治理攻击与快照/缓解手段说明, https://www.olympix.ai, 2023。
  28. “Time-Weighted Snapshot Framework for DAO Governance Voting,” arXiv:2505.00888, https://arxiv.org/abs/2505.00888, 2025。
  29. The Block, “Defunct Swerve Finance still subject of $1.3 million live governance hack,” https://www.theblock.co/post/222744/defunct-swerve-finance-still-subject-of-1-3-million-live-governance-hack, 2023。
  30. Halborn, Swerve Finance 治理接管尝试分析, https://www.halborn.com, 2023。
  31. rekt.news, “Fortress Protocol — REKT,” https://rekt.news/fortress-rekt, 2022。
  32. SlowMist, Fortress Protocol 治理与预言机组合攻击分析, https://slowmist.medium.com, 2022。