作者：Jad Esber 和Scott Duke Kominers
編譯：DeFi 之道
圖片來源：由Maze AI 生成
去中心化是Web3 的當務之急——它在其他業務環境中也很有用。在Web3 中，目標是為了安全、開放和社區所有權而放棄中心化，而在更傳統的企業中，去中心化有助於利益相關者參與以及更明智的決策，例如，去中心化是執行“自我管理組織”這一流行概念的關鍵。
然而，一開始就達成完全去中心化可能是困難的，甚至是完全不現實的。一個項目或企業的早期設計元素往往需要更中心化的視野和控制。早期階段的中心化可以更容易地協調、發布和快速迭代，以適應產品市場。
不過，以某種程度的中心化開始並不一定會迫使你保持這種方式。在這裡，我們將解釋一個高級框架，用於預設未來的去中心化，並就何時以及如何這樣做提供一些指導。這些指導方針既適用於Web3項目，也適用於更傳統的組織。
我們的目的是幫助那些對去中心化感興趣的人思考如何應對這一挑戰。但是，不存在一個放之四海而皆準的方法，因為去中心化的確切機制在很大程度上是由具體的商業環境決定的。因此，這只是一個介紹— 它並不是一本從組件上做決定的遊戲手冊，而是一個如何開始思考總體問題的框架。
如果有一件事需要記住，那就是去中心化不一定是“全然或非然”。有了適當的規劃，你可以隨著時間的推移進行去中心化。為了有效地計劃，重要的是要了解你的企業可以在哪些不同的方面進行去中心化，以及如何在適當的時候進行。
用我們許多人的經驗來做個比喻，漸進式的去中心化就好比一個組織變得完全遠程化。開始的時候，在一個單一的中央辦公室裡舉行面對面的會議對協調是有幫助的，但隨著時間的推移，變得更加去中心化是有意義的。但為了管理分佈式工作，必須投資於遠程通信技術，以及仔細記錄業務實踐和架構。在設計一個組織的時候，知道有一天你們的工作都將是遠程進行的，會使未來的狀態變得更容易。漸進式的去中心化也是如此。
去中心化有價值
去中心化是指將控制權和決策權從一個中心化的實體— 一個特定的個人、組織或團體— 轉移到一個分佈式網絡。這可以適用於企業的許多元素，包括內容創作、組織治理和流程，甚至技術棧。
去中心化通常是功能性的。例如，一個組織可能會從一個去中心化的個人網絡中匯總意見。事實上，Web3 的價值創造在很大程度上是利用共享所有權來激勵許多人同時參與和投入。 （在過去的一篇文章中，我們寫到“建立與用戶直接分享價值的開放平台將為每個人創造更多的價值，包括平台”）。
在其他情況下，去中心化可以提供安全保障— 例如對抗審查制度（儘管要做到這一點，必須正確構建治理結構）。另外，尋求利用自己的數字資產的Web3 平台也需要因監管原因而去中心化。
也許最重要的是，去中心化可以作為一種承諾，以用戶的最佳利益來建設產品— 類似於共同治理如何引導合作社強調健康的文化和在成員之間長期公平分配資源和收益。此外，還有一群人更有可能自我選擇進入那些有計劃去中心化的項目，這既是出於原則，也是因為他們相信這樣的項目從長期來看會更有價值。
去中心化並非易事
雖然去中心化對企業來說是有價值的— 甚至是必要的— 但開始時可能會很困難。許多壓力在短期內推動了中心化，即使是那些致力於長期去中心化的公司。
試想一下在沒有核心的中央團隊或中心化的決策過程的情況下，啟動一個產品或進行快速迭代以達到產品與市場相適應的挑戰。此外，Web3 中的去中心化通常也伴隨著對可組合性的期望，這就帶來了這樣的風險：在你達到規模之前，其他人可能會“分叉”你的產品。依靠去中心化的管理或其他形式的眾包投入，而沒有適當設計的支持結構— 包括那些推動參與的結構— 有可能使平檯面臨欺詐或賄賂的風險。
這些力量鼓勵早期的中心化。但重要的是，要確保它們不會導致設計決策，使未來的去中心化變得更加困難。也就是說，即使在早期有很好的理由要更加中心化，你也應該為未來的去中心化進行設計。
漸進式去中心化
以下是一些指導，可以幫助你積極規劃未來的去中心化。
首先，必須確定你的業務可以在哪些不同維度上實現去中心化。例如，一個平台可能能夠將內容策劃去中心化，即使仍然有一個相對中心化的技術棧。一個特定的產品可以被分割成“最小可去中心化單元”（MDU），這些單元大部分是相互獨立的，然後沿著這些維度分別進行去中心化。 MDU 可能包括核心團隊、外部貢獻者、技術棧等等— 我們將在下面詳細討論各個維度。
即使在一個特定的MDU 中，你也不必一下子從0 跳到100。一個平台可能會逐漸將策展權去中心化，比如說，先從社區中徵求內容建議，然後再最終將內容決定權完全移交。
在視覺上，我們認為這就像一組滑塊 — 也許是一個“去中心化均衡器”，對每個MDU 有不同的調整。你可以按照自己的節奏來滑動每一根滑塊，而滑動每一根滑塊的難度則取決於企業對該維度變化的準備情況。從這個意義上說，雖然考慮到去中心化架構在前期成本較高，但它可以成為競爭優勢的一個關鍵來源，因為從長遠來看，它使去中心化的過程更加容易。
MDU 描述
重要的是要在如何去中心化和去中心化什麼的問題上保持一致，這需要一些高層的協調，通常還要對“去中心化均衡器”進行一些監督。在不同的業務和產品類別中，MDUs 會有所不同，以下是幾個例子，以及如何為去中心化的成功進行設置的說明：
1. 核心團隊。僱用能夠設置工作的人，以便外部成員有可能超越一些責任— 例如，一個社區經理，以允許成員開始以自我管理和自我治理的方式設計社區。此外，投資於提高你的團隊的技能，把去中心化作為一個長期目標，並支持這些努力的新技術和最佳實踐。
2. 外部貢獻者。你越是朝著完全去中心化的方向發展，你的社區就越能參與到產品的發展和管理中。根據你想要的去中心化程度進行調整，你要以參與性的方式進行建設，培養社區參與到共享基礎設施的建設中，貢獻內容，和/或管理系統。這不僅僅是邀請社區參與— 你必須以一種能夠讓人們做出貢獻的方式來設計組織，並獎勵他們這樣做。也就是說，要建立強大的反饋和參與渠道，以及相應的結構和流程。
同時，在獎勵方面，引入獎勵積分或數字代幣來跟踪和獎勵社區貢獻，可以幫助激勵社區活動（更多關於信譽系統設計的信息，請參見我們的這篇文章）。例如，你可以從吸引外部開發者來測試你的核心基礎設施開始— 通過分配獎勵給那些通過在協議基礎上建立而啟動活動的開發者。
3. 技術棧。堆棧可以以模塊化的方式構建，允許你在開始時交易所中心化服務的去中心化版本— 例如，開始時在AWS 上存儲內容，隨著時間的推移，過渡到去中心化的存儲服務，如Arweave 或IPFS。
4. 財務。你應該在最初如何為業務提供資金以及在內部和外部分配資源的方式方面為去中心化進行規劃。特別是，你應該以一種有彈性的方式構建財務，以便在沒有中央控制的情況下維持組織，例如，考慮你帶來的投資者對退出社區控制（我們可以稱之為“去中心化退出”）會有什麼反應，並考慮定期向社區進行財政撥款。
5. 內部程序。重要的是要在前期投入時間，思考你去中心化部分業務和業務流程可能需要的東西— 例如，你可能需要豐富的文件，讓社區成員了解治理的具體決定的先例或背景。
明確列出你的組織的MDU 可能是有幫助的，以便提供一個清晰的觀點，讓你可以與團隊和社區分享各種“滑塊”。分享路線圖不僅符合去中心化的精神，社區也可以幫助你達到目標。一旦你有了一套MDU，弄清楚滑塊目前在每個維度上的位置，並開始形成一個你希望它隨著時間推移而發展的觀點。當然，你還要有一個有意義的操作順序，如果事情出錯，團隊可能應該從負面影響較小的MDU 開始。
移動哪個滑塊，何時？
最後：你要怎麼知道在何時該把滑塊往上移— 也就是說，何時可以增加一個或多個維度的去中心化？
放大來看，首先重要的是，你的整個系統是相對穩定的。但這到底是什麼意思？在a16z 的一篇早期文章中，Jesse Walden 鼓勵團隊評估他們在通往和超越產品市場契合度的過程中的位置：你還需要經歷多少次迭代，以及多快？這一點很重要，因為任何形式的組織變革都會使運營速度減慢；你要把握好移動滑塊的時間，使減慢速度的長期效益超過短期成本。理想的情況是，當你的平台的社會和經濟動態已經足夠穩定，你可以有力地預測調整去中心化的水平將如何影響社區的行為和結果時，你會進行移動。
接下來，你應該依次評估每個MDU。在決定是否調整滑塊時，每個維度都會有自己的一套因素需要權衡。你可能會被推動在一個特定的維度上進行去中心化— 例如，你可能有太多的用戶生成的內容需要自己管理，這使得讓更多的社區參與策劃變得至關重要。另外，你也可能完全按照自己的意願選擇增加去中心化— 一個例子是你看到了以去中心化方式存儲內容的長期商業價值，所以你主動選擇開始使用這樣的服務。
再說一次，這並不是全然或非然。去中心化沿著每個MDU 以不同的速度發生。例如，你可能從第一天就開始計劃你的財務，保持“退出社區”的選擇；在六個月後建立一個社區財政；然後再轉為完全去中心化的財務管理。與此同時，你可以保持一個中心化的技術棧，同時在尋找更多的點對點選擇之前迭代出一個穩定的產品。
***
去中心化是強大的，但它並不容易。特別是在早期，對快速迭代、質量控制和安全的需求往往需要中心化開發（儘管這可能會隨著去中心化開發技術的改進而改變）。
如果你的目標是使你的企業長期處於去中心化狀態，關鍵是要在前期做好計劃，以防在建設過程中失去跟踪。我們可能會看到首席執行官或首席運營官的角色演變，以照顧“去中心化均衡器”– 甚至引入一個全新的職位，如“首席去中心化官”。從MDU 的角度思考，可以幫你弄清在哪里以及如何將業務的不同方面去中心化。隨著產品的發展，當時機成熟時，你可以沿著每個MDU 逐步進行去中心化。
資訊來源：由0x資訊編譯自8BTC。版權歸作者所有，未經許可，不得轉載