延迟与吞吐量

　　传统上，区块链系统性能通过延迟和吞吐量两个维度进行评估：延迟衡量单个交易可以多快得到确认，而吞吐量衡量交易随时间的总速率。这些轴适用于第 1 层和第 2 层系统，以及许多其他类型的计算机系统（例如数据库查询引擎和 Web 服务器）。

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

　　测量延迟的挑战

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

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

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

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

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

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

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

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

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