性能和可扩展性是加密货币领域备受讨论的挑战，与第 1 层项目（独立区块链）和第 2 层解决方案（如汇总和链下通道）相关。然而我们没有标准化的指标或基准。数字通常以不一致和不完整的方式报告，这使得准确比较项目变得困难，并且常常模糊了实践中最重要的内容。
我们需要一种更细致、更彻底的方法来衡量和比较性能——将性能分解为多个组成部分，并在多个轴上进行权衡。在这篇文章中，我定义了基本术语，概述了挑战，并提供了评估区块链性能时要牢记的指南和关键原则。
可扩展性与性能
首先，让我们定义两个术语：可扩展性和性能，它们具有标准的计算机科学含义，但在区块链环境中经常被误用。 性能 衡量系统是什么 目前能够实现。正如我们将在下面讨论的，性能指标可能包括每秒事务数或中位事务确认时间。 可扩展性另一方面，测量 系统通过添加资源来提高性能的能力.
这种区别很重要：如果定义正确，许多提高性能的方法根本不会提高可扩展性。一个简单的例子是使用更高效的数字签名方案，例如 BLS 签名，其大小大约是 Schnorr 或 ECDSA 签名的一半。如果比特币从 ECDSA 切换到 BLS，每个区块的交易数量可能会增加 20-30%，从而在一夜之间提高性能。但我们只能这样做一次——没有更节省空间的签名方案可供切换（BLS 签名也可以聚合以节省更多空间，但这是另一个一次性技巧）。
区块链中还可以使用许多其他一次性技巧（例如 SegWit），但您需要一种可扩展的架构来实现持续的性能改进，其中添加更多资源会随着时间的推移提高性能。这也是许多其他计算机系统中的传统智慧，例如构建网络服务器。通过一些常见的技巧，您可以构建一台非常快的服务器；但最终，您需要一个多服务器架构，可以通过不断添加额外的服务器来满足不断增长的需求。
理解这种区别还有助于避免诸如“区块链 X 具有高度可扩展性，它每秒可以处理 Y 笔交易！”之类的陈述中常见的类别错误。第二个主张可能令人印象深刻，但它是一个 性能 指标，而不是可扩展性指标。它并不意味着通过添加资源来提高性能的能力。
可扩展性本质上需要利用并行性。在区块链领域，第一层扩展似乎需要分片或类似分片的东西。分片的基本概念——将状态分割成多个部分，以便不同的验证器可以独立处理——与可扩展性的定义紧密匹配。第 1 层还有更多选项允许添加并行处理，包括链下通道、汇总服务器和侧链。
延迟与吞吐量
传统上，区块链系统性能是通过延迟和吞吐量两个维度来评估的：延迟衡量确认单个交易的速度，而吞吐量衡量一段时间内交易的总速率。这些轴适用于第 1 层和第 2 层系统，以及许多其他类型的计算机系统（例如数据库查询引擎和 Web 服务器）。
不幸的是，延迟和吞吐量的测量和比较都很复杂。此外，个人用户实际上并不关心吞吐量（这是系统范围的衡量标准）。他们真正关心的是延迟和交易费用——更具体地说，他们的交易尽可能快、尽可能便宜地得到确认。尽管许多其他计算机系统也根据成本/性能进行评估，但交易费用是区块链系统的一个新的性能轴，在传统计算机系统中并不存在。
测量延迟的挑战
延迟乍一看似乎很简单：一笔交易需要多长时间才能得到确认？但总是有几种不同的方法来回答这个问题。
首先，我们可以测量不同时间点之间的延迟并得到不同的结果。例如，当用户在本地点击“提交”按钮时，或者当交易到达内存池时，我们是否开始测量延迟？当交易处于提议的区块中时，或者当一个区块被一个或六个后续区块确认时，我们是否会停止时钟？
最常见的方法采用验证者的观点，测量从客户端首次广播交易的时间到交易被合理“确认”的时间（从某种意义上说，现实世界的商家会考虑收到的付款并释放商品） 。当然，不同的商户可以采用不同的接受标准，甚至单个商户也可以根据交易金额使用不同的标准。
以验证者为中心的方法忽略了实践中一些重要的事情。首先，它忽略了点对点网络上的延迟（从客户端广播交易到大多数节点听到它需要多长时间？）和客户端延迟（准备交易需要多长时间）在客户端的本地计算机上？）。对于签署以太坊付款等简单交易，客户端延迟可能非常小且可预测，但对于更复杂的情况（例如证明受保护的 Zcash 交易是否正确）可能会很重要。
即使我们标准化了我们试图用延迟来衡量的时间窗口，答案几乎总是 这取决于。迄今为止，还没有任何一种加密货币系统能够提供固定的交易延迟。要记住的基本经验法则是：
延迟是一个分布，而不是一个单一的数字。
网络研究界早已理解这一点（例如，参见 Gil Tene 的精彩演讲）。特别强调的是分布的“长尾”，因为即使 0.1% 的事务（或 Web 服务器查询）中的高度升高的延迟也会严重影响 的影响 终端用户。
对于区块链，确认延迟可能因多种原因而有所不同：
批处理： 大多数系统以某种方式批量处理交易，例如在大多数第 1 层系统上批量处理交易。这会导致可变的延迟，因为某些事务必须等到批次填满。其他人可能会幸运地最后加入这批人。这些交易会立即得到确认，不会遇到任何额外的延迟。
可变拥塞： 大多数系统都存在拥塞，这意味着发布的交易数量（至少在某些时候）超过了系统可以立即处理的数量。当事务在不可预测的时间广播时（通常抽象为 泊松过程）或者当新交易的比率在一天或一周内发生变化时，或者响应外部事件（例如流行的 NFT 发布）时。
共识层方差： 在第 1 层上确认交易通常需要一组分布式节点在一个区块上达成共识，无论拥塞情况如何，这都会增加可变的延迟。工作量证明系统在不可预测的时间发现区块（抽象上也是泊松过程）。权益证明系统还可能增加各种延迟（例如，如果在线节点数量不足以在一轮中形成委员会，或者如果需要更改视图以响应领导者崩溃）。
由于这些原因，一个好的指导方针是：
关于延迟的声明应该呈现确认时间的分布（或直方图），而不是像平均值或中位数这样的单个数字。
虽然平均值、中位数或百分位数等汇总统计数据提供了部分情况，但准确评估系统需要考虑整个分布。在某些应用中，如果延迟分布相对简单（例如高斯分布），则平均延迟可以提供良好的洞察力。但在加密货币中，情况几乎从来不是这样：通常，确认时间很长。
支付通道网络（例如闪电网络）就是一个很好的例子。作为经典的 L2 扩展解决方案，这些网络在大多数情况下提供非常快速的支付确认，但有时它们需要通道重置，这可能会导致延迟增加几个数量级。
即使我们确实有关于确切延迟分布的良好统计数据，它们也可能会随着系统和系统需求的变化而随着时间的推移而变化。如何比较竞争系统之间的延迟分布也并不总是清楚。例如，考虑一个系统，该系统确认交易的延迟时间均匀分布在 1 到 2 分钟之间（平均值和中位数为 90 秒）。如果一个竞争系统在 95 分钟内准确地确认了 1% 的交易，而另外 5% 在 11 分钟内（平均值为 90 秒，中位数为 60 秒），那么哪个系统更好？答案可能是有些应用程序更喜欢前者，有些应用程序更喜欢后者。
最后，需要注意的是，在大多数系统中，并非所有事务的优先级都是相同的。用户可以支付更多费用以获得更高的纳入优先级，因此除了上述所有内容之外，延迟还随着支付的交易费用而变化。总之：
延迟很复杂。报告的数据越多越好。理想情况下，应在不同的拥塞条件下测量完整的延迟分布。将延迟分解为不同的组件（本地、网络、批处理、共识延迟）也很有帮助。
测量吞吐量的挑战
乍一看，吞吐量似乎也很简单：系统每秒可以处理多少个事务？出现了两个主要困难：“交易”到底是什么，我们是在衡量系统今天做什么或者它可能做什么？
虽然“每秒交易数”（或 tps）是衡量区块链性能的事实上的标准，但交易作为衡量单位是有问题的。对于提供通用可编程性（“智能合约”）甚至有限功能（例如比特币的多重交易或多重签名验证选项）的系统，根本问题是：
并非所有交易都是平等的。
这在以太坊中显然是正确的，其中交易可以包含任意代码并任意修改状态。以太坊中的 Gas 概念用于量化交易正在执行的总体工作量（并收取费用），但这对于 EVM 执行环境来说是高度特定的。没有简单的方法可以将一组 EVM 事务完成的工作总量与一组使用 BPF 环境的 Solana 事务进行比较。将其中任何一个与一组比特币交易进行比较同样令人担忧。
将交易层分为共识层和执行层的区块链可以使这一点更加清晰。在（纯）共识层，吞吐量可以用每单位时间添加到链上的字节数来衡量。执行层总是会更加复杂。
更简单的执行层，例如仅支持支付交易的汇总服务器，避免了量化计算的困难。但即使在这种情况下，支付的输入和输出数量也可能有所不同。 支付渠道 事务所需的“跳数”可能会有所不同，这会影响吞吐量。汇总服务器吞吐量可能取决于一批事务可以“汇总”为较小的一组摘要更改的程度。
吞吐量的另一个挑战是超越凭经验测量当今的性能来评估理论容量。这引入了各种建模问题来评估潜在容量。首先，我们必须确定执行层的实际事务工作负载。其次，真实的系统几乎永远无法达到理论能力，尤其是区块链系统。出于稳健性的原因，我们希望节点实现在实践中是异构且多样化的（而不是所有客户端都运行单个软件实现）。这使得对区块链吞吐量的精确模拟变得更加困难。
总体而言：
声称吞吐量需要仔细解释交易工作负载和验证器的数量（它们的数量、实现和网络连接）。在没有任何明确标准的情况下，来自以太坊等流行网络的历史工作负载就足够了。
延迟与吞吐量的权衡
延迟和吞吐量通常是一个权衡。作为 Lefteris Kokoris-Kogias 概述，这种权衡通常并不顺利，当系统负载接近其最大吞吐量时，会出现延迟急剧上升的拐点。
零知识汇总系统提供了吞吐量/延迟权衡的自然示例。大批量交易会增加证明时间，从而增加延迟。但链上的足迹，无论是在证明大小还是验证成本方面，都将分摊到更多批量更大的交易上，从而提高吞吐量。
交易手续费
可以理解的是，最终用户更关心延迟和延迟之间的权衡 费，而不是延迟和吞吐量。用户根本没有直接理由关心吞吐量，只是他们可以以尽可能低的费用快速确认交易（一些用户更关心费用，另一些用户更关心延迟）。在较高层面上，费用受到多种因素的影响：
- 有多少市场需求进行交易？
- 系统实现的总吞吐量是多少？
- 系统为验证者或矿工提供了多少总体收入？
- 这些收入中有多少是基于交易费用与通货膨胀奖励？
前两个因素大致是导致市场出清价格的供需曲线（尽管有人声称 矿工充当卡特尔，将费用提高到这一点以上）。在其他条件相同的情况下，更高的吞吐量应该会导致更低的费用，但还有更多的事情发生。
特别是，上面的第3点和第4点是区块链系统设计的基本问题，但我们对它们都缺乏良好的原则。我们对从通货膨胀奖励与交易费用中为矿工提供收入的优点和缺点有一些了解。然而，尽管对区块链共识协议进行了许多经济分析，但对于验证者需要多少收入，我们仍然没有广泛接受的模型。如今，大多数系统都建立在有根据的猜测之上，即多少收入足以让验证者诚实行事，而不会扼杀系统的实际使用。在简化模型中， 可以证明，发动 51% 攻击的成本与验证者的奖励成正比.
提高攻击成本是一件好事，但我们也不知道多少安全性才“足够”。想象一下您正在考虑去两个游乐园。其中一家声称其游乐设施维护费用比另一家少 50%。去这个公园是个好主意吗？可能他们的效率更高，并且以更少的钱获得同等的安全性。也许另一个人花费的钱超过了保证游乐设施安全所需的钱，却没有任何好处。但也有可能第一个公园很危险。区块链系统是类似的。一旦考虑到吞吐量，费用较低的区块链的费用也较低，因为它们对验证者的奖励（因此激励）较少。今天我们没有好的工具来评估这是否可以或者是否会使系统容易受到攻击。全面的：
比较系统之间的费用可能会产生误导。尽管交易费用对用户来说很重要，但除了系统设计本身之外，它们还受到许多因素的影响。吞吐量是分析整个系统的更好指标。
结论
公平、准确地评估绩效是很困难的。对于测量汽车的性能来说同样如此。就像区块链一样，不同的人会关心不同的事情。对于汽车，一些用户会关心最高时速或加速度，另一些用户会关心油耗，还有一些用户会关心牵引能力。所有这些评估起来都很重要。例如，在美国，环境保护局制定了关于如何评估油耗以及如何向经销商的用户提供油耗的详细指南。
区块链空间距离这种标准化水平还有很长的路要走。在某些领域，我们将来可能会通过标准化工作负载来评估系统的吞吐量或通过标准化图表来呈现延迟分布。目前，评估者和构建者的最佳方法是收集和发布尽可能多的数据，并详细描述评估方法，以便可以复制并与其他系统进行比较。
