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

郭涛 等: 智能合约可升级技术综述 53

废弃合约本身. 通过使用 SELFDESTRUCT, 开发人员可以在紧急情况发生时 (如受到攻击) 删除智能合约并转移
以太币. 此外, 当不再需要合约时, 调用 SELFDESTRUCT 可以帮助清理以太坊环境.
自毁智能合约 [106] 的概念主要有两种实现方式, 它们允许在特定条件下通过合约自身的机制终止其功能.
1) 如果实现合约中包含 SELFDESTRUCT 操作, 并通过调用它来执行自毁.
2) 对具有 SELFDESTRUCT 逻辑的合约进行 delegatecall() 或 CALLCODE.
在这种情况下, 应该检查实现合约是否使用 SELFDESTRUCT 方法或将 delegatecall()、CALLCODE 设置为
恶意方可以控制的地址. 如果有该方法, 恶意方可以通过调用 SELFDESTRUCT 来自毁合约, 所有对代理的调用失
败. 这就构成对 DApp 的拒绝服务攻击. 当然, 代理合约的管理员也可以通过升级到新版本的实现合约来应对这种情
况. 另外, 可以通过计算代码相似性来识别自毁合约 (即前任合约) 及其更新版本 (继任者合约). 然而 SELFDESTRUCT
函数对于合约用户和合约所有者而言也存在一定的风险, 恶意方可能会利用自毁功能打开攻击向量 [107] .
尽管使用自毁功能和开发可升级合约在成本上可能更为经济, 但也会因合约可变性而产生信任威胁. Chen [104]
提出一种权利分配方法来减轻使用自毁函数所带来的信任和安全问题, 这种方法同样适用于可升级合约的安全管
理. 作者建议开发者应该将权利分配给合约的使用者, 让他们投票决定合约是否应该被销毁或升级. 通过引入延迟
升级步骤以降低以太币被锁定的风险, 因为转移到销毁地址的以太币将永远无法取回. 在投票和延迟步骤中, 开发
者应该暂停合约的功能, 以防止攻击或其他不必要的行为.
4.2 形式化升级规范
代理模式允许对智能合约进行修补, 但它并未解决故障升级问题: 如何确保升级后合约内容的正确性. 此外,
升级过程通常赋予合约维护者较大的权力, 允许他们在缺乏适当监管的情况下更改合约代码, 然而这种更新过程
没有任何强制执行保证; 只要正确的参与者批准更改, 合约实现就可以相当随意地更改. 鉴于智能合约的不可变性
和自动执行特性, 以及“代码即法律”的原则 [108] , 在合约的创建和升级之前, 必须进行严格的代码规范验证, 确保其
符合预定的“法律”和逻辑规范.
4.2.1 合约升级规范
Casolari 等人 [109] 就合约规范探讨《欧盟数据法》提案对智能合约的实际影响, 并强调在创建和升级合约之前
进行正式验证的必要性. 然而, 目前大多数合约规范都是非正式的, 一些区块链社区使用的规范格式, 例如以太坊
征求意见 (ERC) [110] , 在 ERC-20 中仅描述合约实现的功能签名, 以及关于功能应如何表现的简短文本、非正式解
释等相关规范. 并未提及如何确保合约规范在其生命周期内保持不变. 参与者可以通过框架检查合约是否已部署,
以便他们可以确定他们想要执行的合约具有预期的行为.
Antonino 等人 [108,111] 提出一种“规范即法律”智能合约安全部署与演化方法, 该方法基于可信部署者创建的安
全框架来管理智能合约升级. 该框架通过在链上的钻石代理执行升级操作, 而链下依靠受信任的部署者对合约创
建以及升级规范进行审查. 仅当新的实现满足预期规范时才允许执行升级操作. 图 21 介绍受信任部署者的基础架
构. 其中可信部署程序依赖于以下组件:
1) 验证者 (verifier): 检查合约的创建和升级是否符合规范.
2) 升级者 (upgrader): 执行合约的创建与升级.

验证者 升级者
获取规范

升级合约 创建合约 以太坊平台
验证升级 升级合约
验证创建 创建合约
创建合约

图 21 可信部署者架构