很顯然，這篇宣稱使用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有意識地增加客戶端節點多樣性，贊助多種客戶端的開發者，問題則會相應改善。