重分配协议
Canton 合约重分配(跨参与方迁移)协议参考。
同步器重新分配协议的技术参考,涵盖取消分配、分配、验证规则和确认策略
为什么存在重新分配
一个参与节点可以连接到多个同步器。不同的同步器可能有不同的用途:法规遵从性、性能特征、成本、治理模型或特定于应用程序的限制。在不同同步器上创建的合约需要一种参与同一事务的方式,而重新分配就是这种机制。
两步过程:取消分配和分配
sequenceDiagram
participant Sub as Submitting Participant
participant S1 as Source 同步器 (S1)
participant S2 as Target 同步器 (S2)
Note over Sub,S2: Step 1 — Unassignment
Sub->>S2: Request time proof (target timestamp)
S2-->>Sub: Target timestamp
Sub->>S1: Submit unassignment request
S1->>S1: Sequence and distribute
Note over S1: Confirming participants validate
S1->>S1: Collect confirmations, commit
Note over Sub,S2: Contract is now inactive (pending assignment)
Note over Sub,S2: Step 2 — Assignment
Sub->>S2: Submit assignment request
S2->>S2: Sequence and distribute
Note over S2: Confirming participants validate
S2->>S2: Collect confirmations, commit
Note over Sub,S2: Contract is now active on S2
关键定义
重新分配计数器
重新分配计数器跟踪合同重新分配的次数。创建合约时将其设置为零,并在每次取消分配时加一。取消分配事件和相应的分配事件具有相同的重新分配计数器。
目标时间戳
当提交取消分配时,会在目标同步器上请求时间证明。此时间戳(目标时间戳)用于在取消分配处理期间执行与目标同步器相关的验证(包审查、涉众托管等)。使用单个固定目标时间戳可确保所有确认参与者针对相同的拓扑快照运行相同的验证。
重新分配参与者
重新分配参与者连接到源同步器和目标同步器,并在两者上托管利益相关者。这种双重连接使其能够验证完整的重新分配并防止双重支出。
正式而言,如果满足以下所有条件,则参与者P是一方S和合同c的重新分配参与者:
S是c的利益相关者。S由目标同步器上的P在目标时间戳 托管。S由源同步器上的P托管。
最后一个条件在提交期间使用最近的拓扑快照进行检查,并在协议的第 3 阶段期间在请求时使用拓扑快照进行检查。
签署者取消分配参与者
合同c和当事人S的签署取消分配参与者是重新分配参与者,其中:
S是c的签署人。S托管在P上,至少具有源同步器的确认权限。
签署取消分配参与者是取消分配请求的确认者——只有签署方才应该确认,因为非签署方观察员无论如何都不会阻止重新分配。
签署者指定参与者
合同c和当事人S的签署分配参与者是重新分配参与者,其中:
S是c的签署人。S托管在P上,至少对目标同步器具有确认权限。
签署转让参与者被告知合同的取消转让和转让,并且是转让请求的确认者。
确认政策
验证规则
取消分配验证
赋值验证
对于这两个步骤都执行也适用于常规 Daml 事务的标准验证:正确的视图解密、正确的收件人列表和正确的根哈希消息。<警告> 如果拓扑在取消分配和分配之间发生变化,则可能无法完成重新分配。在这种情况下,您可以调整拓扑以允许分配,或者使用修复服务手动修复每个相关参与者节点上的合约分配。 </警告>
提交政策
这种宽松的要求有两个动机。首先,在重新分配后失去同步器提交权限的一方仍然可以发起重新分配,保留行使选择的能力。其次,去中心化各方(无法提交 Daml 交易)仍然应该能够提交重新分配以实现可组合性。
分配排他性
这种机制为发起者提供了一个窗口来完成重新分配而不受干扰,同时仍然允许其他参与者完成放弃的重新分配。
自动与显式重新分配
您可以通过两种方式触发重新分配。
自动(同步路由器)
当您通过 Ledger API 提交交易时,Canton 的同步器路由器会自动识别合适的同步器。它将所有输入合约重新分配给该同步器,执行交易,然后可以选择重新分配输出合约。您的应用程序不需要管理同步器选择或重新分配命令。
路由器选择具有最高优先级的可接受的同步器,最小化重新分配的次数,并且(作为决胜局)具有最低的同步器ID。应用程序可以通过每个同步器包审查、非同质方托管或明确披露的合同来影响路由。
显式(Ledger API 命令)
对于细粒度的控制,您可以直接通过 Ledger API 提交重新分配命令。取消分配命令指定合约、源同步器和目标同步器。分配命令引用取消分配返回的取消分配 ID。您还可以指定提交事务时使用哪个同步器;如果该同步器不合适,则提交失败。
账本 API 数据
取消分配命令字段
- 合同:要重新分配的合同(所有合同必须共享相同的签署人和利益相关者)。
- 源同步器:当前分配。
- 目标同步器:所需的分配。
未分配的事件字段
- 取消分配ID:唯一标识重新分配的不透明标识符,用于提交分配。
- 重新分配计数器:合同重新分配的次数。
- 作业独占性:截止日期之前,只有取消作业提交者才能提交作业。
分配命令字段
- 取消分配 ID:未分配事件的标识符。
- 源同步器:之前的分配。
- 目标同步器:新的分配。
分配的事件字段
- 取消分配 ID:用于关联未分配和分配的事件。
- 重新分配计数器:与未分配事件中的值相同。
- 创建的事件:包含合同数据,以便首次了解合同的参与者(因为它进入了他们的可见性)可以访问其有效负载。
合约进入和离开可见性
当参与者在目标同步器上托管利益相关者(因此是分配的通知者)但没有在源同步器上托管利益相关者(因此它不是取消分配的通知者)时,合约可以进入参与者的可见性。分配的事件中包含的创建事件让参与者可以在合约首次可用时了解合约的有效负载。相反,当参与者是取消分配的通知者(因为它在源同步器上托管了利益相关者)但不是分配的通知者(因为那里没有托管相同的利益相关者,或者因为该利益相关者托管在目标同步器上的不同节点上)时,就会发生相反的情况——合约留下参与者的可见性。取消分配后,该合约在该参与者上变得不可用,即使它对于目标同步器上的其他利益相关者仍然处于活动状态。
合约在其生命周期内可以多次进入和离开参与者的可见性。当参与者上托管的利益相关者以随时间变化的方式跨同步器进行多托管时,通常会发生这种情况。
更新流排序
当参与者连接到多个同步器时,更新流会合并来自所有同步器的事件。由于无法跨同步器比较时间,因此更新流上没有全局因果关系保证。来自不同同步器的事件可能以任意顺序出现,并且不同的参与者可能会看到不同的顺序。
在单个同步器中,顺序是一致的:创建的事件始终出现在该合约的任何未分配或存档的事件之前,而存档的事件始终出现在任何分配或创建的事件之后。
本文由 CC Privacy Club 根据 Canton Network 官方文档(CC-BY-4.0)整理翻译,仅供学习;实现细节以官方最新版本为准。