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