先界定研究对象：主链扩容还是链下扩容
“扩容”不是单一技术名称。核验一项方案前，应先问它是否改变主链协议，还是在主链之外处理交易。以太坊扩容概览将链上扩容与链下扩容区分开来，并说明许多扩容方案采用链下处理、再与主网交互的方式。两类方案的证据不能直接互换：链上方案需要关注协议规则和节点验证，链下方案则要说明交易如何结算，以及安全性从哪里来。
链下路线也不等于同一种安全模型。概览材料指出，Rollup将执行放在链外，并把交易数据或有效性相关信息提交到主链；侧链则使用自己的共识规则；Validium的数据不存储在以太坊主链上。核验时应把方案名称拆成具体机制，确认数据存放位置、状态如何更新、争议如何处理，以及主链在其中承担什么作用。
把扩容主张转成可检验指标
一项扩容主张通常涉及交易吞吐、确认速度或最终确定时间，也可能涉及网络拥堵和使用成本。以太坊扩容概览将提高速度与吞吐、同时不牺牲安全性和去中心化列为扩容目标。阅读研究结论时，应检查它实际测量了哪些指标，而不是把“更快”或“容量更大”当作不需定义的结论。
可复核的比较还应交代测试条件：测的是单笔交易、持续负载还是峰值；采用什么交易类型和配置；结果对应实验环境还是实际运行网络。不同条件下的数字不能直接排名。若研究只报告吞吐提升，却没有说明确认和结算过程、节点参与要求或安全假设，就不足以单独证明整体扩容效果。
核对安全假设与主链依赖
扩容性能必须和安全机制一起审查。对Rollup，应检查其提交到主链的信息、有效性证明或挑战机制如何工作；对依赖独立共识的链，则不能仅凭它与主链连接，就推断其安全性由主链完整保障。研究结论应明确适用的技术类型和信任假设，不能把一种方案的性质推广到所有链下系统。
比特币开发者指南提供了另一种核验主链规则的视角：全节点独立保存并验证区块链，并依据共识规则判断区块有效；区块通过前序区块哈希相连，交易还可通过默克尔树相关信息验证其包含关系。这些机制说明，评估主链变更时应关注节点实际执行的规则及其验证路径。不过，比特币的区块链机制本身并不能证明某个以太坊扩容方案有效，适合用来理解验证概念，而非替代针对具体方案的证据。
区分设计、测试与实际运行证据
研究材料中的设计说明回答的是“方案打算怎样工作”，测试结果回答的是“在给定环境下测得什么”，而实际网络证据才涉及部署后的运行情况。核验时可以逐层追问：规则是否写明，节点或相关组件是否按规则实现，测试是否可重复，实际链上记录是否与所述流程相符。单有路线图、概念说明或一次测试结果，不宜写成已经证明持续改善了主链表现。
对主链升级，还要确认测量对象确实包含协议或共识层面的变化；对链下方案，则应分别检查链下执行和主链结算。比特币指南关于分叉的说明也提醒读者，区块高度相同不必然代表同一个区块，区块头哈希可用于区分区块。因此，在引用链上观察结果时，应明确识别对象和观察范围，避免只凭一个容易混淆的标签作判断。
交叉核对来源，并说明结论边界
不同来源可能分别解释目标、协议机制或验证方法，不能因为它们谈论“扩容”就视为相互印证。以太坊扩容概览有助于区分扩容路线及其安全模型；比特币开发者指南则说明区块、共识规则和链上验证的基本关系。两者适合支持概念辨析，但不构成某一具体方案的性能评测。要支撑具体效果结论，还需要与该方案直接相关、方法和适用范围清楚的技术证据。
归纳结论时，写清楚“对哪种方案、在哪些条件下、支持什么主张”，并把尚未验证的部分单独标出。若来源只描述目标，就称为目标；若结果只来自特定测试条件，就限定结论的适用范围。这样的写法比把不同技术路线的指标拼成一个排名更可靠。
常见问题：一个性能数字够不够？
不够。吞吐或速度数据需要与测试条件、结算方式、安全假设和去中心化影响一并阅读。特别是链下执行可能改变交易处理位置，却不必然意味着主链本身处理能力发生了相同幅度的变化。应先确认数字衡量的是主链、链下系统，还是二者组合。
适用范围也要写清：评价主链协议升级时，重点是规则变更及节点验证；评价Rollup等链下方案时，重点还包括其与主链的数据和安全关系。材料不足以回答这些问题时，应把结论限定为“机制说明”或“特定条件下的测试观察”，而不是推广成所有区块链或所有扩容路线都成立的事实。