第一问：来源能否追溯，属于哪类证据？
核验首先要明确主张：讨论的是账本记录遭到修改、合约逻辑存在漏洞，还是管理员权限被滥用？这些问题对应不同证据，不能用一句“区块链安全”统一回答。
NIST IR 8202《Blockchain Technology Overview》的摘要将区块链描述为具有篡改可察觉性和抗篡改能力的分布式账本，并将已发布交易不可更改的描述限定于网络正常运行条件下。其定位是高层次技术概述，适合解释机制，不足以证明某个应用安全。
来源核验应对应标题、作者、发布机构、版本及原文位置。官方出处有助于确认文献身份，但结论仍需接受方法和适用范围的检查；多个网页转述同一报告，也不能算多份独立研究。
第二问：方法与结果是否足以支持主张？
Ethereum.org的智能合约安全指南讨论访问控制、测试和独立审查，并提醒单元测试与审计都有局限。这类指南能够说明应检查哪些风险，却不能直接提供某个项目的漏洞发生率或安全评级。
面对具体研究，应检查研究对象、代码版本、测试环境、输入范围和判定标准。声称发现漏洞，需要说明触发条件及可复核的结果；声称某项措施降低风险，需要交代比较对象和评价指标。缺少这些信息时，结论的支持程度有限。
形式化验证也需要检查证明了什么。它针对明确规格、模型和假设下的性质提供证明；未纳入规格的业务要求、外部依赖和运行条件，不能自动获得同等保证。
第三问：结论能否用于目标系统？
应用结论前，应核对网络机制、合约实现、权限配置与研究假设是否一致。账本抗篡改讨论记录层面的性质，无法单独回答敏感函数是否允许未授权调用；两者需要分别核验。
对审计报告，应检查审查范围、对应代码版本、问题状态和修复复核记录。如果部署代码或权限配置后来改变，原报告是否仍然适用，需要重新判断。
常见问题：两份来源和一次审计够不够？
两个独立发布渠道不一定构成对同一结论的交叉验证。技术概述与开发指南可以互补，但若要确认具体漏洞，还需要与该漏洞直接相关的证据。
“没有发现漏洞”应保留检查范围与条件，不能改写成“不存在漏洞”。记录核验结果时，把原始主张、证据位置、适用条件和未解决问题一起写清楚，读者才能区分已获支持的结论与仍待验证的判断。