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

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

引入一定程度的技术债务 [19] , 例如代码中的漏洞代码、临时性解决方法和非最优实现. Ebrahimi 等人 [19] 研究智能
合约中的技术债务, 指出开发人员通常通过代码注释在源代码中明确承认存在的技术债务, 导致选择一个快速的、
次优的解决方案需要更长的时间来解决该方案所造成的额外工作成本. 此外, Li 等人 [47] 讨论一些合约升级时潜在
的安全问题, 包括缺少权限限制性检查、逻辑地址检查、合约版本检查问题.
4.1 升级性安全管理
首先, 需明确区分“合约升级”与“合约可升级性”这两个概念. Qasse 等人 [18] 认为合约升级是指在部署后修改智
能合约代码, 同时维护合约数据和状态的过程. 而合约可升级性指的是合约是否具备被修改和升级的潜在能力, 因
此并非所有具备可升级性的合约都会被实际修改或升级. 区分这两者一个关键的特性是: 可升级性是否可能在不
经意间被移除? 在代理模式中, 如果升级机制被设计在代理合约之外, 无论是嵌入在实现合约中还是在外部合约
控制, 合约的可升级性都可能被意外且永久地移除. 一些以太坊改进提案 (EIP, 如 EIP-1822) 警告, 为保留可升级
性, setter() 必须存在于实现合约中. 但其他一些以太坊改进提案 (如 EIP-2535) 则持不同立场, 认为使其代码不可
变是一种功能特性而非代码漏洞.
4.1.1 升级性风险
在设计智能合约时, 合约的可升级性是一个重要的考虑因素. Xu 等人 [102] 研究两种旨在提高合约升级能力的
模式: 合约注册模式和数据合约模式. 合约注册模式通过合约注册中心来管理合约地址, 从而实现合约的升级, 例
如, AAVE 的早期版本就使用这种模式. 数据合约模式则是将数据和逻辑分离, 通过升级实现合约来实现合约的升
级, 同时保留数据不变. 此外, 考虑到合约升级的安全性, 提出嵌入许可和工厂合约两种模式. 嵌入许可模式通过在
合约中嵌入权限控制逻辑, 确保只有授权的实体才能执行关键操作. 工厂合约则通过创建标准化的合约实例来简
化部署和管理过程. 例如钻石框架就是一种特殊的合约升级模式, 通过预定义的逻辑, 在不影响其状态的情况下来
处理升级, 并有效避免硬分叉问题.
在设计复杂的智能合约时, 必须综合考虑包括可升级功能、版本约束以及数据治理在内的多个方面 [103] . 在代
理合约中, 如果未正确地实现升级功能, 具有升级控制的单个实体可能会引入潜在的漏洞或恶意更改. 此外, 在去
中心化的系统就升级达成共识是复杂和漫长的, 同样会增加用户信任和运营担忧. Salehi 等人 [46] 将可升级性的安
全控制策略细分为 3 个主要类别: 私钥控制问题、版本升级延迟以及代码重用灾难.
1) 私钥控制问题: 由于私钥的高度集中, 一个恶意的管理员或被泄露的私钥可能是灾难性的 [57] . 事实上已经
报道几起关于代理合约的事件. 例如, 在 PAID 事件中, 攻击者破坏管理员的私钥并篡改实现合约, 使他们能够随
意燃烧和铸造 PAID 代币. 如果攻击者获得控制代理的管理特权, 他们可以将代理重定向任何逻辑.
2) 版本升级延迟: 如果在可升级合约中发现漏洞并需要修补, 恶意用户在下一个版本升级之前的时间窗口内
利用该漏洞. Chen [104] 提出一种通过比较以太坊智能合约的历史版本来识别安全问题的方法, 通过寻找自毁合约的
更新版本并计算代码相似性, 来追踪升级过程中的安全问题. 然而, 代理模式为 DApp 引入额外的层次, 这可能会
增加事务处理时间. 此外, 与单个合约相比, 开发人员至少需要维护两个合约 (代理合约和实现合约). 这种升级增
加维护负担, 因为开发人员需要监控、更新并确保在不同版本的代理合约之间的兼容性. 对于最终用户来说, 他们
可能并不总是清楚地知道他们正在与代理合约进行交互, 这种差异导致对当前合约实际功能的混淆或误解, 特别
是在用户不知情的情况下更改逻辑.
3) 代码重用灾难: Abuhashim 等人 [105] 将智能合约聚类为 39 个可升级的集群, 每个集群包含大量在嵌套智能
合约数量和每个组件如何编写方面相似的智能合约. 一旦发现初始重用合约存在漏洞时, 代码重用将会无形中传
播漏洞灾难.
4.1.2 自毁智能合约
无论是不可升级的合约, 还是使用代理模式的可升级合约, 基本共识是: 已经部署在区块链上的原始合约是不
可变的. 然而 EVM 有一个操作码 SELFDESTRUCT, 使得改变链上的合约可以被删除. 自毁合约是从以太坊区块
链中删除智能合约的唯一方法. 当执行此 SELFDESTRUCT 时, 合约可以将所有以太币余额转移到特定地址, 然后