渐进式去中心化：一个高级框架

去中心化在web3中是一个必然的趋势——它在其他商业上下文中也会很有用。在web3中，目标是为了安全、开放和社区所有权而避免中心化，而在更传统的商业中，去中心化可以帮助与利益相关者进行互动，并促进更明智的决策——例如，去中心化是执行“自我管理组织”这一流行概念的关键。

然而，从一开始就完全去中心化可能非常困难，甚至完全不切实际。项目或业务早期的设计元素往往需要更多的中心化视角和控制。并且在早期阶段的中心化可以使协调、启动和快速迭代以实现产品市场适应变得更容易。

然而，从某种程度的中心化开始，并不一定会迫使你一直保持这样的状态。这里，我们将解释一个高层次的框架，用于在一开始就设计未来的去中心化，并提供一些关于何时以及如何这样做的指导。这些指导适用于web3项目和更传统的组织。

我们的目的是帮助那些对去中心化感兴趣的人思考如何应对这个挑战。可惜的是，没有一种通用的做法，因为去中心化的具体机制在很大程度上取决于特定的商业背景。因此，这被视为一个介绍——它不是一个操作手册，以便分组件地做决策，而是一个关于如何开始思考整体问题的框架。

如果有一个要记住的点，那就是去中心化不一定是“全有或全无”。通过适当的规划，你可以随时进行去中心化。为了有效地规划，重要的是要理解你的业务可以沿着哪些不同的维度去中心化，以及在适当的时机如何进行。

用许多我们曾经经历过的事情来类比，渐进式去中心化就像一个组织变得完全远程。一开始在一个中央办公室内进行面对面会议有利于协调，但随着时间的推移，变得更加分散是合理的。但要管理分散的工作，必须投资于远程通讯技术，以及仔细记录业务实践和架构。设计一个组织，以便你们有一天会都变得远程，使得未来的状态更容易。渐进式去中心化也是如此。

去中心化的价值…

去中心化是将控制权和决策从一个中心化实体——一个特定的个人、组织或团体——转移到一个分布式网络。这可以适用于商业的许多元素，包括内容创作、组织治理和流程，甚至技术栈。

去中心化通常是功能性的。例如，一个组织可能会从一个去中心化的个人网络中汇集意见。事实上，web3中的价值创造在很大程度上取决于利用共享的所有权来激励众多人的参与和互动。（在之前的一篇文章中，我们写过，“创建直接与用户分享价值的开放平台将为每个人，包括平台，创造更多价值。”）

在其他背景下，去中心化可以提供安全性——例如防止审查（尽管要实现这一点，重要的是要正确构建治理）。另外，寻求利用自身数字资产的web3平台也需要出于合规原因进行去中心化。

或许最重要的是，去中心化可以作为一种承诺，以构建符合用户最佳利益的产品——类似于如何共享治理使合作社强调健康文化和资源及收益的长期公平分配。还有一类人更可能自愿加入那些计划去中心化的项目，既出于原则上的考虑，也因为他们相信这样的项目在长远中更具价值。

…但去中心化并不容易。

虽然去中心化对于商业可能是有价值的——甚至是必要的——但一开始以这种方式起步可能很困难。即使对于长期致力于去中心化的公司，短期内也有许多因素推动中心化。

例如，想想在没有核心团队或集中决策流程的情况下，启动产品或进行快速迭代以达到产品市场适应所面临的挑战。此外，web3中的去中心化通常还伴随着对可组合性的期望，这引入了风险，即在你取得规模之前，其他人可能会对你的产品进行“分叉”。而依赖于去中心化治理或其他形式的众包输入而没有设计得当的支持结构（包括驱动参与的结构），可能会使平台面临欺诈或贿赂的风险。

这些因素在早期鼓励中心化。然而，确保这些因素不会导致以后更难进行去中心化的设计决策是非常重要的。也就是说，尽管早期中心化有很好的理由，但你应该为未来的去中心化进行设计。

渐进式去中心化

以下是一些指导，以帮助你积极规划未来的去中心化。

首先，明确定义你的业务可以在哪些不同维度上实现去中心化是至关重要的。例如，一个平台可能可以在内容策划上实现去中心化，即使技术栈仍然比较中心化。一个特定的产品可以被划分为“最小可去中心化单元”（MDUs），这些单元彼此之间大部分都是独立的，然后在每个这些维度上分别进行去中心化。MDUs可能包括核心团队、外部贡献者、技术栈等——我们会在下面详细讨论各种维度。

即使在一个给定的MDU内，你也不必一次性从0到100。一个平台可能逐渐去中心化策划，比如先征求社区的内容推荐，然后最终完全交由社区决定内容。

在视觉上，我们将此视为一组滑杆——一个“去中心化均衡器”，每个MDU有不同的调节。你可以根据自己的节奏调整每个滑杆，而调整每个滑杆的难度取决于业务在该维度上的变化准备程度。从这个意义上讲，虽然以去中心化为目标进行架构设计在前期成本更高，但从长远来看，这可以成为竞争优势的重要来源，因为它使去中心化的过程更加容易。

描述MDUs

围绕如何以及去中心化什么保持一致的愿景是非常重要的，这需要一些高层次的协调，通常还需要对“去中心化均衡器”进行一些监督。MDUs在不同的业务和产品类别中会有所不同，但以下是一些例子，以及你可能如何为去中心化成功进行设置的说明：

1. 核心团队。招聘能够设置其工作，使外部成员可以接管部分责任的人——例如，设立以允许成员开始自我管理和自我治理的方式设计社区的社区经理。此外，投资于提升团队技能，朝着去中心化的长期目标以及支持这些努力的新技术和最佳实践。

2. 外部贡献者。你越是向完全去中心化滑动，你的社区对产品变化和治理的参与就越多。根据你希望去中心化的程度，你将希望以参与的方式重建，并培养将参与到共享基础设施之上进行构建、贡献内容和/或治理系统的社区。而且这不仅仅是邀请社区参与——你必须以一种使人们能够参与并奖励他们的方式来设计组织。这意味着建立强大的反馈和参与渠道，以及随之而来的结构和流程。

在奖励方面，引入奖励积分或数字代币来追踪和奖励社区贡献可以帮助激励社区活动（参见我们这篇文章关于声誉系统设计的文章）。例如，你可以首先邀请外部开发者测试核心基础设施——也许通过向那些通过在协议上构建而激活活动的开发者分配奖励。

3. 技术栈。 技术栈可以以模块化方式架构，以便你可以替换你最初使用的中心化服务的去中心化版本——例如，最初存储内容在AWS上，随后逐渐转向去中心化存储服务，如Arweave或IPFS。

4. 财务。你应该在如何最初为业务融资以及如何在内部和外部分配资源方面规划去中心化。特别是，你应该以一种能够在没有中心控制的情况下维持组织的韧性结构来构建财务——例如，考虑你所引入的投资者对社区控制的退出（我们也许可以称之为“去中心化退出”）的反应，并考虑定期分配给社区金库。

5. 内部流程。很重要的是前期花时间思考你为了去中心化部分运营和业务流程可能需要什么——例如，你可能需要丰富的文档，以便社区成员理解具体治理决策的前例或背景。

显式列出你的组织MDUs可能会有所帮助，以便为不同杠杆的分享提供清晰的视图，以便与你的团队和社区进行共享。分享路线图不仅符合去中心化的精神，社区也可以帮助你实现目标，并要求你承担责任。一旦你拥有了一组MDUs，弄清楚每个维度上滑杆目前的状态，并开始形成你希望随着时间推移而改变的愿景。同时，这里也有一个操作顺序是重要的，团队可能应当从负面影响较小的MDUs开始。

该移动哪个滑杆，何时移动？

最后：你怎么知道何时该移动滑杆——也就是说，何时可以增加一个或多个维度的去中心化？

放眼全局，首先重要的是你的整体系统相对稳定。这究竟意味着什么？在之前为a16z撰写的一篇文章中，Jesse Walden建议团队评估他们在通向及通过产品市场适应的旅程中的位置：你还需要经过多少次迭代？多快？这是很重要的，因为任何形式的组织变革都会放慢运作；你希望调节滑杆的时间是，使得长期利益超过短期成本。理想情况下，你也将在社交和经济动态在你的平台上已经稳定的时间，来作出计划，从而能够更加强有力地预测调整去中心化水平将如何影响社区行为和结果。

接下来，你应依次评估每个MDU。每个维度在决定是否调整滑杆时都有自己的一组要考虑的因素。你可能会被推动在某个特定维度上去中心化——例如，你可能有太多用户生成内容无法自行管理，进而迫切需要让更广泛的社区参与策划。或者，你可能选择完全出于自愿地增加去中心化——一个例子可能是你看到以去中心化方式存储内容的长期商业价值，因此主动选择开始使用这样的服务。

再次强调，这不是全有或全无。去中心化在每个MDU上的进展速度各不相同。例如，你可以从第一天开始以一种保持“共同体退出”选项的方式规划你的财务；六个月后建立一个社区金库；然后再转向完全去中心化的财务治理。同时，你可能保持一个中心化的技术栈，同时迭代以实现一个稳定的产品，再寻找更多的点对点选项。

\\*\

去中心化是强大的，但并不容易。尤其是在早期，对快速迭代、质量控制和安全性的需求常常驱动中心化开发（尽管随着去中心化开发技术的改善，这种情况可能会改变）。

如果你希望你的业务在长期内实现去中心化，关键是事先进行规划，并在构建的过程中不至于偏离方向。我们可能会看到CEO或COO的角色 evolve，来负责“去中心化均衡器”——甚至引入一个全新的职位，如“首席去中心化官”。通过考虑MDUs，你可以帮助搞清楚在哪里以及如何去中心化不同方面的业务。随着产品的发展，你可以在每个MDU沿着正确的时间渐进式去中心化。

\\*\

Jad Esber是koodos labs（商号为koodos）的联合创始人和CEO，也是哈佛伯克曼克莱因互联网与社会中心和新学校合作数字经济研究所的研究员。他建设、撰写并谈论社交空间、创意工具及其与去中心化技术交叉的主题。此前，他曾在谷歌和YouTube工作，为新兴市场的创作者和艺术家提供服务并建立相关工具。

Scott Duke Kominers是哈佛商学院的商业管理教授，哈佛经济系的教员工作者，并是a16z crypto的研究伙伴。他还为许多公司在市场和激励设计方面提供咨询；有关更多披露，请参见他的网站。

\\*\

致谢：作者感谢 Brandon Baraban , Dmitriy Berenzon , Cam Brand , Apurva Chitnis , Sonal Chokshi , Andy Hall , Miles Jennings , Valet Jones , Steve Kaczynski , Elena Mikhaylova , Kirill Noskov , Tim Roughgarden , SAFA , Kevin Shay , Jennie Silber , 和 Porter Smith 提供的有益想法和评论。特别感谢编辑 Tim Sullivan.

\\*\

• 原文链接： a16zcrypto.com/posts/art...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～