天眼深度为什么很难衡量区块链的性能？

日期：2023年04月16日 08:27 浏览量：1

性能和可扩展性是加密领域的争议，与第1层项目(独立的块链)和第2层解决方案(如rollup和降链通道)相关。但是，没有标准化的指标和标准。数字通常以不一致和不完整的方式报告，这使得准确比较项目变得困难，往往模糊了实践中最重要的内容。

需要更精细、更彻底的方法来测量和比较如何将性能——分割为多个组件，并在多个轴上权衡比较。在这篇文章中中选择所需的族。定义基本术语，概述挑战，并提供评估区块链性能时应牢记的指导原则和重要原则。

可扩展性和性能

首先，让我们定义两个具有标准计算机科学含义的术语：可扩展性和性能经常在区块链环境中被滥用。绩效测量系统目前可以实现的目标。如下所述，性能指标可能包括每秒事务数或事务确认时间的中值。另一方面，可扩展性衡量系统通过添加资源提高性能的能力。

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

区块链提供许多其他主要技巧，例如隔离见证但是，为了实现持续的性能提高，需要可扩展的体系结构。其中，添加更多资源将随着时间的推移提高性能。这也是许多其他计算机系统中的传统智慧，例如构建Web服务器。通过一些常见的技巧虽然可以构建非常快的服务器，但最终需要一种不断添加服务器的多服务器体系结构来满足不断增长的需求。

理解这一差异意味着“块链x具有高度可扩展性每秒可以处理y笔交易！ ”等陈述中发现的常见类别错误。第二种说法可能令人印象深刻，但它是一种性能指标，而不是可扩展性指标。没有说明通过添加资源来提高性能的能力。

可扩展性本质上需要利用并行性。在区块链领域，第1层扩展似乎需要瓷砖或看起来像瓷砖的东西。片的基本概念3354将状态分成若干块，从而允许不同的验证者独立处理——，这与可扩展性的定义非常一致。第2层增加了添加并行处理——的选项，包括链路下信道、rollup服务器和侧链。

延迟和吞吐量

传统，通过延迟和吞吐量两个维度评估块链系统的性能。延迟衡量一个事务可以多快看到，而吞吐量衡量事务的总速度。这些轴适用于第1层和第2层系统中选择所需的族。有许多其他类型的计算机系统，例如数据库查询引擎和Web服务器。

不幸的是，延迟和吞吐量很难测量和比较。此外，个人用户实际上并不在乎吞吐量。这是整个系统的衡量标准。。他们真正关心的是延迟和交易费用——。更具体地说，他们的交易将尽快得到确认，并尽可能便宜。许多其他计算机系统也是根据成本/性能进行评估的，而交易费用是区块链系统的新绩效轴心这在传统的计算机系统中是不存在的。

测量延迟的挑战

延迟最初似乎很简单。交易得到确认需要多长时间？但是，回答这个问题有几种不同的方法。

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

最常见的方法是从验证者的角度测量从客户首次广播交易到交易得到合理“确认”的时间(请参阅)现实世界的商家会考虑接受支付后再发货)。当然，不同的商户可能采用不同的接受标准，个别商户也可能根据交易金额采用不同的标准。

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

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

延迟是分布而不是数字。

网络研究社区早就明白了这一点。特别强调分布的“长尾”中选择所需的族。因为即使0.1%的事务(或Web服务查询)延迟较高，也会对最终用户产生很大影响。在

区块链中，确认延迟可能由于各种原因而不同。

批处理：大多数系统都以某种方式批处理事务，例如第1层系统中的块。这将导致可变延迟，因为某些事务处理必须等待批处理完成。其他人可能幸运地最终加入那个批次。这些交易很快就会被确认没有额外的延迟。

可变拥塞：大多数系统都拥塞。这意味着要处理的事务至少在某些情况下超过了系统可以立即处理的数量。如果交易在不可预测的时间(通常抽象为泊松过程)播出或者，如果新交易的速度在一天或一周内发生变化，或者响应了常见的外部事件(如NFT发布)，则拥塞程度可能会有所不同。

合意层差异：在第1层确认事务处理通常需要一组分布式节点才能对块达成一致，这可能会增加可变延迟，而不受拥塞的影响。工作量证明系统在不可预测的时间发现块(也抽象为泊松过程) )。。权益证明系统还可能增加各种延迟。例如，如果在线节点数量不足，则无法一次配置委员会，或者必须更改视图以应对领导崩溃。

由于这些原因，一个好的方针是

关于延迟的说明应该表示确认时间的分布(或直方图)，而不是平均值或中央值等单一数字。

汇总平均值、中值或百分位数等统计数据可以提供部分情况，但正确评估系统需要考虑整体分布。在某些APP应用中，如果延迟分布相对简单(例如高斯分布)，平均延迟可提供出色的洞察力。但是，在密码货币中，几乎不是这样。通常，确认时间会很长。

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

即使我们有很好的延迟分布统计数据，系统和系统需求的变化也可能会随时间变化。如何比较竞争系统之间的延迟分布也未必明确。例如，考虑系统，确保交易的均匀分布延迟在1分钟到2分钟之间。平均和中值为90秒。如果一个竞争系统在1分钟内准确确认了95%的交易，在11分钟内确认了其他5%的交易(中值为60秒)，哪个系统好？答案是，一些APP应用程序可能喜欢前者，而一些APP应用程序可能喜欢后者。

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

延迟很复杂。报告的数据越多越好。理想情况下必须在不同的拥塞条件下测量完整的延迟分布。将延迟分解为不同的组件(本地、网络、批处理和一致延迟)也很有用。

吞吐量测量挑战

吞吐量乍一看也很简单。一个系统每秒能处理多少交易？出现了两个主要的困难：什么是“交易”，我们的系统今天做了什么，或者也许能做什么？

“

”每秒的事务数(tps )是衡量块链性能的实际标准，但事务作为衡量单位存在问题。在提供一般可编程性(“智能契约”)、比特币的多交易和多签名验证选项等有限功能的系统中，基本问题如下

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

这在以太体上显然是正确的。在以太网上，交易可以包括任意代码和任意修改状态。以太网的gas概念用于量化(和计费)交易的总工作量但是，这与EVM运行环境高度相关。没有简单的方法可以将一系列EVM交易完成的工作总量与使用BPF环境的一系列Solana交易进行比较。也有人担心将其中任何一个与比特币交易集团进行比较。

将交易层分为协议层和执行层的区块链可以更加明确这一点。 (在纯共识层中，吞吐量可以通过每单位时间添加到链中的字节数来测量。执行层比往常更复杂。

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

吞吐量的另一个挑战是超越通过经验性地测量当前性能来评估理论容量。这引入了各种用于评估潜在容量的建模问题。首先，您需要确定实际的运行级事务处理工作量。其次，实际系统几乎没有达到理论容量，特别是区块链系统。出于稳健性的理由中选择所需的族。我们希望在实践中实现异构、多样化，而不是所有客户端都只执行一个软件实现。这使得精确模拟块链吞吐量变得更加困难。

总体上：

吞吐量声明必须仔细说明事务的工作量和验证者的数量(他们的数量、实现和网络连接)。如果没有明确的标准，来自以太坊等热门网络的历史工作负载就足够了。

延迟-吞吐量权衡

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

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

交易费用

可以理解的是，最终用户关注延迟和费用之间的折衷，而不是延迟和吞吐量。用户没有直接的理由在意吞吐量，但是可以尽可能低的成本迅速地确认交易(有些用户在意费用)其他用户对延迟感兴趣)。一般来说，费用受多种因素的影响。

有多少市场需求在交易？

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

该系统为验证者或矿工提供了多少总收入？

这笔收入中有多少是基于交易费用和通货膨胀奖励？

前两个因素是通过市场价格的供需曲线(尽管矿工作为卡特尔声称会进一步提高费用)。其他条件相同时，更多的吞吐量应该会带来更低的成本，但还有很多事情要做。

特别是上述第三点和第四点是区块链系统设计的基本问题，但我们对它们缺乏良好的原则。我们从通货膨胀奖励和交易费用中对给予矿工收入的优缺点有了一点了解。然而，尽管对区块链协议进行了大量的经济分析，但还没有一种模式被广泛接受来确定验证者需要多少收入。今天，大多数系统都是建立在有根据的猜测基础上的。这意味着验证者有多少收入可以诚实行事，而不干扰系统的实际使用。简化的模型显示，发起51%攻击的成本与对验证者的报酬成比例。

提高攻击成本是件好事，但不知道有多少安全性是“足够的”。想象一下。你在考虑去两个游乐园。一方主张乘车维护所需费用比另一方少50%。去这个公园是个好主意吗？可能更有效率用更少的钱就能得到同等的安全性。另一个人的费用超过了保持玩具安全所需的费用，可能没有任何好处。但是，第一个公园可能很危险。区块链系统是相似的。考虑到吞吐量，低成本区块链成本较低因为验证者很少。今天没有好工具来评估这是否可能，或者系统是否容易受到攻击。总体而言，

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

结论

很难公平准确地评价性能。这也适用于测量车的性能。就像区块链一样对因人而异的事情感兴趣。对于汽车，一些用户关注最高速度和加速度，一些用户关注油耗，一些用户关注牵引能力。这些都不容易评价。例如，在美国，环保署就如何评估汽油的里程，以及必须如何为经销商用户提供详细的指引。

区块链区域距离这个标准化水平还有很长的路要走。在一些领域中选择所需的族。将来，可能会使用标准化的工作负载来评估系统吞吐量，或者评估用于显示延迟分布的标准化图表。目前，对评估人员和建设者最好的方法是尽可能多地收集和公开数据，详细说明评估方法