智能合约升级概览
为什么智能合约升级很重要，以及 Canton 的升级模型如何工作
Canton 应用会不断演进：模板增加字段、Choice 行为变化、全新工作流上线。智能合约升级（Smart Contract Upgrade，SCU）让你在不破坏既有合约、也不强迫所有组织同时停机的前提下完成这些变更。注意：SCU 有必须遵守的规则。
为什么 Canton 上的升级与众不同
在传统数据库里，你运行迁移脚本即可改 schema。在 Canton 上，合约不可变，并分布在多个组织的验证者节点上。修改模板结构意味着：所有托管相关 Party 的验证者都必须知晓这次变更。
难点在于：你无法强迫所有组织同时升级。SCU 的解法是：允许多个包版本在账本上共存，并在受控规则下跨版本交互。
升级模型
推荐做法结合异步 rollout 与同步切换：
异步 rollout：
- 应用提供方实现并测试 v2 组件。
- 应用提供方将 v2 组件提供给应用用户。
- 提供方与用户异步升级后端、前端，审计升级后的 DAR 包，然后 vet 这些包。
前后端应同时支持 v1 与 v2 工作流，使各方可按自己的节奏部署。在所有人切到 v2 之前，混合版本部署是常态。
同步切换：
- 应用提供方公布目标日期，要求用户完成升级并下线 v1。
- 临近升级日，提供方与用户协调，将 v2 包（DAR）上传到各自验证者。
- 在约定时刻，各方一起 vet 新上传的包，使新版本生效。
包版本
每个 Daml 包在 daml.yaml 中有名称与版本。上传新版本（同名、更高版本号）后，两个版本会同时在账本上存在。既有合约仍关联创建它的版本，但在 SCU 兼容规则下，账本可用新版本代码解析旧合约。
多版本共存是零停机升级的基础：新版本生效前，不必先迁移旧合约——在兼容允许时，旧合约可通过新版本代码读取与执行。
何时用升级 vs 新模板
并非每次改动都要走升级机制：
适合 SCU：
- 给现有模板增加可选字段
- 给现有模板增加新 Choice
- 需要旧合约在新代码下继续工作且不想迁移
- 需要零停机部署
适合新模板：
- 变更根本不相容（删字段、改类型等）
- 新工作流与旧逻辑本质不同
- 希望新旧行为清晰隔离
关键挑战
- 异步 rollout — 提供方与用户往往无法同时升级，必须支持独立部署节奏。
- 混合版本部署 — 异步 rollout 期间，跨组织可能同时存在 v1/v2；前后端需兼容两套 DAR 工作流。
- 零停机升级 — 部分工作流需 7×24 不间断；SCU 与异步 rollout 使升级过程中工作流可继续。
本模块结构
本模块按步骤讲解升级流程，包括：兼容性规则、编写第一个升级、包选择、测试升级、部署升级等主题（详见官方对应章节）。
本文由 CC Privacy Club 根据 Canton Network 官方文档（CC-BY-4.0）整理翻译，仅供学习；实现细节以官方最新版本为准。