先把“优质”拆成可核验的主张
“优质项目”是综合评价，不是区块链协议能够直接证明的属性。研究时应先区分：项目是否公开源码、公开源码是否对应部署代码、某笔交易是否被区块收录，以及业务是否符合预期。这些问题需要不同证据，不能用一个验证标签全部回答。
本文讨论适用于以太坊及相关EVM合约的源码核验，以及比特币交易记录的基础核验，不据此认定任何具体项目的质量。
源码核验：确认公开代码对应什么
以太坊开发者文档说明，源码验证通过编译源码并比对字节码，检查公开代码与链上部署代码的对应关系；结合编译元数据哈希的完整匹配，还能加强对源文件及编译设置一致性的确认。它与验证行为是否符合预期的形式化验证不同。
研究记录应明确网络、合约地址、源码版本和编译设置，并注明匹配范围。代码仓库只能证明存在公开代码，不能单独证明该代码就是指定地址执行的代码。即使匹配成立，仍需另行分析权限和业务逻辑，不能将其表述为“没有漏洞”。
交易核验：确认记录而非业务解释
比特币开发者指南说明，全节点按共识规则验证区块；默克尔证明可用于核验交易是否被某个区块收录。由于分叉时同一高度可能出现不同区块，区块高度不能作为全局唯一标识，应结合区块哈希定位。
核验交易证据时，应保留交易标识、区块哈希和所处链的上下文。收录证明回答的是记录归属问题，不能独立证明地址背后的现实身份，也不能证明一笔转移对应真实销售或实际用户需求。研究中的业务解释需要另外的证据。
让研究结论能够复核
每项结论都应对应明确对象、原始记录、核验方法和限制条件。引用源码验证结果时说明验证覆盖什么；引用交易时说明该记录支持什么事实。其他研究者应能沿着这些信息找到同一对象，而不是只能看到截图或宣传性摘要。
两个来源的作用在于提供不同问题的核验依据，并非数量足够就能证明项目可靠。上述两份技术文档分别解释代码对应关系和账本记录验证，均不构成对某个项目的背书。
常见问题：验证通过能说明多少
源码验证通过，是否代表合约安全？不能，它主要证明代码对应关系。交易确实上链，是否代表业务真实？不能，账本记录与业务解释需要分别核验。证据不足时，应将结论限定为“该技术主张尚未证实”，而不是直接判断整个项目可靠或不可靠。