吞吐量高，是否就意味着确认快
高性能区块链通常关注单位时间处理多少交易，以及交易结果多久能够稳定确认。这两个指标回答不同问题：前者衡量容量，后者关系到应用何时可以依赖处理结果。理解性能描述时，需要明确“完成”指收到请求、执行交易，还是完成结算。
以太坊扩容文档将提高吞吐量、加快最终确认与保持安全和去中心化共同列为目标，并指出拥堵可能推高费用。由此可见，单个速度指标不足以说明系统在繁忙时的整体表现。
为什么交易进入区块后仍有确认问题
比特币开发文档说明，节点独立验证区块，同时产生的区块可能形成临时分支；在有效分支中，节点依据累计工作量选择链。这说明，对采用此类机制的系统，进入一个区块与交易记录进一步稳定之间存在区别。
应用需要依据所用链的共识机制定义确认条件。页面显示成功、节点接收交易和业务允许后续操作，应有清晰的对应关系。比特币的分支选择规则具有特定适用范围，不能直接套用于所有高性能链。
扩容会不会提高节点参与门槛
性能评估还要考虑谁能够运行节点、谁能够独立验证结果。如果某种容量提升需要更高的计算、存储或网络资源，就应同时审视参与门槛，而不能只记录处理速度。对于强调公开验证的系统，节点参与条件本身就是技术评价的一部分。
链下处理是否具有相同安全保障
以太坊扩容文档区分了不同安全路径：Rollup在链外执行并向主链提交数据；侧链采用自身共识；Validium使用有效性证明，但数据不保存在主链上。状态通道则允许参与者链下交互，再向主链结算。
因此，评估链下方案时需要分别追问：执行结果如何验证，验证所需数据在哪里，最终由什么机制解决争议。连接主链本身不足以回答这些问题，具体实现的安全条件仍需单独分析。
不同应用应关注哪些问题
交互频繁的应用需要关注响应时间，依赖最终结算的业务需要关注确认条件，参与者之间反复交互的场景可以理解状态通道的适用方式。费用评估也应明确是否包含主链结算环节。
常见误区是把一种场景下的性能结论推广到所有业务。更清楚的技术说明应交代交易类型、负载条件、完成标准以及验证责任，使“高性能”对应可理解的能力和边界。