很显然，这篇宣称使用 Geth 客户端 Staking 会导致资产丢失的文章过于危言耸听了。
作者：Haotian
作者通过 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 有意识地增加客户端节点多样性，赞助多种客户端的开发者，问题则会相应改善。
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。文章内的信息仅供参考，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
