A16z：为什么区块链性能很难衡量？

原文：https://a16zcrypto.com/why-blockchain-performance-is-hard-to-measure/

作者：Joseph Bonneau

性能和可扩展性是加密领域中备受讨论的挑战，与第 1 层项目（独立区块链）和第 2 层解决方案（如rollup和链下通道）相关。然而，我们没有标准化的指标或基准。数字通常以不一致和不完整的方式报告，这使得准确比较项目变得困难，并常常模糊了实践中最重要的内容。

我们需要一种更细致、更彻底的方法来衡量和比较性能——一种将性能分解为多个组件，并在多个轴上进行权衡比较的方法。在这篇文章中，我定义了基本术语，概述了挑战，并提供了在评估区块链性能时要牢记的指导方针和关键原则。

可扩展性与性能

首先，让我们定义两个术语，可扩展性和性能，它们具有标准的计算机科学含义，在区块链环境中经常被滥用。性能衡量系统当前能够实现的目标。正如我们将在下面讨论的那样，性能指标可能包括每秒交易数或交易确认时间中值。另一方面，可扩展性衡量系统通过添加资源来提高性能的能力。

这种区别很重要：如果定义得当，许多提高性能的方法根本不会提高可扩展性。一个简单的例子是使用更高效的数字签名方案，例如 BLS 签名，其大小大约是 Schnorr 或 ECDSA 签名的一半。如果比特币从 ECDSA 切换到 BLS，每个区块的交易数量可能会增加 20-30%，从而在一夜之间提高性能。但是我们只能这样做一次——没有更节省空间的签名方案可以切换（BLS 签名也可以聚合以节省更多空间，但这是一个一次性技巧）。

许多其他一次性技巧（例如隔离见证）在区块链中是可能的，但你需要一个可扩展的架构来实现持续的性能改进，其中添加更多资源会随着时间的推移提高性能。这也是许多其他计算机系统中的传统智慧，例如构建 Web 服务器。通过一些常用技巧，你可以构建一个非常快速的服务器；但最终，你需要一个多服务器架构，通过不断添加额外的服务器来满足不断增长的需求。

理解这种区别还有助于避免在诸如“区块链 X 具有高度可扩展性，它每秒可以处理 Y 笔交易！”之类的陈述中发现的常见类别错误。第二种说法可能令人印象深刻，但它是一个性能指标，而不是可扩展性指标。它并没有说明通过添加资源来提高性能的能力。

可扩展性本质上需要利用并行性。在区块链领域，第 1 层扩展似乎需要分片或看起来像分片的东西。分片的基本概念——将状态分成几块，以便不同的验证者可以独立处理——与可扩展性的定义非常吻合。第 2 层还有更多选项允许添加并行处理——包括链下通道、rollup服务器和侧链。

延迟与吞吐量

传统上，区块链系统性能通过延迟和吞吐量两个维度进行评估：延迟衡量单个交易可以多快得到确认，而吞吐量衡量交易随时间的总速率。这些轴适用于第 1 层和第 2 层系统，以及许多其他类型的计算机系统（例如数据库查询引擎和 Web 服务器）。

不幸的是，延迟和吞吐量都很难测量和比较。此外，个人用户实际上并不关心吞吐量（这是一个系统范围的衡量标准）。他们真正关心的是延迟和交易费用——更具体地说，他们的交易被尽快确认并尽可能便宜。尽管许多其他计算机系统也在成本/性能的基础上进行评估，但交易费用是区块链系统的一个新的性能轴，这在传统计算机系统中并不存在。

测量延迟的挑战

延迟一开始似乎很简单：交易需要多长时间才能得到确认？但总有几种不同的方法可以回答这个问题。

首先，我们可以测量不同时间点之间的延迟并得到不同的结果。例如，我们是在用户点击本地“提交”按钮时开始测量延迟，还是在交易到达内存池时开始测量延迟？当交易在提议的区块中时，或者当一个区块被一个或六个后续区块确认时，我们是否会停止计时？

最常见的方法是从验证者的角度来衡量，从客户首次广播交易到交易被合理“确认”的时间（从某种意义上说，现实世界的商家会考虑收到付款并发出商品） .当然，不同的商户可能采用不同的接受标准，甚至单个商户也可能根据交易金额采用不同的标准。

以验证者为中心的方法忽略了一些在实践中很重要的事情。首先，它忽略了点对点网络上的延迟（从客户端广播交易到大多数节点听到它需要多长时间？）和客户端延迟（在客户端的本地机器上准备交易需要多长时间?）。对于签署以太坊支付等简单交易，客户端延迟可能非常小且可预测，但对于更复杂的情况（如证明屏蔽Zcash 交易是正确的）则可能很重要。

即使我们标准化了我们试图用延迟测量的时间窗口，答案几乎总是取决于它。从来没有一个加密货币系统能够提供固定的交易延迟。要记住的基本经验法则是：

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

网络研究社区早就明白这一点。特别强调分布的“长尾”，因为即使是 0.1% 的交易（或 Web 服务器查询）的高度延迟也会严重影响最终用户。

在区块链中，确认延迟可能会因多种原因而有所不同：

批处理：大多数系统以某种方式批处理交易，例如大多数第 1 层系统上的块。这会导致可变延迟，因为某些交易必须等到批处理填满。其他人可能会很幸运并最后加入该批次。这些交易会立即得到确认，不会出现任何额外的延迟。

可变拥塞：大多数系统都遭受拥塞，这意味着要处理的交易（至少在某些时候）超过了系统可以立即处理的数量。当交易在不可预测的时间（通常抽象为泊松过程）广播时，或者当新交易的速率在一天或一周内发生变化时，或者响应外部事件（如流行的 NFT 发行）时，拥塞程度可能会有所不同。

共识层差异：在第 1 层确认交易通常需要一组分布式节点才能就区块达成共识，这可能会增加可变延迟，而不受拥塞的影响。工作量证明系统在不可预测的时间发现块（也抽象为泊松过程）。权益证明系统还可能增加各种延迟（例如，如果在线节点数量不足，无法在一轮中组成委员会，或者需要更改视图以响应领导者崩溃）。

由于这些原因，一个好的指南是：

关于延迟的说法应该呈现确认时间的分布（或直方图），而不是像平均值或中位数这样的单个数字。

虽然平均值、中位数或百分位数等汇总统计数据提供了部分情况，但准确评估系统需要考虑整个分布。在某些应用程序中，如果延迟分布相对简单（例如，高斯分布），平均延迟可以提供很好的洞察力。但在加密货币中，几乎从不这样：通常情况下，确认时间会很长。

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

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

最后，需要注意的是，在大多数系统中，并非所有交易的优先级都相同。用户可以支付更多费用来获得更高的包含优先级，因此除了上述所有内容之外，延迟还取决于支付的交易费用。总之：

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

测量吞吐量的挑战

吞吐量乍一看似乎也很简单：一个系统每秒可以处理多少交易？出现了两个主要困难：究竟什么是“交易”，我们是在衡量一个系统今天做了什么，或者它可能能够做什么？

虽然“每秒交易数”（tps）是衡量区块链性能的事实上的标准，但交易作为衡量单位是有问题的。对于提供通用可编程性（“智能合约”）甚至比特币的多重交易或多重签名验证选项等有限功能的系统，基本问题是：

并非所有交易都是平等的。

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

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

更简单的执行层，例如只支持支付交易的rollup服务器，避免了量化计算的困难。但是，即使在这种情况下，支付的输入和输出数量也会有所不同。支付通道交易所需的“跳数”数量可能会有所不同，这会影响吞吐量。rollup服务器的吞吐量可能取决于一批交易可以在多大程度上“归结”为一组较小的汇总更改。

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

整体上：

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

延迟-吞吐量权衡

延迟和吞吐量通常是一种权衡。正如 Lefteris Kokoris-Kogias 所述，这种权衡通常并不顺利，当系统负载接近其最大吞吐量时，延迟会急剧增加。

零知识rollup系统提供了吞吐量/延迟权衡的自然示例。大批量交易增加了证明时间，从而增加了延迟。但是，在证明大小和验证成本方面，链上足迹将分摊到更多具有更大批量的交易中，从而提高吞吐量。

交易费用

可以理解的是，最终用户更关心延迟和费用之间的权衡，而不是延迟和吞吐量。用户根本没有直接的理由关心吞吐量，只是他们可以以尽可能低的费用快速确认交易（一些用户更关心费用，而其他用户更关心延迟）。总体而言，费用受多种因素影响：

• 有多少市场需求进行交易？
• 系统实现的总吞吐量是多少？
• 该系统为验证者或矿工提供了多少总收入？
• 这笔收入中有多少是基于交易费用与通货膨胀奖励？

前两个因素大致是导致市场出清价格的供需曲线（尽管有人声称矿工作为卡特尔将费用提高到这一点之上）。在其他条件相同的情况下，更多的吞吐量应该会导致更低的费用，但还有很多事情要做。

特别是上面的第 3 点和第 4 点是区块链系统设计的基本问题，但我们对它们都缺乏好的原则。我们对从通胀奖励与交易费用中给予矿工收入的优缺点有了一些了解。然而，尽管对区块链共识协议进行了许多经济分析，我们仍然没有广泛接受的模型来确定需要多少收入流向验证者。今天，大多数系统都建立在有根据的猜测，即有多少收入足以让验证者诚实行事，而不会妨碍系统的实际使用。在简化的模型中，可以显示发起 51% 攻击的成本与对验证者的奖励成正比。

提高攻击成本是一件好事，但我们也不知道多少安全性“足够”。想象一下，你正在考虑去两个游乐园。其中一个声称在乘车维护上的花费比另一个少 50%。去这个公园是个好主意吗？可能是它们效率更高，并且以更少的钱获得同等的安全性。也许另一个人的花费超过了保持游乐设施安全所需的费用，而没有任何好处。但也可能是第一个公园很危险。区块链系统是类似的。一旦考虑到吞吐量，费用较低的区块链费用较低，因为它们奖励（并因此激励）验证者较少。我们今天没有好的工具来评估这是否可行，或者它是否会使系统容易受到攻击。整体上：

比较不同系统之间的费用可能会产生误导。尽管交易费用对用户来说很重要，但除了系统设计本身之外，它们还受到许多因素的影响。吞吐量是分析整个系统的更好指标。

结论

公平而准确地评估性能是很困难的。这同样适用于衡量汽车的性能。就像区块链一样，不同的人会关心不同的事情。对于汽车，一些用户会关心最高速度或加速度，其他用户会关心油耗，还有一些用户会关心牵引能力。所有这些都不容易求值。例如，在美国，环境保护署就如何评估汽油里程以及必须如何向经销商处的用户提供详细的指导方针。

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