a16z：如何客观评估区块链性能？

公平而准确地评估区块链性能并非易事。

撰文：Joseph Bonneau，a16z crypto research 成员

编译：Amber，Foresight News

围绕性能和可扩展性的讨论，是整个加密世界最经久不衰的辩题。

关于一层和二层解决方案优劣以及有效性的争论一直在进行，不过由于缺乏标准化的指标和考核标准，争论中各方拿出的数据往往缺乏一致性，无疑进一步加剧了观点的分歧。

简单来说，我们需要一种更加细致和更加彻底的方法来进行性能的比较，比如说我们需要把性能分为几个维度进行分别对比，并找到一个综合性的权衡标准。本文中，我将从基本术语讲起，概述目前市场所面临的挑战，并针对评估区块链性能时需要牢记的一些基本原则进行展开。

可扩展性 & 性能

首先，让我们定义两个术语，可扩展性和性能。这两个词具有标准的计算机科学含义，但却经常在区块链环境中被滥用。性能一般用于衡量系统所能够实现的目标功效，性能指标可能包括每秒能处理的进程数量或者特定需求下所需要的时间长短。而可扩展性则是被用于衡量系统通过添加一定资源来提升性能的能力如何。

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

实际上，区块链网络中还有很多提升的技巧也是一次性的（例如 SegWit），但对于我们来说，真正需要的是一个可扩展的架构来实现持续的性能改进，只有这样我们才能通过持续添加资源来持续提升性能。实际上在 Web2 时代，这已经是一种通用的手段了，以搭建服务器为例，虽然我们可以直接搭建一个足够快的服务器，但最终一般都需要升级成为多服务器架构，其间就需要通过不断添加新的服务器来满足不断增长的数据存储 / 处理需求。

理解这种区别后还有助于避免在诸如「某区块链具有高度可扩展性，它每秒可以处理多少笔交易！」之类的陈述中出现常识性错误。虽然这种话术可能很具有煽动性，但事实上处理多少笔交易是性能指标而不是可扩展性指标。

可扩展性本质上需要利用并行性。在区块链领域，一层扩展往往需要分片或看起来像分片的东西。分片的基本概念其实就是将状态分成几块，以便让不同的验证者可以独立处理其中一部分，而这与可扩展性的定义非常吻合。当然，二层还有更多选项允许添加并行处理，包括链下通道、Rollup 和侧链等等。

延迟与吞吐量

过去我们往往习惯用延迟和吞吐量两个维度评估区块链的性能：延迟可用于衡量单笔交易可以多快得到确认，而吞吐量则用于衡量特定时间内可以确认的交易总量。这种衡量方式既适用于一层和二层网络，甚至在区块链以外的其他类型计算机系统中也完全适用。

不幸的是，延迟和吞吐量这两个纬度实际上都很难测量和比较。而且另一个很重要点在于，个人用户实际上并不关心吞吐量，他们真正关心的只有延迟和交易费用。交易费用是区块链系统中的一个重要维度，而这个在传统计算机领域中并不存在。

测量延迟的挑战

延迟的测量看起来似乎很简单：交易需要多长时间才能得到确认？但实际操作中问题才会显现出来。首先，我们在不同时间点测量的延迟往往是不一样的，我们究竟是从用户本地点击提交按钮开始计算？还是在任务到达内存池的那一刻开始计算？还有就是当区块确认时，我们是否要立即停止计时？不同的操作细节都会带来不同的结果。

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

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

即使我们标准化了测量延迟的时间窗口，最终的答案也依旧是视情况而定的。从来没有一个加密货币系统能保证恒定的交易延迟。要记住的基本经验法则其实是：延迟是一个分布，而不是一个数字。

网络研究社区早就意识到了这一点，并指出长尾至关重要，即使是 0.1% 的进程出现延迟也会严重影响最终的用户体验。

对于区块链来说，确认延迟可能会因多种原因而有所不同：

批处理：大多数系统以某种方式批处理事务，这会导致产生可变延迟，因为某些事务必须等到批处理队列被填满后才会被处理。网络参与者可能会很幸运地乘上该批次的末班车。这些交易会立即得到确认，不会出现任何额外的延迟，但那些提前进入队列的人们就必须要花费更长的时间去等待确认。

不确定的拥堵：大多数系统都经历过拥堵的状况，这意味着发布的交易超过了系统可以立即处理的数量。当交易在不可预测的时间（通常抽象为泊松过程）广播时，或者当新交易的速率在一天或一周内发生变化时，或者响应外部事件时，拥堵程度可能会有所不同。

共识层差异：在一层确认交易通常需要一组分布式节点才能就区块达成共识，这可能会增加可变延迟，而不受拥堵的影响。工作量证明系统在不可预测的时间发现块。权益证明系统还可能增加各种延迟。

由于这些原因，一个好的指导方针是：关于延迟的声明应该以确认时间的分布呈现，而不是像平均值或中位数这样的单个数字。

虽然平均值、中位数或百分位数等汇总统计数据也能表明部分规律，但准确评估系统需要考虑整个分布。在某些应用程序中，如果延迟分布相对简单，平均延迟可以提供很好的洞察力。但在加密货币中这种理想状况并不多见：通常情况下，确认时间会很长。

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

即使我们对确切的延迟分布有很好的统计数据，它们也可能会随着系统和系统需求的变化而随时间变化，如何比较竞争系统之间的延迟分布也非常模糊。例如，考虑一个系统，它确认事务的均匀分布延迟在 1 到 2 分钟之间（平均和中位数为 90 秒）。如果一个竞争系统在 1 分钟内准确地确认了 95% 的交易，而在 11 分钟内确认了另外 5%（平均 90 秒，中位数为 60 秒），那么哪个系统更好？答案是不同类别的应用可能选择并不一致。

最后，需要注意的是，在大多数系统中，并非所有事务的优先级都相同。用户可以支付更多费用来获得更高的包含优先级，因此除了上述所有内容之外，延迟还取决于支付的交易费用。总之：延迟很复杂。报告的数据越多越好。理想情况下，应在不同的拥堵条件下测量完整的延迟分布。将延迟分解为不同的组件（本地、网络、批处理、共识延迟）也很有帮助。

测量吞吐量的挑战

吞吐量乍一看似乎也很简单：一个系统每秒可以处理多少事务？但事实上问题同样被隐藏在水面之下。难点主要体现在两个方面，第一是究竟什么算交易，我们是在衡量一个系统今天做了些什么？还是要去衡量他能做到些什么？

虽然每秒交易笔数（或 TPS）是衡量区块链性能的通用标准，但交易作为衡量单位是有问题的。对于提供通用可编程性（智能合约）甚至比特币的多重交易或多重签名验证选项等限定功能的系统，一个最基本的问题是：并非所有交易都是平等的。

在以太坊网络中，交易可以包含任意代码以及任意状态。以太坊中的 Gas 概念用于量化（并收取费用）交易正在执行的总工作量，但这是高度限定于 EVM 执行环境的。没有简单的方法可以将一组 EVM 事务完成的工作总量与使用 BPF 环境的一组 Solana 事务进行直接比较。将其中任何一个与一组比特币交易进行直接比较也并不合理。

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

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

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

总的来说，权衡吞吐量需要仔细解释交易工作量和验证者的数量。在没有任何明确标准的情况下，只能以以太坊这种比较流行的网络历史负载作为标准来对比计量。

延迟与吞吐量二者的综合考量

延迟和吞吐量各自统计过后，我们还需要在二者之间进行综合权衡。正如 Lefteris Kokoris-Kogias 所述，这种权衡通常并不顺利，当系统负载接近其最大吞吐量时，延迟会急剧上升。

ZK Rollup 系统提供了吞吐量 / 延迟权衡的自然示例。大批量交易增加了证明时间，从而增加了延迟。但是，在证明大小和验证成本方面，链上算力将像更大规模的交易簇倾斜，从而提高吞吐量。

交易费用

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

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

简单来说，在其他条件相同的情况下，更高的吞吐量应该会导致更低的费用。不过上面提到的第 3 点和第 4 点是区块链系统设计的基本问题。尽管对区块链共识协议进行了许多经济分析，但对于验证者需要多少收入，我们仍然没有达成一个共识性的模型。今天大多数系统都建立在有根据的猜测之上，即提供多少收入足以让验证者诚实行事的同时还不会影响网络对于用户的吸引力。在简化的模型中，让发起 51% 攻击的成本与验证者的奖励成正比即可。

提高攻击成本是一件好事，但我们也不知道多少安全性「够用」。想象一下，您正在考虑去两个游乐园。其中一个声称在乘车维护上的花费比另一个少 50%。去这个公园是个好主意吗？可能是它们效率更高，并且能以更少的钱获得同等的安全性。也许另一个人的花费超过了保持游乐设施安全所需的费用，而没有任何好处。但也可能是第一个公园很危险。区块链系统是类似的。一旦考虑到吞吐量，费用较低的区块链费用较低，因为它们奖励较少。我们今天没有好的工具来评估这是否可行，或者它是否会使系统容易受到攻击。总的来说：比较系统之间的费用可能会造成一定程度的误导。尽管交易费用对用户来说很重要，但除了系统设计本身之外，它们还受到许多因素的影响。吞吐量是分析整个系统的更好指标。

结论

公平而准确地评估性能是很困难的。衡量区块链和衡量一款车值不值得买一样复杂，不同的人会关心不同的事情，对于汽车来说，一些用户会关心极限速度或百公里加速成绩，有一些人关心油耗，还有一些人则只关心这辆车能装多少货。正因如此，美国环境保护署甚至直接出台了一个汽车评定准则的指导方针。

而区块链领域中，我们还远没有来到可以出台一个标准化准则的时刻，某些时候我们可能会找到一个标准的工作负载并以此绘制区块链网络吞吐量和延迟分布的「标准图表」，但现如今对于研究者和建设者来说，最好的方法只有去收集尽可能多的数据，并在发表观点前尽可能详尽地描绘出测试环境，因为只有这样我们才能得到一个相对客观的对比结果。