区块链技术团队DAO怎么搭 从架构到治理的实操路径

导读： 在过去的那些日子里, 有越来越多的属于技术研发方面的集体开始把那种叫做去中心化自治组织的东西当作是一种组织的模样来进行各种尝试。如果你说实在话...

在过去的那些日子里, 有越来越多的属于技术研发方面的集体开始把那种叫做去中心化自治组织的东西当作是一种组织的模样来进行各种尝试。

如果你说实在话, 那么所谓区块链技术团队采用的这种去中心化自治组织形式的概念, 听上去确实是非常崭新的, 可是等你真正着手把它放到实际场景中去应用的时候, 你肯定会发现, 真正的困难地方并不是在于那个共识机制到底是怎么运作的一回事儿, 而是会体现在怎么能够让那些记录在区块链上的治理行为和你大家在现实生活网络之外进行的工作配合得能够紧密无缝这样一个连接过程上。

接下来我们会谈一些在实际操作的各种项目里遭遇到的各种让人头疼的失误与教训。

区块链团队DAO怎么搭

最终决定的核心点在于, 要把治理合约部署在哪个区块链网络上。虽然以太坊这个生态已经很成熟了, 但是那个气体费太贵了, 让人退避三舍。而如果把投票功能运行在索拉那网络上的话, 体验确实不错, 可是周围的生态支持工具又太少了。

因为我们是一个专门做智能合约审计的团队, 经过反复权衡后, 最后选了那个 Arbitrum 网络。这样可以让手续费降到几毛钱, 结果就是让内部成员参与投票的积极性提高了整整一倍那么多。

不要一上来就把所有的治理工作全都放到链上去做。在早期的阶段, 团队只有十个人左右, 很多时候大家只要在群聊里面把相关的决策内容讨论清楚，然后再把这些结果记录到区块链上面去就足够了。

如果非要等到团队的人员规模扩大到了五十人以上, 再去考虑把提案、投票以及执行这几个部分分别拆分开来放到区块链上进行处理, 那样的话, 整体的运行节奏才会显得比较顺畅且轻松, 这才是让人感到舒服的状态。

DAO团队怎么选链

选择具体的区块链技术栈, 这件事本身并不是纯粹的技术层面的难题, 更核心的关键在于团队自身的综合能力状况。如果你的团队具备全栈开发的能力, 那么去选取像Ethereum加上Layer2这样架构的方案是完全可行的。

然而, 要是你的团队成员大多只擅长编写Solidity代码, 并且对前端开发的了解并不深入的话, 那就不应该强行去采用Cosmos这样的技术路线, 因为与之配套的工具链在实际应用中会给你带来非常大的困扰, 甚至可能导致工作无法正常推进。

另外, 有一个点往往容易被忽视, 那就是代币的设计工作。

因为团队内部用来进行治理的流通代币, 其增发的具体节奏、锁定的周期时长以及最终退出的机制安排这些关键内容, 都需要在写入智能合约条款之前, 强烈建议邀请至少两位投资人共同来进行一次全面的审核和确认, 这样就可以有效避免后续再去做修改所面临的麻烦局面。

DAO它不是一套那种拿来就能直接用的现成模板, 它更像是你把自己团队内部的那些规则通过代码的形式给它表达出来了, 你需要先把谁拥有投票权这个问题想清楚, 然后还要把怎么修改规则的这件事也想明白, 当这两点都理顺了, 那剩下关于技术方向的选择问题反而就变得容易处理了很多。