先把研究结论拆成可核对的问题
“项目已经验证”不是完整结论。应先区分：验证的是公开源码与部署代码的一致性，某笔交易是否被区块收录，还是合约行为是否符合预期？这些问题需要不同证据，不能用一个验证标记代替全部判断。
适用范围也要明确。以太坊合约源码验证与比特币区块结构分别回答特定技术问题，不能直接推广为所有区块链项目的可信证明。
源码验证证明的是一致性
以太坊开发者文档《Verifying smart contracts》说明，源码验证通过编译与比对，检查公开源码是否对应部署的字节码；结合元数据哈希的完整匹配，可以进一步核对源文件和编译信息。形式化验证则针对合约是否满足规定性质，二者含义不同。
核验此类证据时，应记录网络、合约地址、源码版本、编译设置及匹配类型。仅有“已开源”声明，尚不能建立公开代码与某个链上地址的对应关系；仅有验证成功的截图，也不足以交代验证对象与范围。
即使完整匹配，也不能据此认定代码不存在缺陷。变量名、注释和项目介绍表达的是说明或意图，不能替代对实际逻辑的判断。
链上记录证明什么，不证明什么
比特币开发者参考文档《Block Chain》说明，区块头包含前一区块头的哈希及交易构成的默克尔根。这些结构将区块与交易关联起来；修改相关交易会改变相应的哈希关系。
因此，核验交易记录时，需要明确交易标识、所属区块和对应网络。若要判断交易是否被某个区块收录，应检查对应的包含关系，而不是只看展示页面上的文字描述。
记录可以核对，不等于记录所描述的链外事实已经证实。例如，交易存在本身不能充分证明某项业务真实发生，也不能自动证明地址背后的现实身份。
让证据与结论逐项对应
整理证据时，可分别写下待核验主张、原始记录位置、核验条件、核验结果与尚未解决的问题。结论应限定在实际检查过的范围内，不把局部一致性扩大为整体可信度。
多个页面展示相同内容，不一定构成多份独立证据。技术文档用于解释验证原理，具体合约或交易记录用于核对具体对象；两类材料作用不同，不能相互替代。
常见问题与适用边界
源码验证是否等于安全审计？不等于。前者主要确认代码对应关系，不能单独支持“合约安全”的结论。形式化验证也应交代验证了哪些性质以及采用了哪些前提。
旧文档能否证明工具当前的能力？不能直接证明。工具功能、协议规则和界面标记可能随版本变化。引用技术资料时，应区分稳定原理与具有时效性的描述；缺少版本依据时，不宜断言某项服务目前只支持某种验证方式。