解決客戶端多樣性問題的一個技術方案：小衆客戶端項目

2021-10-23 21:10:22

截至發稿時，以太坊有多個客戶端實現，但 Geth / go-ethereum 作為一個多數客戶端脫穎而出，擁有 80%~90% 網絡佔有率。盡管這是對客戶端穩定性及其开發者的褒獎，但這種情況會帶來不良後果。

在以太坊1.0裏，當一個單一的客戶端在網絡裏佔絕對的主導，其弊端是衆所周知的：

如果 Geth 在一個 DoS 攻擊裏崩潰了，依賴它的用戶將無法進行交易或跟上權威鏈。
如果 Geth 有一個共識故障，依賴它的用戶將會看到不同版本的網絡狀態。

前一個問題有點糟糕，因為它會導致網絡中斷，但這是最糟糕的情況了。然而，後一個問題也特別糟糕，因為通過對網絡的錯誤 (無效) 狀態作出不可逆轉的反應它會導致出現雙花情況。高級用戶 (如交易所) 通過同時運行多個客戶端來解決上述問題，並在客戶端間無法達成共識時發出警報 (例如禁止存款/提款)。

礦池也通常運行多個客戶端，盡管對它們來說，在开發者搞清楚情況前在鏈分叉的兩邊都挖礦更有利，因為這可以避免它們因在歷史上站錯隊而失去所有收入。無論怎樣，區塊鏈會繼續延展下去，而無效的側鏈最終不會成為權威鏈的一部分。一切如常進行。

在以太坊 2.0 裏，一個新的潛在問題是出現以下兩種情況：

如果1/3 + 1 的網絡驗證者出現共識故障，網絡就無法繼續做最終敲定。
如果 2/3 的網絡驗證者出現共識故障，無效鏈會被最終敲定。

有一些提議是將多數客戶端的漏洞“寫入”協議中，以避免重組最終敲定的結果，但這只是火上澆油。這不是激勵驗證者運行其他類型的客戶端，而似乎是开發者為此懲罰他們，因為所有由有效但小衆的客戶端生成的區塊都會變成孤塊。這從本質上就鎖定了一個100%的單客戶端網絡。

另一個提議是要求人們運行一個小衆的客戶端，這一點一直被置若罔聞 (多年了)，原因不過是當有一個在大多數情況下更好且可用的客戶端時，為什么會有人想運行一個沒那么穩定的客戶端？維護基礎設施是很耗時的，而且與照看可能不穩定的東西相比，人們有更好的事情要做。

似乎我們在這裏有一個衝突：對於用戶來說，運行 Geth 又好又簡單，但可能會損害網絡；而運行其他客戶端可能沒那么穩定且煩人，但可能會拯救網絡。由於要求驗證者運行一個小衆客戶端是不公平的 (並首當其衝地承擔所有問題)，這個項目旨在提出一個不一樣的要求：還是要運行小衆客戶端，為你最喜歡的客戶端充當哨兵。

共識協調

在深入 minority 項目是什么之前，有必要強調它不是什么。雖然我們表明的目標是讓用戶 (也) 運行小衆客戶端，這個項目不是關於實際設置和運行以太坊客戶端的。有各種項目讓家庭用戶可以輕松運行一個或另一個客戶端 (例如 DappNode)，但一旦我們達到產品級的基礎設施要求，它在很大程度上取決於個人使用情況、預算限制和开發運營能力，以提出關於運行什么、運行多少、在哪裏和如何部署的“最佳”解決方案。

minority 項目假設驗證者已經熟悉如何最好地部署到他們的基礎設施；以及如何以合理穩定的方式提供和維護不同的獨立客戶端。其目標是成為共識層和執行層客戶端之間的通信層，使得任何人都可以運行多個客戶端 (多數的、小衆的和組合)，並且在接受一個狀態變換 (無論是一個執行結果或要給共識更新) 之前達成一個 N/M 的共識。

例如：

minority 協調器可以確保只有在 2/3 的共識層客戶端都對新鏈頭達成共識時 (例如，Lighthouse 和 Lodestar 贊成，Teku 反對)，執行層客戶端的鏈頭才會更新。
minority 協調器可以確保只有在 2/3 的執行層客戶端對新的狀態根達成共識 (例如，Geth 和 Nethermind 贊成，OpenEthereum 反對) 時，執行數據才會被接受。

在共識層和執行層客戶端間的高級通信層有一個額外的好處，就是能夠對各種客戶端統一收集和報告行為指標；並有可能在它們失控，導致網絡中斷之前檢測到操作降級問題。通信中間件也允許統一收集兩層之間事件的審計軌跡，有可能有助於調試客戶端問題。

常見問題

Q: 運行一個執行客戶端已經很昂貴了！要求驗證者運行 2-3 個不是太過分了嗎？

在撰寫本文時，1 個 ETH= 3785 美元。運行一個驗證者需要 32 個 ETH 的初始存款，相當於 12 萬美元。在這個資金量級上，我們覺得並行運行 3 個執行層客戶端以支持驗證者是可以接受的安全投資。

Q: 運行一個額外的中間件意味着更多的工作！為什么共識層客戶端不直接與多個執行層客戶端通信？

共識層客戶端和執行層客戶端之間的多路復用解耦使得它們可以在任何時候被調換，而不會發生意外的行為變化。在任何一邊重新實現多路復用器都會在最低程度帶來輕微變化，最終可能需要拓撲重構來改變底層組件。

Q: 運行一個分布式多路復用器是顯然的選項。中央協調器不是更簡單嗎？

中央服務器無疑更簡單，但它也會形成單點故障，無論是因為硬件故障、軟件錯誤還是機器過載。我們無法控制共識/執行層客戶端生成的負載，所以在面對故障時，保持它們隔離似乎更安全。去中心化的架構也可能證明更容易橫向擴展。

Q: 運行每個客戶端都要帶上多路復用器不是很奇怪嗎？為什么不用一個編排集群？

每個客戶端運行都帶上一個額外的進程確實比簡單地將它們指向一個編排集群需要更多的工作，但它可以減少復雜性，因為共識/執行層客戶端仍然以1對1的形式運行。把集群理念帶到任何一個客戶端層，都要求這些客戶端有效地處理1對N的連接問題，這是我們一开始就盡量避免的。