隐藏在提案治理中的“财富密码”(二)——治理提案问题反思
2022-08-03 12:53
郑说Web3
2022-08-03 12:53
郑说Web3
2022-08-03 12:53
订阅此专栏
收藏此文章

在上一篇文章中,我们讲了 DEF 的故事,在这篇文章中,让我们来看看目前 DAO 治理提案机制存在三个较为显著的问题。

第一个是 DAO 治理的原生问题——链上操作无法覆盖治理全流程。这导致治理透明度和去中心化含量的缺失。

首先,我们需要认识到,智能合约的部署并不代表 DAO 治理的全盘上链。作为一个社会有机体,DAO 的治理是多层次的,有链上的层次(协议)存在,也有链下的层次(运营、社区)存在。

对去中心化协议进行人种学研究的理论框架    图源:seeDAO

作为 DAO 治理的核心,DAO 治理提案也无法实现全流程上链。一般来说,DAO 治理提案会经历四个阶段:提出 - 讨论 - 投票 - 落地,其中第三、四步的部分环节(后文会说明为什么是“部分”环节)可以通过智能合约在链上自动化完成,但一、二步无法通过链上操作实现。

首先,就第一步而言,治理提案的提出缺乏对“假冒伪劣”提案的链上筛查。例如我之前写的研究 CultDao 的文章被别人冒用申请奖励的情况,以及上一篇文章中提到的 Uniswap 将 100 万 UNI 捐赠给 DeFi 教育基金的治理提案事件,均为治理提案的透明性蒙上了一层阴影。

此外,作为第二步的社区(例如 Discord、论坛和 Twitter)讨论及更具隐蔽性的私人讨论是发生在链下的。再来看第三、四步。首先,DAO 治理提案的投票并不是完全的链上操作。我们可以以 Uniswap 为案例说明这一点。Uniswap 协议的治理过程分为三个阶段,每个阶段都包含从前一阶段收到的反馈:

  1. 热度审查(Temperature Check)在两天的窗口期后,至少有 25k UNI 的多数票同意,就可以让提案进入共识审查阶段。
  2. 共识审查(Consensus Check)。这一阶段允许提案者纳入 “热度审查 “的反馈,如果提案涉及到伙伴关系,则意味着正式讨论的开始。
  3. 治理提案。该提案应附带可执行的链上代码。提交者必须至少有 200 万个 UNI 委托给他们,并且至少需要 4000 万个 UNI 赞成票才能通过。在这一流程中,前两个阶段是链下投票,旨在衡量 DAO 成员对特定提案的兴趣并收集意向反馈。最后阶段才是链上投票,这一阶段可能导致 Uniswap 协议参数发生变化(例如尚未发生的费用转换),也可能形成资金分散的决策(例如 DeFi 教育基金的资助)。而第四步,即提案通过后的问责与执行机制,也是无法完全在链上实现的——在 Polygon 上部署 Uniswap v3 的提案通过后,Polygon 团队在执行上的拖延便可以说明这一点。在这一 D2D(DAO2DAO)的案例中,提案里的财务和非财务承诺是缺乏链上协议担保的,甚至没有链下法律约束力的背书,以至于问责和执行无法落地、治理提案效力大大削弱。据此,PrimeDAO 提出了规范 D2D 提案的链上解决方案,即 Proposal Inverter mechanism 和 CTF(Conditional Tokens Framework)。如果这些方案在未来落地,或许能够成为 D2D 提案问题的“链上解药”。

Proposal Inverter mechanism 下的自动化 D2D 资源配置    图源:PrimeDAO

综上,虽然 DAO 的治理作为一个多层次的社会有机体,无法实现链上操作的全覆盖,但随着链上解决方案的落地,可以实现链上权重的上升;同时,辅以特定的链下操作(例如引入特定的法律约束力),也有利于缓解或解决部分智能合约无法彻底覆盖的问题。

第二个问题是,治理提案的提出和投票很大程度上被巨鲸垄断,投票设计不完善

先谈谈治理提案的提出。还是以 Uniswap 为例。Uniswap 的提案一直是小圈子的产物,由极少数账户发起,且 Uniswap 提交提案所需的最低门槛为 UNI 总供应量的 0.25%。再来看看投票。在 PoS 机制下,持币量决定投票权,导致投票权集中在少数人手里,这也是 DeFi 治理最广受诟病的一环。

在治理提案的提出和投票都由极少数人垄断时,尤其在链上操作无法覆盖提案全流程的背景下,巨鲸们可以利用提案流程的背光面为自己谋利。去年 Uniswap 的 DeFi 教育基金拨款提案便因这一问题引起广泛的争议。有质疑者提出,该基金的立项团队中有 Uniswap 资方 a16z 的身影,投出的 UNI 票也多来自该机构授权的组织,其“自提自投”的行为是有违公允的。显然,单以持币量决定投票权剥离了巨鲸外的社区话语权,和 DAO 的去中心化精神相悖。投票设计还有很长的路要走。

投票设计可以大体分为投票工具和投票机制,我们可以简要回顾一下投票工具和投票机制的发展现状。

首先,来看看投票工具,我们可以分链上和链下两个维度去考量。此前链上最广泛采用的投票工具是 OpenZeppelin/Compound Bravo,这种方案虽然可以实现去中心化,但具有高成本、低灵活度(不支持个性化投票机制,例如全息投票和信念投票)的缺陷;而链下最广泛采用的工具是 Snapshot 链外投票——Snapshot 协议通过去中心化的文件存储介质 IPFS(行星间文件存储系统)处理投票。这一方案具有诸多优势:投票白名单的设置具有灵活性、可定制性;支持多种投票系统;链外投票,能够规避交易费用;用户易于操作。它的劣势也很明显,就是无法实现去中心化。而 Snapshot 推出的链上和链下结合的方案似乎是个万全的解决方案。Layer 2: Snapshot X(之前名为 StarkVote)与 StarkWare 团队合作,是建立在 StarkNet(第二层 ZK-Rollup)上的投票框架。Snapshot 声称,在 Snapshot X 上投票的成本约为 1000gas,比原生以太坊上便宜约 50 倍至 100 倍;除此之外,这一系统完全开放,任何人都可以在链上与之互动,不需要通过 Snapshot 客户端。当然,用户也可以将 Snapshot X 与现有的 Snapshot 客户端整合在一起。这一方案的推出,为 DAO 治理协议提供高度可定制性和灵活性。目前来看,Snapshot X 有潜力满足 DAO 治理协议去中心化、低费用、灵活度的不可能三角。

其次,再来看看投票机制。目前并没有一个取得广泛共识的投票机制,现存的机制各有千秋,大体可以按投票权重和偏好诱发机制两大类来分。

投票权重:1P1V;基于声誉的权重;委托投票;流民主

偏好诱发机制:基于法定人数的直接投票;全息投票;二次方投票;信念投票

如果读者对现存机制的具体模型和应用场景比较好奇,可以移步至 DAOrayaki 的全面研究 DAO 的治理:挑战、想法和工具,具体了解上述投票机制。

第三个问题是,社区和治理的脱节。

大部分 DeFi 社区都设置在 Discord,而社区管理的需求催生了 mod 这一角色。然而,各社区的 mod 有一个通病:他们的定位更像是服务者(解决社区成员甚至是开发者的问题),而不是引导者,这也使得社区成员自我认知为客户 / 用户而非治理者,从而导致社区成员自我定位和治理角色的脱节。

当然事物的发展都需要经历一个逐渐完善的过程,对于治理提案机制也是如此。我们需要对这个过程具有一定的包容心,同时除了对目前尚未完善的治理提案机制不满意之外,我们是否又能发现之中隐藏的“财富密码”呢?

本文内容仅代表作者看法,合作撰稿:Linda 郑郑,LuciaD。欢迎大家一起交流学习,加好友请备注姓名 - 公司\项目。市场有风险,本文中的信息或表述的意见均不构成对任何人的投资建议。

相关Wiki

【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。

郑说Web3
数据请求中
查看更多

推荐专栏

数据请求中
在 App 打开