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

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

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

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

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

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

　　整体上：

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

　　延迟-吞吐量权衡

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

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

　　交易费用

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