很显然,这篇宣称使用Geth客户端Staking会导致资产丢失的文章过于危言耸听了。(相关阅读:《如果用Geth进行质押,真的可能会失去所有资产?》)

作者通过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有意识地增加客户端节点多样性,赞助多种客户端的开发者,问题则会相应改善。