Page 53 - 《软件学报》2026年第1期

50 软件学报 2026 年第 37 卷第 1 期

安全漏洞和常见错误. 例如, 许多 DeFi 协议使用 OpenZeppelin 升级合约来更新和改进功能, DAO 将其用于升级新
的治理规则和决策.
类似的工具例如 Foundry [93] , 它由 Paradigm 开发, 用于以太坊智能合约开发的高效、模块化和安全的框架.
Foundry 提供两个主要开发组件: Forge 和 Cast. Forge 用于编写和测试合约的工具, 而 Cast 是用于与以太坊网络交
互的命令行工具. 此外 Foundry 也能够提供详细的 Gas 消耗报告, 帮助开发者识别和优化高 Gas 消耗的操作. 虽然
正在快速发展, 但相比于更成熟的框架如 Truffle 和 Hardhat. Foundry 的社区和文档资源相对较少. 对于没有使用
过该框架的开发者来说, 可能需要一些时间来适应 Foundry 的工具链和工作流程.
2020 年, Angelo 等人 [94] 提出一种通过对大量智能合约进行分类, 使用差分代码的方式来支持智能合约链下升
级的方法. 同年, Shao 等人 [95] 开发一个智能合约漏洞监控框架, 该框架将日志异常分析方法引入区块链日志系统,
并将检测结果传输到相关合约, 最后实现智能合约链下升级的提示. Jean-Louis 等人 [29] 提出基于可信执行环境的
智能合约修复区块链架构 SGXonerated, 讨论访问模式泄露、软件升级机制和状态一致性等问题, 并介绍基于可
信执行环境的智能合约安全平台, 包括秘密网络 (secret network)、Oasis、Phala 和 Obscuro 等.
3.2 链上升级框架
链上升级通常指的是在区块链上直接对智能合约进行升级. 这种方式需要在合约代码中实现升级机制, 允许
合约逻辑在保持合约地址和状态不变的情况下进行更新. 链上升级的常见实现方式是使用代理模式, 其中代理合
约负责存储状态和转发调用, 而实现合约包含实际的业务逻辑. 当需要升级时, 只需更新代理合约中指向实现合约
的引用地址即可. 这种方式的优点是用户无需知道合约已经升级, 因为他们总是与代理合约交互. 缺点是实现相对
复杂, 并且如果代理模式使用不当, 可能会引入安全风险, 如函数选择冲突等问题. 如图 19 所示, 传统的 3 层智能
合约模型包括接口层、业务层、数据层. 其中数据层不能升级, 同时也忽略合约链上升级的安全性.

合约验证 业务合约 1
...
代理合约
业务合约 n
业务合约 1−n
合约签订 合约拆分
存储合约 版本管理协议
记录

链下合约检测 链上合约认证 升级合约
图 19 智能合约部署架构和链下数据流程

1) 接口层 (interface layer): 通常由代理合约实现, 作为与用户或其他合约直接交互的接口, 定义包括函数的声
明和用户可以调用的方法.
2) 业务层 (business logic layer): 包含合约的核心业务逻辑, 放置在一个或多个独立的实现合约中. 当需要升级
时, 只需替换或更新这些实现合约, 而不需要改变接口层.
3) 数据层 (data layer): 数据层通常由代理合约实现, 它保存实现合约的地址和合约的状态变量.
当需要升级智能合约时, 通常会部署一个新的实现合约, 并通过接口层的代理合约更新对实现合约的引用, 而
不需要改变接口层或数据层. 接口层将调用转发到业务层的实现合约, 实现合约包含实际执行的代码. 数据层存储
合约的状态 (如账户余额、所有权信息等), 这些状态信息由代理合约管理. 因此用户通过同一个接口层与合约交
互, 无需知道背后发生升级, 而合约的业务逻辑已经更新.
2021 年, Liu 等人 [96] 提出一个智能合约访问控制服务框架, 通过将昂贵的访问控制规则 (access control rule,
ACR) 验证和管理操作的负担转移到链下基础设施, 同时仅实现链上轻量级的基于令牌的访问控制. 例如, 存储公