DAO的可编程性、可组合性

BlueYard热度: 18854

DAO 本质上是通过 API 执行功能的可编程组件。

原文作者:BlueYard

编译:Kevin Tse

翻译机构:dao2

原文来源:mirror

关于 "货币乐高 "的想法已经谈了很多,特别是在去中心化的金融系统方面,加密货币是可编程的货币,而可编程的组件做得好是可组合的。软件行业有丰富的可组合性方法的历史(以及与之相关的代码重用)。因此,当你开始把钱和围绕它的能力(借贷,借出等)看作是可编程的组件时,接下来的自然步骤就是看看这些与货币相关的各种组件如何以新的和意想不到的方式组合在一起。

有鉴于此,什么是 DAO(去中心化自治组织)?根据我目前的经验,DAO 是在线讨论组,充其量只有一个共享的资金库和一个治理系统,以帮助确定如何使用这些资金库。但 DAO 的真正承诺是它们可以成为可编程组织,就像加密货币是可编程货币一样。

可编程组织的概念带来了创建可组合、可重用的组织结构和能力的能力。

尽管 DAO 表面上是由人(或其他 DAO、机器人或……)组成的,但在其核心,DAO 与任何其他人群的不同之处在于它是通过代码进行管理的。用程序员的话说,我们通过 API 或应用程序编程接口与 DAO 交互。在分散的基于区块链的系统中,这些 API 采用智能合约上可公开调用的函数的形式。虽然 DAO 是由人类(有时是其他程序)编排的,但 DAO 的真正功能是它的智能合约。其他一切,正如 Orca 协议团队喜欢称之为的那样,SocialWare(基于人类信任由人类手动运行的系统)。

DAO 本质上是通过 API 执行功能的可编程组件。

这些能力是什么?什么是 API?

就可编程系统而言,目前,大多数 DAO 包含两件事:


  • 会员名单
  • 共享钱包/金库


讨论在 Discord 中进行,聚会在会议上进行,小组开始编写代码、设计东西、推文等,但大多数 DAO 的本质——将它们作为 DAO 与在线俱乐部区别开来的地方——归结为这些两个功能领域。今天的 DAO 实施代码来管理会员资格和花钱。

那么,可以管理成员和钱包的组件是可组合的,这意味着什么?


  • 成员管理(加入、离开等)和多方钱包(投票、执行交易、转移资金)的公开访问功能
  • 这些功能的标准化接口(记录的名称、输入和预期输出),以便多个实现可以互换。
  • 一组标准化的调用约定,因此每组功能或接口不需要完全不同的交互方式。这样做的好处是允许不同类型的模块相互替代或以相同的方式进行管理。这也意味着调用可以以接口创建者没有计划的方式链接在一起。像这样的调用约定的一个历史示例是基于 UNIX 的系统的工具几乎都从其输入和输出文本中读取文本,从而允许将它们与管道链接在一起。


Zodiac 团队在为可组合的 DAO 行为创建提议的标准方面做了一些出色的工作,这与面向方面编程的概念方法类似。

虽然我们现在在行为方面讨论可组合性,但可组合性也适用于数据。例如,Orca 协议实现了由许多 DAO(称为 Pod)组成的 DAO。在理论上无限大小和复杂性的图中,每个 DAO 可以有零个或多个 DAO 作为父级。在顶层,DAO 由其所有成员递归组成,无论是人类、DAO/Pod 还是与机器人相关的其他身份等。

现在我们对大多数 DAO 是什么以及可组合对它们意味着什么有了一个简化的认识,您可能会认为这听起来并不令人兴奋,人类协作的世界远比简单的组建团队、筹集和花钱的能力丰富得多。事实上,到目前为止,我们构建的这些 People Lego 并不是很有用。他们除了存在还做什么?不多,尽管 DAO 中的人类可能很忙并且非常有生产力,创作艺术、音乐、公司、在线材料或试图拯救地球,但 DAO 本身是肤浅的,几乎没有特色。

DAO 可组合性的下一步是扩展 DAO 本身的功能,并相应地扩展 DAO API 的表面积。

我的方法是从实现一个具体的实例开始,迭代那个实例,然后转到另一个实例。在一些具体的实现之后,模式就会出现。让我们探索一个可能的实例:客户服务。

想象一下,一个新的DAO,SupportDAO,被创建来为web3公司的客户支持票提供服务,这可能是一个营利性组织,其成员是客户支持专家,并围绕着大规模处理在线客户支持建立了一门学科, 我选择这个例子是因为这个行业已经为客户支持制定了一套半标准的可衡量的关键绩效指标,几乎所有这些指标都很容易衡量(见下文的例子)。

SupportDAO 有成员和共享的金库,因此,在可组合的通用 DAO 生态系统中,它可以为这些高级功能实现标准接口,但是 SupportDAO 还能做什么呢?其 API 的核心是从票务系统向其提供客户支持票证的功能,以解决这些票证,然后根据这些票证的成功解决进行支付。

DAO(或公司)如何不信任地向另一个 DAO 支付处理客户支持票的费用?根据商定的一组 KPI 付款。例如,付款可能是以下功能:


  • 处理的票据数量
  • 解决问题的时间
  • 首次接触的时间
  • 已解决的工单与未解决的已关闭工单的百分比
  • 排队工单的平均年龄
  • 客户 NPS
  • 等等


这些都是可测量的,并且可以通过链上(可能不是)或通过预言机进行集成,这意味着 SupportDAO 可以作为一个自主的、无需信任的组件运行,而不是由人类手动协调以进行支付,这是对设计的一种公认的幼稚肤浅的看法,但我觉得它令人兴奋。

像这样的支持 DAO 的 API 将是可组合的,任何构建应用程序或服务的组织都可以评估将其插入并拥有新的客户支持功能,而不是建立自己的客户支持组织,更重要的是,如果 API 是标准化的(甚至是事实上的),多个支持 DAO 可以实时竞争,以便为每个组织提供更好、更快的服务,同时(甚至是匿名)坐在 API 后面。

客户支持只是可以通过智能合约和标准化 API 实现的领域之一。随着我们探索去中心化组织和协作模型的未来,这些模型看起来更像是小团队的联盟而不是单体,更多的接口和自动化协作机制将会出现。


声明:本文为入驻“MarsBit 专栏”作者作品,不代表MarsBit官方立场。
转载请联系网页底部:内容合作栏目,邮件进行授权。授权后转载时请注明出处、作者和本文链接。未经许可擅自转载本站文章,将追究相关法律责任,侵权必究。
提示:投资有风险,入市须谨慎,本资讯不作为投资理财建议。
免责声明:本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况,及遵守所在国家和地区的相关法律法规。