区块链的难，难以衡量

本文属于老雅痞原创文章，转载规矩不变，给我们打声招呼～

转载请微信联系：huangdiezi，更多DAO、Web3、NFT、Metaverse资讯请关注老雅痞

作者：Joseph Bonneau

性能和可扩展性是加密货币领域讨论较多的挑战，与 Layer 1 项目（独立区块链）和 Layer 2 解决方案（如 rollups 和 off-chain channels）都有关。然而，我们没有标准化的衡量标准或基准。数字往往以不一致和不完整的方式出现在报告中，使其难以准确地起到比较的作用，并常常掩盖了实践中最重要的东西。

我们需要一种更细微、更彻底的方法来衡量和比较绩效――一种将绩效分解成多个组成部分，并在多个轴上比较权衡的方法。在这篇文章中，我定义了基本的术语，概述了挑战，并提供了在评估区块链性能时应牢记的准则和关键原则。

可扩展性与性能

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

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

在区块链中，其他一些一次性的技巧（如SegWit）是可能的，但你需要一个可扩展的架构来实现持续的性能改进，即增加更多的资源来改善性能。例如构建一个网络服务器，这也是许多其他计算机系统中的传统智慧。通过一些常见的技巧，你可以建立一个非常快的服务器；但最终，你需要一个多服务器架构，通过不断增加额外的服务器来满足不断增长的需求。

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

可扩展性本质上需要利用并行性。在区块链领域，Layer 1 的扩展似乎需要分片或看起来像分片的东西。分片的基本概念：将 state 分割成片，以便不同的验证器可以独立处理――与可扩展性的定义密切相关。在 Layer 2 有更多的选择，允许增加并行处理――包括链外通道、rollup 服务和侧链。

延迟与吞吐量

传统上，区块链系统的性能是通过两个维度进行评估的，也就是延迟和吞吐量。延迟衡量的是单个交易的确认速度，而吞吐量衡量的是一段时间内交易的总速率。这些轴既适用于第一层和第二层系统，也适用于许多其他类型的计算机系统（如数据库查询引擎和网络服务器）。

不幸的是，延迟和吞吐量的测量和对比都很复杂。此外，个人用户实际上并不关心吞吐量（这是一个全系统的衡量标准）。他们真正关心的是延迟和交易费用。更具体地说，他们的交易被确认的速度越快越好，费用越低越好。尽管许多其他计算机系统也在成本/性能的基础上进行评估，但对于区块链系统来说，交易费用是一个有点新的性能轴，在传统计算机系统中并不存在。

测量延时的挑战

延迟起初似乎很简单：一笔交易需要多长时间才能得到确认？但总是有几种不同的方式来回答这个问题。

首先，我们可以在不同的时间点之间测量延迟，得到不同的结果。例如，我们是在用户点击本地的 “提交 “按钮时开始测量延迟，还是在交易进入mempool时开始测量延迟？还有，我们是在交易处于建议区块时停止计时，还是在区块被确认有一个或六个后续区块时停止计时？

最常见的方法是从验证者的角度出发，从客户第一次广播交易的时间到交易被合理 “确认 “的时间（在现实世界中的商家会认为收到付款并释放商品）来衡量。当然，不同的商家可能采用不同的接受标准，甚至一个商家也可能根据交易额的不同而采用不同的标准。

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

即使我们将我们试图用延迟来衡量时间窗口的标准化，答案几乎总是取决于它。有史以来，没有一个加密货币系统提供固定的交易延迟。

要记住的一个基本经验法则是:

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

网络研究学界长期以来一直理解这一点（Gil Tene的精彩演讲就专门讲过）。特别强调分布的 “长尾”，因为即使是0.1%的交易（或网络服务器查询）的高度延迟也会严重影响终端用户。

对于区块链，确认延迟会因多种原因而变化。

分批：大多数系统以某种方式对交易进行批处理，例如在大多数 Layer 1 系统上将交易分为区块。这导致了不同的延迟，因为一些交易将不得不等待，直到批量填满。其他交易可能很幸运，最后才加入批处理。这些交易会被立即确认，不会有任何额外的延迟。
可变的拥堵：大多数系统都有拥堵问题，这意味着发布的交易（至少在某些时候）比系统能立即处理的要多。当交易在不可预测的时间（通常被抽象为 Poisson process）或新交易的速度在一天或一周内发生变化时，或对外部事件（如流行的NFT发布）的反应，拥堵的程度会有所不同。
共识层的差异。在Layer 1确认交易通常需要一组分布式节点对区块达成共识，无论是否拥堵，都会增加可变的延迟。Proof-of-work工作证明系统在不可预测的时间找到区块（也是抽象的 Poisson process）。押注证明系统也会增加各种延迟（例如，如果一个回合中在线的节点数量不足，无法形成委员会，或者需要改变视图来应对领导者崩溃）。

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

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

虽然像平均数、中位数或百分位数这样的汇总统计提供了部分情况，但准确评估一个系统需要考虑整个分布。在一些应用中，如果延迟分布相对简单（例如，Gaussian），平均延迟可以提供良好的洞察力。但在加密货币中，几乎没有这样的情况。通常情况下，有一个缓慢确认时间的长尾。

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

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

最后，需要注意的是，在大多数系统中，并不是所有的交易都被平等地优先处理。用户可以支付更多的钱来获得更高的优先收录权，所以除了上述所有情况外，延迟也会随着支付的交易费用的不同而变化。

综上所述：

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

测量吞吐量的挑战

吞吐量乍看之下也很简单：不就是衡量一个系统每秒能处理多少个交易？这里出现了两个主要的困难：”交易 “到底是什么，以及我们是在衡量一个系统今天的吞吐量，还是它未来的吞吐量？

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

根本问题是：

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

这在以太坊中显然是真实的，交易可以包括任意的代码和任意的修改状态。以太坊中的gas概念被用来量化（并收取费用）一个交易所做的工作总量，但这对于EVM执行环境来说是非常特殊的。没有简单的方法来比较一组EVM交易和一组使用BPF环境的Solana交易的总工作量。将两者与一组比特币交易相比较，也同样充满了麻烦。

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

简单的执行层，比如只支持支付交易的 rollup servers，避免了量化计算的困难。不过，即使在这种情况下，支付也会在inputs 和 outputs的数量上有所不同。支付通道交易可以在所需的 “hops “的数量上有所不同，这影响了吞吐量。而 rollup servers 的吞吐量可能取决于一批交易能在多大程度上被 “netted “为一组较小的摘要变化。

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

总的来说：

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

延迟-吞吐量的权衡

延迟和吞吐量通常是需要权衡的两端。正如Lefteris Kokoris-Kogias所概述的，这种权衡往往是不平滑的，有一个拐点，当系统负载接近其最大吞吐量时，延迟也会急剧上升。

Zero-knowledge rollup systems 是吞吐量/延迟权衡的一个自然例子。大批的交易增加了证明时间，从而增加了延迟。但是，链上的足迹，无论是证明的大小还是验证的成本，都将在更多的交易中摊薄，而批量更大，增加了吞吐量。

交易费用

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

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

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

特别是，上述第3点和第4点是区块链系统设计的基本问题，然而我们对其中任何一点都缺乏良好的原则。我们对从通货膨胀的奖励与交易费用中给予矿工收入的利弊有一些了解。然而，尽管对区块链共识协议进行了许多经济分析，我们仍然没有广泛接受的模型来说明有多少收入需要给验证者。今天，大多数系统建立了一个有根据的猜测，即多少收入足以让验证者诚实行事，同时也不会扼杀系统的实际使用。在简化的模型中，可以证明发动51%的攻击的成本与验证者的奖励成正比。

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

总的来说：