先明确分层讨论的范围
区块链分层可以指系统内部的功能划分，也可以指基础链与扩容网络的协作。这里讨论后一种：交易在何处执行、由谁验证、数据放在哪里，以及结果如何得到基础链认可。层数本身不能说明安全性或效率，关键是各层之间的依赖条件。
安全性由哪些机制提供
以太坊扩容文档区分了依托主网安全性的二层方案与采用自身共识的侧链，并说明 Rollup、状态通道和 Validium 在证明及数据安排上存在区别。因此，与主网连接并不意味着所有方案拥有相同的安全保障。
评估分层协议时，应分别追问：谁能提交状态，谁能验证结果，错误如何处理？这些问题适合用于理解协议设计；判断具体实现还需要对应的技术说明，不能仅凭“二层”名称得出结论。
验证结果与取得数据要分别考虑
证明机制解决的是结果如何被验证，数据安排关系到参与者能否取得核验所需的信息。理解协议时，应把这两条路径分别梳理，检查它们是否依赖额外参与方。
常见问题是把“有证明”理解为其他条件都已满足。更完整的分析需要继续追问：所需数据由谁提供，无法获取时哪些操作会受影响，以及协议是否规定了处理方式。
快速响应与最终确认如何衔接
比特币开发者指南说明，全节点独立验证区块；出现竞争分支时，节点在有效链中依据累计工作量选择链，同一高度可能存在不同区块。这表明交易被记录后，还需要理解底层共识如何处理分支变化。
对于依赖基础链的上层协议，界面显示成功、上层接受交易和基础链完成相应确认，可能代表不同阶段。需要可靠结算的应用，应明确每个状态的含义，以及底层记录发生变化时如何同步处理。比特币的具体规则不能直接套用于其他链。
性能与适用条件一起评估
比较扩容能力时，应同时观察吞吐量、确认时间、费用和节点参与条件。单项指标无法覆盖完整使用过程：执行更快，并不自动说明最终结算也更快。
适用条件取决于应用需求。交互频繁的应用更关注响应速度，需要跨层结算的应用还要关注等待过程。常见误区是认为层数越多越好；每增加一层，都应说明它解决了什么问题，以及额外引入了哪些依赖和故障处理责任。