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