为什么区块链性能难以衡量

性能和可扩展性是加密领域中被广泛讨论的挑战，与 Layer 1 项目（独立的区块链）和 Layer 2 解决方案（如 rollups 和 off-chain channels）都相关。然而，我们没有标准化的指标或基准。数字通常以不一致和不完整的方式报告，这使得准确比较项目变得困难，并且常常掩盖了实践中最重要的事情。我们需要一种更细致和彻底的方法来衡量和比较性能——将性能分解为多个组成部分，并在多个维度上比较权衡。在这篇文章中，我将定义基本术语，概述挑战，并提供在评估区块链性能时需要记住的指导方针和关键原则。

可扩展性 vs. 性能

首先，让我们定义两个术语，可扩展性和性能，它们具有标准的计算机科学含义，但在区块链上下文中经常被误用。性能衡量的是一个系统当前能够实现的。正如我们将在下面讨论的那样，性能指标可能包括每秒交易数或中位数交易确认时间。另一方面，可扩展性衡量的是一个系统通过添加资源来提高性能的能力。这种区别很重要：许多提高性能的方法根本没有提高可扩展性，如果正确定义的话。一个简单的例子是使用更有效的数字签名方案，例如 BLS 签名，它大约是 Schnorr 或 ECDSA 签名的一半大小。如果比特币从 ECDSA 切换到 BLS，每个区块的交易数量可能会增加 20-30%，从而在一夜之间提高性能。但是我们只能做一次——没有更节省空间的签名方案可以切换（BLS 签名也可以聚合以节省更多空间，但这是另一个一次性的技巧）。在区块链中，还有许多其他一次性的技巧（例如 SegWit）是可能的，但是你需要一个可扩展的架构来实现持续的性能改进，在这种架构中，添加更多资源可以随着时间的推移提高性能。这也是许多其他计算机系统中的传统观点，例如构建 Web 服务器。使用一些常见的技巧，你可以构建一个非常快的服务器；但是最终，你需要一个多服务器架构，该架构可以通过不断添加额外的服务器来满足不断增长的需求。理解这种区别也有助于避免在诸如“区块链 X 具有高度可扩展性，它可以处理每秒 Y 笔交易！”之类的陈述中发现的常见范畴错误。第二个说法可能令人印象深刻，但这是一个性能指标，而不是可扩展性指标。它没有说明通过添加资源来提高性能的能力。可扩展性本质上需要利用并行性。在区块链领域，Layer 1 扩展似乎需要分片或类似于分片的东西。分片的基本概念——将状态分成几部分，以便不同的验证者可以独立处理——与可扩展性的定义非常匹配。Layer 2 上有更多的选项，允许添加并行处理——包括 off-chain channels、rollup servers 和 side chains。

延迟 vs. 吞吐量

通常，区块链系统性能是在两个维度上进行评估的，延迟和吞吐量：延迟衡量的是单个交易被确认的速度，而吞吐量衡量的是一段时间内的总交易速率。这些维度既适用于 Layer 1 系统，也适用于 Layer 2 系统，以及许多其他类型的计算机系统（例如数据库查询引擎和 Web 服务器）。不幸的是，延迟和吞吐量都难以衡量和比较。此外，单个用户实际上并不关心吞吐量（这是一个系统范围的度量）。他们真正关心的是延迟和交易费用——更具体地说，他们的交易能够以最快和最便宜的方式得到确认。尽管许多其他计算机系统也在成本/性能的基础上进行评估，但交易费用是区块链系统的一种新颖的性能维度，在传统计算机系统中并不真正存在。

衡量延迟的挑战

延迟起初看起来很简单：交易需要多长时间才能得到确认？但是，总是存在几种不同的方式来回答这个问题。首先，我们可以测量不同时间点之间的延迟，并获得不同的结果。例如，我们是从用户在本地点击“提交”按钮时开始测量延迟，还是从交易进入内存池时开始测量？我们是在交易位于提议的区块中时停止计时，还是在区块被一个或六个后续区块确认时停止计时？最常见的方法是从验证者的角度出发，从客户端首次广播交易到交易被合理“确认”的时间进行测量（从现实世界的商家会认为已收到付款并放行商品这一意义上来说）。当然，不同的商家可能会应用不同的接受标准，甚至单个商家也可能会根据交易金额使用不同的标准。以验证者为中心的方法遗漏了实践中重要的几个方面。首先，它忽略了点对点网络上的延迟（从客户端广播交易到大多数节点听到交易需要多长时间？）以及客户端延迟（在客户端的本地机器上准备交易需要多长时间？）。对于像签署以太坊付款这样的简单交易，客户端延迟可能非常小且可预测，但对于更复杂的情况，比如证明受保护的 Zcash 交易是正确的，客户端延迟可能会很大。即使我们标准化了尝试使用延迟测量的时间窗口，答案几乎总是视情况而定。任何已构建的加密货币系统都没有提供固定的交易延迟。要记住的一个基本经验法则是：

延迟是一个分布，而不是一个单一的数字。

网络研究界长期以来一直理解这一点（例如，请参阅 Gil Tene 所做的精彩演讲）。特别强调的是分布的“长尾”，因为即使 0.1% 的交易（或 Web 服务器查询）出现高度延迟也会严重影响最终用户。

对于区块链，确认延迟可能会因多种原因而异：

批处理： 大多数系统以某种方式批处理交易，例如在大多数 Layer 1 系统中将交易批处理成区块。这会导致可变的延迟，因为某些交易将不得不等到批处理完成。其他人可能会很幸运，最后加入该批处理。这些交易会立即得到确认，并且不会遇到任何额外的延迟。

可变拥塞： 大多数系统都会受到拥塞的影响，这意味着发布的交易（至少在某些时候）多于系统可以立即处理的交易。拥塞程度可能会因交易在不可预测的时间广播（通常抽象为 泊松过程）或当新交易的速率在一周中的一天或一周内发生变化时，或响应于像流行的 NFT 发布这样的外部事件而变化。

共识层差异： 在 Layer 1 上确认交易通常需要一组分布式节点就一个区块达成共识，这可能会增加可变的延迟，而与拥塞无关。工作量证明系统在不可预测的时间找到区块（同样可以抽象地看作是泊松过程）。权益证明系统也可能会增加各种延迟（例如，如果在线的节点数量不足以在一个回合中组成一个委员会，或者如果需要响应于领导者崩溃而进行视图更改）。

因此，一个好的指导原则是：

关于延迟的声明应提供确认时间的分布（或直方图），而不是像平均值或中位数这样的单个数字。

虽然像平均值、中位数或百分位数这样的汇总统计信息提供了一个局部视图，但是准确评估一个系统需要考虑整个分布。在某些应用程序中，如果延迟分布相对简单（例如，高斯分布），则平均延迟可以提供很好的见解。但是在加密货币中，几乎从来都不是这样：通常，存在等待确认的漫长尾部。

支付通道网络（例如，闪电网络）就是一个很好的例子。作为经典 L2 扩展解决方案，这些网络在大多数情况下都提供非常快速的支付确认，但是偶尔它们需要重置通道，这可能会使延迟增加几个数量级。

即使我们确实有关于确切延迟分布的良好统计信息，它们也可能会随着系统和对系统的需求的变化而随时间变化。而且，如何比较竞争系统之间的延迟分布也并不总是很清楚。例如，考虑一个系统，该系统以 1 到 2 分钟之间的均匀分布延迟确认交易（平均值和中位数为 90 秒）。如果一个竞争系统恰好在 1 分钟内确认了 95% 的交易，而在 11 分钟内确认了另外 5% 的交易（平均值为 90 秒，中位数为 60 秒），那么哪个系统更好？答案可能是某些应用程序会更喜欢前者，而另一些应用程序会更喜欢后者。

最后，重要的是要注意，在大多数系统中，并非所有交易都具有相同的优先级。用户可以支付更多费用以获得更高的包含优先级，因此，除了以上所有内容之外，延迟还会随着支付的交易费用而变化。总结一下：

延迟很复杂。报告的数据越多越好。理想情况下，应在不同的拥塞条件下测量完整的延迟分布。将延迟分解为不同的组成部分（本地、网络、批处理、共识延迟）也很有帮助。

衡量吞吐量的挑战

吞吐量乍一看也很简单：一个系统每秒可以处理多少笔交易？出现两个主要难题：究竟什么是“交易”，以及我们衡量的是系统今天所做的还是可能能够做的？虽然“每秒交易数”（或 tps）是衡量区块链性能的事实标准，但交易作为衡量单位是有问题的。对于提供通用可编程性（“智能合约”）或什至有限功能的系统，例如比特币的多路复用交易或多重签名验证的选项，根本问题是：

并非所有交易都是一样的。

这在以太坊中显然是正确的，在以太坊中，交易可以包括任意代码并任意修改状态。以太坊中的 gas 的概念用于量化（并收取费用）交易正在执行的总工作量，但这对于 EVM 执行环境而言非常特殊。没有简单的方法可以将一组 EVM 交易完成的总工作量与使用 BPF 环境的一组 Solana 交易进行比较。将任何一个与一组比特币交易进行比较同样令人担忧。

将交易层分离为共识层和执行层的区块链可以使这一点更加清楚。在（纯粹的）共识层，吞吐量可以用每单位时间添加到链中的字节数来衡量。执行层将永远更加复杂。

更简单的执行层，例如仅支持支付交易的 rollup servers，可以避免量化计算的困难。但是，即使在这种情况下，付款也会因输入和输出的数量而异。 支付通道交易可能会因所需的“hops”数量而异，这会影响吞吐量。并且 rollup server 吞吐量可能取决于一批交易可以“净额”到一组较小的摘要更改的程度。

吞吐量的另一个挑战是超越经验性地衡量今天的性能，从而评估理论容量。这就引入了各种建模问题，以评估潜在的容量。首先，我们必须为执行层确定一个实际的交易工作量。其次，实际系统几乎从未达到理论容量，尤其是区块链系统。出于健壮性的考虑，我们希望节点实现在实践中是异构的和多样的（而不是所有客户端都运行单个软件实现）。这使得对区块链吞吐量的准确模拟更加难以进行。

总而言之：

声明吞吐量需要仔细解释交易工作量和验证者的数量（它们的数量、实现和网络连接）。在没有任何明确标准的情况下，来自像以太坊这样的流行网络的历史工作量就足够了。

延迟-吞吐量权衡

延迟和吞吐量通常是一种权衡。正如 Lefteris Kokoris-Kogias 概述的那样，这种权衡通常并不顺畅，当系统负载接近其最大吞吐量时，延迟会急剧上升，存在一个拐点。零知识 rollup 系统展示了吞吐量/延迟权衡的自然例子。大批量交易会增加 proving 的时间，从而增加延迟。但是，链上的 footprint，无论是在证明的大小还是验证成本方面，都将在更大的批次大小中分摊到更多的交易上，从而提高吞吐量。

交易费用

可以理解的是，最终用户更关心延迟和费用之间的权衡，而不是延迟和吞吐量。用户没有直接理由关心吞吐量，而只是希望他们能够以尽可能最低的费用快速确认交易（有些用户更关心费用，而另一些用户更关心延迟）。在较高层面上，费用受多种因素影响：

1. 进行交易的市场需求有多大？
2. 系统实现的总吞吐量是多少？
3. 系统为验证者或矿工提供的总收入是多少？
4. 这些收入中有多少是基于交易费而不是通胀奖励？

前两个因素大致是供求曲线，导致市场出清价格（尽管有人声称矿工充当卡特尔以将费用提高到该点以上）。在所有条件相同的情况下，更高的吞吐量应该会降低费用，但是还有更多的事情发生。特别是，以上第 3 点和第 4 点是区块链系统设计的根本问题，但是我们缺少针对这两个问题的良好原则。我们对从通胀奖励与交易费中向矿工提供收入的优缺点有了一些了解。但是，尽管对区块链共识协议进行了许多经济分析，但我们仍然没有被广泛接受的模型来了解需要向验证者提供多少收入。如今，大多数系统都建立在一种有根据的猜测之中，即有多少收入足以使验证者诚实地行事，而又不会扼杀系统的实际使用。在简化的模型中，可以证明发起 51% 攻击的成本会随着对验证者的奖励而增加。提高攻击成本是一件好事，但是我们也不知道有多少安全性是“足够”的。想象一下，你正在考虑去两个游乐园。其中一个声称在游乐设施维护上的花费比另一个少 50%。去这个游乐园是个好主意吗？可能是他们效率更高，并且以更少的钱获得了同等的安全性。也许另一个公园的花费超过了保持游乐设施安全所需的费用，而没有带来任何好处。但是也可能是第一个公园很危险。区块链系统与之类似。一旦你剔除吞吐量，费用较低的区块链的费用较低，因为它们奖励（并因此激励）其验证者的程度较低。我们今天没有好的工具来评估这是否可以，或者是否会使系统容易受到攻击。总而言之： 比较系统之间的费用可能会产生误导。即使交易费用对用户而言很重要，但它们受到系统设计本身以外的许多因素的影响。吞吐量是分析整个系统的更好的指标。

结论

公平、准确地评估性能很难。衡量汽车的性能同样如此。就像区块链一样，不同的人会关心不同的事情。对于汽车，有些用户会关心最高速度或加速，另一些用户则关心汽油行驶里程，还有一些用户则关心牵引能力。所有这些都很难评估。例如，在美国，美国环境保护署维护着详细的指导方针，专门针对如何评估汽油行驶里程以及如何在经销商处将其呈现给用户。

区块链领域距离这种标准化水平还有很长的路要走。在某些领域，将来我们可能会通过标准化工作负载来评估系统的吞吐量或用于呈现延迟分布的标准化图表来实现这一目标。就目前而言，对于评估人员和构建人员而言，最佳方法是收集并发布尽可能多的数据，并详细描述评估方法，以便可以对其进行重现并与其他系统进行比较。

• 原文链接： a16zcrypto.com/posts/art...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～