为什么需要DAO

这是我们系列文章中的第七篇同时也是倒数第二篇文章，“在区块链上获得API”。到目前为止，我们已经介绍了API连接问题，并着重介绍了我们解决方案的几个主要组成部分，即第一方预言机和可量化的安全性。这篇文章重点介绍了我们设计的另一个主要组成部分。

关于以DAO形式的去中心化治理的讨论很多，直至现在也仍在讨论中。这是因为我们讨论DAO的各种运行方法越多，就越需要客观的功能来衡量DAO的成功程度，以便比较好的/坏的/更好的DAO结构和运行机制。在这个领域中任何目标的创建都不可避免地涉及以下问题：我们如何最佳地组织大众？而且，我认为这是完全没有争议：这仍然是一个尚未解决的问题。

我个人对DAOs未来的思考将在我自己的文章中阐述。因此，为了使这篇文章保持简短，我将快速分享一些以前关于DAOs主题的文章链接，为我们的讨论提供一些背景，并激发我们的哲学审美，然后我将转移到更实际的问题上

去中心化的治理如何使接受链上数据源的用户受益? 为什么是API3 DAO，而不是一个中心化的项目？

也就是说，我宁愿使用具体项目原因的具体例子来回答这些问题，而不是以老生常谈的某种形式宣扬“去中心化就是好''的论点（总的来说，我确实相信，但这并不是最初的“热点”）。

理论:为什么需要DAO

创建DAO是为了帮助区块链协议处理未知问题。也就是说，如果可以从一开始就完美地设计协议，那么创建一个DAO来监督协议的更改就完全没有必要了

自治代理是最难创建的东西之一，因为为了成功，它们需要能够在一个不仅复杂、变化迅速，而且充满敌意的环境中运行。

去中心化的自治组织的理想很容易描述：它是一个生活在互联网上并自主存在的实体，但在很大程度上也依赖雇用个人来执行自动机制自身无法完成的某些任务。

— Vitalik Buterin, 2014

蜜蜂被困在琥珀中并成为了化石的一部分。尼克·萨博（Nick Szabo）以前曾用“困在琥珀中的苍蝇”类比来解释区块链，特别是不变性和区块确认时间。（图片来自George Poinar Jr./ OSU）

在许多方面，区块链最大的优点之一是它的不可变性;但是，就像所有的事情一样，积极的背后总是隐藏着消极的一面。如果协议的次优实现像是琥珀一样在区块链中固定住，那该怎么办呢？

也许人们可以创建一个生活在区块链上的自治代理，该代理针对其特定的环境进行了完美的设计，以至于永远不需要人工输入（或者，也许使用时间很短。）但是， 协议越复杂，这种完美工程的假设就越不可能成立。

当协议被创造出来时，将会遇到许多未知因素。事实上，许多区块链项目甚至在开始之前就能明确指出，他们的协议在未来必须解决什么样的不确定因素(已知的未知因素);就像是许多抵押贷款平台面对的ETH价格变化和波动性。这些已知的未知通常通过使用预言机来解决的。然而，更令人担忧的是，协议很可能遇到未知的未知。这些类型的未知的存在要么被忽略，导致项目或分支失败，要么通过DAO预期和准备它们。

如今，许多项目都正确的认识到未来不可避免的会遇到未知问题，因此选择开放他们的协议，以便通过DAO以去中心化的方式提出和商定未来的修正案(以维护端到端分散系统的良好外观)。

如何最好地构造一个DAO

这个小节的标题可能有点误导人，因为我不会提供一个解决方案(而且现在没有办法提供一个解决方案)。相反，我将简单地提及一些关于这个主题的好文章和一些好的观点。

在2014年的这篇文章中，Vitalik Buterin通过将DAO与传统机构甚至是机器人和AI（自治代理）进行多样化比较/对比来定义DAO。他以许多开放式的问题（“难题”）结束，其中包括：“ 【DAO中的成员】资格应为公司形式，拥有可出售和可转让的股份，还是非营利性形式，成员可以在其中投票其他成员” ？DAO应该尝试保持其他货币的余额，还是仅通过发行自己的内部代币来奖励行为？”

还有一篇去年由Daniel Kronovet写的优秀文章。在书中，他比较了四个主要DAOs的技术实现和基本观点:Aragon、DAOstack、Colony和Moloch。Kronovet还提出了几个难以回答的开放式问题:组织边界的可渗透性应该有多大（进入组织的难易程度）?每个人应该有多大的影响力?如何保护个人免受他人不良行为的伤害?参与的难度如何？

在Joshua Tao最近的一篇文章中，他认为DAOs不仅仅是一堆智能合约;它们也是社会组织，由为一个共同目的而聚集的个人组成的实体。因此，他将注意力集中在研究DAOs的整体方法上，将技术工程和社会设计结合起来。四个关键概念被定义为制度、组织、章程、可计算章程，并结合起来创建一个框架，在其中考察当前DAO的景观。他的结论很开放，和其他文章一样:但是还有很多要探索的地方。

我看到所有这些讨论都被粗略地归结为无处不在的推拉式/阴阳式的结构vs可变性(或刚性vs流动，或秩序vs混乱，……)。有多少DAO需要进行硬编码和不可变？其中有多少可以更改和修改？“代码即法律”在多大程度上真实？DAO的结构是否仅通过不可变的智能合约在区块链上单独执行和维护，还是该结构也作为由社会共识执行的社会契约而存在？

这些非常基本的问题很快就打破了政治学、社会学以及其他一些主要学科的领域。在这篇简短的文章中，我们无论如何都不会再讨论这些事情。但我确实想指出，我们一直都在注意这些问题。

我个人的看法是，就像人类语言通常以一种美丽而复杂的结构进化且不会瓦解，稳定而又不断变化一样，DAO也可以平衡体系和流动性，使其在踏上未知之路时得以发展和加强。（遇到DAO（道）这个词也增加了我对此的信念，这是一个古老的中文单词，象征着道路，路径和主义的融合。）

现在，我们来讨论一些更实际的问题。

实践：API3如何从成为DAO中受益

通过解决API连接问题，我们不仅在处理区块链，还在处理链下的世界，通过它具有独特的优势。创建能够与世界上所有丰富的数据类型(链上和链下)完美交互的自主代理(通过智能合约)变得更加困难。这就需要创建一个DAO来管理协议。

下文用4个实际的用例来突出说明DAO特别有利于API3项目的原因。

组织扩展性

默认情况下，DAO由成员创建提案并对提案进行投票（更改/修改区块链协议）来工作。这种默认行为并不是特别有效或可扩展。但是，DAO的潜力比其传统的公司同类产品更具效率。

一个示例治理拓扑结构，由分布在链上的主DAO、子DAO和团队组成。DAO 主体通过有选择地分配资金和下放权力进行管理。当一个任务达到一个团队不能再完成的规模时，它被分配给一个子dao。

与传统的公司层次结构相比，DAO通过子DAO和支持多签的团队更容易并行化（或分形）。这是因为这样的子结构可以相当独立地发挥作用，而最小化较大的管理实体的干扰，而仍然受到精心设计的激励措施的驱动，并受到某些程序限制的约束。

API3 DAO将对有关系统的高级参数进行投票，例如鼓励最佳staking奖励。此外，DAO将从DAO银行提供赠款，从而决定项目的总体方向。通过分层的团队结构将执行更精细的任务。

此外，独特的是，API3 DAO将被初始化为若干里程碑，为更大的API3目标提供主要的路标(或非线性路线图)，从而指导项目的总体方向。这些就是API3故事的主题和元素，它们将团结整个社区

所有人类合作的基础是对共同故事的信仰。

尤瓦尔·赫拉利：《人类简史》

透明数据源结构

有数据喂价经验的用户可能想知道数据源的准确性，可信性和可靠性。 尤其是如果他们的系统对错误和不准确性特别敏感（例如带有清算爆仓环节的区块链协议）。

使用API3 DAO时，新数据源的构建是一个完全开放的过程，因为每个数据源落实之前都会有一个提案。DAO将众包和/或分配给团队以评估API提供方（及其准确性，可信赖性和可靠性），并将意见转化为适当的数据过滤和汇总方法。

引入区块链的每种新数据类型都需要定制专业的分析方法。为了说明这一点，请考虑以下内容：汇总来自传感器（位于不同位置）的天气数据，汇总来自多个交易所的价格数据（代表不同的交易量）以及汇总二进制是/否响应。这些不是同一件事，也不应将其视为同样的事情而处理数据。

数据源的结构必须透明且灵活。深入研究数据的任何人都了解透明性和定制数据分析是至关重要的，毕竟，数据科学既是科学，也是艺术。

监管套利

通过将控制权去中心化，可以分散治理者的执法目标，从而实现更自由的系统。DAO的优势在于，监管机构甚至没有必要去追究它们（要么因为他们认为它们是良性的，要么他们认为这样做是徒劳的）。

从法律层面上讲，一个区块链充分去中心化的证明就是没有人能控制这个系统,,没有人在法律上对它负责，它不受通常在类似情况下适用的法规（例如证券法）的约束。²

消除故障的中心点

数据源和/或“去中心化的” 预言机网络中心化管理意味着这些相应的智能合约集可由中心化的单一个体配置。这是单点故障。重要的是，这可能会导致管理错误不被注意，甚至在基础API和预言机正常运行时，也可能导致数据提要错误报告。我们已经看到了这样的例子。¹

集中的管理有权重组数据源，这意味着切换预言机和它们各自代表的数据源。这对于数据源的长期维护是必需的，但它会使数据源用户受到治理者的各种滥用和攻击。一个中心化管理者很容易不透明地使用不合标准的做法，甚至更明显地，使用他们的权力恶意地错误报告。在任何情况下，预言机网络和数据传输的中心化治理都是不合理的。

结论和最后的博客文章预告

我们已经讨论了DAO不断发展的理论，并且更实际地讨论了DAO治理如何使API3项目受益。API连接问题的某些细微之处使其解决方案特别受益于去中心化治理。

如果您从一开始就关注这个系列，我很高兴地告诉您，现在已经向您介绍了API3设计背后的主要思想，尽管有些不连贯。下周，在本系列的最后一篇文章中，我将再次列出这些部分，并展示如何将它们组合在一起来解决API连接问题。