a16z：能否公平准确地评估一条链的性能？

公链的那些性能指标，都代表了什么？

性能和可扩展性是加密领域备受讨论的挑战，与 L1 项目和 L2 解决方案有关。然而，我们没有标准化的指标或基准。数据报告的方式往往不一致且不完整，这使得准确比较项目变得困难，并常常模糊了实践中最重要的内容。

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

可扩展性 vs. 性能

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

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

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

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

可扩展性本质上要求利用并行性。在区块链空间中，L1 扩展似乎需要 分叉 或类似于分叉的东西。分叉的基本概念是将状态分割成块，以便不同的验证器可以独立处理，与可扩展性的定义非常匹配。在 L2 还有更多的选项，允许添加并行处理，包括链下通道、Rollup 服务器和侧链。

延迟 vs. 吞吐量

通常，区块链系统性能是通过两个维度进行评估的，即延迟和吞吐量。延迟度量确认单个交易的速度，而吞吐量度量随着时间的推移交易的总速率。这些轴既适用于 L1 和 L2 系统，也适用于许多其他类型的计算机系统（如数据库查询引擎和 web 服务器）。

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

测量延迟的挑战

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

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

最常见的方法是从验证者的角度，测量从用户第一次广播交易到合理地“确认”交易的时间。当然，不同的商家可能采用不同的验收标准，甚至单个商家也可能根据交易金额的不同采用不同的标准。

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

即使我们将试图测量延迟的时间窗口标准化，答案也是视情况而定。迄今为止，还没有一个加密货币系统提供固定的交易延迟。一个基本的经验法则是：

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

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

在区块链中，确认延迟的变化有很多原因：

批处理：大多数系统以某种方式将交易批处理，例如，在大多数 L1 系统上将交易批处理到区块中。这将导致可变的延迟，因为一些交易将不得不等待，直到批处理填满。其他人可能会幸运地最后加入。这些交易立即得到确认，并且不会经历任何额外的延迟。

可变拥塞：大多数系统都会出现拥塞，这意味着发布的交易比系统能够立即处理的交易要多。当交易在不可预测的时间进行广播时，或者当新交易在一天或一周内的速度发生变化时，或者在对像热门 NFT 启动这样的外部事件时响应，拥塞的程度会发生变化。

共识层差异：在 L1 确认交易通常需要一组分布式节点来达成对一个区块的共识，这可能会增加可变的延迟，无论拥塞情况如何。工作量证明系统在不可预测的时间找到区块。 PoS 系统还可以添加各种延迟（例如，如果在线节点数量不足，不能在一轮中组成一个委员会，或者如果需要改变观点以应对领导者的崩溃）。

基于这些原因，一个好的指导原则应该是：

关于延迟的声明应该显示确认时间的分布，而不是像平均值或中位数这样的单个数字。

虽然像平均值、中位数或百分位数这样的汇总统计提供了部分情况，但准确地评估一个系统需要考虑整个分布。在某些应用程序中，如果延迟分布相对简单，则平均延迟可以提供很好的洞察。但在加密货币中，这种情况几乎从未发生过。通常情况下，确认时间很长。

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

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

最后，需要注意的是，在大多数系统中，并非所有交易的优先级都是相同的。用户可以支付更多的钱来获得更高的优先级，所以除了以上这些，延迟也取决于所支付的交易费用。总而言之：

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

测量吞吐量的挑战

表面上看吞吐量似乎也很简单：一个系统每秒可以处理多少交易？但有两个主要的困难：究竟什么是“交易”，以及我们是否在度量一个系统今天做什么或者它可能做什么？

虽然“每秒交易数”（tps）是度量区块链性能的实际标准，但作为度量单位的交易存在问题的。对于提供通用可编程性（智能合约）或甚至有限功能的系统，如比特币的多路交易或多信号验证选项，其基本问题是：

不是所有的交易都是平等的。

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

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

更简单的执行层，例如只支持支付交易的 Rollup 服务器，避免了量化计算的困难。即使在这种情况下，支付也会因投入和产出的数量而变化。支付通道交易可能因所需的“跳跃次数”而异，这将影响吞吐量。Rollup 服务器吞吐量取决于将一批交易“联网”到更小的汇总更改集的程度。

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

总而言之：

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

延迟和吞吐量权衡

延迟和吞吐量通常是一种权衡。这种权衡通常不是一帆风顺的，当系统负载接近最大吞吐量时，延迟会急剧增加。

零知识汇总系统是吞吐量/延迟权衡的一个自然例子。大量的交易会增加证明时间，从而增加延迟。但链上的足迹，无论是在证明大小和验证成本方面，将分摊到更多的交易，更大的批处理大小，增加吞吐量。

交易费用

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

1. 有多少市场需求进行交易？

2. 系统实现的总体吞吐量是多少？

3. 系统提供给验证者或矿工的总收入是多少？

4. 这部分收入中有多少是基于交易费用还是基于通货膨胀奖励？

前两个因素大致是导致市场清算价格的供需曲线（尽管有人声称，矿工像联盟企业一样将费用提高到这一点以上）。在其他条件相同的情况下，更高的吞吐量应该会导致更低的费用，但还有更多因素要处理。

特别是上面的第 3 点和第 4 点是区块链系统设计的基本问题，但是我们对它们都缺乏良好的原则。相对于交易费用，我们对给予矿工以通货膨胀奖励的好处和坏处有一定的了解。然而，尽管有许多关于区块链共识协议的经济分析，我们仍然没有一个被广泛接受的模型来说明需要多少收入给验证器。今天，大多数系统都建立在一个有根据的猜测中，即有多少收入足以让验证器诚实地工作，而不会扼杀系统的实际使用。在简化的模型中，可以看出，安装 51% 攻击的成本与验证程序的回报成正比。

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

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

结论

公平准确地评估性能是很难的。这同样适用于测量汽车的性能。就像区块链一样，不同的人会关心不同的事情。对于汽车，有些用户会关心最高速度或加速，有些人会关心油耗，还有一些人会关心牵引能力。所有这些都不容易得到准确值。例如，在美国，环境保护署就制定了详细的指导原则，规定如何评估汽油里程数，以及在经销商处必须如何向用户展示。

区块链空间距离这个级别的标准化还有很长的路要走。在某些领域，未来我们可能会使用标准化的工作负载来评估系统的吞吐量，或者使用标准化的图形来表示延迟分布。目前，对评价者和建设者来说，最好的办法是收集和公布尽可能多的数据，并对评价方法进行详细的描述，以便它能够被复制和与其他系统进行比较。