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