治理机制设计

   

💡 本课将深入探讨 DAO 治理机制的设计与实现。从最基础的代币投票到高级的二次方投票，从链上治理到链下信号，你将了解各种治理模式的优缺点，以及一个治理提案从构思到执行的完整生命周期。

欢迎关注我的推特：@bhbtc1337

进入微信交流群请填表：表格链接

文章开源在 GitHub：Get-Started-with-Web3

购买 BTC / ETH / USDT 等加密货币推荐 币安 注册链接

目录

• [Token 投票机制](#token - 投票机制)
• [委托治理](# 委托治理)
• [时间锁机制](# 时间锁机制)
• [链上治理 vs 链下治理](# 链上治理 - vs - 链下治理)
• [Snapshot：链下投票工具](#snapshot 链下投票工具)
• [Tally：链上治理界面](#tally 链上治理界面)
• [治理提案的生命周期](# 治理提案的生命周期)
• [二次方投票](# 二次方投票)
• [其他投票机制](# 其他投票机制)
• [总结](# 总结)
• [延伸阅读](# 延伸阅读)

Token 投票机制

Token 投票是目前最常见的 DAO 治理机制，核心逻辑很简单：** 一币一票 **（One Token, One Vote）。

基本原理

每个持有治理代币的地址，其投票权重等于其持有的代币数量。例如：

• Alice 持有 1,000 个 UNI → 她有 1,000 票的投票权
• Bob 持有 100 个 UNI → 他有 100 票的投票权

投票通常分为三种选择：** 赞成（For）、 反对（Against）、 弃权（Abstain）**。

投票阈值

大多数 DAO 设置了两个关键阈值：

1. ** 法定人数（Quorum）**：提案需要达到最低投票量才有效。例如 Uniswap 要求至少 4,000 万 UNI（总量的 4%）参与投票
2. ** 通过门槛（Approval Threshold）**：赞成票需要超过一定比例。通常是简单多数（>50%），有些重要决策要求超级多数（>66%）

一币一票的优点

• ** 简单直观 **：规则清晰，容易理解和实现
• ** 利益对齐 **：持有越多代币意味着承担越多风险，因此有更大的动力做出好的决策
• **Sybil 抗性 **：基于代币而非地址，创建多个钱包无法增加投票权
• ** 可组合性 **：与 DeFi 生态良好集成（如质押中的代币也能投票）

一币一票的缺点

• ** 富人治理 **：大户（Whale）的投票权远超普通用户，可能导致寡头治理
• ** 投票冷漠 **：小额持有者觉得自己的票无关紧要，导致投票率低下
• ** 短期主义 **：代币可以随时卖出，持有者可能更关注短期利益
• ** 买票攻击 **：攻击者可以临时借入大量代币来影响投票

投票快照

为了防止投票期间的代币转移操作影响结果，大多数治理系统使用 ** 快照（Snapshot）机制 **：在提案创建时记录某个区块高度，以该区块的代币持有情况为准计算投票权。

solidity
// OpenZeppelin Governor 中的投票权查询
// 在提案创建时的区块快照处查询余额
function getVotes (address account, uint256 blockNumber)
    public view returns (uint256)
{
    return token.getPastVotes (account, blockNumber);
}

委托治理

委托治理（Delegated Voting）是解决投票冷漠和专业性不足问题的重要机制。

什么是委托治理

代币持有者可以将自己的投票权 ** 委托（Delegate）** 给另一个地址，由被委托者（Delegate）代为投票。这类似于现实世界中的 ** 代议制民主 **。

代币持有者 A（100 票）──委托──→ 代表 X
代币持有者 B（200 票）──委托──→ 代表 X
代币持有者 C（50 票） ──委托──→ 代表 Y

代表 X 拥有 300 票投票权
代表 Y 拥有 50 票投票权

关键特性

• ** 随时可撤销 **：委托者可以随时收回投票权，重新自己投票或更换代表
• ** 不转移代币 **：委托只转移投票权，代币仍在原持有者地址
• ** 可自我委托 **：持有者可以委托给自己，这是参与投票的前提（许多治理合约要求先委托才能投票）
• ** 传递性 **：部分系统支持代表再委托（但多数不支持，以避免复杂性）

委托治理的优势

1. ** 提高参与率 **：不活跃的持有者也能通过委托间接参与治理
2. ** 专业化 **：代表通常是深入研究治理提案的专家或社区领袖
3. ** 降低参与门槛 **：普通用户不需要花时间研究每个提案
4. ** 增加投票量 **：帮助提案更容易达到法定人数

知名委托代表

在 Uniswap、Compound、Aave 等大型 DAO 中，有许多知名的委托代表：

• a16z：作为大型投资机构，在多个 DAO 中持有并行使投票权
• Blockchain@Columbia：大学区块链社团作为委托代表
• ** 独立研究者 **：如 Penn Blockchain、Stanford Blockchain Club 等

在 Uniswap 治理中，前 20 名委托代表通常控制了超过 60% 的投票权。

委托的操作方法

以 Uniswap 为例，委托投票权的操作：

solidity
// 在 UNI 代币合约中调用 delegate 函数
// 将投票权委托给指定地址
uni.delegate (delegateAddress);

// 自我委托（激活自己的投票权）
uni.delegate (msg.sender);

在 Tally 等治理界面上，委托操作可以通过简单的前端交互完成，无需手动调用合约。

时间锁机制

时间锁（Timelock）是 DAO 治理中的关键安全机制。它在投票通过和实际执行之间设置了一段 ** 强制等待期 **。

为什么需要时间锁

想象这个场景：某个恶意提案通过了投票（可能是通过闪电贷或投票窗口很短），如果立即执行，用户来不及反应。时间锁的作用就是给所有人一个 ** 退出窗口 **：

• 用户可以在执行前 ** 撤出资金 **（如果发现提案有问题）
• 社区可以 ** 组织反对 **（如发起新提案取消执行）
• 安全审计人员可以 ** 审查提案内容 **

时间锁的工作流程

投票通过 → 提案进入 Timelock 队列 → 等待期（如 48 小时）→ 执行窗口 → 提案执行

典型的时间锁配置

OpenZeppelin TimelockController 示例

solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/governance/TimelockController.sol";

// 创建一个 48 小时时间锁
//minDelay: 172800 秒 = 48 小时
//proposers: 可以提交操作的地址（通常是 Governor 合约）
//executors: 可以执行操作的地址（通常设为 address (0) 允许任何人执行）
TimelockController timelock = new TimelockController (
    172800,       // 最小延迟（秒）
    proposers,    // 提案者列表
    executors,    // 执行者列表
    admin         // 管理员地址
);

紧急操作

某些 DAO 还设置了 ** 紧急操作（Emergency Actions）** 机制，允许在特定情况下（如协议遭受攻击）绕过时间锁。这通常需要更高的投票门槛或多签批准。

链上治理 vs 链下治理

DAO 的治理可以分为 ** 链上（On-chain）** 和 ** 链下（Off-chain）** 两种方式，各有优劣。

链上治理

** 定义 **：投票和执行都发生在区块链上。投票结果直接触发智能合约操作。

** 代表 **：Compound Governor、OpenZeppelin Governor、Tally

** 优点 **：

• 投票结果不可篡改，完全透明
• 提案通过后自动执行，无需人工干预
• 具有约束力，投票即决策

** 缺点 **：

• 每次投票需要 Gas 费，成本较高
• 治理过程较慢（需要等待区块确认）
• 修改治理参数本身也需要治理流程

链下治理

** 定义 **：投票在链下进行（通常基于签名而非交易），投票结果需要其他机制来执行。

** 代表 **：Snapshot、Discourse 论坛投票

** 优点 **：

• ** 零 Gas 费 **：使用签名而非链上交易
• 投票体验更好，参与门槛更低
• 更灵活，可以快速调整投票参数

** 缺点 **：

• 投票结果不具有链上约束力，需要多签或其他方式执行
• 存在「信号 vs 执行」的差距
• 理论上存在中心化风险（Snapshot 服务器）

混合模式（推荐实践）

大多数成熟的 DAO 采用 ** 混合治理模式 **：

1. 论坛讨论（Discourse/Commonwealth）→ 非正式讨论，收集意见
2. 温度检查（Snapshot）→ 链下投票，测试社区态度
3. 正式提案（链上 Governor）→ 有约束力的链上投票
4. 时间锁等待 → 安全缓冲
5. 执行 → 智能合约自动操作

这种模式既降低了参与成本，又保证了最终决策的链上可执行性。

Snapshot：链下投票工具

Snapshot 是目前最流行的链下治理投票平台，被超过 20,000 个项目使用。

Snapshot 的工作原理

1. ** 空间（Space）创建 **：DAO 在 Snapshot 上创建自己的治理空间
2. ** 投票策略（Voting Strategy）**：定义如何计算投票权（如 ERC-20 余额、NFT 持有、LP Token 等）
3. ** 提案创建 **：符合条件的成员创建提案，设置投票时间和选项
4. ** 签名投票 **：用户用钱包签名投票（不需要发送交易，零 Gas 费）
5. ** 结果统计 **：投票结束后，根据策略计算最终结果

核心特性

• ** 零 Gas 费 **：投票使用 EIP-712 签名，不需要链上交易
• ** 多链支持 **：支持以太坊、Polygon、Arbitrum、Optimism 等多条链
• ** 灵活的投票策略 **：支持多种代币类型和组合策略
• ** 多种投票类型 **：单选、多选、排序投票、加权投票等
• **IPFS 存储 **：投票数据存储在 IPFS 上，具有去中心化特性

投票策略示例

json
{
  "name": "erc20-balance-of",
  "network": "1",
  "params": {
    "address": "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984",
    "symbol": "UNI",
    "decimals": 18
  }
}

Snapshot 的局限性

• 投票结果没有链上约束力，需要多签团队手动执行
• 依赖中心化的 Snapshot 服务器（虽然数据存在 IPFS）
• 无法直接触发智能合约操作

Tally：链上治理界面

Tally 是最流行的链上治理前端界面，为 OpenZeppelin Governor 等链上治理合约提供用户友好的交互体验。

Tally 的主要功能

1. ** 提案浏览 **：查看所有进行中和历史提案
2. ** 投票操作 **：直接在界面上进行链上投票
3. ** 委托管理 **：查看和管理投票权委托
4. ** 代表排行 **：查看各个委托代表的投票记录和持票量
5. **DAO 数据 **：国库余额、投票率、参与度等数据分析

Tally vs Snapshot 对比

在 Tally 上参与治理的步骤

1. 连接钱包到 Tally 网站
2. 找到你参与的 DAO 页面
3. 如果还没委托，先将投票权委托给自己或代表
4. 浏览活跃提案，阅读提案内容
5. 点击投票按钮，选择赞成 / 反对 / 弃权
6. 确认交易（需要支付 Gas 费）

治理提案的生命周期

一个治理提案从构思到执行，通常经历以下阶段：

第一阶段：讨论（Discussion）

• ** 平台 **：Discord、Discourse 论坛、Commonwealth
• ** 内容 **：提出想法、收集反馈、迭代方案
• ** 时间 **：通常 3-7 天
• ** 参与者 **：任何社区成员

第二阶段：温度检查（Temperature Check）

• ** 平台 **：Snapshot（链下投票）
• ** 目的 **：测试社区对提案的态度，避免浪费链上投票资源
• ** 门槛 **：较低的参与要求
• ** 时间 **：通常 3-5 天

第三阶段：正式提案（Formal Proposal）

• ** 平台 **：链上（Governor 合约）
• ** 要求 **：提案者需要持有一定数量的代币（如 Uniswap 要求 250 万 UNI 的投票权）
• ** 内容 **：包含具体的合约调用参数
• ** 时间 **：投票延迟期（如 2 天）+ 投票期（如 7 天）

第四阶段：投票（Voting）

• ** 机制 **：链上代币加权投票
• ** 选项 **：赞成 / 反对 / 弃权
• ** 条件 **：需达到法定人数且赞成票超过门槛
• ** 时间 **：通常 5-7 天

第五阶段：时间锁（Timelock）

• ** 目的 **：安全缓冲期，允许反对者退出
• ** 时间 **：通常 24-48 小时
• ** 特殊情况 **：可被取消（如果发现严重问题）

第六阶段：执行（Execution）

• ** 方式 **：任何人都可以触发执行（调用 execute 函数）
• ** 效果 **：智能合约自动执行提案中定义的操作
• ** 不可逆 **：一旦执行，操作上链不可撤销

完整流程图

💬 论坛讨论（3-7 天）
    ↓
📊 Snapshot 温度检查（3-5 天）
    ↓
📝 正式链上提案
    ↓
⏳ 投票延迟期（1-2 天）
    ↓
🗳️ 投票期（5-7 天）
    ↓ [达到法定人数 + 通过门槛]
⏰ 时间锁等待（24-48 小时）
    ↓
✅ 执行

二次方投票

二次方投票（Quadratic Voting，QV）是一种旨在平衡大户影响力的创新投票机制。

基本原理

在二次方投票中，投票权的成本按照 ** 平方关系 ** 增长：

公式：** 投票成本 = 票数的平方 **（即 cost = votes²）

为什么二次方投票更公平

在一币一票的模式下：

• 持有 1,000,000 代币的大户 = 1,000,000 票
• 持有 1 代币的小用户 = 1 票
• 差距：1,000,000 倍

在二次方投票模式下：

• 持有 1,000,000 代币的大户 = 1,000 票（√1,000,000）
• 持有 1 代币的小用户 = 1 票
• 差距：1,000 倍

二次方投票大幅缩小了大户和小用户之间的投票权差距，更能反映社区的广泛共识而非少数人的意志。

实际应用

• Gitcoin Grants：使用二次方资助（Quadratic Funding），这是二次方投票在资金分配中的应用
• Optimism RetroPGF：在公共物品资助中使用类似机制
• ** 部分 DAO 的温度检查 **：在 Snapshot 上可以配置二次方投票策略

挑战

• ** 女巫攻击（Sybil Attack）**：攻击者可以创建多个地址来规避二次方成本，因此需要配合身份验证（如 Gitcoin Passport、Proof of Humanity）
• ** 复杂性 **：普通用户可能不理解二次方投票的原理
• ** 代币流动性 **：如何定义「成本」在代币系统中的含义

其他投票机制

除了上述主流机制外，还有一些创新的投票方式值得关注：

信念投票（Conviction Voting）

• ** 原理 **：投票权随时间累积，持续投票的权重越来越高
• ** 特点 **：有利于长期关注者，减少突然涌入的操纵
• ** 应用 **：1Hive、Gardens

乐观治理（Optimistic Governance）

• ** 原理 **：提案默认通过，除非有人在规定时间内提出反对
• ** 优点 **：大幅提高治理效率，减少投票疲劳
• ** 应用 **：Optimism Collective 的部分治理流程

全息共识（Holographic Consensus）

• ** 原理 **：使用预测市场来筛选提案，只有被市场「看好」的提案才进入投票
• ** 优点 **：减少需要投票的提案数量，提高信噪比
• ** 应用 **：DAOstack

愤怒退出（Rage Quit）

• ** 原理 **：不满投票结果的成员可以在执行前退出 DAO 并带走自己份额的国库资金
• ** 作用 **：保护少数派利益，防止多数暴政
• ** 应用 **：Moloch DAO 系列

总结

1. Token 投票（一币一票） 是最基础的治理机制，简单但存在富人治理和投票冷漠等问题
2. ** 委托治理 ** 通过代议制提高了参与率和专业性，是解决投票冷漠的有效手段
3. ** 时间锁机制 ** 提供了安全缓冲，保护用户在恶意提案执行前有退出的机会
4. ** 链上链下混合模式 ** 是目前的最佳实践：用 Snapshot 做温度检查，用 Governor 做最终决策
5. ** 二次方投票 ** 等创新机制正在探索更公平的治理方式，但仍面临身份验证等挑战

延伸阅读

• Snapshot 官网
• Tally 官网
• OpenZeppelin Governor 文档
• Vitalik Buterin: Moving beyond coin voting governance
• Quadratic Voting 原理解释 (RadicalxChange)
• Compound 治理文档
• Moloch DAO: Rage Quit 机制