# 設計非相關性：深入研究 DVT 和 Charon 的架構 By [maix](https://paragraph.com/@maix) · 2023-02-15 --- **在設計 DVT 時，最小化相關性至關重要，因為以太坊權益證明旨在嚴厲懲罰相關行為。在設計 Obol 時，我們做出了謹慎的選擇，以創建一個信任最小化和非關聯的架構。** **作者：Oisín Kyne** **2022 年 11 月 1 日 • 8 分鐘閱讀** **原文來自：** [https://blog.obol.tech/deep-dive-into-dvt-and-charons-architecture/](https://blog.obol.tech/deep-dive-into-dvt-and-charons-architecture/) **翻譯：JW** ![Chloe McGann 的“Charon”專題圖片](https://storage.googleapis.com/papyrus_images/bfca898d48f70cd64b93ea5f06569430f7a45d741b3bf82154abd09661eadf9e.png) Chloe McGann 的“Charon”專題圖片 早在 [Devcon 4](https://www.youtube.com/watch?v=Km9BaxRm1wA&t=1272s) 上發布的原來的Serenity設計規範時，我就一直[擔心權益證明的去中心化](https://blog.goodaudience.com/the-staking-problem-9b1e344b24ab)。今天我想談談 Obol 的分佈式驗證中間件客戶端 Charon 的架構如何使其能夠增長以太坊驗證設置了一個數量級，而沒有將相關行為引入採用該技術的驗證。 首先，相關性有什麼重要的？ 權益證明以太坊規範旨在通過嚴厲懲罰集中化來鼓勵分散化。有一些機制旨在懲罰相關的不活躍，也有一些機制可以最大限度地懲罰相關的惡意行為。當你離線時離線的人越多，你的不活躍懲罰就越嚴重（特別是如果 >33% 的網絡處於離線狀態）。類似地，如果你的驗證者被認為正在攻擊網絡，你將被懲罰，並且懲罰會隨著在你被懲罰後的三週內有多少其他驗證者被懲罰而增加。如果你的驗證者是這段時間內唯一被懲罰的人，它可能會損失 2 個以太幣。如果發生大規模懲罰事件，您可能會失去驗證者的全部以太幣。 因此，既然我們了解了這裡的利害關係😏，那麼讓我們看一下構建分佈式驗證客戶端的一些好的（和壞的）想法，旨在使網絡会比沒有它的網絡更安全、更有彈性，並且相關性更低。 術語 -- 為新接觸 Charon 和 DVT 的人快速介紹幾個術語： * [分佈式驗證](https://docs.obol.tech/docs/int/key-concepts#distributed-validator)：一個 32 個以太幣质押，由一個 BLS 公鑰表示，由多個私鑰協同操作。 * [分佈式驗證集群](https://docs.obol.tech/docs/int/key-concepts#distributed-validator-cluster)：一組連接在一起以運行一個或多個分佈式驗證的以太坊節點（包括 Charon）。 * 中間件：位於另外兩個獨立軟件之間的軟件，攔截它們之間的通信線路。 Charon 位於驗證客戶端和共識客戶端上的 HTTP [Beacon API](https://ethereum.github.io/beacon-APIs/) 之間。 私鑰 -- 在討論除私鑰之外的分佈式驗證架構時，你還可以從这里開始。分佈式驗證器集群中涉及兩種類型的私鑰： 1. SECP256K1 公鑰/私鑰對用於識別 Charon 客戶端。 Charon 以這種方式與現有的 Eth1 和 Eth2 網絡堆棧緊密結合，使用以太坊節點記錄 ([ENR](https://eips.ethereum.org/EIPS/eip-778)) 和 [discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md) 發現協議在互聯網上找到合適的對等點，無論它們最終在哪裡。 2. BLS12-381 閾值密鑰份額。這些是 BLS 私鑰，它們像普通的以太坊驗證者一樣簽署職責，但有一點不同。多個私鑰以份額的方式生成，即它們一起代表一個特定的私鑰。重要的是，並非所有私鑰都需要為關聯的公鑰構造有效簽名。可以把它想像成一個用於驗證器私鑰的多重簽名錢包。 當建立一個新的分佈式驗證器集群時，每個操作員生成一個私鑰（1）供他們的 Charon 客戶端使用，然後他們在[分佈式驗證啟動板](https://bia.launchpad.obol.tech/)的幫助下準備分佈式密鑰生成儀式以創建分佈式驗證器私鑰（ 2). 在設置集群條款、添加所有操作員並通過啟動闆對他們進行身份驗證後，操作員將生成的集群[定義文件](https://docs.obol.tech/docs/charon/intro)提供給他們的 Charon 客戶端，然後 DKG 過程開始。每個 Charon 客戶端在互聯網上找到彼此，建立安全和加密的通信線路，然後以一種沒有任何客戶端控製或知道完整私鑰是什麼的方式創建這些 BLS 私鑰。完成後，每個 Charon 客戶端都會以廣泛採用的 [EIP-2335](https://eips.ethereum.org/EIPS/eip-2335) 密鑰庫格式將其私鑰寫入磁盤。作為此過程的一部分，私鑰用於生成存款數據以激活所選網絡上的驗證器。這是 Charon 唯一一次保管並能夠使用分佈式驗證器的私鑰進行簽名。在 DKG 過程完成後，驗證器私鑰被導入到運營商選擇的驗證器客戶端中。 將這種私鑰生成方法與另一種方法進行對比；有可能（但不明智）讓一個受信任的實體（如潛在客戶）自己創建一個完整的私鑰，讓這個實體將私鑰分成多個份額，讓這個實體用每個運營商的客戶的私鑰加密私鑰份額密鑰，並將加密的私鑰發佈到鏈上以供全世界查看。這是我們的第一個關聯風險，它與運營商丟失客戶私鑰可能造成的損害有關。在 Charon 中，什麼都沒有發生，該節點可以開始以拜占庭方式運行，這不是主要問題，因為集群是拜占庭容錯的。在替代架構中，攻擊者可以追溯解密（並發布）位於鏈上的每個 BLS 驗證者私鑰共享，這些私鑰共享被發送給這個受損的運營商，從而使每個分佈式驗證者成為這個運營商的一部分不那麼安全。 中間件 --- 一旦創建了分佈式驗證器集群，下一個架構設計決策就是不惜一切代價降低相關懲罰的風險。 Charon 的目標是通過沒有能力做一些可懲罰的事情來實現這一目標。 Charon 不保管驗證器私鑰，也沒有簽署任意數據的能力。相反，Charon 是一個中間件，位於現有共識客戶端和驗證器客戶端之間，並攔截兩者之間流動的數據。所有 Charon 客戶所做的是： * 在他們之間就應該向他們連接的驗證者客戶提供什麼進行簽名達成共識。 * 捕獲返回的簽名並將它們組合在一起形成一個聚合簽名，該簽名被發送到更廣泛的網絡。 我們認為基於中間件的架構比替代方案更安全，信任最小化，後者將分佈式驗證客戶端實現為完整的驗證客戶端，具有保管私鑰和簽署任意數據的能力。例如，如果您考慮最壞的情況，即 Charon 受到供應鏈攻擊、遠程代碼執行攻擊或 Obol 團隊成為壞人並決定推送惡意版本，Charon 無法執行作為中間件的損害很大。如果一個受損的 Charon 客戶端向驗證者提出潛在的雙重投票或環繞投票以進行簽名，驗證者客戶端將檢查其反削減數據庫，看看它是否已經簽署了一些衝突的東西，並且將簡單地拒絕返回簽名。 Charon 可以建議驗證者簽署一個無效的塊，但鏈會拒絕這一點並簡單地認為驗證者離線，這比被懲罰要好得多。 作為一個中間件，Charon 獲得了將所有現有驗證客戶端作為故障安全的好處，可以雙重檢查沒有任何錯誤。多個實現一起工作來驗證使得意外懲罰的可能性很小。在我看來，分佈式驗證作為一個完整的驗證客戶端實現，能夠在沒有第二個軟件實現監督的情況下簽署任意數據，導致相關懲罰的風險要高得多。 溝通 -- 當我們將威脅的嚴重程度從關鍵妥協降低到懲罰風險，再到相關的不活動風險時，下一個要考慮的架構決策是 Charon 客戶端如何相互通信。在不讓驗證相關性更高的指導原則下，我們的目標是降低它們的相關性，我們決定將分佈式驗證集群之間的共享網絡基礎設施保持在最低限度。 每個集群都與其他集群完全隔離，而不是讓每個單獨的 Charon 客戶端連接到一個共享 Gossip網絡。集群中的 Charon 客戶端與其對等方建立直接 TCP 連接。這種方法比連接到公共Gossip網絡需要更多的初始設置，因為你需要確保你的 Charon 節點可以直接在公共互聯網上訪問，但從長遠來看，我認為回報是值得的。 * 直接 TCP 連接是可靠的，消息不會像在Gossip網絡上那樣丟失。 * 直接 TCP 連接比簽名在到達您之前通過多跳在網絡中反彈要快得多。這提高了驗證者的盈利能力。 * 沒有發送給你的客戶的消息不是為你的客戶準備的。 * 沒有一個中央網絡層，如果它出現故障，每個分佈式驗證都會在相關中斷中脫機。 * 如果您在雲基礎架構提供商中運行集群，則使用他們的私有數據中心間網絡速度快、吞吐量高且成本低廉。使用他們的網絡出口到公共互聯網的Gossip協議會為帶寬較少的較慢網絡帶來更多的云成本。 Obol 目前只有一個通用網絡基礎設施，那就是一個 discv5 引導節點，用於使 Charon 節點能夠找到彼此。對於有安全意識的抵押社區來說，他們自行託管自己的引導節點而不是切斷 Charon 集群之間唯一的公共鏈接是有意義的。我們已經讓[這樣做變得很容易](https://github.com/ObolNetwork/charon-distributed-validator-node#steps-to-host-your-own-bootnode)，並且已經看到我們的許多 [Athena 測試網](https://mirror.xyz/0x8100D20d8C40dfF90e848dB80cdead83db41Aed4/glGPEmnYzQT7eS1IKebzyBgkIeBuUGWgtJWLg0n-d6o)參與者已經選擇了這一點。 版本控制 ---- 最後但同樣重要的是，努力將集群彼此分離開闢了另一種方式來確保您不會以相關的方式失敗，這與軟件升級有關。軟件升級總是令人恐懼和冒險的，在分佈式系統中更是如此。如果您讓每個客戶端共享相同的消息總線；如果您發布的新版本改變了消息的結構方式，舊版本的軟件將不知道如何處理這些消息。因此，要解決此問題，您需要在新協議生效時設置一個時間（或時隙號），然後在您的通訊頻道上向所有運行您的軟件的人大聲疾呼，說他們必須在此之前運行您的軟件的最新版本時間或他們的節點將離線。一旦該時隙到達，每個分佈式驗證器都會同時切換到新協議。我幾乎不需要強調這是多麼相關，如果出現任何問題，每個人都會出錯。即使沒有任何問題，如果人們沒有及時更新，他們也會被迫離線。 有時，例如當你運行具有多個獨立客戶端實現的第 1 層區塊鏈時，選擇一個協調的時刻進行升級是推出更改的唯一可行解決方案，但是在 Obol 中，因為每個集群彼此獨立，結合事實上，這些集群具有拜占庭容錯能力，讓每個集群在空閒時升級到最新協議成為可能，當它們準備好時。我們正在為 Charon 客戶端構建優雅的版本升級，以便他們定期就他們都使用的最新協議版本達成共識，一旦每個人都運行最新的軟件，集群就會意識到，“嘿，我們都使用 n+ 版本1 現在，讓我們從下一個紀元開始使用它”。這降低了推出重大更改所涉及的相關風險，集群可以一次升級一個，並且隨著對新版本穩定性的信心建立，所有集群都可以異步升級。 總結 -- 我在這篇文章的開頭強調，四年來我一直在思考以太坊權益證明的架構。我希望在這篇文章結束時，您確信 Obol 正在認真對待以安全的方式將 DVT 引入生態系統的重要性。我還希望您閱讀本文後能夠更好地理解在構建分佈式驗證器時可以做出的設計權衡。我堅信，與具有公共網絡層的自定義驗證器客戶端相比，信任最小化、非託管、非關聯架構是一種向世界[引入高可用性驗證](https://ethresear.ch/t/distributed-validator-middlewares-and-the-aggregation-duty/13044)的更健康的方式。 謝謝閱讀。 --- *Originally published on [maix](https://paragraph.com/@maix/dvt-charon)*