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

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

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

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

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

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

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

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

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

　　测量吞吐量的挑战

　　吞吐量乍一看似乎也很简单：一个系统每秒可以处理多少交易？出现了两个主要困难：究竟什么是“交易”，我们是在衡量一个系统今天做了什么，或者它可能能够做什么？ (责任编辑：admin)