Ethereum · Chapter 14 · Lesson 01

没有 CEO,组织如何作出并执行决定?

DAO 不是把公司换成群聊,也不是让代码自动拥有智慧。它把 成员如何形成意志、谁拥有投票权、结果如何成为链上动作 拆成一套任何人都能检查的规则。

  • 约 55 分钟
  • 2 个互动实验
  • 6 组机制图
  • 从组织到字节调用
01 / POWER

DAO 是一套权力安排,不是一种固定软件。论坛、多签、代币、Governor 和 Timelock 各自只负责其中一段。

02 / VOTES

余额、票权与所有权是三件事。委托可以移动票权但不移动代币;治理代币也不天然等于股票。

03 / EXECUTION

真正改变状态的是 calldata 与权限。投票页面显示“通过”,只有在执行器确实持有相应角色时才会成为现实。

00 / ORIENTATION

先别问“哪个 DAO”,先问它在解决什么

正式目录主题:去中心化组织、治理代币与链上投票机制

想象 10,000 个互不认识的人共同管理一笔链上资金:没有共同银行账户, 没有一个天然可信的财务负责人,也没有 CEO 可以替所有人拍板。 他们必须先回答一组非常具体的问题。

01 / MEMBERSHIP

谁属于组织?

持币者、NFT 持有人、受邀成员、贡献者,还是通过某种身份验证的人?一个地址是否等于一个人?

02 / AGENDA

谁能提出行动?

任何人都能提案,还是必须积累一定票权、声誉或押金?高门槛能过滤垃圾,也可能垄断议程。

03 / DECISION

什么叫“同意”?

一人一票、一币一票、代表委托、简单多数、绝对多数与法定人数会产生完全不同的权力分布。

04 / EXECUTION

谁真正动用资产?

投票通过后由多签人工执行,还是由 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]

Vⱼ(t) = Σᵢ uᵢ(t) · 1[dᵢ(t) = j]
uᵢ(t) 是账户 i 在时点 t 的 voting units;dᵢ(t) 是它选择的受托人; Vⱼ(t) 是受托人 j 聚合的票权。委托移动的是治理权,不是资产。
ALICE · 40余额 40,委托给 D
BOB · 35余额 35,委托给 D
CHEN · 25余额 25,自委托
DELEGATE D · 75保管 0 枚代币,拥有 75 票
CHEN · 25保管 25 枚代币,拥有 25 票
CHECKPOINT tₛD = 75 · Chen = 25
AFTER tₛ转账会改变未来,不改本提案

为什么不直接在投票时读取余额?

如果每次投票都读取当前 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]

治理代币不天然代表什么

NOT / SHARE

不天然是公司股票

是否具有股权、分红权或法律上的所有权,要看法律安排与明确权利,不能从 ERC-20 接口推出。

NOT / REVENUE

不天然拥有协议收入

合约必须明确把费用、回购、分配或请求权连接到代币;“治理”二字不会自动产生现金流。

NOT / VOTE

不保证余额自动成为票权

在常见 ERC20Votes 结构中,持币者需先自委托或委托给代表,才会建立可查询的票权检查点。

NOT / CONTROL

不保证投票能控制系统

如果金库、ProxyAdmin 或升级角色仍由团队密钥掌握,代币投票可能只有信号意义。

成员资格不只一种

模型 票权来源 优势 主要难题
可转让代币 ERC-20、ERC-721 或可组合持仓 开放、可委托、易与链上状态连接 财富集中、借票、交易所托管与低参与
成员份额 申请、出资或组织批准 边界清楚,适合紧密协作 准入者可能集中,退出和转让受限
声誉 / 贡献 工作、证明、评审或不可转让凭证 权力更接近贡献,较难直接购买 贡献计量、身份、偏见与治理成本
一地址一票 钱包地址 实现简单 地址不等于人,极易被女巫攻击

03 / PROPOSAL LIFECYCLE

一项意见怎样穿过状态机,最终改变链上状态?

讨论 → 提案 → 延迟 → 快照 → 投票 → 计票 → 排队 → 时间锁 → 执行

链上治理最有价值的地方,不只是“公开计票”,而是把谁能在什么时间做什么, 变成一组确定的状态转换。攻击者和防守者都必须在这些时间窗里行动。

Interactive model 01

点击一站,检查那一刻的权力

默认展示快照。没有 JavaScript 时,下方正文仍解释完整流程。

Snapshot:固定本提案的历史票权

voting delay 结束时,Governor 在一个历史时点读取 getPastVotes。快照之后转账或临时获得代币,不会改变这项提案的票权。

关键权力委托后的历史票权
典型状态Pending → Active
首要失败面快照前借币或租票仍可能

三段时间,保护的是三件不同的事

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ₛ 的线性一币一票模型,先把每个地址的历史票权按选择相加:

F = Σ wᵢ·1[sᵢ=For]  A = Σ wᵢ·1[sᵢ=Against]  Z = Σ wᵢ·1[sᵢ=Abstain]
wᵢ 来自快照处的历史票权,而不是投票时的当前余额。F、A、Z 分别是赞成、反对与弃权。

OpenZeppelin GovernorCountingSimple 模块明确采用 F > A,并以 F + Z 检查 quorum;弃权帮助达到参与门槛, 但不帮助任何一方赢得多数。[8] 基础 Governor 本身不提供一套全局默认计票规则。Compound Governor Bravo 风格的经典规则则以 For 票检查 quorum;两者可能对同一组票给出不同结果。

Interactive model 02

同一组票,两种规则会怎样判?

固定快照总供应量 1,000,000。示例只用于理解模块差异,不代表任何 DAO 的当前配置。

1%20%
0100,000
0100,000
0100,000
FOR
28,000
AGAINST
20,000
ABSTAIN
12,000
OZ SIMPLE · F + Z CHECK QUORUM 通过
BRAVO STYLE · F CHECKS QUORUM 未通过

赞成 28,000 > 反对 20,000,满足多数条件;OZ 示例以赞成 + 弃权 = 40,000 检查 40,000 票 quorum;Bravo 风格示例只以赞成 = 28,000 检查同一 quorum。

Quorum 的分母也需要审计

若模块把 quorum 定义为快照时历史总供应量的比例,则:

Q(tₛ) = pastTotalSupply(tₛ) × quorumNumerator(tₛ) / quorumDenominator
分母常为 100,但不是自然法则。应确认金库持币、销毁地址、锁仓、未委托余额与跨链供应如何进入 totalSupply。

如果总供应量为 1,000,000,而只有 100,000 枚完成委托并激活票权, “总供应量 4%”其实要求活跃票权中 40% 参与。相反,quorum 过低时, 攻击者可能远不需要控制 51% 总供应量,只需在冷清的投票中控制一小部分即可。

还有哪些计票制度?

制度 表达方式 适合的问题 主要代价
单选线性投票 全部权重给一个选项 明确的通过 / 否决 财富权力集中,偏好表达粗糙
分数 / 加权投票 在多个选项之间分配权重 预算、候选人组合 解释和界面更复杂
Approval voting 可同时认可多个选项 寻找广泛可接受方案 总票数不等于参与人数
排序选择 按偏好排列候选项 多候选人选举 计票规则难以直觉验证
平方投票 购买 v 票的成本近似 v² 表达偏好强度 若无抗女巫身份,拆分地址会放大影响

05 / EXECUTION

合约执行的不是提案标题,而是一组字节调用

targets、values、calldatas 与 description hash 共同标识一次可执行行动

“给安全研究团队拨款 50,000 枚代币”只是人类语言。要让 EVM 执行,它必须被翻译为: 调用哪个地址、发送多少 ETH、调用哪个函数、传入哪些参数。

01 / INTENT 人类主张

用途、受款人、金额、里程碑与风险说明。

02 / ENCODE ABI 编码

transfer(grantee, amount) 被编码成 calldata。

03 / GOVERN 提案数据

targets[]、values[]、calldatas[] 与 description。

04 / CALL Timelock 执行

以执行器身份调用代币或金库,真正改变余额。

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”也不等于没有加密验证。三种结构各自在成本、强制性、隐私和信任上取舍。

01 / OFFCHAIN SIGNAL

链下签名投票

  • 钱包签署消息,通常不支付投票 Gas。
  • 按指定区块快照和策略计算票权。
  • 结果可能只是温度检查或社会信号。
  • 执行常依赖多签或后续链上提案。

主要信任边界:空间管理员、策略、索引与结果执行者。

02 / HYBRID

链下决策 + 受约束执行

  • 论坛与 Snapshot 先降低讨论和投票成本。
  • 多签按结果执行,或由模块把结果桥接到 Safe。
  • 可以加冷却期、挑战或预言机判定。
  • 实际安全取决于桥接规则是否可绕过。

主要信任边界:签名人、结果判定模块、挑战期与紧急权力。

03 / ONCHAIN EXECUTION

链上计票 + 自动执行

  • 提案、票权、计票与状态都可由合约验证。
  • 通过后进入 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]

01 / DELEGATE 激活并聚合票权

持有人自委托或委托代表。

02 / PROPOSE 跨过提案门槛

已委托票权必须严格大于 25,000。

03 / REVIEW 等待并固定权重

按区块计的审阅期,文档近似为 2 天。

04 / VOTE 多数 + For quorum

按区块计的投票期,约 3 天;争取至少 400,000 For。

05 / TIMELOCK 排队后执行

再等 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 不应从代币价格、持有人数量或宣传口号开始,而应从权限拓扑开始。 下面十问可以把大多数治理系统拆回可验证事实。

  1. 谁是成员,谁只是旁观者? 确认资格来自代币、NFT、白名单、贡献还是身份;区分钱包地址、自然人、机构与托管平台。
  2. 谁能形成议程? 记录论坛权限、提案门槛、押金、验证者和前端发布权;投票开放不代表提案开放。
  3. 票权从哪里来? 查代币或策略地址、voting units、委托规则、是否需自委托,以及质押或包装是否改变票权。
  4. 哪一个时点决定权重? 确认快照区块或时间戳、voting delay、时钟模式,以及快照前借币和跨链票权如何处理。
  5. 到底怎样才算通过? 分别写出 proposal threshold、quorum 分母、For/Against/Abstain 计法、超级多数和末段延长。
  6. 提案包含哪些机器动作? 逐项解码 targets、values 与 calldatas;模拟升级、授权、转账和批处理中的每一个调用。
  7. 谁真正持有资产与角色? 追踪 Treasury、owner、ProxyAdmin、upgrader、pauser、minter、oracle admin 与桥接权限。
  8. Timelock 能否被绕过? 列出 proposer、canceller、executor、admin 与最短延迟;确认初始化账户是否已放弃额外权限。
  9. 紧急权力如何退出? 检查 Guardian、多签和安全委员会能做什么、持续多久、如何轮换,以及谁能取消其权限。
  10. 不同意的人有什么出口? 时间锁期间能否退出、资产是否可赎回、前端消失后能否直接调用、链外权利是否受到法律保护。

把答案压缩成四条线

LINE 01 / INFORMATION

谁知道发生了什么?

讨论、代码、模拟和投票信息是否可获得,是否有独立验证渠道。

LINE 02 / DECISION

谁能让结果成立?

票权与计票规则如何分布,少数人是能阻止、推动,还是两者皆可。

LINE 03 / EXECUTION

谁能改变状态?

最终调用者是谁,实际资产和管理员权限是否完整放进治理电路。

LINE 04 / RECOVERY

失败时谁能停下?

时间锁、取消、暂停、分叉、退出与现实法律救济分别覆盖哪些故障。

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
在限定条件下暂停、取消或紧急干预的角色;提供救援也引入中心化信任。

官方与标准原文

  1. [01]
    Ethereum.org · What is a DAO?

    DAO 定义、智能合约金库、委托、自动交易治理与多签治理概览。

  2. [02]
    Ethereum.org · Introduction to Ethereum governance

    明确区分以太坊协议的链下治理与应用 DAO 的链上治理。

  3. [03]
    ERC-20 · Token Standard

    余额、转账、授权等基础代币接口;标准本身不定义治理。

  4. [04]
    ERC-5805 · Voting with Delegation

    委托、当前和历史票权、检查点、签名委托与预期性质;当前状态为 Stagnant。

  5. [05]
    ERC-6372 · Contract Clock

    合约的非递减时钟接口与模式声明;当前状态为 Review。

  6. [06]
    EIP-712 · Typed structured data hashing and signing

    域分离的结构化签名编码,是签名投票与委托的基础之一。

  7. [07]
    OpenZeppelin · How to set up on-chain governance

    ERC20Votes、Governor、quorum、提案生命周期与 Timelock 配置。

  8. [08]
    OpenZeppelin · Governance API

    Governor 模块、CountingSimple、Votes、TimelockController 与角色接口。

  9. [09]
    Compound v2 · Governance

    COMP 委托、Governor Bravo、经典门槛、投票期与 Timelock 流程。

  10. [10]
    Snapshot · FAQ

    区块快照、链下签名、无 Gas 投票与投票资格的官方说明。

  11. [11]
    Safe · Glossary

    多签 owner、M-of-N threshold、签名收集与共享账户控制。

  12. [12]
    ENS DAO · Governance Process

    论坛、Snapshot、代表委托、社会与可执行提案、Governor 和 Timelock。

  13. [13]
    ENS DAO · Constitution

    治理合法性的社会约束、组织原则与章程修改要求。

DAO 的真正问题从来不只是“有多少人投票”,而是: 谁能形成议程、哪一刻的票权被计算、什么规则决定通过,以及哪个地址最终拥有执行权限。