a16z：渐进式去中心化的高级框架
去中心化不一定是“全然或非然”。作者：Jad Esber 和 Scott Duke Kominers
编译：DeFi 之道
图片来源：由 Maze AI 生成
不过，以某种程度的中心化开始并不一定会迫使你保持这种方式。在这里，我们将解释一个高级框架，用于预设未来的去中心化，并就何时以及如何这样做提供一些指导。这些指导方针既适用于 Web3 项目，也适用于更传统的组织。
去中心化有价值
去中心化是指将控制权和决策权从一个集中的实体 -- 一个特定的个人、组织或团体 -- 转移到一个分布式网络。这可以适用于企业的许多元素，包括内容创作、组织治理和流程，甚至技术栈。
去中心化并非易事
虽然去中心化对企业来说是有价值的 -- 甚至是必要的 -- 但开始时可能会很困难。许多压力在短期内推动了中心化，即使是那些致力于长期去中心化的公司。
试想一下在没有核心的中央团队或集中的决策过程的情况下，启动一个产品或进行快速迭代以达到产品与市场相适应的挑战。此外，Web3 中的去中心化通常也伴随着对可组合性的期望，这就带来了这样的风险：在你达到规模之前，其他人可能会“分叉”你的产品。依靠去中心化的管理或其他形式的众包投入，而没有适当设计的支持结构 -- 包括那些推动参与的结构 -- 有可能使平台面临欺诈或贿赂的风险。
这些力量鼓励早期的中心化。但重要的是，要确保它们不会导致设计决策，使未来的去中心化变得更加困难。也就是说，即使在早期有很好的理由要更加中心化，你也应该为未来的去中心化进行设计。
渐进式去中心化
以下是一些指导，可以帮助你积极规划未来的去中心化。
首先，必须确定你的业务可以在哪些不同维度上实现去中心化。例如，一个平台可能能够将内容策划去中心化，即使仍然有一个相对中心化的技术栈。一个特定的产品可以被分割成“最小可分权单元”（MDU），这些单元大部分是相互独立的，然后沿着这些维度分别进行分权。MDU 可能包括核心团队、外部贡献者、技术栈等等 -- 我们将在下面详细讨论各个维度。
即使在一个特定的 MDU 中，你也不必一下子从 0 跳到 100。一个平台可能会逐渐将策展权去中心化，比如说，先从社区中征求内容建议，然后再最终将内容决定权完全移交。
在视觉上，我们认为这就像一组滑块 -- 也许是一个“去中心化均衡器”，对每个 MDU 有不同的调整。你可以按照自己的节奏来滑动每一根滑块，而滑动每一根滑块的难度则取决于企业对该维度变化的准备情况。从这个意义上说，虽然考虑到去中心化架构在前期成本较高，但它可以成为竞争优势的一个关键来源，因为从长远来看，它使去中心化的过程更加容易。
MDU 描述
重要的是要在如何去中心化和去中心化什么的问题上保持一致，这需要一些高层的协调，通常还要对“去中心化均衡器”进行一些监督。在不同的业务和产品类别中，MDUs 会有所不同，以下是几个例子，以及如何为去中心化的成功进行设置的说明：
1. 核心团队。雇用能够设置工作的人，以便外部成员有可能接管一些责任 -- 例如，一个社区经理，以允许成员开始以自我管理和自我治理的方式设计社区。此外，投资于提高你的团队的技能，把去中心化作为一个长期目标，并支持这些努力的新技术和最佳实践。
2. 外部贡献者。你越是朝着完全去中心化的方向发展，你的社区就越能参与到产品的发展和管理中。根据你想要的去中心化程度进行调整，你要以参与性的方式进行建设，培养社区参与到共享基础设施的建设中，贡献内容，和/或管理系统。这不仅仅是邀请社区参与 -- 你必须以一种能够让人们做出贡献的方式来设计组织，并奖励他们这样做。也就是说，要建立强大的反馈和参与渠道，以及相应的结构和流程。
同时，在奖励方面，引入奖励积分或数字代币来跟踪和奖励社区贡献，可以帮助激励社区活动（更多关于信誉系统设计的信息，请参见我们的这篇文章）。例如，你可以从吸引外部开发者来测试你的核心基础设施开始 -- 通过分配奖励给那些通过在协议基础上建立而启动活动的开发者。
3. 技术栈。堆栈可以以模块化的方式构建，允许您在开始时交换中心化服务的去中心化版本 -- 例如，开始时在 AWS 上存储内容，随着时间的推移，过渡到去中心化的存储服务，如 Arweave 或 IPFS。
明确列出你的组织的 MDU 可能是有帮助的，以便提供一个清晰的观点，让你可以与团队和社区分享各种“滑块”。分享路线图不仅符合去中心化的精神，社区也可以帮助你达到目标。一旦你有了一套 MDU，弄清楚滑块目前在每个维度上的位置，并开始形成一个你希望它随着时间推移而发展的观点。当然，你还要有一个有意义的操作顺序，如果事情出错，团队可能应该从负面影响较小的 MDU 开始。
移动哪个滑块，何时？
最后：你要怎么知道在何时该把滑块往上移 -- 也就是说，何时可以增加一个或多个维度的去中心化？
放大来看，首先重要的是，你的整个系统是相对稳定的。但这到底是什么意思？在 a16z 的一篇早期文章中，Jesse Walden 鼓励团队评估他们在通往和超越产品市场契合度的过程中的位置：你还需要经历多少次迭代，以及多快？这一点很重要，因为任何形式的组织变革都会使运营速度减慢；你要把握好移动滑块的时间，使减慢速度的长期效益超过短期成本。理想的情况是，当你的平台的社会和经济动态已经足够稳定，你可以有力地预测调整去中心化的水平将如何影响社区的行为和结果时，你会进行移动。
接下来，你应该依次评估每个 MDU。在决定是否调整滑块时，每个维度都会有自己的一套因素需要权衡。
你可能会被推动在一个特定的维度上进行去中心化 -- 例如，你可能有太多的用户生成的内容需要自己管理，这使得让更多的社区参与策划变得至关重要。另外，你也可能完全按照自己的意愿选择增加去中心化 -- 一个例子是你看到了以去中心化方式存储内容的长期商业价值，所以你主动选择开始使用这样的服务。
再说一次，这并不是全然或非然。去中心化沿着每个 MDU 以不同的速度发生。例如，你可能从第一天就开始计划你的财务，保持“退出社区”的选择；在六个月后建立一个社区财政；然后再转为完全去中心化的财务管理。
与此同时，你可以保持一个中心化的技术栈，同时在寻找更多的点对点选择之前迭代出一个稳定的产品。
***
去中心化是强大的，但它并不容易。特别是在早期，对快速迭代、质量控制和安全的需求往往需要中心化开发（尽管这可能会随着去中心化开发技术的改进而改变）。
如果你的目标是使你的企业长期处于去中心化状态，关键是要在前期做好计划，以防在建设过程中失去跟踪。我们可能会看到首席执行官或首席运营官的角色演变，以照顾“去中心化均衡器”-- 甚至引入一个全新的职位，如“首席去中心化官”。
从 MDU 的角度思考，可以帮你弄清在哪里以及如何将业务的不同方面去中心化。随着产品的发展，当时机成熟时，你可以沿着每个 MDU 逐步进行去中心化。
