适用范围与证据起点
本文讨论以太坊及兼容 EVM 网络上的通用核验方法，不对任何具体路由项目作安全判断。路由只是功能描述，不能据此推定合约采用哪种代理、是否可升级或具有何种权限。
研究证据应先固定网络、合约地址和观察区块，再记录结论对应的函数、代码版本与链上状态。缺少这些定位信息，即使展示了源码，也难以确认研究对象是否与实际部署一致。
源码验证证明什么
ethereum.org 的合约验证说明区分了源码验证与形式化验证：前者关注源码编译结果是否对应部署字节码，后者关注行为是否满足预期规范。包含元数据哈希的完整匹配，还能加强对源文件与编译信息一致性的确认。
核验记录应保留源文件、编译器版本、优化设置及匹配结果，并说明库链接、构造参数和不可变变量等因素的处理方式。不能把创建字节码与运行时字节码直接混为一谈，也不能把“已验证”标签解释为没有漏洞。
代理关系决定核验对象
OpenZeppelin 的代理文档说明，不同代理的升级机制位置不同：透明代理在代理侧包含升级与管理逻辑，UUPS 将升级机制放在实现侧，信标代理通过信标取得实现地址。因此，入口地址的代码不一定就是全部业务逻辑。
针对采用代理的路由合约，证据需要覆盖观察区块对应的实现地址、实现源码及升级授权机制；涉及信标时，还要追踪信标。只验证代理外壳，不能支持对其实际路由行为的完整判断。
把研究结论拆成可复核命题
“源码匹配”“某函数存在权限限制”“实现可以被替换”是不同命题，应分别列出依据。源码匹配依赖编译比对；权限结论需要查看实际执行路径和相关状态；升级能力则需要结合代理类型与授权逻辑。
研究若声称路由始终符合某项约束，应说明检查覆盖哪些入口、实现及外部依赖。对代码的局部观察不能自动推广为系统整体结论，有限测试也不能替代对所有可能行为的证明。
常见问题与结论边界
完整匹配是否等于安全？不是，它加强的是源码身份确认，不保证逻辑正确。部分匹配是否必然意味着恶意？也不是，应明确未匹配内容及其影响，避免把证据缺口直接写成漏洞。
入口地址不变，旧研究是否一直有效？不一定。代理实现或相关配置变化后，原有结论可能不再适用。可靠的研究应保留证据快照、适用区块与未核验事项，让读者区分已确认事实、条件性判断和待验证问题。