许多客户端

以太坊的一个信条是，以太坊 首先是一套协议。以太坊是构成协议的许多规则的抽象集合，而不是这些规则集合的某种实现。因此，以太坊社区从一开始就鼓励多种客户端实现。现在有 besu、ethereumJS、geth、nthermind、nimbus、open-ethereum、trinity 和 turbo-geth 这么多客户端软件都能同步以太坊区块链。而在 Eth2 这边，我们有 cortex、lighthouse、lodestar、nimbus、prysm、teku、和 trinity 这么多种客户端软件。

多客户端范式有很多好处：

• 多种客户端实现可以产生广泛的观念、算法以及架构（每一种客户端实现都会给出自己的观点和方法）。这种交叉碰撞是很有好处的，最终我们都能开发出更可靠的软件。
• 不同客户端软件通常有不同的设计目标。那么随着时间推移，用户和应用也会更加多样化。客户端软件多多少少会围绕着下面几个目标来开发：性能、安全性、水平可扩展性、用户体验、轻客户端、浏览器友好、资源节约性，等等等。
• 如果有众多的客户端软件可用于生产环境，一次重大攻击可能只会导致一种客户端软件崩溃（例如一次 DoS 攻击），而其它的客户端软件仍然完好，攻击的破坏力也就被限制住了。这就是我们在以太坊的早期、遭遇 「上海 DoS 攻击」 时出现的情况：一系列 DoS 攻击或许导致 geth 客户端或者 parity 客户端崩溃，但从未导致两者都崩溃。
• 每一种客户端都是通向一种编程语言社区的门户。特定语言的客户端可以作为基础，让该种语言内的实验和创新得以引入。而且，围绕着客户端的基础工具通常会借助该语言的贡献者和工具生态系统，滚雪球般地扩大。多客户端的范式加强了以太坊的吸引力。

当然，我们也要为此付出一些代价：

• 技术规范和测试工具都必须无懈可击，以避免主网上线后的意外分叉。如果协议只有一种实现，那么该实现就会变成协议本身。在这种情况下，任何一种共识机制上的 「bug」 都在实质上变成了协议本身。从纯粹中立的角度来看这似乎不是好事，但它会消除意外分叉的风险。作为一种解决办法，如果同步主网的客户端使用情况有一种健康的分布（例如没有超过 1/3 的全体节点 / 验证者在使用同一种客户端），那么全网也能够在某一种客户端出现共识问题的时候保持活性。
• 与单一客户端相比，N 种客户端要相互协作，会引入额外的工作，做得好可能是线性增长的负担，但有时候会是平方级增长的负担。我们可以使用一些方法来降低负担 —— 例如共识机制测试套件（还有网络测试套件）—— 但总不可能完全消除。

Eth2 客户端和测试网的现状

Phase 0 的 Eth2 客户端在过去两年中已成为了相当复杂的软件，也因此能处理数十万的验证者、数千个节点间的分布式共识过程。我们现在已经有了测试网，每一天都在向正式启动迈进。所谓行百里者半九十，事实证明确实如此。 (责任编辑：admin)