吞吐量、延迟与最终性
区块链技术的性能涉及哪些技术概念，首先要从三个指标理解。吞吐量表示单位时间内处理的交易数量，常用TPS描述；延迟表示交易从提交到某个确认阶段的等待时间；最终性描述交易结果在协议规则下确定的程度。比较性能时，必须说明统计的是接收、执行、入块还是最终确认。
吞吐量高不代表每笔交易等待时间短。批量处理可以增加处理量，却可能需要等待批次形成。不同交易的数据量和计算需求也不同，简单转账与复杂合约调用的TPS不能脱离测试条件直接比较。
区块容量、传播与共识
区块能容纳的交易负载、产生区块的节奏，以及节点传播和验证数据的能力，共同影响基础层性能。扩大容量会增加节点需要处理的数据；缩短出块间隔，则需要考虑网络传播是否跟得上。这些参数需要结合节点资源评估。
比特币开发者指南说明，全节点独立验证区块，发生竞争分支时按累计工作量选择有效链。这有助于理解确认深度与重组风险的关系。该机制适用于比特币式工作量证明分析，不能直接套用到所有共识协议。
执行、存储与验证
交易处理包括执行规则、检查可花费状态和验证数据等环节。判断瓶颈时，需要区分计算负担、状态访问和网络传输；单纯提高某一环节的速度，未必能提高整条处理流程的吞吐量。
默克尔树支持用较少的证明数据核验交易是否包含在区块中，适合解释轻量验证的效率。但包含证明不能单独证明整条链上的所有交易均合法，也不能替代完整的共识与有效性检查。
扩容与数据可用性
以太坊扩容文档区分基础层调整与链外处理。Rollup把执行移到基础层之外，并向基础层提交相关数据；乐观型方案通过争议机制处理错误，零知识型方案使用有效性证明。状态通道适合参与者之间的多次链外交互，侧链则采用自己的共识。
评估这些方案，需要问清执行在哪里完成、验证依赖什么，以及验证所需数据能否取得。有效性证明与数据可用性解决不同问题；数据放在不同位置，会改变系统依赖的条件，不能仅凭处理速度认定安全属性相同。
常见问题与适用条件
手续费低是否代表性能高？费用还受需求和资源定价影响，不能单独作为性能指标。节点配置越高是否越好？更高配置可能提升处理能力，也可能提高独立运行节点的门槛。
比较方案时，应统一交易类型、负载、确认标准和节点条件，再观察吞吐量、延迟、费用与资源消耗。对需要快速反馈的应用，还应区分初步响应与最终结算，避免把两个阶段混为一谈。