DAO 是一套权力安排,不是一种固定软件。论坛、多签、代币、Governor 和 Timelock 各自只负责其中一段。
Ethereum · Chapter 14 · Lesson 01
没有 CEO,组织如何作出并执行决定?
DAO 不是把公司换成群聊,也不是让代码自动拥有智慧。它把 成员如何形成意志、谁拥有投票权、结果如何成为链上动作 拆成一套任何人都能检查的规则。
Governance control circuit / not a single contract
余额、票权与所有权是三件事。委托可以移动票权但不移动代币;治理代币也不天然等于股票。
真正改变状态的是 calldata 与权限。投票页面显示“通过”,只有在执行器确实持有相应角色时才会成为现实。
00 / ORIENTATION
先别问“哪个 DAO”,先问它在解决什么
正式目录主题:去中心化组织、治理代币与链上投票机制
想象 10,000 个互不认识的人共同管理一笔链上资金:没有共同银行账户, 没有一个天然可信的财务负责人,也没有 CEO 可以替所有人拍板。 他们必须先回答一组非常具体的问题。
谁属于组织?
持币者、NFT 持有人、受邀成员、贡献者,还是通过某种身份验证的人?一个地址是否等于一个人?
谁能提出行动?
任何人都能提案,还是必须积累一定票权、声誉或押金?高门槛能过滤垃圾,也可能垄断议程。
什么叫“同意”?
一人一票、一币一票、代表委托、简单多数、绝对多数与法定人数会产生完全不同的权力分布。
谁真正动用资产?
投票通过后由多签人工执行,还是由 Governor 与 Timelock 自动调用金库和协议合约?
- 本课中的 DAO
- 一套把成员资格、集体决策、资产控制与执行权限连接起来的可验证规则系统。 它可以依赖智能合约,也一定依赖人:代码负责约束可编码的部分,人负责讨论、解释、 研究、谈判和处理现实世界中无法被 EVM 直接判断的事实。
Ethereum.org 将 DAO 描述为围绕共同使命、由成员共同拥有的组织;其金库与规则 可以由智能合约约束,而不必把最终控制权交给单个领导者。[1] 但“DAO”不是一种全球统一的合约标准。两个都自称 DAO 的组织,可能在成员、票权、 管理员和法律身份上毫无相似之处。
四个必要部分,缺一就要补问
成员 / Members
谁有参与权、如何加入、能否退出,以及一个链上地址如何对应现实中的人或机构。
规则 / Rules
提案门槛、投票时钟、票权来源、计票方式、法定人数、否决和紧急流程。
资源 / Resources
金库里的 ETH 与代币、协议收入、域名、知识产权、服务账号以及现实法律实体。
执行器 / Executor
真正持有资产或管理员权限的合约与密钥:Timelock、多签、模块、基金会董事或工作组。
01 / ORGANIZATION
DAO 不是一个合约,而是一整条权力链
社会层形成意志,计票层汇总偏好,执行层改变状态,现实层承担链外义务
“去中心化”描述的是控制权如何分布;“自治”描述的是哪些动作能在规则满足后无需 额外裁量地执行。二者都不是开关,而是一条需要逐层检查的光谱。
研究、论坛讨论、会议、利益披露、代表竞选、预算说明与舆论。它决定谁掌握信息和议程。
成员资格、委托、快照、提案门槛、投票期、quorum、计票方式,以及通过或否决条件。
Governor、Timelock、Safe、多签模块、金库与协议权限。它决定“通过”是否真的能生效。
基金会、签约主体、雇员、银行账户、税务、域名与服务商。链上投票不能自动迫使链外主体履约。
同一个 DAO,可以同时分散又集中
| 观察面 | 看起来分散 | 仍可能集中的位置 | 应该验证什么 |
|---|---|---|---|
| 投票 | 数千地址可投票 | 前十个代表控制多数已委托票权 | 票权集中度、委托集中度、真实参与率 |
| 金库 | 预算由公开投票批准 | 3/5 多签仍能选择何时或是否执行 | 多签阈值、签名人、模块与替换权限 |
| 协议 | Governor 可提交升级 | 另一个 ProxyAdmin 仍由团队单独控制 | 每个 owner、admin、upgrader 与 guardian |
| 信息 | 合约与投票公开 | 前端、索引器和论坛管理员决定可见性 | 替代前端、事件日志、原始 calldata 与存档 |
“自治”究竟自动了什么?
智能合约能自动验证签名、历史票权、时间、阈值和角色,也能在条件满足后发送资产或 调用其他合约。它不能自动判断一份安全审计是否高质量、某项公共物品是否值得资助、 某个受款团队是否按约交付,或提案文字是否诚实解释了 calldata。
02 / GOVERNANCE TOKEN
持有 100 枚代币,为什么可能还是 0 票?
余额、voting units、委托、当前票权与历史检查点是五个不同状态
ERC-20 只定义余额、转账和授权等代币接口;它本身没有“提案”“委托”或“过去某一区块的票权”。 治理系统必须额外实现票权追踪。[3]
balanceOf(account)
现在持有多少代币。它回答资产余额,不自动回答谁能投票,也不能可靠代表过去。
delegates(account)
该账户把票权交给了谁。可以委托给自己,也可以交给代表;代币所有权仍留在原账户。
getVotes(account)
某地址现在聚合了多少已激活票权,可能来自自己,也可能来自许多委托人。
getPastVotes(account, t)
历史时点 t 的不可回写票权。Governor 在提案快照处读取它来防止重复使用同一批代币。
ERC-5805 提出一套委托与历史票权查询标准:账户可把 voting units 委托给一个地址, 票权变化写入检查点;Governor 因而能查询过去,而不依赖当前余额。 要注意它目前仍处于 Stagnant 状态,而不是 Final。[4]
为什么不直接在投票时读取余额?
如果每次投票都读取当前 balanceOf,同一批代币可以在地址 A 投票后转给地址 B,
再投一次。历史快照把本提案的权重固定为
wᵢ = getPastVotes(i, tₛ):快照之后的转账、增发、销毁或重新委托,
都只影响未来提案。
治理时钟:数字 7,200 到底是什么单位?
ERC-6372(目前处于 Review)允许投票代币公开自己的
clock() 与 CLOCK_MODE()。常见时钟按区块号或时间戳,
也可以是其他非递减函数;Governor 查询历史票权时,timepoint 必须与代币的时钟语义一致。
因此看到 votingPeriod = 50,400 时,必须先确认它表示区块还是秒,
尤其是在出块节奏不同的 L2 上。ERC-5805 只要求实现者“应当”实现 ERC-6372;
若未实现,就按默认区块号时钟解释。[4][5]
治理代币不天然代表什么
不天然是公司股票
是否具有股权、分红权或法律上的所有权,要看法律安排与明确权利,不能从 ERC-20 接口推出。
不天然拥有协议收入
合约必须明确把费用、回购、分配或请求权连接到代币;“治理”二字不会自动产生现金流。
不保证余额自动成为票权
在常见 ERC20Votes 结构中,持币者需先自委托或委托给代表,才会建立可查询的票权检查点。
不保证投票能控制系统
如果金库、ProxyAdmin 或升级角色仍由团队密钥掌握,代币投票可能只有信号意义。
成员资格不只一种
| 模型 | 票权来源 | 优势 | 主要难题 |
|---|---|---|---|
| 可转让代币 | ERC-20、ERC-721 或可组合持仓 | 开放、可委托、易与链上状态连接 | 财富集中、借票、交易所托管与低参与 |
| 成员份额 | 申请、出资或组织批准 | 边界清楚,适合紧密协作 | 准入者可能集中,退出和转让受限 |
| 声誉 / 贡献 | 工作、证明、评审或不可转让凭证 | 权力更接近贡献,较难直接购买 | 贡献计量、身份、偏见与治理成本 |
| 一地址一票 | 钱包地址 | 实现简单 | 地址不等于人,极易被女巫攻击 |
03 / PROPOSAL LIFECYCLE
一项意见怎样穿过状态机,最终改变链上状态?
讨论 → 提案 → 延迟 → 快照 → 投票 → 计票 → 排队 → 时间锁 → 执行
链上治理最有价值的地方,不只是“公开计票”,而是把谁能在什么时间做什么, 变成一组确定的状态转换。攻击者和防守者都必须在这些时间窗里行动。
Interactive model 01
点击一站,检查那一刻的权力
默认展示快照。没有 JavaScript 时,下方正文仍解释完整流程。
Snapshot:固定本提案的历史票权
voting delay 结束时,Governor 在一个历史时点读取 getPastVotes。快照之后转账或临时获得代币,不会改变这项提案的票权。
三段时间,保护的是三件不同的事
Voting delay
提案创建到投票开始的等待期。给成员阅读、委托、发现恶意调用并协调回应的时间。
Voting period
可实际投票的窗口。太短排除慢时区和小持有人,太长则降低组织响应速度。
Timelock delay
投票通过到动作可执行之间的安全延迟。它与票权时钟不必相同;OpenZeppelin TimelockController 的 minDelay 独立按秒计。
Grace / expiry
有些系统还规定到期窗口:通过的动作若长期无人执行,会失效,避免陈旧决定突然落地。
三道门,也不要混为一谈
- Proposal threshold:谁有资格把一项行动正式放进状态机。
- Quorum:至少需要多少有效票参与,结果才具有程序上的最低代表性。
- Approval rule:赞成、反对、弃权之间要满足什么关系,提案才算成功。
OpenZeppelin 的 Governor 是模块化框架:票权来源、quorum、计票、时间锁与设置都可以组合。 所以“Governor 风格”描述一种架构,不代表所有部署使用相同参数。[7]
04 / COUNTING
“多数人赞成”为什么仍可能没有通过?
多数门槛决定方向,quorum 决定最低参与;弃权如何计入取决于具体模块
一场投票至少要回答两道独立问题:赞成是否战胜反对?参与是否达到最低门槛? 把两者合成一句“多数通过”,会掩盖治理规则最重要的部分。
对快照时点 tₛ 的线性一币一票模型,先把每个地址的历史票权按选择相加:
OpenZeppelin GovernorCountingSimple 模块明确采用
F > A,并以 F + Z 检查 quorum;弃权帮助达到参与门槛,
但不帮助任何一方赢得多数。[8]
基础 Governor 本身不提供一套全局默认计票规则。Compound Governor Bravo 风格的经典规则则以
For 票检查 quorum;两者可能对同一组票给出不同结果。
Interactive model 02
同一组票,两种规则会怎样判?
固定快照总供应量 1,000,000。示例只用于理解模块差异,不代表任何 DAO 的当前配置。
赞成 28,000 > 反对 20,000,满足多数条件;OZ 示例以赞成 + 弃权 = 40,000 检查 40,000 票 quorum;Bravo 风格示例只以赞成 = 28,000 检查同一 quorum。
Quorum 的分母也需要审计
若模块把 quorum 定义为快照时历史总供应量的比例,则:
如果总供应量为 1,000,000,而只有 100,000 枚完成委托并激活票权, “总供应量 4%”其实要求活跃票权中 40% 参与。相反,quorum 过低时, 攻击者可能远不需要控制 51% 总供应量,只需在冷清的投票中控制一小部分即可。
还有哪些计票制度?
| 制度 | 表达方式 | 适合的问题 | 主要代价 |
|---|---|---|---|
| 单选线性投票 | 全部权重给一个选项 | 明确的通过 / 否决 | 财富权力集中,偏好表达粗糙 |
| 分数 / 加权投票 | 在多个选项之间分配权重 | 预算、候选人组合 | 解释和界面更复杂 |
| Approval voting | 可同时认可多个选项 | 寻找广泛可接受方案 | 总票数不等于参与人数 |
| 排序选择 | 按偏好排列候选项 | 多候选人选举 | 计票规则难以直觉验证 |
| 平方投票 | 购买 v 票的成本近似 v² | 表达偏好强度 | 若无抗女巫身份,拆分地址会放大影响 |
05 / EXECUTION
合约执行的不是提案标题,而是一组字节调用
targets、values、calldatas 与 description hash 共同标识一次可执行行动
“给安全研究团队拨款 50,000 枚代币”只是人类语言。要让 EVM 执行,它必须被翻译为: 调用哪个地址、发送多少 ETH、调用哪个函数、传入哪些参数。
用途、受款人、金额、里程碑与风险说明。
transfer(grantee, amount) 被编码成 calldata。
targets[]、values[]、calldatas[] 与 description。
以执行器身份调用代币或金库,真正改变余额。
targets = [governanceToken]
values = [0]
calldatas = [encode("transfer(address,uint256)", grantee, 50_000e18)]
description = "Grant 50,000 tokens to the security research team"
proposalId = keccak256(
abi.encode(targets, values, calldatas, keccak256(bytes(description)))
)
在 OpenZeppelin Governor 中,提案 ID 由这些参数的哈希得到。哈希可以证明“当前看到的数据 与提交时相同”,却不能证明自然语言准确解释了 calldata。投票者必须解码并模拟每个调用: 一个标题写着“调整费率”的提案,字节数据仍可能转移金库或授予升级角色。
Timelock 为什么常是实际权力中心?
当 Governor 与外部 Timelock 配合时,最终发起目标调用的是 Timelock。
因此金库资产、协议 owner、升级权限与关键角色通常应交给 Timelock,
而不是只交给 Governor。OpenZeppelin 也明确建议让时间锁持有被治理资产与权限。
[7]
| 角色 | 能做什么 | 常见安全配置 | 配置错误的后果 |
|---|---|---|---|
| Proposer | 排入满足格式与延迟要求的操作;角色本身不知道投票是否通过 | Governor 通常是唯一 proposer | 额外 proposer 可能绕过代币投票排队动作 |
| Canceller | 取消已排队操作 | 权限明确、受治理或高阈值紧急委员会控制 | 可审查合法提案,或无人能阻止恶意动作 |
| Executor | 到期后触发已固定的操作 | 可开放给任何人,或授予可靠自动化主体 | 无人执行会使通过的决定无法落地 |
| Admin | 授予和撤销上述角色 | 初始化后由 Timelock 自管理,部署者放弃额外权力 | 管理员可重写整个权限拓扑 |
“任何人都能 execute”不等于任何人能改提案
如果 executor 角色开放给零地址,任何账户都能在时间锁到期后支付 Gas 触发执行。 但它只能执行已经排队、内容哈希匹配、延迟满足的动作;调用内容不是由执行者临时选择。 开放执行常用于避免组织因某个指定账户离线而停摆。
签名投票与委托:Gas 可以由别人支付
EIP-712 定义结构化数据签名,使钱包能显示带有域、类型和字段的消息。
delegateBySig 或 castVoteBySig 可以让持有人签署意图,
再由第三方提交交易。域分离、chainId、验证合约、nonce 与 expiry
一起降低跨域和重放风险;标准化编码本身并不会自动替应用完成所有重放保护。
[6]
06 / ARCHITECTURES
链上、链下、混合治理,差别到底在哪里?
真正的分界是:投票结果能否直接支配权限,以及中间还需要信任谁
“投票发生在区块链上”与“结果能自动执行”不是同一句话; “不用 Gas”也不等于没有加密验证。三种结构各自在成本、强制性、隐私和信任上取舍。
链下签名投票
- 钱包签署消息,通常不支付投票 Gas。
- 按指定区块快照和策略计算票权。
- 结果可能只是温度检查或社会信号。
- 执行常依赖多签或后续链上提案。
主要信任边界:空间管理员、策略、索引与结果执行者。
链下决策 + 受约束执行
- 论坛与 Snapshot 先降低讨论和投票成本。
- 多签按结果执行,或由模块把结果桥接到 Safe。
- 可以加冷却期、挑战或预言机判定。
- 实际安全取决于桥接规则是否可绕过。
主要信任边界:签名人、结果判定模块、挑战期与紧急权力。
链上计票 + 自动执行
- 提案、票权、计票与状态都可由合约验证。
- 通过后进入 Timelock,再调用金库或协议。
- 参与者承担链上交易成本与公开投票影响。
- 代码错误与治理攻击可直接触发高价值权限。
主要信任边界:合约代码、权限拓扑、代币分布与经济安全。
Snapshot:链下不等于不可验证
Snapshot Classic 的典型投票是钱包对消息签名;系统按提案设定的历史区块和投票策略计算权重。 投票者无需发链上交易,因此没有投票 Gas。官方文档强调其核心是链下签名消息与区块快照。 [10] 但签名证明“这个地址表达了这个选择”, 不会自动把结果变成金库转账。
多签:共享控制工具,不自动等于 DAO
Safe 的 M-of-N 阈值表示 N 位 owner 中至少 M 位签名,交易才能执行。 它能消除单密钥故障、支持密钥轮换并留下可审计记录。[11] 但如果只有 3/5 位签名人能决定所有事项,而广泛成员没有任何约束他们的机制, 这仍是五人委员会,不会因为钱包叫“DAO Treasury”就自动去中心化。
链上治理适合
可编码、需要强制执行、价值较高且值得承担审计与 Gas 成本的协议参数、金库和权限变更。
链下治理适合
温度检查、观点调查、候选人排序,以及最终动作无法被链上合约直接强制的社会决定。
混合治理适合
需要低成本广泛参与,但仍希望用多签、挑战期或模块把结果转成可审计执行的组织。
没有通用最优解
高强制性同时放大代码与经济攻击;高人工裁量提高灵活性,也提高代理人偏离结果的风险。
07 / GOVERNANCE SECURITY
攻击者不必破解合约,也能“合法”接管系统
治理安全 = 代码安全 + 权限安全 + 经济安全 + 社会协调能力
如果规则允许某批票权通过并执行恶意提案,那么每一行合约都可能按设计工作, 系统却仍然被攻破。治理攻击的特殊之处,是它经常借用系统自己的合法路径。
临时票权与借票
攻击者在关键时点借入、租用或集中足够票权,通过提案后归还资产。
防线:历史快照、voting delay、持有期;局限:不防快照前融资。低参与治理劫持
大多数代币沉睡或未委托,少量活跃票权就能代表整个系统。
防线:合理 quorum、委托、提醒;局限:quorum 过高会使治理瘫痪。最后一刻突袭
巨鲸在投票末段才投下决定性票仓,让反对者来不及组织回应。
防线:late-quorum 延长机制、监控;局限:延长决策时间。恶意或误导 calldata
标题与描述看似无害,实际调用却转移资产、升级实现或授予管理员。
防线:解码、模拟、独立审阅;局限:哈希只能保证内容没变。委托集中与贿选
少数职业代表聚集大量票权,可能被收买、利益冲突或形成长期政治集团。
防线:透明披露、易撤委托、代表多样性;局限:活跃治理天然会专业化。时间锁旁路
额外 admin、proposer、ProxyAdmin 或升级密钥可以绕过公开投票和等待期。
防线:完整权限盘点、最小角色、管理员退出;局限:漏掉一个角色即可失效。多签或 Guardian 滥权
紧急角色能暂停、取消或升级,用于救火的权力也能审查合法决定。
防线:高阈值、限时限权、透明监控、退出路线;局限:仍需信任人。界面与索引偏差
前端隐藏提案、错误显示截止时间或不解码调用,用户看到的不是完整链上事实。
防线:多前端、区块浏览器、事件与原始合约;局限:验证成本转给用户。防线为什么总有代价?
| 安全机制 | 阻挡什么 | 引入的代价 | 不能解决什么 |
|---|---|---|---|
| Proposal threshold | 垃圾与低成本提案洪泛 | 小持有人难以形成议程 | 有钱攻击者与代表垄断 |
| 历史快照 | 重复投票与快照后临时票权 | 检查点 Gas、时钟与实现复杂度 | 快照前借币、贿选与收购 |
| 高 quorum | 少数活跃地址快速接管 | 低参与时任何决定都无法通过 | 多数票权持有人恶意 |
| Timelock | 投票通过后立即执行的突袭 | 紧急响应更慢,用户需持续监控 | 没有出口的用户和权限旁路 |
| Guardian / Security Council | 已知恶意提案与紧急漏洞 | 引入中心化否决或升级权 | 委员会被攻破或本身作恶 |
08 / CASE STUDIES
把抽象结构放回真实组织,会看到什么?
Compound 展示经典 Governor 电路;ENS 展示社会提案、代表委托与链上执行的分层
案例的目的不是背参数,而是练习一套阅读方法:谁控制议程?票权在哪个时点确定? 哪类投票具有执行力?哪个地址最终持有资产与管理员权限?
案例一:Compound Governor Bravo 的经典路径
Compound v2 官方治理文档把系统拆成 COMP 代币、Governor Bravo 与 Timelock。
文档中的经典配置要求提案者在前一区块拥有严格大于
proposalThreshold() 的已委托票权;门槛为 25,000 COMP 时,恰好 25,000 仍不足。
官方概览把审阅与投票近似写成 2 天和 3 天,但合约参数的单位是 Ethereum 区块;
Timelock 的 2 天延迟才按时间计。提案还需多数赞成且至少 400,000 个 For 票,
因此文档称协议变更至少约一周。[9]
持有人自委托或委托代表。
已委托票权必须严格大于 25,000。
按区块计的审阅期,文档近似为 2 天。
按区块计的投票期,约 3 天;争取至少 400,000 For。
再等 2 天,任何地址可触发到期动作。
这组数字是特定版本与文档中的设计,不是 DAO 普遍标准,而且治理本身可以修改参数。 真正值得记住的是三段防线:提案门槛过滤议程,历史票权防止重复使用, Timelock 在多数决定与高权限执行之间插入反应时间。
案例二:ENS 的分层治理
ENS 官方建议流程展示了混合架构:论坛用于起草和讨论,三类正式提案随后都安排 Snapshot 投票。 社会提案与章程修正若在 Snapshot 通过,流程即完成;可执行提案还要提交 Governor 再进行一次链上投票,通过后经历两天 Timelock,才调用链上合约。 这份流程是社区维护的 living document,并非每一步都由合约强制。[12]
| 提案类型 | 决定什么 | 执行方式 | 首要验证 |
|---|---|---|---|
| 社会提案 | 表达组织立场或要求链外行动 | Snapshot 结果 + 人或法律实体履行 | 谁承诺执行,是否有现实约束 |
| 章程修正 | 改变组织自我约束的原则 | 更高赞成门槛的社会治理 | 章程能否约束未来链上动作 |
| 可执行提案 | 转移金库、升级合约或改变参数 | Snapshot → Governor → Timelock → 合约调用 | calldata、快照、角色与等待期 |
| 工作组事务 | 日常拨款、项目与运营 | 民选 steward 与工作组多签 | 授权边界、报告、任期与多签阈值 |
ENS 章程还说明了另一层事实:链上可执行权限之外,组织需要一套“哪些行动被视为合法” 的社会规则。当前章程对修改本身设置更高赞成门槛。[13] 合约能强制程序,章程与社会共识决定组织是否承认程序结果。
09 / GOVERNANCE AUDIT
面对任何 DAO,怎样在一页内画出控制权?
沿着成员、议程、票权、计票、时间、执行、旁路与退出逐层检查
评价 DAO 不应从代币价格、持有人数量或宣传口号开始,而应从权限拓扑开始。 下面十问可以把大多数治理系统拆回可验证事实。
- 谁是成员,谁只是旁观者? 确认资格来自代币、NFT、白名单、贡献还是身份;区分钱包地址、自然人、机构与托管平台。
- 谁能形成议程? 记录论坛权限、提案门槛、押金、验证者和前端发布权;投票开放不代表提案开放。
- 票权从哪里来? 查代币或策略地址、voting units、委托规则、是否需自委托,以及质押或包装是否改变票权。
- 哪一个时点决定权重? 确认快照区块或时间戳、voting delay、时钟模式,以及快照前借币和跨链票权如何处理。
- 到底怎样才算通过? 分别写出 proposal threshold、quorum 分母、For/Against/Abstain 计法、超级多数和末段延长。
- 提案包含哪些机器动作? 逐项解码 targets、values 与 calldatas;模拟升级、授权、转账和批处理中的每一个调用。
- 谁真正持有资产与角色? 追踪 Treasury、owner、ProxyAdmin、upgrader、pauser、minter、oracle admin 与桥接权限。
- Timelock 能否被绕过? 列出 proposer、canceller、executor、admin 与最短延迟;确认初始化账户是否已放弃额外权限。
- 紧急权力如何退出? 检查 Guardian、多签和安全委员会能做什么、持续多久、如何轮换,以及谁能取消其权限。
- 不同意的人有什么出口? 时间锁期间能否退出、资产是否可赎回、前端消失后能否直接调用、链外权利是否受到法律保护。
把答案压缩成四条线
谁知道发生了什么?
讨论、代码、模拟和投票信息是否可获得,是否有独立验证渠道。
谁能让结果成立?
票权与计票规则如何分布,少数人是能阻止、推动,还是两者皆可。
谁能改变状态?
最终调用者是谁,实际资产和管理员权限是否完整放进治理电路。
失败时谁能停下?
时间锁、取消、暂停、分叉、退出与现实法律救济分别覆盖哪些故障。
10 / RECAP
把整课折回一条治理电路
成员形成意志,代币记录历史票权,Governor 汇总选择,Timelock 承接高权限执行
| 层 | 核心对象 | 它能证明什么 | 它不能证明什么 |
|---|---|---|---|
| 社会协调 | 论坛、研究、代表、章程 | 组织形成了可讨论的主张 | 主张一定正确或会被执行 |
| 票权 | Token、delegation、checkpoints | 某时点谁拥有多少治理权 | 持有人是一人、独立或无利益冲突 |
| 计票 | Governor、quorum、counting mode | 结果满足预设程序 | 程序具有道德正当性或不被经济操纵 |
| 执行 | Timelock、Safe、Treasury、roles | 批准动作按权限改变链上状态 | 链外主体履约或用户免受所有损失 |
六题自检
1. 以太坊协议升级是否由 ETH 持有人按余额链上投票决定?
选择答案后查看解析。
答案:B。以太坊核心协议依赖 EIP、实现、测试、节点选择与社会协调,不以 ETH 持币投票自动升级。
2. Alice 把 100 票委托给 Delegate D 后,谁拥有 Alice 的代币?
选择答案后查看解析。
答案:C。委托只把 voting power 指向代表;代币仍由原持有人保管,持有人也能重新委托。
3. 为什么 Governor 常读取 getPastVotes,而不是当前 balanceOf?
选择答案后查看解析。
答案:A。历史快照让本提案读取固定时点的票权,之后转账不会给同一批代币第二次投票机会。
4. 在本课的 OpenZeppelin Simple 示例中,弃权票有什么作用?
选择答案后查看解析。
答案:B。GovernorCountingSimple 模块规定 For + Abstain 检查 quorum,而多数比较是 For 与 Against。
5. 为什么投票通过后还要检查 Timelock 持有什么权限?
选择答案后查看解析。
答案:C。Timelock 提供反应时间;要真正控制目标,资产和 owner/admin/upgrade 等角色也必须授予相应执行器。
6. Snapshot 投票显示 Passed,是否必然自动转出 DAO 金库资产?
选择答案后查看解析。
答案:A。Snapshot Classic 的签名投票通常发生链下;若没有多签、模块或后续链上提案,结果本身只是信号。
11 / GLOSSARY & SOURCES
术语与一手资料
机制定义优先引用标准、官方文档与协议原始资料;真实参数会变化,使用前应重新核对
核心术语
- DAO
- 把成员、决策、资源与执行连接起来的规则系统;不是单一合约类型。
- Governance token
- 按具体规则提供治理权的代币;不天然等于股权、收入权或已激活票权。
- Voting units
- 票权系统用于计算影响力的基础单位,可以来自 ERC-20、ERC-721 或其他策略。
- Delegation
- 持有人把票权指向自己或代表,不转移代币所有权。
- Delegate
- 聚合自己与他人委托票权、实际参与提案和投票的代表地址。
- Checkpoint
- 某时点票权的历史记录,使 Governor 能查询过去而非当前余额。
- Snapshot
- 为一项提案固定票权状态的区块或时间点;也可指同名链下投票工具。
- Proposal threshold
- 创建正式提案所需的最低票权、资格或其他门槛。
- Voting delay
- 提案创建到投票开始之间的等待期,也是快照前的准备窗口。
- Voting period
- 提案处于 Active、可以提交投票的时间范围。
- Quorum
- 结果有效所需的最低参与或支持;具体哪些票计入由规则决定。
- Governor
- 管理提案生命周期、读取历史票权并按计票规则确定结果的治理合约。
- Timelock
- 让通过的操作在执行前至少等待一段时间的权限控制合约。
- Calldata
- 目标合约调用的函数选择器与编码参数;真正被 EVM 执行的指令数据。
- Multisig
- 需要 N 位 owner 中至少 M 位签名才能执行交易的共享账户控制。
- Guardian
- 在限定条件下暂停、取消或紧急干预的角色;提供救援也引入中心化信任。
官方与标准原文
-
[01]
Ethereum.org · What is a DAO?
DAO 定义、智能合约金库、委托、自动交易治理与多签治理概览。
-
[02]
Ethereum.org · Introduction to Ethereum governance
明确区分以太坊协议的链下治理与应用 DAO 的链上治理。
-
[03]
ERC-20 · Token Standard
余额、转账、授权等基础代币接口;标准本身不定义治理。
-
[04]
ERC-5805 · Voting with Delegation
委托、当前和历史票权、检查点、签名委托与预期性质;当前状态为 Stagnant。
-
[05]
ERC-6372 · Contract Clock
合约的非递减时钟接口与模式声明;当前状态为 Review。
-
[06]
EIP-712 · Typed structured data hashing and signing
域分离的结构化签名编码,是签名投票与委托的基础之一。
-
[07]
OpenZeppelin · How to set up on-chain governance
ERC20Votes、Governor、quorum、提案生命周期与 Timelock 配置。
-
[08]
OpenZeppelin · Governance API
Governor 模块、CountingSimple、Votes、TimelockController 与角色接口。
-
[09]
Compound v2 · Governance
COMP 委托、Governor Bravo、经典门槛、投票期与 Timelock 流程。
-
[10]
Snapshot · FAQ
区块快照、链下签名、无 Gas 投票与投票资格的官方说明。
-
[11]
Safe · Glossary
多签 owner、M-of-N threshold、签名收集与共享账户控制。
-
[12]
ENS DAO · Governance Process
论坛、Snapshot、代表委托、社会与可执行提案、Governor 和 Timelock。
-
[13]
ENS DAO · Constitution
治理合法性的社会约束、组织原则与章程修改要求。