由於嚴格的懲罰措施，以太坊網路客戶端靈活性很高。標準解決方案是客戶端多樣性，但現實中不太現實。提出了無狀態驗證的解決方案，允許使用者使用喜歡的任何客戶端，並進行無狀態地交叉驗證。仍需解決技術問題。
由於嚴格的懲罰措施，以太坊坊的客戶端彈性非常高：如果出現思考錯誤，錯誤的驗證者越多，懲罰動作就越重。更重要的是，如果大多數驗證者都錯了，那麼錯誤的鏈就會被最終確定，從而導致「如何從錯誤中恢復」的複雜治理問題，而大多數驗證者會採取不正當的激勵措施來避免這種行為。這樣的事件可能會對整個以太坊的採用產生影響寒蟬效應。
這個問題的標準解決方案是客戶端多樣性：確保網路中的風扇客戶端風格（思想和執行）的市場貢獻低於50%。如果出現思想錯誤，有錯誤的客戶端會受到懲罰，但會受到懲罰不會過度，也不會對整個網路產生不利影響。方法在共識層上效果很好。但是，CL客戶端都是相對較新的，具有相似的效能概況。
在執行層，事情有點複雜（至少現在是這樣）。雖然目前還慶Geth相對於其他客戶端的市值有很大優勢（統計數據是不可靠的），但人們普遍認為Geth確實比其他客戶端更受關注主導地位。這使得Geth和整個網路使用者在比理想情況下更高的風險範圍。通常「使用少量客戶端」會有所幫助，但切換可能會暴露的不相容，不同的資源需求，新的監控系統等。可行，但不夠理想。
更好的解決方案是大量的運行客戶端，並在它們之間交叉引用區塊。這是大型參與者（質押礦池、高風險）的「期望」方法，但從硬體和工作成本方面來也就是說，這也是一個昂貴的解決方案：每個客戶端都有自己的怪癖，運營商需要意識到，每個客戶端自己必須承擔的維護負擔。對於專門的團隊來說，這不是問題，但從去中心化的角度來看，這是一個明確的問題。
推動多樣性看起來是必要的，但從實際情況來看，至少在短期內是不切實際的。但是，我們確實也需要一個短期的解決方案。
重新思考問題
實現真正彈性的唯一解決方案是使用多個客戶端驗證區塊。然而，對於大多數用戶來說，運行多個客戶端是不切實際的。理論和實踐似乎是相互矛盾的，直到我們意識到，我們不是在一個二元的情況下。除了運行一個客戶端或運行多個客戶端之外，還有第三種選擇：運行一個客戶端，但使用所有客戶端進行驗證（而不實際運行它們） 。
觀察結果是，驗證一個區塊實際上非常便宜。對於在大多數硬體上運行的大多數客戶端來說，100-200ms的計算量已經足夠了。因此，從計算的角度來看——考慮到任何遠端電腦都有足夠的CPU核心——使用一個客戶端或所有客戶端驗證一個區塊是相同的。
問題不佔用CPU或內存，甚至不佔用網路。問題需要狀態。儘管幾乎任何客戶端都100毫秒來驗證一個區塊，但提供必要的狀態來進行驗證會造成非常昂貴。維護N次狀態絕對是多餘的，這是一件事情，只是在每個客戶端儲存的有點不同。當然，我們不能在客戶端之間共享狀態，所以似乎我們又回到了起點…
雖然我們確實不能在客戶端之間共享250GB的狀態（現在忽略歷史區塊），但也沒有必要這樣做。執行單一區塊只需要幾個帳戶和可用的儲存槽，驗證最終狀態根只需要這些狀態簡單來說，我們不需要與其他客戶端共享整個狀態來驗證一個區塊，我們只需要與他們共享（或者更有意的是發送）一個見證。
這改變了一切…
多樣性，沒有多樣性
不是要求人們運行少數客戶端（可能不方便），或要求他們運行多個客戶端（可能是昂貴的），我們可以讓他們使用他們喜歡的任何客戶端，而只要求他們與其他客戶端進行無狀態地交叉驗證。
從高層的角度來看，執行客戶端的區塊驗證包括一組交易，然後根據區塊頭運行將產生的結果與預期的結果進行比較。
我們的建議是這最後一步小小的擴充一下。用戶的客戶端在執行區塊時也可以為區塊創建一個我們的見證，而不是運行交易將結果視為最終結果。在執行完成後，建議新增一個額外的交叉驗證步驟，將見證傳送到其他用戶端以無狀態運作。
匯總它們的結果，如果所有（或大多數）客戶端同意主機，則結果可以傳輸到共識客戶端。另外，如果有多個交叉的驗證客戶端不同意，則用戶的客戶端將接受拒絕並驗證區塊。
細節，細節，細節
Q：這是否仍然意味著每個人都需要維護多個客戶端？
不是真的。每個人都需要/可能有多個可用的客戶端，但它們不會有一個即時客戶端運行。相反，每個客戶端都有一種新的操作模式——無狀態驗證——在這種模式下，他們只使用了相當數量的見證結果並返回驗證。
最簡單的形式甚至不需要這些客戶端不間斷地運行，而是使用CLI命令無狀態地驗證區塊，但超出了本文檔範圍的實作/規範細節。
Q：希望客戶端提供無狀態驗證是否合理？
大多數客戶端已經支援類似的方式來運行狀態測試，因此這不是一個新概念。因此，與思考問題可能導致的後果相比，這個功能似乎是大概的。
Q：期望的客戶支援證人產生以及與其他客戶的交叉驗證是否合理？
證明壞塊可能會導致嚴重的損失和損失。產生見證並執行交叉驗證步驟是一個直接而簡單的過程。我們的期望是，所有客戶的用戶都會要求支援易於交付並保護他們的倉庫財務損失功能。
Q：我們做Verkle不是因為證明太多了嗎？
雖然Merkle-Patricia的證明確實相當大，但它們的大小只有在透過網路發送時才有意義。如果交叉驗證器用戶端確實是無狀態的，可以與主客戶端並排運行（或交叉運行）在這種情況下，向他們傳輸見證資料是在作業系統記憶體中進行的，所以是幾十MB或者幾百MB都無關緊要。
Q：你希望我安裝6個不同的客戶端嗎？
取決於：
• 如果你是一個高風險的運營商，你可能已經運行了多個成熟的客戶端，這對你來說是沒有意義的。
• 如果你正在運行自己的基礎設施，那麼添加一些交叉驗證客戶端可能不是一個非常困難的任務，但是我們可以創建所有客戶端的docker和裸機包來進行交叉驗證。
• 如果你正在運行DAppNode或類似的設置，我們希望他們在運行所有客戶端時添加支援交叉驗證模式，並在預設情況下為用戶提供開箱即用的保護。
後記
該提案旨在解決多樣性的需求，而不是強迫多樣性。它允許每個人運行他們喜歡的客戶端，而不必擔心所有可能出錯的事情。該提案確實需要每個人的合作才能完成，但與最初的問題相比，這似乎是一個非常簡單的解決方案。
當然，還有一些技術問題需要解決（單次與日誌驗證器、通訊協定、見證運行格式和內容、K-out-of-N 有效性影響、硬暫停與空證明等）。這份文件更其主要任務是解決多元化問題作為一個預告和高階概述。
資訊來源：0x資訊編譯自網際網路。版權歸作者火星財經所有，未經許可，不得轉載