作者： 币安app官方 日期：2024-11-01 22:04
原标题：《Ethereum -> Solana -> Aptos: the high-performance competition is on》
编译：SevenUp DAO
文章中会提及的项目包括：
Solana, Aptos, Ethereum, StarkWare, zkSync, Serum,Meteplex
这部分包括：
- 直到目前，Solana 作为唯一的一条高性能区块链仍处于垄断地位
- Solana 的设计基因是激进地优化最理想情况下的网络性能：并行运算、减少冗余度和更高的出块率。
是什么让 Solana 与众不同？
作为唯一接近 Visa 65,000 TPS 容量的区块链，Solana获得了华尔街和硅谷的支持，以尝试应用大规模的区块链服务。
Solana 并没有通过一些图灵奖的魔法来实现 TPS（与零知识证明不同，这是我们即将讨论的另一个重要话题）。相反，Solana 在性能和可靠性之间做了一系列的设计权衡。我们将在第一部分讨论 Solana 的性能，在第二部分讨论可靠性的成本。
设计选择 1：并行计算。
以太坊虚拟机（EVM）是单线程的——EVM 只能利用一个 CPU 核心来按顺序处理交易。由于单核产生的热量随着速度的提高而呈指数级增长，物理学限制了单核性能的上限是很低的。
解决方案是什么？更多的核心! 八个 2GHz 的核心比一个 8GHz 的核心温度要低很多，但也更强大。2007 年，英特尔推出了双核的奔腾处理器，从而结束了单核时代。今天的计算机消费者拥有的 GPU 和 CPU 有 4 到 4096 个核心。让更多的核心合作得更好，而不是拥有更强大的单核，已经成为了十多年来半导体行业的研究重心。
为了实现原生多线程，Solana 必须放弃 EVM 的兼容性。Solana 的智能合约可以利用 Nvidia GPU 的 4096 个核心来并行地运行计算。
- 我们的观点：在这个[EVM v.s Multi-thread]的二元选择中，我们倾向于多线程而不是 EVM 的兼容性。我们认为 2027 年的 DApp 却只能使用 2007 年的半导体技术是非常荒谬的。
有些人可能会指出 EVM/Solidity 相关的开发者的护城河问题。但是开发者其实很容易转换编程语言。今天的大多数 Web 2 应用和开发人员使用的编程语言都是原生的多线程。我们认为未来的开发者会像当前高 GAS 一样对 EVM 的神秘的单线程架构感到沮丧。(另外，我们也不是 EVM 兼容的rollups 方案的粉丝）。
设计选择 2：通过确定的领导节点轮换减少冗余度
去中心化需要冗余性。在谷歌这样的中心化云服务中，计算只发生一次——因为用户相信谷歌是正确的。
在区块链中，由于我们不能信任任何人，所有数据都需要由不同的节点进行计算和验证。一个相同的计算所做的额外次数就是所谓的间接费用 / 冗余度。为了量化冗余，我们使用[Big-O 符号](https://en.wikipedia.org/wiki/Big_O_notation#:~:text=Big Onotation is a,a particular value or infinity.)（大 O 符号，渐进符号），如[O(n^2), O(n), O(log n)]，里面的函数表示当他们扩展到更多节点时，网络计算将变得多么复杂。例如，随着网络的增长，O(n^3) 可能意味着比 O(n^2) 大几个数量级的冗余度。
在比特币、以太坊和其他许多简单的 PoS 链中，共识的冗余度至少是O(n^2)，与节点数量的平方成正比：每个区块都必须传输、检查和比较其他每个区块的工作。
对于 Solana，只有被指定的那个领导节点来生产下一个区块。(SeeGulf Stream, Leader Rotation。在此基础上，Solana将区块分割成很多小块，然后只有一小部分节点验证者来验证每个小块 (See Turbine)，而不是所有的节点都要发送和验证所有的区块。
Solana 的协议将 Solana 的最佳情况下的冗余度从 O(n^2) 减少到 O(log n)，这是计算复杂性理论中最有效的可能。这个结果确实很了不起。考虑一个（过于简化的）说明。
网络 A 和 B 在其他方面是相同的，100 个节点有 100k TPS。一个O(n^2) 网络每增长 10 倍的节点性能就会衰减 100 倍。一个 O(log n) 网络每增长 10 倍节点性能才会衰减~ 3 倍。在 10 万个节点时，两个网络的性能将相差 30000 倍。
这种复杂性的降低也有意识形态上的意义。在这方面，我们认为Vitalik 对 Solana 的批评有些误导——Vitalik 认为 Solana 因为硬件要求高而不够去中心化。Solana 4000 美元的硬件成本阻止了 “每个用户在自己的机器上运行 Solana 节点”。这个成本是没错的。但从长远来看，计算成本会越来越便宜，而且 Solana 的复杂度降低的设计使它有可能拥有 100 倍的节点，而不会使网络变得难以忍受的缓慢。
其他的设计选择：
支持者和批评者还就 Solana 的其他一些技术特点进行了辩论。我们认为这些特点不那么核心，所以我们概括性地讨论：
3.1 投票交易算入了 TPS
一些批评者指出 Solana 通过将验证者投票也算入了交易，从而人为的增加了 TPS。投票确实被算入了交易，但这只是一个表面问题。也许 Solana 应该重申一下它的 TPS 是 60,000（剔除投票交易），而不是 65,000。
3.2 吞吐量—更快的出块时间和更大的区块
Vitalik和StarkWare都批评 Solana 的性能改进有些懒惰，因为 Solana 只是让每个区块更大，区块时间更短，以更高的硬件要求为代价来容纳更多的交易。简单的数学会告诉你这并不是全部。
- Solana 的最大区块大小为 10MB，是ETH 目标大小 1MB.)的 10 倍。
- Solana 的出块时间是 0.4 秒，是以太坊 12 秒的 30 倍。
- 相比以太坊，以上两者的组合给了 Solana 大概 300 倍的懒惰性能改进。
- 但实际上 Solana 的 TPS 比以太坊通常的 TPS 要高 3000 倍。这另外 90% 的性能提升可以由我们讨论过的 Solana 的并行运算和降低冗余性的设计来更好的解释。
3.3 历史证明（POH）
Solana 将 POH 宣传为其最大的创新。从长远来看，历史证明允许 Solana 将区块时间减少到极端的 400ms / 区块，尽管事实上物理网络延迟往往大于 400ms。这个功能的花哨名字是异步共识，更多细节见Multicoin 的文章。
设计选择总结：Solana 的高性能秘诀
三个关键指标共同决定了区块链的最大吞吐量：出块率、并行计算和冗余性。
- 冗余度决定了总共需要多少数据和计算量，也就是说，总计算量 = 有效计算 + 冗余度；
- 并行计算允许节点计算的速度更快；
- 出块率决定了一定时期内区块链数据库中可保存的数据量。
Solana 在这三个方面都做出了大胆的设计选择：从 O(n^2) 到 O(log n) 冗余；从 1 核到 4096 核并行，以及从5MB/min 到 1500MB/min 的出块速率。这些是Solana 的 65,000TPS 背后的主要秘诀。在下一章中，我们将讨论 Solana 这些选择的成本。
这部分包括：
- Solana 激进的性能优化的 DNA 使它比其他区块链更容易发生故障。
- 我们提出了冗余困境：鉴于有限的计算能力，L1 必须在性能和可靠性之间做出权衡。
- 冗余困境是第 3 部分中高性能三难问题的一个子集。
频繁的网络事故
在过去的一年里，Solana 至少经历了 4 次重大网络事故。2021 年 9 月停运事故，2021 年 12 月降级事故，2022 年 1 月降级事故，2022 年 4 月停运事故。任何有兴趣的利益相关者一定有很多问题：
是什么导致了事故？
本质的原因是是什么？一次性的系统 BUG ？意外的攻击？还是区块链设计 DNA 中的某些问题，我们只能缓解？
选择最佳性能而不是可靠性
在第一部分中，我们讨论了 Solana 如何积极地优化其最佳情况下的性能。“最佳情况” 是这里的一个关键词。当事情没有完全按照理想模式发生时，Solana 就会失控。
设计成本 1：当交易在逻辑上有顺序时，激进的的并行计算就会退化。
NFT mint 和 IEO 交易常常导致 Solana 网络中断。原因是：这些交易无法在 4096 个核心上同时进行。Minting NFTs 时，不知道哪些已经被 mint 了，这会导致重复和 BUG。所有在同一个 collection 的 mint 交易必须按顺序处理。一个直接含义就是，Solana 的 65,000 TPS 并不意味着用户可以在一秒钟内铸造 6 个 BAYC 集合：由于只依赖一个 GPU 核心，Solana 的按顺序处理能力可能更接近甚至低于以太坊，大约在 10 到 100 TPS 之间。
这就解释了性能下降的原因：NFT mint 时失控的交易量会使Metaplex 无法使用，但其他不依赖 Metaplex 的应用（如 Serum 订单簿）仍然可以在其他 4095 个核心之一上处理交易。
但更多的时候，性能降低变成了网络中断：等待 Metaplex 的未处理的交易致使节点内存溢出——当内存溢出时，节点崩溃并完全离线。
核心权衡：通过使用 4096 核心的 GPU 而不是 16 核 CPU，Solana 牺牲了单核性能而支持激进的并行运算。通常情况下，当交易不相关时，网络运行得很好，但一旦交易表现出不理想的模式，Solana 比高冗余度的以太坊更容易崩溃。
设计成本 2：当领导者崩溃时，决定性的领导者选择会变得很难看
当 Solana 接近崩溃时，负责当前的区块领导节点往往是第一个崩溃的。Solana 的低冗余设计严重依赖领导结点是否在线 – 其他节点都没有与当前领导节点相同的交易数据或网络角色。这意味着一旦领导节点离线，网络的其他部分需要做大量的应急工作：同意跳过一个区块，重新组织交易数据，并将丢失的交易数据转发给下一个领导节点……
考虑以太坊网络，它没有领导节点，每个节点都有一份精确和重复的副本，这份副本中包含有将被放入一个区块（mempool）的交易数据。如果任何以太坊节点离线，所有其他节点手头仍有他们需要产生一个新区块的所有内容。这就是冗余的双刃剑：在理想的情况下，冗余导致了网络的缓慢；但在坏的情况下，它可以防止重大事故。
让我们用数字来说明。根据这篇论文，在领导者节点崩溃的情况下（正式称为 “级联领导者故障 cascading leader failure”），Solana 的紧急计算量开销可以达到 O(n^4)。一个 O(n^2) 的网络很慢，但可以使用，然而一个一下子需要 O(n^4) 计算量的网络就好比死了。这就是为什么 Solana 一旦进入 O(n^4) 级联领导故障模式，就难以自行恢复的主要原因。
这是一种特性，不是 BUG
Solana 的基因是激进的以最佳性能为优先。这个原则在架构中无处不在，所以很难只改变一个地方而不改变其他一切。(我们没有讨论这个问题，但为了说明相互依赖性，如果在 CPU 而不是 GPU 上运行，核心的 PoH 算法将是不切实际的，而 Solana 的 PoH—最理想情况下进行性能优化的数据管理系统使其难以实现类似 ETH 的 mempool）。再次说明，这是一个权衡，不能两全其美——要从根本上使 Solana 更加稳定，需要创造更多的冗余度，从而牺牲最理想情况下的性能。
即使是 Solana 的支持者，也需要做好心理准备，网络中断和性能降低还会发生很多次，因为今天的 Solana 网络还远远没有尝试过所有可能的缓解措施。缓解措施是一个需要迭代的捉迷藏游戏。有一天，Solana 实验室的努力工作可能使 99.99% 的网络正常运行时间成为可能。但是，它从来都不意味着要达到 100% 的网络正常运行，今天的主网 beta 版离 99.99% 也还很远。
这部分包括：
- Aptos的设计选择是在可靠性和性能之间的折衷，位于 Solana 和 Ethereum 之间
- 我们提出了高性能、可靠性和效率之间的高性能三难问题
- 对开发者来说，未来的趋势是根据具体使用场景进行优化。我们提出了一个 3 个问题的问答手册来帮助开发者选择基础设施
在过往整整一年多的时间里，Solana 仍然是高性能 L1 细分市场里唯一的名字。现在我们有了 Aptos，由 Facebook 的前Libra 团队开发，并由 a16z、Tiger、Multicoin 和 FTX 投资。Multicoin和 FTX 明显也是 Solana 的重注投资者。Aptos 最近成为头条新闻，因为他们声称有 16 万的 TPS，显然将自己定位为 Solana 的竞争对手。
这也是时我们为什么花这么多时间来剖析 Solana 的原因：这是一个最好的角度来结合实际理解 Aptos：
回顾第二部分，以太坊对网络能够正常运行的时间进行了优化：以太坊花费了大量的数据冗余来为最坏的情况做准备，所以几乎不可能用攻击来使以太坊网络中断。而 Solana 是为最理想情况下的性能进行了优化，在冗余上花费较少，从而使网络在极端情况下的可靠性降低。
在解决冗余度困境时，Aptos 试图从 Solana 退一步。下面是它的一些关键设计选择：
Aptos 设计选择 1：16 核服务器级 CPU
这是 Solana 的 4096 个 GPU 核心和以太坊的 1 个 CPU核心之间的一个中间地带。在处理高度可并行的任务时，Aptos 可能不如 Solana 快。Aptos 的每个CPU 核心都比 Solana 的 GPU 核心性能高得多，所以在 NFT mint 等逻辑上按顺序交易的情况下，Aptos 可能比 Solana 处理得更好。
Aptos 设计选择 2：最理想情况冗余为 O(n)，最差情况冗余为 O(n^2)
相对于 Solana，Aptos 试图通过增加冗余使其网络更具弹性。Aptos 没有试图达到 Solana 的极端 O(log n) 次线性冗余度，而是设置为 O(n) 的冗余度。在每一轮共识中，Aptos 要求所有非领导者的节点同步额外的数据，以备当前领导者节点失败时其他节点需要接管。Aptos 也没有尝试对区块进行分割和验证，因为分割会在出错的情况产生额外的工作量。这么设计的结果是：当领导者节点确实失败时，Aptos 的应急处理并没有 Solana 那么混乱。
比较一下：Aptos 的最佳性能不如 Solana，但 Aptos 在最差情况下的表现更容易接受——O(n^2)，而 Solana 为 O(n^4)。如果我们把这五个性能表现放在一起，它们刚好是一个漂亮的三明治，把 Aptos（紫色）夹在 Ethereum（蓝色）和 Solana（绿色）之间。
Aptos 设计选择 3：疯狂的硬件要求
你们可能已经看到 Aptos 声称有 16 万的 TPS，并想知道为什么我说其最理想情况下的性能不如 Solana 好。
注意 Aptos 的硬件要求：他们所有的测试都是在AWS EC2 实例上运行的，有 16 核服务器级别的 CPU。Aptos还公开建议在谷歌云平台上运行他们的节点，而不是个人电脑。
16 万这个数字是在大约 100 个有权限的节点上进行的实验室测试的结果——在更复杂的实际生产环境中，如果节点更多，TPS 肯定会更低。Aptos 的内部测试也表明，随着网络扩展到更多节点，其性能将接近甚至低于 Solana目前的 65,000 TPS。
下面是对 Aptos、Solana 和以太坊关键技术规格的快速总结，供参考：
把所有东西放在一起总结一下：高性能的三难问题
把问题扩展到冗余困境，同时把 Aptos 变态的硬件要求也考虑在内，我们提出了一个 Vitalik 的区块链可扩展性三难问题的翻版：高性能三难问题。
在这个三难问题中，三个不能同时满足的符合第一性原则的特质如下：
- 可靠性：通过在冗余度上花费更多的计算来保证网络正常运行时间
- 性能：通过在冗余上花费更少的计算来加强网络的吞吐量
- 效率：提升可靠性和性能的唯一方法是获取更多的计算资源来用于这两方面
在以太坊、Solana、Aptos 三者中：
- 以太坊选择了网络正常运行时间和效率，所以它在冗余度上花费了的一定的计算量，导致性能缓慢。
- Solana选择了性能和（相对）效率，所以它把有限的计算量都花在了最佳情况的性能上，较低的冗余度导致可靠性受到了负面影响。
- Aptos选择了网络正常运行时间和高性能，所以为了有足够的计算来覆盖这两个方面，Aptos 不得不选择基于服务器的节点，放弃了效率。
Aptos 的设计理念相当 Web 2：强调对用户的友好，而不是去中心化。早期的描述表明，Aptos 可能会整合一个带有密码恢复功能的高级用户账户系统。从任何角度看，Aptos 肯定不是最去中心化的区块链。它并不以意识形态的纯粹性为目标。来自 a16z 和 Tiger 的 2 亿种子轮投资者将一些真正的资金和资源放在这个有点逆向的愿景背后。
这一切对投资者和开发者意味着什么？使用场景优化。
No Maxis.（非最大主义者）
No Maxis.（非最大主义者）
No Maxis.（非最大主义者）
根据你的使用场景进行优化。
甚至 AWS(亚马逊云服务）也为不同的使用场景提供了几十种数据库配置，因为没有一个万能的解决方案。区块链是数据库。
成为一个最大主义者可能有助于在快速增长的投机市场中通过承担短期风险而获利，但部落主义不利于真正的价值发现和建设。一个好的投资者和建设者应该对各方面的权衡持现实的态度，并真正理解你的用例，而不是沉溺于推销、泡沫和公关话术中。
现在我们对未来会发展成什么样只有一个广泛的轮廓。Solana 和Aptos 都将经历更多的错误，中断，微调和补丁。Solana 会再次瘫痪，Aptos 也会。但这并不改变它们作为解决有利可图的高性能 L1 问题的顶级竞争者的地位。
对于开发者：至少需要知道三件事：
- 你的使用场景：什么是至关重要的，什么只是锦上添花。
- 你想使用的基础设施的利弊权衡和基因是什么样的？
- 混合和匹配的成本和效益。跨链解决方案和风险，The Anti Ape 之前的文章。伟大的 DApp 利用区块链，糟糕的DApp 被他们使用的区块链所消耗。
对于投资者来说：Aptos 将在 2022 年发布公共测试网和代币。这意味着 Solana 在高性能区块链领域的垄断很快就会结束。我们预计 Solana 的代币价格将经历一些卖压，因为投资者在高性能区块链这个垂直领域有更多的选择了。但现在说赢家还为时过早。
无论如何，Aptos 看起来是一个 Solana 的有力挑战者，因为它试图平衡 Solana 的长期可靠性和其他的一些权衡点。但我们还需要观察，Aptos 团队是否能很好地执行落地，以及他们是否能挑战 Solana 两年的生态系统的领先优势。