很顯然，這篇宣稱使用Geth客戶端Staking會導致資產遺失的文章過於危言聳聽了。
作者透過Nethermind客戶端故障導致節點被Slash的案例來假定佔比84%的Geth客戶端故障可能出現的糟糕狀況。只能說這是一種極端的假設，是對Geth客戶端中心化問題過度解讀。簡單說說，我的想法：
1）以太坊的節點客戶端包含Geth、Nethrmind、Besu、Erigon、Reth等客戶端。這些執行客戶端只是開發者在執行出塊權的一種終端配置選擇，和鏈的共識，尤其是出塊權這些問題並沒有直接關係。
唯一差別是，有的開發者從熟悉度或成本等因素考慮可能選擇了Nethermind等小型客戶端，有的開發者會隨大流選擇Geth。不管開發者用哪一類客戶端，在POS出塊機制的機率都只和質押的ETH 有關係，只是Geth客戶端覆蓋率高，給人直觀感覺大部分出塊權都在Geth，事實上只是因為大部分節點都用了Geth而其上邊質押的ETH量又大才產生的邏輯關聯；
2）至於為啥Geth客戶端會佔84%成為主流客戶端，是其本身性能優越、相容性強、功能豐富、成熟穩定產生結果。正循環：Geth性能好——開發者活躍——bug修的快——穩定好用——開發者更活躍——Geth佔比越大。儘管以太坊基金會也透過持續的Grant來增加其他客戶端的比重，但結果無濟於事，Geth客戶端的共識越來越強大；
順著文章作者的邏輯，由於Geth客戶端佔比大，所以一旦Geth出現問題以太坊出塊就會不穩定，給Staking造成巨大的Slash傷害，但是個偽命題。因為若不是Geth客戶端好用，就不可能佔比最大，既然佔比大是好用的結果，那假設Geth出問題的機率能有多大呢？即便這種假設成立，那以太坊面臨的也並非節點slash那麼簡單了，可能得涉及鏈的硬分叉問題；
3）Staking以及Restaking中有一個AVS（Activity Validator Set）的概念，這就使得參與Staking的節點要確保通訊連接的穩定性，軟體穩定性和Bug修復率，有效的出塊和驗證過程等等。
這意味著，參與Staking以及Restaking的節點會傾向於選擇Geth客戶端，而Staking AVS集合中的節點要想繼續參加Restaking就得設法提高終端負載水平進一步提升效能。所以Staking和Restaking只會導致客戶端層面的競爭更加捲，這意味著Geth客戶端的比例可能會進一步放大。
因此以Geth客戶端中心化佔比大，來唱衰Staking和Restaking潛在風險的觀點顯然站不住腳。
Geth客戶端的中心化問題也確實是個問題，尤其是在去中心化的世界建模背景下，大比例的佔比總是會讓人產生隱憂，但客戶端多樣性問題以太坊基金會一直在想辦法優化，這和Staking以及Restaking的爆火並沒有直接關聯關係，若非要牽扯關係，只能說Staking和Restaking的盛行可能會加劇Geth客戶端的進一步中心化。只是，這樣一來再抱怨Geth客戶端中心化問題的風險就有些杞人憂天了。
Note：要權衡Geth客戶端中心化和Staking潛在風險的主動權實際上在Lido等大節點主體手裡，若Lido有意識地增加客戶端節點多樣性，贊助多種客戶端的開發者，問題則會相應改善。
