基础概念：账本如何被验证
区块链的规模应用涉及哪些技术概念，可以从“如何验证记录”和“如何承载更多操作”两个问题展开。前者决定系统的可信基础，后者涉及计算、存储与通信负担的分配。
比特币开发者文档说明了哈希链接、默克尔树和节点独立验证：区块通过前一区块的哈希形成关联，默克尔树支持交易包含性验证，共识规则约束节点接受哪些记录。比特币还通过未花费交易输出检查支出，并用工作量证明参与确定交易历史。
这些机制承担不同职责。证明一笔交易被某个区块收录，不等于证明它符合全部交易规则；理解这一点，有助于区分轻量验证与完整验证的能力边界。
性能指标：吞吐量与确认时间
吞吐量描述单位时间内能处理多少交易，确认时间描述交易达到相应确认状态所需的等待。二者不能互相替代：一次处理更多交易，并不必然意味着每笔交易更快获得可靠确认。
规模应用还需要关注费用与节点负担。评价一种扩容设计时，应说明交易复杂度、确认标准和验证资源需求，否则不同系统的性能数字缺乏可比性。
扩容路径：链上、链下与二层
以太坊扩容文档区分了修改基础协议的链上扩容和在主网之外处理操作的链下扩容。其中，Layer 2强调通过主网获得安全保障。Rollup在链下执行交易，并向基础层提交数据；乐观型依靠挑战机制处理争议，零知识型提交有效性证明。
分层设计需要回答三个具体问题：谁执行操作，谁验证结果，出现争议时由谁裁决。链下执行本身并不能完整说明安全性，还要看结果如何与基础层关联。
适用条件：数据与参与方式
状态通道适合参与者之间反复进行链下交互，再向主网结算；侧链使用自身共识；Validium使用有效性证明，但数据保存在基础层之外。不同方案对参与方式、数据获取和安全机制的要求各不相同。
数据可用性关注验证或恢复状态所需的数据是否能够取得。结果证明和数据可用性回答的是不同问题，因此不能只看证明形式，也要了解数据由谁保存、参与者如何获取。
常见问题：扩容是否只需增加容量
增加容量会不会自动解决规模应用问题？还需考虑新增负担由谁承担，以及普通节点能否继续参与验证。处理能力与参与门槛应一起评估。
所有链下方案都属于Layer 2吗？按上述安全定义，不能仅凭“在主网之外运行”作判断。适用范围也需区分：比特币的交易验证机制与以太坊的扩容分类分别说明不同系统的设计，不能直接视为所有区块链共有的实现。