如何衡量一个公链的好坏？ - johns

作者推特：https://twitter.com/johns20178

discord交流群：https://discord.gg/YNuryGXypV（有问题一定要进群交流，比你一个人埋头研究效率高得多）

性能和可扩展性是衡量公链时备受瞩目的关键指标，与 Layer-1 本身逻辑与 Layer-2 给出的解决方案（如卷叠和链下渠道）相关。然而，对于它们的衡量，我们并没有标准化的指标或基准，数字通常以不一致和不完整的方式报告，这使得准确比较项目变得困难，并且经常导致我们难以看出实际表现如何。

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

1.可扩展性与性能

首先，让我们定义两个术语，可扩展性和性能，它们的含义在区块链环境中经常被曲解。性能衡量系统当前能够实现的目标。正如我们将在下面讨论的，性能指标可能包括每秒交易数或交易平均确认时间。而可扩展性衡量系统通过添加资源来提高性能的能力。

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

还有许多其他一次性的技巧（例如 SegWit ）可以提高区块链的性能，但一个可扩展的架构来实现持续的性能改进也是有必要的，你可以不断地添加组建来提高区块链的性能。这也是许多其他传统计算机系统中的智慧，例如构建 Web 服务器。通过一些常用技巧，你可以构建一个非常快速的服务器；但最后你仍然需要一个多服务器架构，通过不断添加额外的服务器来满足不断增长的需求。

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

可扩展性本质上需要利用并行性。在区块链领域，L1 的可拓展性需要分片或类似分片的机制来实现。分片的基本概念——将状态分成几部分，以便不同的验证者可以独立处理——与可扩展性的定义非常匹配。L2 还有更多选项允许并行处理——包括链下通道、汇总服务器和侧链。

2.延迟与吞吐量

传统上，公链的性能通过延迟和吞吐量两个维度进行评估：延迟衡量单个交易多快可以得到确认，而吞吐量衡量交易随时间的总速率。这两个标准在 L1 和 L2 系统以及许多其他类型的计算机系统（例如数据库查询引擎和 Web 服务器）中都可以使用。

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

测量延迟的挑战：

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

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

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

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

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

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

网络研究社区早就明白这一点（例如 Gil Tene 的精彩演讲）。特别值得注意的是区块链延迟中的“长尾”效应，即使是 0.1% 的交易（或 Web 服务器查询）的高度延迟最终也会严重影响用户。

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

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

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

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

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

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

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

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

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

测量吞吐量的挑战：

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

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

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

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

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

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

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

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

延迟-吞吐量权衡：

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

零知识汇总系统提供了吞吐量/延迟权衡的示例。大批量交易增加了证明时间，从而增加了延迟。但是，当这些数据汇总到链上时，将会与其他大批量的交易一起写入区块中进行处理，从而提高吞吐量。

3.交易费用

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

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

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

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

提高攻击成本是一件好事，但我们也不知道究竟多少的安全性是“足够的”。想象一下，你正在考虑去游乐园，你有两个选择。其中一个声称维护上的花费比另一个少 50%，所以你可能享受更便宜的门票，那么去这个公园是个好主意吗？它可能更加经济实惠，但也可能是第一个公园很危险。区块链系统是类似的。一旦考虑到吞吐量，费用较低的区块链费用较低，因为它们奖励（并因此激励）验证者较少。我们今天没有好的工具来评估这是否可行，或者它是否会使系统容易受到攻击。

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

结语：

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

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

来源：a16z

参考资料：

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