【英文长推】Sonic 联创：区块链性能优化背后的思考与实践

Chainfeeds 导读：

与 Solana 相比，Sonic 的优化侧重于去中心化共识，旨在为分布式网络提供高效且低成本的解决方案。

文章来源：

https://x.com/AndreCronjeTech/status/1890754309005935045

文章作者：

Andre Cronje

观点：

Andre Cronje：一开始是一个简单的问题：「Sonic 是否以某种方式并行执行交易？」 答案是「不」。这在一开始可能看起来是个奇怪的选择，因为在过去两年里，如果你关注虚拟机（VM）技术，你会看到「并行化」几乎无处不在。那么，为什么我们没有采用这种方法呢？要回答这个问题，我们首先需要了解 Sonic 工程团队是如何评估我们应该专注的工作内容的。我们有很多理论，从理论上看都很实用，我们本来想实现它们，但由于团队资源有限，我们该如何选择最具影响力的方向呢？因此，团队决定花一年时间去构建 Aida。Aida 是一个非常强大的工具，允许我们在几分钟内重放整个区块链（任何区块链），而不是几个月，并且内置了有用的性能指标。这意味着我们可以在 Aida 中进行原型设计和测试，并且能够迅速判断哪些理论成立，哪些则不成立。 Aida 还允许我们进行强大的分析和性能评估，产生以下输出结果：通过这些工具，我们能够非常快速和准确地测试我们的吞吐量假设，因此我们开始比较内存中的纯虚拟机与磁盘、并行执行、RDMS（关系数据库管理系统）与 KV（键值存储）与平面文件、超集、新的共识模型等多个方案。最大的一项改进是数据库（DB），提高了 800%，其次是超集，然后是共识，而并行执行则排在较低的位置，仅带来了约 30% 的提升。这似乎违背直觉，因为并行执行看起来应该比测试结果更有效。那么我们是如何进行并行化的呢？或许我们犯了一个错误，测试是「Clairvoyance」，即完美排序引擎，这个引擎能够在执行前预知最优排序和并行化（实际上这在实践中已经是不可能的，因此即使 30% 的提升也高于预期）。虚拟机和区块链是非常复杂的组件，很多时候我们测量的指标是错误的（或者根本没有测量）。 我们看到一个趋势，越来越多的系统倾向于单一强大的服务器；Solana、Megaeth 以及各种单序列器都依赖于一个东西：单一的高吞吐量、高内存服务器（其中非 L2 的方案在实际应用中通常是最快的）。如果优化得当，这种解决方案将永远比多个参与者的系统更快。因此，像 Solana 或 Megaeth 这样的系统，如果进行了最大化优化，其吞吐量将高于采用 2+ 服务器共识的下一个最快竞争对手。那么下一个问题可能是，为什么 Sonic 不采用单领导者选举服务器呢？ 答案是，这不是我们优化的目标。我在 2018 年就写过一个方向，那就是随着互联程序的到来，在某些情况下，必须实现共识。假设一个繁忙的十字路口，没有红绿灯或停车标志，交通量非常大。最优化的方法是让所有的车辆在交叉口注册自己，然后就排序达成共识，并找到每辆车以最优化的方式移动，以最大化吞吐量。在这种情况下，你不能使用基于领导者的系统，也不能假设某一方不是恶意的。在这种情况下，Sonic 共识被优化到，即使在 Raspberry Pi 上也能进行验证，而不会丧失吞吐量，因此所有的车辆都可以根据 Sonic 共识来达成排序。Sonic 是针对网状网络（mesh network）进行优化的。【原文为英文】