先明确分层的适用范围
这里讨论基础链与链外扩容协议之间的分工。评估分层设计，首先要说明交易在哪里执行、结果由谁检查、争议在哪里解决，以及哪些数据需要公开。这些职责决定了上层服务能够获得什么保障。
以太坊扩容文档区分依赖主网安全的二层方案与采用其他安全安排的链外方案，并介绍了Rollup、状态通道、侧链和Validium。链外执行或连接主网，本身不足以说明各方案具有相同的安全条件。
安全边界与数据可用性
需要分别检查执行正确性与数据可用性：前者关注状态变化是否符合规则，后者关注验证和恢复状态所需的数据能否取得。评估时应说明数据由谁发布、存放何处，以及数据缺失会影响哪些功能。
按照以太坊扩容文档的分类，Rollup向基础链发布数据，Validium将数据放在链外；侧链采用自身的共识规则。因此，比较这些方案时，要分别审视证明机制、数据依赖和共识依赖，不能仅凭名称判断保障强弱。
区分响应速度与最终确认
比特币开发者指南说明，全节点独立验证区块；发生分叉时，有效分支之间依据累计工作量选择链，区块高度也不能作为全局唯一标识。这表明，上层协议必须理解底层的验证与分叉处理规则。
在分层系统中，应明确交易已接收、已执行和已结算分别代表什么。适合即时展示的状态，未必满足后续不可撤销操作的确认要求。涉及区块引用时，也需要考虑分叉后原引用是否仍然有效。
性能指标要带上成立条件
吞吐量、延迟与费用应结合交易类型和运行条件理解。协议评估应覆盖执行、数据发布和底层结算等环节，说明性能瓶颈可能出现在哪里。
节点运行所需的硬件、带宽和维护能力也会影响参与门槛。若一项设计提高处理能力，同时增加独立验证的难度，就需要把两方面影响一起解释。
常见问题与适用条件
连接主网是否就继承主网安全？需要检查主网实际验证了什么，以及哪些环节仍依赖外部参与者。具有相同接口或能够跨链通信，也不能直接证明安全模型相同。
是否存在适合所有业务的分层方案？应先明确业务是否需要通用计算、参与者范围如何、能够接受多长的结算等待，再评估对应协议。接口设计还应明确失败、延迟和状态变化时的处理规则，避免应用把暂时状态当作最终结果。