先明确要核验的主张
“高效”可能指交易吞吐量更高、确认等待更短、费用更低，或验证所需资源更少。这些目标需要分别核验，不能用一个速度数字代替全部结论。阅读技术介绍时，应先把主张拆成具体问题：优化了哪个环节，在什么条件下成立，是否增加了其他成本或信任前提。
确认来源身份与证据范围
以太坊扩容文档讨论链上与链下扩容，并强调吞吐量、速度、安全和去中心化之间的关系。它可以支持扩容概念及分类解释，但不能单独证明某个具体网络的实际性能。参考地址：https://ethereum.org/developers/docs/scaling/。
比特币开发者指南解释独立节点验证、工作量证明和默克尔树等机制。其中，默克尔树支持检查交易是否被纳入某个区块；这一检查的范围与完整交易验证不同。参考地址：https://developer.bitcoin.org/devguide/block_chain.html。
两处文档属于不同来源，但讨论对象不同。它们可以分别支撑相关基础概念，不能因为引用了两个网站，就声称某项性能结论得到交叉证实。核验同一主张，需要寻找直接讨论该主张的独立证据。
检查正文是否完整、版本是否对应
自动提取的网页可能丢失公式、链接文字或段落结尾。若证明机制的名称缺失，或论证在句中截断，应回到完整页面核对，不能自行补全后当作原文依据。
还应记录文档版本、更新时间和对应实现。路线图、设计方案与已经部署的功能具有不同证据意义；没有版本信息时，应限制结论范围，不据此判断当前运行状态。
性能数字必须附带适用条件
吞吐量主张需要说明交易类型、测试环境、统计时段和计数方式。等待时间则应区分收到交易、初步确认与最终确定等环节。缺少这些条件，数字即使准确，也可能不适合横向比较。
安全条件同样影响效率结论。以太坊扩容文档区分了不同方案的数据存放与安全机制，因此“连接主网”不足以证明所有方案具有相同保障。核验时应进一步检查数据可用性、证明机制及运营者权限，而不是只看技术名称。
常见问题：可靠来源是否足以定论
权威文档适合确认机制定义，但具体实现是否达到宣传效果，仍需要对应版本的实现说明、测试方法和可复核结果。设计目标不能直接视为实测表现。
多篇文章重复同一数字，也不一定构成多个独立证据。应追溯它们是否来自同一公告或测试报告。证据不足时，可以保留有依据的机制解释，并明确性能结论尚缺哪些条件，避免把一般原理扩大为具体项目的已证实成果。