前序

“Everything is Meme”，这句话在MemeC.oin爆发的那段时间里特别流行。从前作为一名自视过高的“SmartMoney”，我并不是很理解这句话，喜欢研究的特性使得在选择项目的时候过分关注细节和解决方案。导致养成了看这也不行，看那也不行的坏毛病。不过直到People的出现才改变了我的想法，我突然开始想做这样一件事，从0开始认识和研究DAO，排除以前对DAO的偏见，从建设者的角度来分析DAO所存在的问题并给出解决方案。

我们为什么需要DAO？

DAO是一个很宽泛的名词，我看过的不同的文章对DAO都有不同的解读，这本质是在不同的范畴下对DAO作出的定义。实际上DAO是一种新的组织形式或者说是生产关系。

在去中心化的基础上，不同的团队和个人建立协作的一种组织。

总结来说，DAO具备：

自主性：任何确定的规则均基于去中心化系统自动执行，不以个人的意志为转移。这在一些对公信力要求较高的场景十分适用。如涉及重大用户利益的项目参数公投，项目代币流通解锁规则的变更等均需要通过DAO投票的形式由DAO来共同决定并依照既定结果自动执行。

去中心化：任何DAO的发展，演进，决策均基于去中心化生态，不受监管的限制，并不围绕某些核心利益集体，DAO从建立之初就应符合公开透明，公正公平的基本原则。这对一些具备共同利益，拥有共同价值观的人群极具吸引力，以ConstitutionDAO为例，按照既定的捐赠规则，ConstitutionDAO完成了一项不限地域，不限身份，没有核心利益团体的去中心化的标志性事件。这一切的基础皆是由于DAO所赋予用户的信任基础以及ConstitutionDAO用户共同的价值观。

如果你是一个追求自由，遵守规则，理解并支持按劳分配基本原则的web3建设者，那么DAO真的很适合你。

DAO的问题

不过在看过很多DAO的文章甚至是参与过一些DAO组织之后我们常常会发现一些关键问题：

1. DAO在组织效率上十分低下，过高的沟通和协作成本使得DAO很难以完成一些复杂事项的协作。

2. DAO的组织形式并没有法律法规上的依据，DAO的权利和义务没有得到充分的监督。

在面临上述问题时，我们需要再对DAO的类型做一些基本的划分，原因是不同类型的DAO对协作的要求并不一致，提出问题的前提是明确问题的范畴。

所以从协作复杂度这个角度来看，我会把DAO分为以下几类：

一般情况下，初级协作需求的场景已经足以满足，ConstitutionDAO既是一个很好的例子。

中级协作需求在一些成熟的DeFi项目里发挥着很好的作用，比如curveDAO，甚至由于curveDAO的成熟，针对DAO的新型攻击也出现了，虽然攻击行为不对，但是这也证明了DAO的社区治理模型得到了越来越多用户的尊重和认可。

不过，在更为复杂的场景下，现有DAO的治理效率会严重影响事件的推进。这也导致，大量去中心化产品的去中心化程度并不高，本质上大量项目依旧由某个具体的公司来运营和决策。即使是sushi这样开创了无VC，无预挖机制的社区项目，运营至今也出现了多次中心化的负面事件。灵魂人物离职，亚太地区市场负责人公开质疑sushi的集权问题。

出现了这么多问题是不是意味着DAO在面临复杂场景时只能完成局部的改造？比如初，中级需求社区治理，高级需求公司治理？

我认为并不是，问题并不是DAO不可行，而是：

1）DAO的基础设施太过薄弱

我试用了多个DAO的工具，包括Aragon,DAOstack,Colony,Haus这样的DAO创建工具以及GNOSIS，Snapshot，Superfluid这样的一些DAO Tools。

发现大多只针对一些较为简单的需求，如投票捐赠，资金管理等。无法处理高级协作需求。

2）社区对DAO的重要性并不能完全理解。

越是在fomo情绪浓的市场当中，用户教育成本也越高，这意味着大量用户并无充足耐心理解DAO的重要性，也导致用户对去中心化自治的兴趣不足。

第二个问题较容易解决，在两种情况下用户会主动接受更高的门槛：

（1）是黑天鹅事件发生，比如DeFi项目被盗事件频发，而大量项目被盗的原因却经常是私钥泄漏这种愚蠢的问题，甚至钓鱼的黑客会盯上那些在github频繁提交代码的开发者，向他们发送钓鱼邮件和信息。最终结果是泄漏事件频发。这种问题很好解决，可以有管理员权限，但务必多签管理。这也是DAO的职责之一，分散的管理结构会极大的增强安全性。

（2）经济效益促使用户完成学习，DeFi一开始的门槛也很高，在18年我在为一些早期项目做贡献时仔细计算过，对于真正的小白来说，完成从登陆到投资再到退出变现的完整流程平均需要16步。曾经我也怀疑DeFi的可行性，但是流动性挖矿所造成的造富效应使得DeFi的用户得到了爆发式的增长。想象在Web3热点的加持下，DAO可以重新激起大家的兴趣。

但是第一个问题较难解决，因为在面向复杂协作关系时，DAO的基础设施所需要考虑的点太多，且很少有团队能够完整的梳理整个协作过程中所需要准备的所有的内容。涉及的“接口”过多，需要更加深入的思考才可以做出最好的设计。

解决方案

1：正向推演

要处理复杂的协作问题，首先我们需要确定协作的各类变量以及最小单位，比如复杂协作中的组织架构问题，收益分配问题，权限管理问题，贡献判定问题等。每一个问题都是一个大的变量，大的变量里面包含各类细分变量。

以组织架构问题举例，组织架构中涉及到不同职能的级别，权限，职责，义务等诸多小的变量。从公司层面来说，如果要顾及到复杂协作的方方面面，难度约等于制定完整的公司章程，管理制度以及人事制度等等。

因此很难从头开始直接给出完整的变量以及最小单位，但是从产品设计的角度来说，完善的需求并不是一蹴而就的，需要不断的完善和演进。因此，我们可以换一个思路，从实际情况出发，用逆向的思路推演出一些现有的明确的需求，并且尽量最小化，使得未来新加入的需求不会受制于初期的设计，增强扩展性。