由于严厉的惩罚措施，以太坊的客户端多样性非常重要：如果出现共识错误，错误的验证者越多，惩罚就越重。更糟糕的是，如果大多数验证者都错了，那么错误的链就会被最终确定，从而导致“如何从错误中恢复”的复杂治理问题，而大多数验证者会采取不正当的激励措施来避免这样做。这样的事件可能会对整个以太坊的采用产生寒蝉效应。 这个问题的标准解决方案是客户端多样性：确保网络中的每种客户端风格(共识和执行)的市场份额低于50%。如果出现共识错误，有错误的客户端会受到惩罚，但惩罚不会过高，也不会对整个网络产生不利影响。这种方法在共识层上效果很好。然而，CL客户端都是相对较新的，具有相似的性能概况。 在执行层，事情有点复杂(至少现在是这样)。虽然目前还不清楚Geth 相对于其他客户端的市值有多大优势(统计数据是不可靠的)，但人们普遍认为Geth确实比其他客户端更占据主导地位。这使得Geth用户和整个网络处于比理想情况下更高的风险范围。通常 “使用少数客户端”会有所帮助，但切换可能会暴露隐藏的不兼容性，不同的资源需求，新的监控系统等。可行，但不够理想。 更好的解决方案是并行运行多个客户端，并在它们之间交叉引用块。这是大型参与者(质押池、高风险提供商)的“期望”方法，但从硬件和工作成本方面来说，这也是一个昂贵的解决方案：每个客户端都有自己的怪癖，运营商需要意识到，每个客户端都有自己必须承担的维护负担。对于专门的团队来说，这不是问题，但从去中心化的角度来看，这是一个明确的问题。 推动多样性似乎是必要的，但从实际情况来看，至少在短期内是不现实的。然而，我们确实也需要一个短期的解决方案。 重新思考问题实现真正弹性的唯一解决方案是使用多个客户端验证块。然而，对于大多数用户来说，运行多个客户端是不现实的。理论和实践似乎是相互矛盾的，直到我们意识到，我们并不是在一个二元的情况下。除了运行一个客户端或运行多个客户端之外，还有第三种选择：运行一个客户端，但使用所有客户端进行验证(而不实际运行它们)。 观察结果是，验证一个区块实际上非常便宜。对于在大多数硬件上运行的大多数客户端来说，100-200ms的计算量已经足够了。因此，从计算的角度来看——考虑到任何远程计算机都有足够的CPU内核——使用一个客户端或所有客户端验证一个块是相同的。 问题不在于CPU或内存，甚至不在于网络。问题在于状态。尽管几乎任何客户端都需要100毫秒来验证一个块，但提供必要的状态来进行验证会使其非常昂贵。维护N次状态绝对是多余的，它是完全相同的事情，只是在每个客户端中存储的有点不同。当然，我们不能在客户端之间共享状态，所以似乎我们又回到了起点…… 虽然我们确实不能在客户端之间共享250GB的状态(现在忽略历史块)，但也没有必要这样做。执行单个块只需要几百个帐户和可用的存储槽，验证最终状态根只需要这些状态项的证明。简而言之，我们不需要与其他客户端共享整个状态来验证一个区块，我们只需要向他们共享(或者更确切地说是发送)一个见证。 这改变了一切…… 多样性，没有多样性不是要求人们运行一个少数客户端(可能不方便)，或要求他们运行多个客户端(可能是昂贵的)，我们可以让他们使用他们喜欢的任何客户端，而只要求他们与其他客户端进行无状态地交叉验证。 从高层次的角度来看，执行客户端的块验证包括运行一组交易，然后根据区块头将生成的结果与预期的结果进行比较。 我们的建议是将这最后一步稍微扩展一下。用户的客户端在执行区块时也会为区块创建一个见证，而不仅仅是运行交易并将结果视为最终结果。在执行完成后，我们建议添加一个额外的交叉验证步骤，将见证发送到各种其他客户端以无状态运行。 汇总它们的结果，如果所有(或大多数)客户端同意主机，结果可以传输到共识客户端。另一方面，如果有多个交叉验证的客户端不同意，则用户的客户端将拒绝接受并验证该区块。 细节，细节，细节问：这是否仍然意味着每个人都需要维护多个客户端？ 不是真的。每个人都需要/可能有多个可用的客户端，但它们不会作为一个实时客户端运行。相反，每个客户端都有一种新的操作模式——无状态验证——在这种模式下，它们只使用富含见证的块并返回验证结果。 最简单的形式甚至不需要这些客户端不停地运行，而是使用CLI命令无状态地验证块，但这超出了本文档范围的实现/规范细节。 问：期望客户端提供无状态验证是否合理？ 大多数客户端已经支持类似的方式来运行状态测试，因此这并不是一个新概念。因此，与共识问题可能导致的后果相比，这个功能似乎是显而易见的。 问：期望客户支持证人生成和与其他客户的交叉验证是否合理？ 证明坏块可能会导致严重的处罚和削减。生成见证并运行交叉验证步骤是一个直接而简单的过程。我们的期望是，所有客户的用户都会要求支持易于交付并可以保护他们免受财务损失的功能。 问：我们做Verkle不是因为证明太多了吗？ 虽然Merkle-Patricia的证明确实相当大，但它们的大小只有在通过网络发送时才有意义。如果交叉验证器客户端确实是无状态的，它们可以与主客户端并排运行(或按需运行)。在这种情况下，向它们传输见证数据是在操作系统内存中进行的，所以它是几十MB还是几百MB都无关紧要。 问：你希望我安装6个不同的执行客户端吗？ 取决于： • 如果你是一个高风险的运营商，你可能已经运行了多个成熟的客户端，因此这对你来说是没有意义的。 • 如果你正在运行自己的基础设施，那么添加一些交叉验证客户端可能不是一项非常困难的任务，但是我们可以创建所有客户端的docker和裸机包来进行交叉验证。 • 如果你正在运行DAppNode或类似的设置，我们希望他们添加支持交叉验证模式下运行所有客户端，并在默认情况下为用户提供开箱即用的保护。 后记该提案旨在解决对多样性的需求，而不是强迫多样性。它允许每个人运行他们喜欢的客户端，而不必担心所有可能出错的坏事情。该提案确实需要每个人的合作才能完成，但与最初的问题相比，它似乎是一个非常简单的解决方案。 当然，还有一些技术问题需要解决(单次与日志运行验证器、通信协议、见证格式和内容、K-out-of-N 有效性影响、硬暂停与空证明等等)。这份文件更多的是对解决多样性问题的提案作一个预告和高级概述。