基础结构：哈希、默克尔树与共识
讨论改良方案，首先要理解账本如何验证。比特币开发者指南介绍了哈希连接区块、默克尔树组织交易、UTXO记录未花费输出，以及工作量证明和共识规则维护账本一致性的机制。默克尔路径能够帮助验证交易是否被某个区块收录。
这些概念分别回答不同问题：数据是否改变、交易是否收录、输出是否已花费，以及节点认可哪条有效链。改良其中一个环节，不能自动替代其他环节的验证。例如，证明交易被收录，并不等于独立完成该交易的全部有效性检查。
扩容分类：链上改动与链下处理
以太坊扩容文档区分链上扩容与链下扩容：前者涉及基础协议调整，后者将部分处理移至主网之外。Rollup在链下执行并向主网发布数据；状态通道让参与者在链下交互后结算；侧链使用自身共识；Validium采用有效性证明，但数据保存在主网之外。
选择方案时，需要先定位瓶颈。如果限制来自执行计算，应考察计算如何分担；如果主要成本来自数据发布，则应关注数据组织和存储方式。仅用“链下”归类，无法说明方案继承了哪些主网安全保障。
证明机制与数据可用性
乐观式Rollup通过挑战及欺诈证明处理错误结果；零知识Rollup通过有效性证明验证计算结果。两者都涉及验证，但验证路径和依赖条件不同。
数据可用性关心验证或恢复状态所需的数据能否取得。计算结果有证明，与相关数据能够获取，是两个需要分别检查的问题。理解分片、面向Rollup的数据扩容等概念时，也应分清方案分担的是执行任务、数据负担，还是验证工作。
适用条件：性能指标需要一起看
状态通道适合参与者之间反复进行链下交互、最终结算的场景；Rollup适合将多笔操作汇总后利用主网验证与结算的场景。采用侧链时，则需要单独理解其共识和跨链连接的安全条件。
吞吐量表示单位时间内的处理能力，确认延迟表示等待结果的时间，最终性涉及结果被确定的程度。界面快速显示成功，不能直接等同于主网最终结算。评价改良效果还应考虑节点的带宽、存储和计算负担，因为参与门槛关系到去中心化。
常见问题：扩容是否必然更安全、更便宜
扩容可以分摊部分处理与数据成本，但实际费用还取决于资源需求和方案设计，不能理解为固定费用保证。
链下方案也不都属于同一种安全模型。判断技术改良是否成立，应明确由谁执行、谁验证、数据在哪里，以及发生争议时如何解决；这些条件比单独比较速度更能解释方案的适用边界。