渐进式的DAO框架：TributeDAO

为了更好的定义TributeDAO，标题里用了渐进式这个词，不知道什么是渐进式请不要担心， 看完下面就知道了。用过Vuejs的人可能知道Vuejs是一个渐进式的前端框架，那么什么是渐进式的DAO框架呢？为了解答这个，我们先看一下TributeDAO的整体架构：

TributeDAO主要由三个部分组成：Core，Adapters，Extensions。

Core包括DAO注册表（用来存储DAO中的重要数据）和一些其他的东西。

Adapters包括投票，DAO准入，贡品，NFT贡品，公会踢，怒退，提现，融资等。

Extensions包括金库和NFT。

另外，有一点需要注意，数据/信息永远是从外界流向Core的, Core想要获取数据只能通过Adapters或Extensions。

熟悉Moloch DAO的人看到这里应该就明白了，这不就是把Moloch DAO给拆了吗？是的没错，就是把Moloch给拆成一个个小模块并且因为细致的拆分使组合变得很方便。有了Tribute DAO，Web3世界里就有了DAO的乐高积木了。因为是渐进式的，所以可以将DAO一点一点的变得更庞大。

现在大家应该可以理解渐进式了，就是把需要的功能像拼乐高那样组合到一起。所以本文也可以有其他的名字，比如：积木式的DAO框架，拆得七零八落连Moloch的工程师来了都认不出来的另一种Moloch DAO框架。

做成积木式的好处就是可以只添加自己需要的功能，比如有的DAO不需要公会踢，那么组合出来的DAO就不包含公会踢。除了组合方便之外定制也很方便，比如可以做一个新的Adaptar来支持二次方投票，或者把任何人都可以发起提案改成只有DAO成员才能发起。

因为Adapters和Extensions的含义比较相近，所以大家可能对这两个词比较困惑。在这里也做下解释：Adapters指的是DAO的一个个模块， 就像乐高积木或者Minecraft的小方块。Extensions指的是与DAO注册表隔离的复杂状态。也就是说，几个DAO可能由相同的Adapters组成，但是内部状态/数据不相同。

看过Moloch合约的人应该可以感受到Moloch的可扩展性很差， Minion(小兵/奴隶)诞生之前基本上只能通过tribute, shares做各种操作。在Moloch V2中，虽然增添了更多的提案类型，但这是通过在合约中增加不同提案函数完成的，就不是很优雅。在Minion诞生之后, 虽然可扩展性得到了增强但是基本上也没逃离代理的思想(Aragon也有个agent)。有了Tribute DAO之后DAO内部的操作就可以通过新的Adapters或Adapters的组合来完成了，除了实现方式优雅外，代码也更容易维护。虽然与外部合约交互依然需要Minion，但启动一个新的项目完全可以把Tribute DAO集成到应用内部(手动狗头.jpg)。

Tribute DAO对NFT支持的很好，在Tribute DAO中可以使用ERC721作为tribute加入一个DAO(在写本文时，DAOHaus的NFT Banks依然是coming soon的状态，快点更新啦)。除了上文提到的二次方投票之外，也可以使用Adapters去实现一人一票。另外，Tribute DAO也支持ACL(访问控制层)，这样可以更容易的做DAO内的权限管理了。

总的来说，在Tribute DAO上可以看到DAO的未来，因为可以像空气，水和电一样无感的融入到各个应用中。如果你的团队有开发人员并且需要一个DAO 那么我非常推荐使用Tribute DAO。

一起拥抱未来吧！

作者的非正经介绍:

茯苓(Poria Cattus): DAOSquare的萌新研究员(顺便敲敲代码?), 今后遇到有趣的项目会写一些调查笔记与大家分享。

郑重声明：本文版权归原作者所有，转载文章仅为传播信息之目的，不构成任何投资建议，如有侵权行为，请第一时间联络我们修改或删除，多谢。