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

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

部署者在执行合约的创建与升级操作时, 会先调用验证创建和验证升级进行合约验证. 若验证通过, 部署者才
会将调用请求转发给升级者, 最终在以太坊平台上完成合约的创建或升级; 获取规范函数可用于查询受信任的部
署者是否已经部署某个合约实例, 并确定该合约满足的规范. 该机制确保智能合约的演化过程始终符合既定的安
全要求, 同时避免未经验证的恶意升级.
4.2.2 合约升级证明
区块链的共识机制在于确保智能合约的所有更新都符合原始规范, 任何后续对实现合约的更新都必须伴随着
规范化的有效证明. Dickerson 等人 [112] 将 Necula [113] 的携带证明代码改造成携带证明的智能合约, 将正式证明 (API
和原始规范) 附加到智能合约上, 在部署前信任一个规范的第三方来验证所有合约升级. 图 22 展示携带证明的智
能合约的升级过程.

父合约:
API, 规范
生成 更新 验证 打包 新区块
规范证明 交易事务
合约拥有者
验证器
候选子
合约代码 矿工
图 22 携带证明的智能合约

1) 假定合约拥有者需要发布父合约 (包含 API 和规范) 以及候选子合约的代码, 因为这些操作不需要验证. 合
约拥有者首先生成一个证明, 证明提议的子合约满足规范的不变量.
2) 合约拥有者将此证明打包并更新事务, 作为交易传输到区块链网络进行挖矿.
3) 矿工验证子合约的代码证明, 并生成一个包含安全更新的新区块. 如果证明无效, 区块仍会将尝试的更新记
录为事务, 但安全更新将失败并出现异常.
4) 最后, 区块链网络的其余参与者重新运行并验证安全更新.
此外, 合约之间重用关系也可以实现升级证明, Kondo 等人 [114] 研究显示, 超过 79.2% 的智能合约包含代码克
隆, 且克隆合约大部分为代币合约. 从而增加代码维护的可重用性因素. Ringer 等人 [115] 通过对比新旧合约之间的
结构相似性, 在更新的代码上重用形式化完成修复证明. 在此基础上, Sorensen 等人 [116,117] 提出合约演化概念, 提出
一个合约升级的形式化框架 in ConCert, 形式化地编码智能合约之间的结构关系, 用它来指定和推理合约升级的
结构和行为. 解决对区块链系统进行范式转换的再工程问题. Galimullin 等人 [118] 引入的前后时间关系指的是以前
版本的合约, 从而为代码设置增加自省功能, 用于验证和规范化智能合约升级的逻辑.
4.3 结构化开发流程
区块链软件开发的范式与传统方法存在显著差异. 主要源于区块链系统对安全性和可靠性的严格要求, 以及
去中心化应用开发领域所特有的挑战, 包括数据不可变性、软件升级复杂性, 以及在高度复杂、去中心化的网络
环境中运行的安全需求. 然而商业浪潮总是催促应用程序的快速开发, 往往以牺牲良好的开发实践、全面的测试
和安全评估为代价. 尽管敏捷开发流程在传统软件开发中取得成功, 但其在满足区块链系统的高标准要求方面存
在局限性.
面向区块链的软件工程是一个新兴领域. Porru 等人 [119] 于 2017 年首次呼吁使用面向区块链的软件工程. 强调
“需要新的专业角色、增强的安全性和可靠性、新颖的建模语言和专门的指标”, 并提出“面向区块链的软件工程

的新方向, 关注大型团队之间的协作、测试活动和用于创建智能合约的专门工具”. 还建议采用现有的设计符号,
如统一建模语言 (UML), 以明确地指定和记录 DApp 开发流程. 尽管有大量资金投入开发, 但健全的软件工程流程
和实践的应用仍然相对较低. 因此目前的可升级智能合约更像是一种系统维护手段.
开发既安全又可升级的智能合约是一项重大挑战, 它要求开发人员具备高度的安全意识和专业知识. 随着越