先把研究结论拆成可核验的问题
区块链借贷合约的研究证据怎么核验，关键是让每项结论都有对应的证据。声称“公开源码对应链上合约”，需要编译匹配记录；声称“某项操作仅管理员可执行”，需要函数的权限检查与角色信息。两类证据回答不同问题，不能相互替代。
以下方法适用于以太坊及相关EVM合约的源码核验，以及采用相应访问控制机制的合约。通用文档解释机制，具体借贷合约是否正确采用这些机制，仍须逐项核实。
确认源码与链上代码的对应关系
ethereum.org的合约验证文档说明，源码验证通过重新编译和字节码比对确认对应关系；形式化验证关注合约是否满足预期性质。包含元数据哈希匹配的完整验证，还能更严格地确认源文件与编译信息的一致性。
研究记录应明确网络、合约地址、源文件、编译器版本和编译设置，并保留匹配结果。构造参数、库链接和不可变量等因素可能影响核验，不能把简单字符串比较直接当作完整验证。引用验证标记时，也应说明匹配范围。
把权限声明落实到函数和角色
OpenZeppelin的访问控制文档说明，Ownable提供单一所有者机制，AccessControl提供角色机制；角色可被授予或撤销，并由相应管理角色控制。默认管理角色还能管理自身。
核验借贷合约权限时，应从所研究的具体函数出发，检查调用限制，再确认谁持有权限、谁能改变权限。仅看到合约引用了访问控制库，无法证明每个关键入口都受到限制；角色名称和注释也不能代替实际检查逻辑。
区分机制证据与实例证据
文档可以解释某个接口的设计含义，部署合约的代码和状态才能支撑实例结论。例如，“此机制允许撤销角色”与“某地址的角色已被撤销”是不同判断。后者需要对应的状态或事件证据，并注明观察范围。
可将研究记录组织为“结论、证据位置、核验方法、适用条件、未确认事项”。缺少权限持有人信息时，就保留这一缺口，不把标准库的设计能力写成目标合约已经具备的事实。
常见问题：验证通过是否等于安全
不等于。源码匹配支持的是代码对应关系，无法单独证明借贷计算、访问限制或其他业务逻辑正确。完整匹配也不会自动扩大为安全保证。
两个独立来源分别解释源码验证与权限机制，有助于建立核验框架，但它们并未共同证明某个借贷项目安全。研究结论应止于实际取得的实例证据，明确哪些已经确认，哪些仍待验证。