先把安全主张变成可核验的问题
讨论时，可将内生安全限定为协议自身规则提供的安全约束，例如交易有效性检查、共识选择和违规惩罚。核验首先要明确研究声称保护什么：交易授权、历史记录一致性，还是网络持续完成确认的能力。不同目标需要不同证据，不能用一个笼统的“安全”概括。
两个来源分别能支持什么
ethereum.org的权益证明攻防说明区分了链重组、冲突最终确定和最终确定延迟，并讨论信息扣留、选择性发布等攻击。它支持的认识是：攻击结果与攻击者能力、消息传播条件及共识规则有关，经济惩罚也有特定适用对象。
Bitcoin开发者指南说明，全节点独立验证区块，哈希链接关联历史记录，工作量证明为修改历史增加成本；在有效分支之间，节点依据累计工作量选择链。这些机制分别涉及有效性、数据关联和分支选择，不能合并解释为绝对不可篡改。
沿着证据链核对研究结论
机制说明可以解释设计意图；核验研究结论还需要追溯原始论文、对应协议规范与实现版本。记录结论所在位置、适用条件和支持它的证明或实验，才能判断转述是否遗漏限制。两个独立网站介绍不同协议，并不构成对同一研究结论的交叉验证。
理论结论应检查模型、假设和推导范围；实验结论应检查代码、配置、输入与结果是否足以复核。若只能找到概述，结论应停留在机制层面，不能升级为具体实现已获验证。
适用条件要与结果一起核对
攻击者控制的权益或算力比例只是条件之一，还应核对其能否延迟消息、影响节点视图，以及研究采用何种网络假设。涉及攻击门槛的数字，必须同时说明攻击目标和协议版本；改变条件后，原结论未必继续成立。
历史攻击研究还需要与后续规则变化对应。旧版本中的攻击结果既不能直接证明当前实现仍然脆弱，也不能仅凭出现防御设计就认定问题已解决。
常见问题与证据缺口
哈希校验通过是否代表整条链安全？它只能支持相应数据关系的核验，仍需检查交易有效性与共识选择。存在罚没机制是否代表攻击不会发生？惩罚约束与攻击能否发生是不同问题。
核验记录可按“主张、来源、版本、假设、验证方法、局限”逐项整理。缺少复现材料、版本对应或原始论证时，应明确标注证据不足，避免把一般原理写成某个具体项目已经证实的安全保证。