扩容目标不能只有速度
区块链扩容需要注意哪些问题，首先要从目标说起：吞吐量表示一定时间内能处理多少交易，确认延迟表示交易需要等待多久，两者不能混为一谈。评估时应明确，是缓解高峰拥堵、降低处理成本，还是缩短应用等待时间。
以太坊扩容文档强调，提高容量不应牺牲安全和去中心化，并区分修改主网协议的链上扩容与在主网之外处理交易的方案。由此可见，扩容不是单一参数调整，而是处理效率与验证条件的共同设计。
节点能否继续独立验证
比特币开发者指南说明，全节点依据共识规则独立验证区块；出现竞争分支时，节点在有效链中依据累计工作量选择链。交易进入某个区块，并不意味着后续绝无重组可能。
因此，评估扩大区块容量等方案，不能只看容纳了多少交易，还应检查传播、存储和验证负担。适用条件是节点能够承担新增资源需求；如果独立验证变得难以参与，就需要重新衡量容量提升的代价。
识别安全来源与数据条件
以太坊扩容文档区分了不同安全机制：Rollup将执行移到链外并向主网发布数据；侧链采用自己的共识；Validium使用有效性证明，但数据不存放在主网。它们不能因为都在主网之外运行，就被视为具有相同保障。
实际评估需要分别回答：谁验证执行结果，验证所需的数据在哪里，发生争议时依靠什么规则解决。证明结果正确与确保数据可获得，是两个不同问题，不能用其中一个替代另一个。
把正常运行与故障处理一起评估
扩容方案适不适合应用，还取决于交互模式。参与者之间反复发生交互，可考察状态通道是否匹配；需要共享执行环境的应用，则需比较不同链外执行方案的能力与限制。
评估还应覆盖异常情况：运营节点停止服务后，交易能否继续提交；结算需要满足哪些条件；用户是否依赖额外参与方。这些应作为核查问题，而不能仅凭方案名称假定已有可靠答案。
常见问题：更快、更便宜是否就更好
不一定。快速返回处理结果，不等于已经完成主网结算；单次执行费用较低，也不等于完整使用过程成本更低。比较方案时，应统一交易类型、负载和确认标准。
扩容的合理判断标准，是在明确安全假设与资源约束后，能否持续满足应用需求。不同区块链的共识机制不同，不能直接把某条链的确认规则或扩容效果套用到另一条链。