先明确“路由合约”是什么
区块链语境中的路由合约，通常负责接收用户调用，再根据规则把调用转发给其他合约。它可能是普通的业务入口，也可能采用代理模式，通过委托调用让多个地址共享实现逻辑。研究时不能把入口地址直接等同于完整业务代码：入口、实现合约、升级管理合约和外部依赖，可能分别承担不同职责。
因此，第一步应固定核验对象的网络、合约地址和区块范围，并记录该地址在目标区块的链上代码。若研究结论涉及“当前实现”，还要注明观察时点，因为可升级代理的实现地址可能发生变化。
源码验证与形式化验证不是一回事
源码验证主要回答一个可操作的问题：公开的源码与编译设置，能否重新生成与目标地址相匹配的字节码。编译器版本、优化器设置、源码文件、库地址以及构造参数等信息，都会影响结果。匹配说明公开源码对应于被部署的代码，但不等于代码逻辑一定正确、没有漏洞或符合项目宣传。
形式化验证关注的是代码是否满足预先定义的性质，属于另一类安全证据。因而，研究报告应分别记录“源码与字节码是否匹配”和“业务性质是否经过证明或测试”，不要用源码已验证替代安全审计、测试或权限分析。
核验完整性：不要只看Verified标签
常见验证流程是将源码和编译参数重新编译，再与链上部署字节码比较。某些验证服务还会检查合约元数据哈希。元数据包含源码文件及编译信息；只要源码内容或编译设置发生变化，元数据也会变化。元数据哈希能够为精确的源码与编译产物提供更强的对应证据。
如果服务只确认主要字节码匹配，却没有核对元数据哈希，应将结果记为部分匹配，而不是完整匹配。部分匹配仍有参考价值，但不能单独证明公开源码逐字节对应原始编译输入。研究记录中最好写明验证类型、验证平台、编译器版本、优化器配置和是否存在构造参数。
代理合约要沿着调用链核验
代理模式下，用户看到的入口地址可能只保存转发逻辑和实现地址。以ERC-1967相关模式为例，实现地址位于约定的存储槽；透明代理通常将管理和升级逻辑放在代理侧，而UUPS模式把升级能力放在实现合约中。Beacon模式则由独立的信标合约提供实现地址，多个代理可能共同受其影响。
核验时应分别取得代理地址的字节码、当前实现地址、实现地址的源码与字节码，以及管理者或升级授权地址。然后沿实际调用路径检查：用户调用是否进入代理，代理把请求转发到哪个实现，实现合约是否还能改变指向，升级操作由谁授权。只验证实现合约而没有验证代理配置，结论是不完整的。
还要关注初始化流程。代理通常依赖初始化函数设置管理员、权限和业务参数；若初始化未执行、权限设置错误，或升级后存储布局不兼容，公开源码的匹配并不能消除这些风险。对于克隆合约或工厂批量部署的实例，还应确认实例实际指向的实现地址，以及创建参数是否影响调用行为。
建立可复核的证据链
一份较稳妥的核验记录至少应包含：目标网络与地址、观察区块、链上代码或交易标识、源码验证状态、完整或部分匹配结果、编译器与优化器配置、代理类型、实现地址、升级管理者、关键存储槽，以及支持这些判断的链上读取结果。每项证据都应能由其他研究者独立复查。
对路由逻辑，还应结合ABI和交易调用进行静态与动态对照。例如，源码声明的入口函数、转发目标和权限检查，应与链上可观察的接口、事件和状态变化相互印证。事件只能作为行为线索，不能单独证明所有内部调用都按预期执行；反编译结果也只能辅助理解，不能替代匹配源码。
常见问题与适用边界
问：区块浏览器显示已验证，是否可以直接相信源码？答：不能。应确认验证是部分匹配还是包含元数据哈希的完整匹配，并进一步检查目标地址是否为代理，以及展示的源码对应代理还是实现。
问：实现合约已验证，是否代表路由合约安全？答：不代表。还需要核对实现地址来源、升级权限、初始化状态、存储布局和实际转发路径。源码匹配只能证明代码对应关系，不能证明业务设计没有缺陷。
问：这套方法适用于哪些合约？答：它适用于以太坊虚拟机兼容网络中的普通合约、代理、Beacon和部分克隆实例。不同网络、验证服务或特殊编译流程可能存在差异，遇到无法重现的字节码时，应保留失败信息并说明限制，而不是推断源码必然不一致。