一

2021 年 9 月底，Compound 协议的治理合约里出现了第 62 号提案，标题平淡无奇：拆分 COMP 奖励的分发，顺带修几个 bug15。它接下来走的那条路，是当时整个 DeFi 世界里最标准的一条流水线，值得一步步看清楚。

提案不是发个帖子就算数。要让 Compound 的链上合约受理一笔提案，发起者控制的地址必须有至少 25,000 枚 COMP 的投票权委托在自己名下1。这是一道门。COMP 这枚代币本身是 2020 年 6 月那个被称作“DeFi 之夏”的起点——6 月 15 日开始按每天 2,880 枚的速度发给协议的借贷双方，上线第二天就一度成为市值最高的 DeFi 资产2。两万五千枚 COMP 在当时是一笔不小的持仓，这道门把绝大多数地址挡在了提案权之外。

跨过门槛，调用 propose()，提案进入合约，状态机开始计时。第一段是 2 天的审查期，Compound 文档里叫 voting delay：提案已经登记，但还不能投票，给社区留出读代码、发警报的窗口1。这 2 天在合约源码里并非写死的具体天数，而以区块计：投票延迟最少 1 个区块，最多 40,320 个区块（约一周），具体取哪个由治理自己设定3。

审查期一过，投票期开启，持续 3 天。任何把 COMP 委托给自己或别人的地址都可以投赞成、反对或弃权。这里有第二道门，也是更关键的一道：赞成票必须累计到至少 400,000 票，提案才算达到法定人数（quorum）1。四十万票的门槛意味着，单靠提案人自己那两万五千枚远远不够，必须说服一批大户把票投过来。

3 天投票结束，赞成过线、超过反对，提案进入“成功”状态。但成功不等于生效。成功的提案被推进一个叫 Timelock 的合约排队，再等 2 天，任何人（不限于提案人）都可以调用 execute()，让提案里那段动作真正落到链上1。25,000 的提案门槛、400,000 的法定票、2 天审查加 3 天投票加 2 天延迟，这套被简称为“2-3-2”的节律，从提案登记到动作生效，最快也要走满将近一周23。

整条流水线里没有任何一处需要人来“批准”。没有董事会签字，没有运营按一下确认。门槛、计票、延迟、执行，全部由合约自动判定。第 62 号提案就这样走完了全程，干净利落地生效了。问题在于，它修 bug 的同时带进来一个新 bug——这件事要到本章后半段才显出它的分量。先把机器看完整。

二

“2-3-2”这串数字看着像产品经理拍脑袋定的默认值，其实每一个都是一次权力的分配。把参数读懂，就读懂了谁能动这台机器。

Compound 治理合约的源码里，这些数字并非写死的常量，而是带上下限的可调参数。提案门槛最低可设到 1,000 枚 COMP，最高 100,000 枚；投票延迟从 1 个区块到约一周；投票期最短 5,760 个区块（约 24 小时），最长 80,640 个区块（约两周）3。也就是说，25,000、2 天、3 天这些具体值，是治理在允许的区间里自己选的一个点。把提案门槛调高，等于抬高发起提案的资格线，让能开口的人更少；调低法定票，等于让更小的一撮票就能拍板。每一次调参，都是在重画“谁有资格说话”和“多少票算数”的边界。

更要紧的是，这套合约本身是可升级的。Compound 的 Governor Bravo 用的是一种委托/被委托（delegate/delegator）的代理结构，逻辑合约可以被换掉，OpenZeppelin 在 2021 年对它做过专门的安全审计4。可升级意味着这台机器有一个“改自己”的开关，而这个开关同样握在治理手里。于是出现一种回环：决定参数的是投票，能不能改投票规则本身，也由按现行参数跑出来的那次投票决定。谁在某一刻凑得齐法定票，谁就能顺手把下一次的规则朝对自己有利的方向挪一格。参数不是中立的刻度，是上一轮权力博弈留在合约里的沉积层。

三

把视线挪到提案内部。投票通过的那一刻，机器到底执行了什么？

一笔链上提案的本体，是一组编码好的动作。每个动作由几样东西拼成：一个目标合约的地址（target），一笔要附带的以太币数量（value），以及一段叫 calldata 的字节5。calldata 才是真正干活的部分。它的开头是 4 个字节的函数选择器，由被调函数的签名做哈希后取前四字节得到，用来告诉目标合约“调你哪个方法”；选择器后面跟着这个方法的参数，按以太坊的 ABI 规则编码成定长的字节块。OpenZeppelin 的治理文档把这层说得很直白：链上操作就是把函数选择器和参数编码进 calldata，到执行时由合约原样发出5。

这意味着“提案”在机器眼里没有语义。一笔把利率参数从 5% 改成 6% 的提案，和一笔把整个金库转给某个地址的提案，在合约层面是同构的：都是“向地址 X 发送一段 calldata”。机器不读标题，不读论坛里那篇情真意切的提案说明，它只忠实地把那段字节发出去。提案标题写着“优化金库收益”，calldata 里编码的却是 transfer(攻击者地址, 全部余额)，机器照样执行，它没有能力察觉这种背离。链上治理后来发生的多起劫案，要害都在这条缝里：人读的是说明，机器执行的是字节，两者可以完全是两回事。

正因为执行是机械的、不可商量的，calldata 一旦随提案通过，就成了一发已经上膛、只等扳机的子弹。下一个问题自然就来了：在子弹打出去之前，有没有一道保险？

四

那道保险，就是 Timelock——强制时间锁。它是链上治理里最不起眼、却最能说明问题的一个零件。

机制本身简单到近乎笨拙。提案投票通过后，不立即执行，而是先进入 Timelock 合约排队，强制等待一段固定的延迟，期满之后才允许调用执行1。Compound 是 2 天。Uniswap 用的是几乎一模一样的结构：UNI 代币、Governor、外加一个 Timelock，而它的延迟在合约里被硬编码成最少 2 天，谁也改不动67。Aave 把这套做得更细：跨链的治理动作落到执行网络上的 PayloadsController，按风险分两档排队，普通动作锁 1 天，触及核心的锁 7 天，期满后任何人都能调 executePayload() 推动执行8。Aave 的治理投票甚至发生在一条网络上，执行落在另一条网络，中间靠一组跨链桥合约把动作转发过去9。MakerDAO 的版本年头最久也最有讲究：投票合约 DSChief 选出要执行的“咒语”（spell），动作不直接落地，先经过一个叫 GSM（Governance Security Module）的暂停延迟合约 DSPause，到点后再由 DSPauseProxy 用 delegatecall 在一块隔离的存储里把咒语执行掉1011。

形式各异，用意是同一个。延迟存在的理由，要从延迟“不存在”时会发生什么来理解。Beanstalk 协议 2022 年 4 月被一笔从 Aave 借来的、规模约 10 亿美元的闪电贷一击致命：攻击者用借来的钱在同一个区块里换成协议的治理凭证，瞬间凑出超过 67% 的投票权，触发一个绕过正常提案周期的紧急执行函数，把价值 1.82 亿美元的抵押品掏空，整套动作在十几秒内完成12。它之所以能成，关键是 Beanstalk 的投票权是“即时”测量的：同一个区块里借票、投票、执行、还款可以一气呵成，中间没有任何延迟把这串动作拆开12。

时间锁就是用来拆开这串动作的。它在“投票结束”和“动作生效”之间插进一段谁也跳不过的等待，让一个本来可以原子完成的攻击被迫暴露在光天化日下好几天。这段延迟真正保护的，是那些没投票、或投了反对票的人：哪怕一笔恶意提案靠着某种方式过了票，延迟也给所有人留出了在它落地之前把钱撤走的时间。Lido 在 2025 年上线的“双重治理”把这层意思做到了极致：stETH 的持有者可以把币存进一个托管合约，当存入量达到全部质押 ETH 的 1%，就给 LDO 治理强加 5 天的动态延迟；达到 10%，直接进入“愤而退出”（rage-quit）状态，冻结提案，让反对者在有争议的升级生效之前先撤离1314。延迟在这里不再只是技术参数，而是少数派对多数派的最后一道刹车。Timelock 的全部价值，可以压缩成一句话：它把“通过”和“生效”拆成两件事，好让那些不同意的人来得及离场。

五

延迟是保险，但同一道延迟，换个场景就成了枷锁。第 62 号提案的下半场，正好把这层讲透。

它上线后约 9 月 29 日生效，结果那段“修 bug”的代码里藏着一个只差一个字符的错误，导致 Compound 的 Comptroller 合约把 COMP 奖励超额发放15。窟窿有多大？据当时的报道，约 28 万枚 COMP（按当时价格约 8,000 万美元）处于风险中，其中约 24 万枚（约 7,000 万美元）已经被错误地发了出去，剩下约 4 万枚还在继续往外漏16。

要命的地方在于，谁也没法立刻按下停止键。Compound 的代码是不可变的，链上没有“热补丁”这种东西；想止血，唯一的办法是再走一遍完整的治理流程：发提案、等审查、投票、进 Timelock、再等延迟，前后又是将近一周16。于是出现了一幅近乎荒诞的画面：所有人都眼睁睁看着 COMP 一块一块往外流，却只能按部就班地走那套为“防止仓促决定”而设计的慢流程。社区先用第 63 号提案止住进一步分发，再用第 64 号提案补上那个字符级的 bug15。创始人 Robert Leshner 一度公开请求那些拿到不该拿的 COMP 的地址把钱退回来，还提醒他们不退可能要面对税务问题，最后只收回了一部分16。

这件事不是一次攻击，却比很多次攻击更说明问题。把延迟设短，机器对突袭的抵抗力就弱；把延迟设长，机器对自身错误的修复力就慢。同一段时间锁，挡攻击时是盾，救火时是镣铐。这是贯穿全书的一条暗线——治理速度的两难——它在链上执行这台机器上的第一次清晰显形，就是 Compound 第 62 号提案那将近一周里无人能止的失血。

六

到这里，机器的几个核心零件（门槛、calldata、Timelock）都拆开看过了。下一个要解释的，是这台机器怎么从 Compound 一家的自研件，变成了整个行业的标准货。

Compound 把这套东西第一次完整地跑通，叫 Governor Bravo。但真正让它扩散开的，是 OpenZeppelin 在 2021 年做的一件事：把 Compound 的 Governor Bravo 一般化，做成一套可复用的标准合约库17。原本要从头写、要单独审计的治理逻辑，被拆成一组可以像积木一样拼装的模块。

OpenZeppelin 的 Governor 把“投票”和“执行”解耦成可替换的组件。计票方式可以换，投票权来源可以换，最关键的执行层挂的就是 Timelock：文档里直接提供了两种现成的时间锁适配器，一种叫 GovernorTimelockControl，配 OpenZeppelin 自家的 TimelockController；另一种叫 GovernorTimelockCompound，专门兼容 Compound 那套 Timelock 合约5。一个新项目想要链上治理，不必再理解重入、delegatecall、存储布局这些底下的脏活，只要 propose → queue → execute 三步拼起来，就有了一套和 Compound 同构的投票机器5。

标准化是一把双刃的工具。好处显而易见：审计成本摊薄，bug 面收窄，几百个 DAO 共享同一套被反复检视的代码。代价同样实在：当几乎所有主流 DAO 的执行层都长一个样，它们也就共享同一类弱点。Compound 的 25,000/400,000/2-3-2、Uniswap 写死的 2 天延迟、MakerDAO 的咒语加 GSM23，骨架都是 propose-vote-timelock-execute 这一条。读懂了 Compound 这一台，就读懂了它们一大半。机器被库化、被复制成标准件，治理的多样性也随之收敛到了少数几种模板里。

七

前面拆的全是链上执行——投票、计票、延迟、落地，每一步都是一笔要付 gas、要进区块、不可撤销的交易。但行业里更常见的那种“投票”，其实根本不在链上。

那就是 Snapshot。它的做法是把投票彻底搬到链下：用户不发交易，只用钱包对一段消息做一次签名，整个过程不付一分钱 gas18。投票权的快照取自某个历史区块的代币余额，计票在链下完成，结果公示在网页上。对一个动辄上千持币地址的社区来说，这几乎是唯一可负担的大规模投票方式——链上投一次票的 gas 费，足以把绝大多数小持有者直接劝退。

代价是，这种投票什么也没“执行”。一次 Snapshot 投票的产物，是一份带着一堆签名的统计结果，本质上是一个信号——社区在这件事上的意向。它本身不会让金库里的钱挪动一分，不会改任何合约的任何参数。签名再多、共识再强，链上的状态机都收不到这个信号，因为它压根没被写进任何区块。Snapshot 投票测的是“社区想要什么”，而不是“合约会做什么”，这两者之间隔着的，正是这一章一直在拆的那台执行机器。

八

信号既然不会自己变成执行，那从信号到动作之间，就必须有人来搭一座桥。这座桥最古老、也最常见的形态，是一组多签钱包。

模式是这样的：社区在 Snapshot 上投出意向，然后由几个被信任的人组成的多签（比如 5 个里凑齐 3 个签名）按照投票结果，手动在链上发起对应的交易。绝大多数早期 DAO、以及今天许多挂着 Snapshot 牌子的项目，跑的都是这条链路。机器的执行键，在这里不在合约手里，而在那几个签名者手里。

把执行键交给人，就引入了一个链上执行从未有过的东西：那几个人可以不照办。多签的签名者完全有能力拒绝执行一项已经通过的投票，也有能力在执行时改动内容，甚至干脆装作没看见——投票对他们没有强制力，整套安排建立在“他们会忠实照办”这个信任假设之上18。这就是为什么有人把链下投票加多签执行的这套组合称作“软治理”，说得更刻薄些，是“治理剧场”：投票热热闹闹，可真正握着扳机的，始终是台下那几个签名者。它不是没有价值——它便宜、灵活、能在出事时由人临场叫停——但它的安全边界，等于那几把私钥的安全边界，以及那几个人的可信度。这是整条自治度光谱最靠下的那一档，也是后面几章里多起“投票通过却被推翻”事件的共同底色。

九

软治理那个“人可以不照办”的窟窿太显眼，于是有人想把它堵上：能不能既保留 Snapshot 链下投票的零 gas、低门槛，又让结果像链上提案一样被强制执行，把多签那几个人从环节里摘掉？2023 年之后的几座桥，干的就是这件事。

一条路是 UMA 做的 oSnap。它在 Snapshot 的链下投票之外，接了一套“乐观”执行：投票结束后，任何人都可以把这个结果连同对应的链上动作提交上去，配一笔保证金；在一段挑战期里，如果没人提出异议，动作就自动在链上执行；如果有人认为提交的动作不符合投票结果，可以发起争议，交由 UMA 的预言机来裁决19。它的卖点正是去掉多签：不再需要一组签名者来当二传手，链下投票通过乐观预言机直接驱动链上执行19。

另一条路更激进，是 Snapshot 自己的 Snapshot X。它把投票和执行都尽量推到链上，让智能合约直接强制执行投票结果，按其说法，“DAO 不再依赖多签签名者，因为合约会自动强制执行”20。

这两座桥的意义，在于它们暴露了链下与链上之间那道真正的分界。oSnap 用一段乐观挑战期加经济保证金来逼近强制执行，Snapshot X 用合约直接兜底。无论哪种，它们要消灭的都是同一个东西——多签那几个人的自由裁量。把这件事反过来看就清楚了：链下投票和链上执行的全部差别，最后落在“投票通过之后，还有没有一个人能说‘不’”这一个点上。桥的工程，就是想把这个能说“不”的人删掉。

十

把这一章拆出来的零件摆到一起，能排出一条由弱到强的自治度光谱。

最弱的一档，是纯 Snapshot 投票：链下签名，零 gas，产出一个信号，执行全靠台下的人，那几个人随时可以不认账。中间一档，是 oSnap、Snapshot X 这类桥，用乐观预言机或存储证明，把链下的票尽量焊死到链上的动作上，删掉自由裁量的人。最强的一档，是 Compound、Uniswap、Aave、Maker 这种全链上治理：提案就是编码好的 calldata，投票就是链上交易，通过之后进 Timelock 排队，期满任何人都能 execute()，没有任何一个环节留给人去“批准”或“拒绝”15。同一光谱上还散落着别的实验：DAOstack 让一批“预测者”拿钱押注提案会不会通过，用押注来动态调整法定门槛21；1Hive 的“信念投票”干脆取消离散的投票日，让支持随质押时间连续累积，攒够阈值就自动放款22。它们各自换了计票的逻辑，但只要执行那一步还落在链上合约里，就仍属于这条光谱靠强的那一端。

光谱的两端，差的究竟是什么？不是技术的复杂度，而是一个信任假设。链上执行假设你只需要信任那段已经公开、已经审计、谁也改不动的字节码；链下信号外加多签，则要你额外信任那几个握着私钥的人会照办。中间所有的桥，都是在想方设法把后面那个“信任几个人”的假设，换成前面那个“信任一段代码”的假设。整台投票机器存在的全部意义，就是把这个假设削到最薄。

但削到最薄，不等于削到没有。链上执行删掉了多签那几个人，却没删掉别的东西。25,000 的提案门槛、400,000 的法定票，决定了谁配开口、多少票算数，而这些参数本身又由按现行参数跑出来的投票来改。2025 年底，Uniswap 社区投票通过了那笔编号 93 的“UNIfication”提案：打开手续费开关、销毁 1 亿枚 UNI（约占总量 16%），全程链上，超过 1.25 亿枚 UNI 投赞成、对面只有 742 枚反对，轻松越过 4,000 万的法定线，通过后照例进 Timelock 排队2324。一笔牵动十几亿美元的决定，机器执行得完美无瑕。可赞成与反对那悬殊到 1.25 亿对 742 的比分背后，是谁手里攥着那么多票？机器忠实地清点了每一张签名，却从不过问这些票从哪来、是借的还是买的、代表的是经济利益还是别的什么。

机器越是可信，关于“谁在喂给它输入”的问题就越是要紧。这台投票机器忠实、透明、不可阻挡，它唯一不做的事，是替你看清楚站在它面前按下 propose() 的那个地址，到底是谁。

参考文献

  1. Compound Labs，《Compound v2 Docs — Governance》，https://docs.compound.finance/v2/governance/ ，访问于 2026 年。

  2. CoinDesk，《With COMP Below $100, a Look Back at the DeFi Summer It Sparked》，https://www.coindesk.com/business/2020/10/20/with-comp-below-100-a-look-back-at-the-defi-summer-it-sparked ，2020 年 10 月 20 日。

  3. Compound，GovernorBravoDelegate.sol（合约源码），https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol ，访问于 2026 年。

  4. OpenZeppelin，《Compound Governor Bravo Audit》，https://www.openzeppelin.com/news/compound-governor-bravo-audit ，2021 年。

  5. OpenZeppelin，《Governance — OpenZeppelin Docs》，https://docs.openzeppelin.com/contracts/4.x/governance ，2023–2024 年。

  6. Uniswap，《Governance Process》（官方开发者文档），https://developers.uniswap.org/docs/ecosystem/governance/governance-process ，访问于 2026 年。

  7. Uniswap，governance/contracts/Timelock.sol（合约源码），https://github.com/Uniswap/governance/blob/master/contracts/Timelock.sol ，访问于 2026 年。

  8. Aave，《Governance》（官方开发者文档，Gov V3 / PayloadsController），https://aave.com/docs/developers/governance ，访问于 2026 年。

  9. Aave，governance-crosschain-bridges（合约源码仓库），https://github.com/aave/governance-crosschain-bridges ，访问于 2026 年。

  10. MakerDAO，《Governance Module》（技术文档：DSChief / DSPause / ds-spell / DSPauseProxy），https://docs.makerdao.com/smart-contract-modules/governance-module ，访问于 2026 年。

  11. MakerDAO，《How Voting Works》（官方治理门户），https://community-development.makerdao.com/en/learn/governance/how-voting-works/ ，访问于 2026 年。

  12. Merkle Science，《Hack Track: Analysis of Beanstalk Flash Loan Attack》，https://www.merklescience.com/blog/hack-track-analysis-of-beanstalk-flash-loan-attack ，2022 年。

  13. Lido，《Dual Governance: An Overview》（官方博客），https://blog.lido.fi/dual-governance-overview/ ，2025 年。

  14. The Block，《Lido DAO votes to enable dual governance, giving stakers veto power》，https://www.theblock.co/post/360212/lido-dao-votes-to-enable-dual-governance-giving-stakers-veto-power ，2025 年 6 月。

  15. Compound，治理提案第 62 号（及 63、64 号），https://compound.finance/governance/proposals/62 ，2021 年 9–10 月。

  16. The Block，《Compound bug could put $80 million worth of COMP at risk》，https://www.theblock.co/amp/linked/119086/compound-bug-comp-risk-misreward ，2021 年 9–10 月。

  17. OpenZeppelin，《Introducing OpenZeppelin Governor》，https://blog.openzeppelin.com/governor-smart-contract ，2021 年。

  18. Cube，《What is off-chain governance?》（软共识与多签信任假设），https://www.cube.exchange/what-is/off-chain-governance ，2024 年。

  19. Clayton Roche（UMA），《Announcing oSnap: Gasless Snapshot Voting with On-Chain Execution by UMA》，https://medium.com/uma-project/announcing-osnap-gasless-snapshot-voting-with-on-chain-execution-by-uma-7374ed729b28 ，2023 年。

  20. BlockEden，《Snapshot X Brings On-Chain Execution to Gasless Voting》，https://blockeden.xyz/forum/t/snapshot-x-brings-on-chain-execution-to-gasless-voting…/542 ，2024 年。

  21. Eric Arsenault（DAOstack），《Voting Options in DAOs / Holographic Consensus》，https://medium.com/daostack/voting-options-in-daos-b86e5c69a3e3 ，2019 年。

  22. 1Hive，conviction-voting-app（合约源码仓库），https://github.com/1Hive/conviction-voting-app ，2020 年。

  23. Uniswap Foundation，《UNIfication — Agora Proposal 93》，https://vote.uniswapfoundation.org/proposals/93 ，2025 年 12 月。

  24. CoinDesk，《Uniswap Token Burn Moves Closer to Reality as 99% of Voters in Favor of Fee Switch Proposal》，https://www.coindesk.com/markets/2025/12/22/uniswap-token-burn-moves-closer-to-reality-as-99-of-voters-in-favor-of-fee-switch-proposal ，2025 年 12 月 22 日。