五問以太坊：客戶端多樣性問題從何而來？
編者按：本文來自以太坊愛好者（ID：ethfans）編者按：本文來自
以太坊愛好者（ID：ethfans）
以太坊愛好者（ID：ethfans）
以太坊愛好者（ID：ethfans）
以太坊愛好者（ID：ethfans）
以太坊愛好者（ID：ethfans）
Geth: 75%
Parity & OpenEthereum: 20%
Nethermind: 1%
二級標題
以太坊愛好者（ID：ethfans）
最近舉行的第90 期核心開發者會議幾乎全程都在討論一個問題。我強烈建議大家親自聽一下這場會議。
二級標題
在這場會議上，Alexey 提出了客戶端開發者負荷過重的問題。雖然我認為這場討論是一個重要的開始，但是我們太急於尋求解決方案了，充分理解這個問題才是當務之急。重要的是，我們需要花點時間來分析問題。在問題內涵的分析上，“五問法（Five Whys）” 是最簡單有效的方法之一。
二級標題
第一問：為什麼Geth 開發團隊的壓力如此之大，甚至到了超負荷的地步？
剩下4% 由一些市場份額不到1% 的客戶端組成，因此忽略不計。
二級標題
重要的是，有超過51% 的算力都集中在Geth 客戶端上。假設在即將到來的柏林硬分叉中，Geth 在實現其中一個EIP（以太坊改進提案）時出現了bug 。即使這個客戶端的其它實現都沒出bug ，只要有區塊碰上了這個bug ，就會導致以太坊網絡分叉。按理來說，這個區塊是無效的，其他客戶端也會將其視為無效塊。但是，有超過51% 的挖礦節點都運行的Geth 客戶端，因此整個網絡都會被帶到錯誤的分叉鏈上去。
因此，第一問的答案是：
二級標題
因為以太坊網絡的客戶端缺乏足夠的多樣性。
二級標題
第二問：為什麼以太坊網絡缺乏客戶端多樣性？
從那時起，除了Parity 之外，沒有一個客戶端能獲得較大的市場份額。去年，Nethermind 異軍突起，成為了一顆冉冉上升的新星，但是目前只佔據了1% 的市場份額。最近，由於Parity 遭遇了一些波折，前途一片黯淡，Parity 的市場份額大幅下降。我們認為，在理想情況下，以太坊網絡需要有3 個及以上的客戶端、每個客戶端佔有的客戶端份額都不至於太高、沒有任何一個客戶端能佔據遠遠超過51% 市場份額。雖然在理想情況下應該實現客戶端多元化，但是我們已經習慣了客戶端霸權的局面。
二級標題
有人可能會立即建議我們想辦法為落後的客戶端提供支持和幫助。我很警惕這種“人月神話” 式的解決方案—— 在軟件開發過程中，讓更多工程師來解決一個難題很少會成功，而且我不指望這種方案會取得成功。
二級標題
注：人月神話，mythical man-month，指出以大量人員和較短的時間，並不能縮短軟件的開發進度。一窩蜂的作業方式無助於軟件生產，且會製造麻煩，產生出更差的軟件。向進度落後的項目追加人力，只會使進度更加落後。
二級標題
二級標題
現在，我們正越來越接近問題的根源。
二級標題
事實證明，大部分困難都來自於組網協議（networking protocol），即以太坊客戶端軟件用於相互連接並分享區塊鏈信息的那一組工具。以太坊的組網規則（定義在devp2p 代碼庫中），最終影響甚至決定了以太坊客戶端的設計和要求。
一些組網工具指定了未經優化的架構，甚至要求以太坊客戶端運行不必要的功能。客戶端開發者需要在這些限制下工作。
二級標題
我相信，這個問題的答案基本上可以分為兩個部分。
狀態管理
GetNodeData是我們用來同步狀態的唯一網絡互聯工具，針對特定的狀態數據庫格式（俗稱“the native layout”）進行了優化。由Turbo Geth 推廣的“扁平式” 數據庫佈局在狀態維護方面具有極大的性能優勢，但是使用這種佈局會加大GetNodeData 請求的處理難度。
解決方案
處理訪問鏈上數據歷史記錄的請求，包括區塊頭、區塊體和收據。
二級標題
解決方案
第五問：為什麼……
二級標題
解決方案
看來我只問了四個“為什麼” 就找到了根本原因。以太坊協議還沒有完全成熟。在設計以太坊協議時，我們並沒有意識到現如今發現的大多數問題，或者因為當時狀態規模較小、發展歷史較短，這些問題還不成問題。
