Canton 心智模型
建立正确的 Canton 开发直觉
高效开发 Canton 需要正确的心智模型。本页帮助建立让后续知识「对上号」的直觉。
私有数据库网络
把 Canton 想成私有区块链/数据库的网络，彼此可同步——而不是单一全球状态链。
要点： 每个 Party 的数据留在自己的验证者上。Alice 与 Bob 交易时，只有 Alice、Bob 的验证者参与；Charlie 的数据不受影响，甚至不知道交易发生。
对设计的影响：
- 查询：通常只能查自己的数据
- 设计：想清楚数据放在哪
- 隐私：数据留在应有权限的一方
合约即事实
把合约想成存在的事实，而不是「会执行的状态机代码」。
| 传统看法 | Canton 看法 |
|---|---|
| 合约状态是 X | 事实：Alice 持有 100 代币 |
| 把状态改成 Y | 归档旧事实，创建新事实 |
| 合约有地址 Z | 事实有 ID，归档后 ID 变化 |
要点： 从不「修改」事实；旧事实进入历史，新事实被创建——既有不可变审计轨迹，也支撑隐私。
授权即结构
授权不是运行时 if 检查，而是在结构里声明，由协议强制执行。
choice DoThing : Result
controller owner
do
-- 只有 owner 能执行到这里你「写不出忘记鉴权」的漏洞，因为根本没有可遗漏的检查分支。
视图即窗口
把交易想成一栋楼，各方透过**不同窗户（视图）**看同一栋楼的不同部分。
要点： 隐私不是「藏数据」，而是各方对共享现实有各自可见的子集。
Party 即利益相关方
Party 不是「账户」，而是在合约中有角色的主体：
| 角色 | 含义 | 类比 |
|---|---|---|
| Signatory | 必须授权，始终可见 | 合同签字方 |
| Observer | 可见不可动（除非另设 controller） | 邮件抄送 |
| Controller | 可执行特定 Choice | 特定门的钥匙 |
同步器如邮局
同步器不是「存你数据的链」，而是邮局：收密封信件、排序投递、不拆信阅读。
交易即提议
多方交易常是提议 + 接受：Bob 必须显式接受，才能与 Alice 共同成立合约。
综合对照
| 场景 | 用哪个模型 |
|---|---|
| 数据存哪 | 私有数据库网络 |
| 状态怎么变 | 合约即事实 |
| 权限怎么设计 | 授权即结构 |
| 隐私怎么保证 | 视图即窗口 |
| Party 关系 | 利益相关方角色 |
| 基础设施 | 同步器如邮局 |
| 多方流程 | 交易即提议 |
常见误解
| 误解 | 事实 |
|---|---|
| Canton 只是另一条链 | 架构根本不同 |
| 能查所有合约 | 只能查自己 Party 的数据 |
| 智能合约有固定地址 | 合约有 ID，归档/创建会换 ID |
| 验证者看到一切 | 验证者只见自己托管 Party 的数据 |
| 同步器存我的数据 | 同步器不存业务数据 |
本文由 CC Privacy Club 根据 Canton Network 官方文档（CC-BY-4.0）整理翻译，仅供学习；实现细节以官方最新版本为准。