Page 40 - 《软件学报》2026年第1期
P. 40
郭涛 等: 智能合约可升级技术综述 37
UUPS 模式进一步扩展到新的区块链和协议中, 其应用量已超过透明代理. 最小代理广泛应用于需要批量实例的
轻量级合约中, 而钻石合约和信标代理在复杂协议中的应用逐步成熟.
上述活动反映出智能合约设计模式的演变和社区对灵活性需求的日益增长. 这一显著增长不仅突显 UUPS 模
式在智能合约开发中的广泛普及, 也展示开发者对于能够灵活升级和维护智能合约的强烈需求.
如表 2 所示提供一些可升级智能合约的相关数据集.
表 2 可升级智能合约分析的相关数据集
文献 类型 地址 备注
[18] 官方文档 https://ethereum.org/en/developers/docs/smart- contracts/upgrading/ 以太坊社区引入的升级模式
[36] 开源仓库 https://github.com/tintinweb/smart-contract-sanctuary 包含各种网络的智能合约源
[41] 开源仓库 https://github.com/USCHunt-Anon/USCHunt 原型工具、数据集和分析结果
[43] 官方文档 https://etherscan.io/contractsVerified 过经验证的智能合约的源代码
[43] 开源仓库 https://github.com/safe-global/safe-contracts 安全合约升级部署及其地址的集合
https://www.selectdataset.com/dataset/547f3b7b06015118aec0d672
[45] 开源仓库 智能合约升级版本谱系数据集
a2ca74b4
[45] 源代码 https://cloud.google.com/blog/products/data-analytics/ethereum- BigQuery中公开的以太坊数据集
bigquery-publicdataset-smart-contract-analytics
[45] 官方文档 https://info.etherscan.com/what-is-proxy-contract/ 代理合约实现相关的可识别的字节码模式
本文致力于按时间顺序梳理和讨论区块链发展过程中的智能合约可升级方法, 针对相关文献梳理, 从可升级
智能合约的模型构造、优化方法、升级框架与安全监督这 4 个角度进行总结, 涵盖可升级智能合约的设计、实现、
测试、部署及运维多个阶段. 引言部分概述可升级智能合约的研究进展和分布. 第 1 节整理可升级智能合约的概
念模型和基本工作流程. 第 2 节介绍相关优化方法、升级需求. 第 3 节介绍相关设计框架、工具与应用工具. 第 4
节讨论升级规范和安全监管问题. 第 5 节对本文内容进行总结, 提出未来研究方向.
1 可升级智能合约
可升级智能合约与可编辑区块链 (redactable blockchain) [48] 有本质区别. 智能合约本身是不可变的, 这使得在
合约部署后无法直接对其业务逻辑进行更新. 为解决业务逻辑地址更新的问题, 最初引入“合约迁移 (contract
migration)”机制.
合约迁移是指在区块链系统 (如以太坊) 中将已部署的智能合约从一个地址或版本迁移到另一个地址或版本
的过程, 通常涉及旧合约的停用和新合约的部署. 为了确保数据和状态的平滑过渡, 在进行迁移之前, 需要明确原
合约的优化需求或漏洞, 是否有必要升级合约的数据结构 (如更改存储方式). 例如在 2015–2016 年, 最早的合约迁
移方式是数据迁移 (data migration) 模式. 如图 3 所示, 数据迁移模式主要包括以下两个步骤.
(1) 数据恢复: 从迁移源区块链中读取相关区块数据, 并根据合约的数据结构使用相应的方法恢复数据.
(2) 数据写入: 收集完需要迁移的数据后, 在目标区块链上部署并初始化新合约.
①
部署新合约
② 数据恢复: ③ 数据写入:
解析数据 智能合约 V1 链上迁移, 智能合约 V2
部署者 格式 链下迁移
确定迁移
需求
图 3 合约迁移流程
合约迁移后, 新版本的合约将被部署, 并且需要将所有状态和余额迁移至新合约实例. 数据迁移方法的优点在
于其简单直接, 可以避免旧逻辑中的漏洞延续到新逻辑中. 新部署的合约还能够进行全面优化以摆脱旧合约的技
术债务. 然而数据迁移会导致合约生成新的地址, 这一过程中高度依赖人工操作, 如果在迁移期间状态更新出现错
误, 会破坏原有功能并引入新的安全漏洞. 此外, 新版本与旧合约之间的关联性丧失会削弱用户体验, 并降低用户

