先把研究结论拆成具体问题
“协议很安全”不是足够明确的核验对象。应先问：研究讨论的是区块有效性、分叉选择，还是历史交易被改写的可能性？再记录涉及的协议、机制、版本和前提。不同问题需要不同证据，不能用一段共识机制介绍同时证明实现正确、攻击不可行和网络运行稳定。
两个来源分别能证明什么
以太坊开发者共识机制文档说明，共识包含协议、激励与分叉选择等部分，不能仅用工作量证明或权益证明概括全部机制；其权益证明分叉选择涉及按质押余额加权的投票。该来源适合核对机制构成，不足以单独证明所有攻击情境下的安全性。
比特币开发者区块链指南说明，全节点独立验证区块；在有效分支之间，链选择看累计工作量，而不是只数区块。指南也指出，低于半数算力不代表完全没有改写历史的机会。这些内容适合核对验证与链选择规则。
这两个来源描述不同协议，可以帮助辨别概念差异，但不能当作对同一项目安全结论的两次独立验证。来源数量不能替代命题匹配。
重点检查数字背后的口径
遇到“达到某个比例就形成共识”，应检查分母是节点数量、算力还是质押权重，并确认所指过程是链头选择还是最终性。不能把概述中的节点比例直接解释成按机器数量投票。
遇到“多数算力才能攻击”，则应区分攻击成功概率与持续、可靠地改写历史的能力。核验时需要保留攻击目标和条件，不能把门槛压缩成低于它绝对安全、高于它任何规则都能突破。
让证据强度与结论相称
概念文档主要回答机制如何运作；具体协议规则还需对应版本的规范与实现；实验结果则需要说明配置、输入、测量方法及复现条件。说明性文字不能替代代码核验，单次实验也不能自动推广为所有网络条件下的保证。
整理研究时，可为每条结论保留原文位置、适用范围与未解决问题。材料若有截断、术语简化或缺少版本信息，应缩小结论范围，而不是自行补足缺失证据。
常见问题与适用范围
官方文档是否足够？用于理解基础规则通常有帮助，但涉及实现行为或量化安全结论时，还需相应证据。两个文档表述不同是否意味着冲突？应先排除协议、版本和讨论层次不同。
这套方法适用于技术文章、协议说明和研究报告的初步审读。最终判断应区分“机制已有说明”“规则已核对”和“安全结论仍待验证”，避免将通用原理写成某个具体项目已经得到证明的结果。