交易生命周期

Canton 交易端到端生命周期参考。

Canton 交易的完整五个阶段生命周期 - 从准备到排序、验证和最终提交

Canton 事务在提交（或被拒绝）之前会经历五个不同的阶段。每个阶段都涉及特定的节点角色——参与者节点、排序器节点和中介者节点——通过加密的排序消息进行通信。没有一个节点能够清楚地看到完整的交易。

这些阶段是：

准备——提交参与者解释命令并构建加密交易视图
提交 — 参与者向排序器发送确认请求批次
排序和分发 — 排序器排序并将消息传递给接收者
验证和确认——每个确认参与者验证其观点并向调解者做出回应
聚合和提交 - 调解者收集响应，做出裁决，参与者根据裁决应用（或丢弃）结果

第一阶段：准备

当提交参与者节点通过 Ledger API (gRPC) 接收到来自应用程序的命令时，生命周期就开始了。然后参与者：

通过在 Daml 引擎本地执行 Daml 智能合约代码来解释命令。引擎根据参与者当前的活动合约集 (ACS) 评估命令，并生成完整的事务树 - 一个包含每个操作（创建、练习、获取）、每个操作的结果以及所有相关元数据的结构。
确定树中每个操作节点的通知对象。知情者是有权查看给定操作的各方——签名者、观察者和参与者（执行选择），如 Daml 模板所定义。为每个操作设置的信息接收者控制谁接收交易的哪些部分。
将事务分解为视图。 事务树中的每个操作节点都成为一个单独的视图。视图包含操作、其后果以及足够的验证上下文，仅此而已。每个视图都经过加密，因此只有其信息接收者（以及托管这些信息接收者的参与者）才能对其进行解密。非知情者对行动一无所知：不了解有效负载，不了解各方，甚至不了解该行动的存在。
计算根哈希，以加密方式提交到整个事务树。根哈希将所有视图绑定在一起：每个确认参与者都可以验证它收到的视图是否属于每个其他参与者正在验证的同一交易。中介器使用根哈希来关联确认响应。

如果交易涉及多个同步器上的合约，则参与者可能需要在提交之前将这些合约重新分配给公共同步器。这是由重新分配协议处理的。

第 2 阶段：提交（确认请求）

提交参与者向排序器发送确认请求批次。该批次包含三类消息：

加密视图 — 每个操作节点一个。每个视图都针对托管其信息对象的参与者进行加密。不主持特定视图的任何信息接收者的参与者无法解密它并且永远不会接收它。
根哈希消息 — 每个接收参与者一个。每个根哈希消息都携带交易的根哈希，允许接收者将其收到的视图与单个交易关联起来。
通知者消息 — 发送给调解员。这些列出了每个视图的信息接收者和确认政策。确认策略指定哪些签名者需要确认，以及每个签名者必须批准的托管参与者的阈值。调解器使用此信息来确定何时有足够的确认到达。

提交参与者将所有这些消息一次性发送到排序器。

第 3 阶段：排序和分发

排序器处理确认请求批次：

分配时间戳。 这是事务的排序时间。排序器执行 BFT 写入：排序节点就该批次在全局消息序列中的位置和时间戳达成一致。时间戳成为所有后续截止日期的参考点。2. 仅将每条消息传递给其指定的收件人。 参与者会收到他们托管通知方的加密视图以及他们的根哈希消息。调解员接收通知者消息。交易中没有任何视图的知情者的参与者不会收到任何信息，也不会了解任何有关交易的信息。

调解员收到被通知者消息后：

记录确认请求元数据（根哈希、通知者列表、确认策略）
根据排序时间和同步器配置的决策时间参数启动确认截止时间计时器
等待参与者的确认回复

第 4 阶段：验证和确认

每个收到观点的参与者都会独立验证它们。验证检查是：

一致性 — 参与者在收到的视图中针对每个操作重新执行 Daml 合约逻辑。重新执行必须产生与视图中声称的相同的结果（创建合同、存档合同）。如果结果存在分歧，则表明视图格式错误或提交者不诚实。
授权 — 参与者检查每个操作是否都经过适当授权。对于每项操作，所需各方（签署方、控制者）必须获得授权。授权通过参与方拓扑和Daml授权规则进行验证。
一致性 — 参与者检查视图引用的所有输入合约在其本地 ACS 中是否仍处于活动状态。已经消费（归档）的合约不能再次使用。此检查可以防止单个同步器内的双花。
时间范围 — 参与者验证交易所要求的账本时间相对于排序时间（记录时间）是否在可接受的范围内。容差窗口是同步器参数。
根哈希 — 参与者验证其收到的视图是否与根哈希消息中的根哈希一致。这确保所有参与者都验证来自同一事务树的视图，从而防止恶意提交者向不同参与者发送不同的视图。

验证后，参与者构建**中介响应（MR）**消息：

批准如果参与者收到的所有视图的所有检查都通过
如果任何检查失败则拒绝，并附上拒绝原因

中介者响应被发送到定序器，定序器执行另一个 BFT 写入来为消息添加时间戳，然后将其传递给中介器。确认参与者不会将其响应直接发送给中介者——所有通信都通过定序器进行。

第 5 阶段：聚合和提交

中介者收集中介者响应消息并根据确认策略对其进行评估：

聚合。 对于每个视图，确认政策指定哪些签署方必须确认。一个签署方可以主持多个参与者；该策略定义了一个确认阈值——必须有多少托管参与者批准该签名者才能算作已确认。调解器跟踪每个签名者、每个视图的批准情况。这包括提交方是多主机的情况。
判决的确定。 可能有两种结果：
- 批准：在确认截止日期之前满足所有视图的所有签名阈值。每个必需的签名者都有足够的批准的托管参与者。
- 拒绝：任何需要的参与者明确拒绝，或者确认截止日期到期而没有得到足够的批准。单个签名者未达到阈值就足以拒绝整个交易。
交易结果分发。 中介者向定序器发送**交易结果（TR）**消息。定序器将此判决传递给所有知情参与者。当参与者从定序器读取判决时，它会执行 BFT 读取 - 验证定序器对所传递消息的签名以确认真实性。
本地提交或丢弃。 每个参与者处理判决：
- 批准时：参与者提交交易。它归档已使用的合同、创建新合同并更新 ACS。交易及其影响成为参与者本地账本预测的一部分。
- 拒绝时：参与者放弃交易。不应用任何状态更改。 ACS 保持不变。一旦判决被排序并交付，交易结果就是最终。没有分叉、重组或回滚。已提交的事务将保持已提交状态；被拒绝的交易将保持被拒绝状态。

消息摘要

下表总结了协议期间交换的消息、消息的发送者、接收者和内容。

|留言 |发件人 |收件人 |内容 | | ------------------------ | | ---------------------- | ------------------------------------------------------ | ---------------------------------------------------------- | | 命令 |应用 |提交参与者|通过 Ledger API 进行 Daml 命令（创建、执行）| | 加密视图 |提交参与者|排序器，然后是知情参与者 |每个动作节点一个；对每个信息者进行加密 | | 根哈希消息 |提交参与者 |排序器，然后是每个接收者参与者 |完整交易树的根哈希 | | 通知消息 |提交参与者 |定序器，然后是中介器 |被通知者列表和每次查看的确认政策 | | 中介反应（MR） |确认参加者|定序器，然后是中介器 |批准或拒绝（并说明理由）| | 交易结果（TR） |调解员| Sequencer，然后是所有信息参与者 |最终判决：批准或拒绝 |

时间和截止日期

两个时间参数控制协议的活跃度：

排序时间 — 在订购确认请求批次时由排序器分配。这是交易的参考时间戳。
决策时间 — 计算为排序时间加上同步器的 decisionTimeout 参数。如果调解员在决策时间内未收到足够的确认，则交易将因超时而被拒绝。

参与者还强制执行参与者响应截止日期：他们必须在从排序时间派生的配置截止时间之前发送调解器响应。未能及时回复的参与者将被视为未确认该交易。

故障模式

事务可能在生命周期中的多个点失败：

准备失败：Daml 引擎拒绝命令（例如，未找到合约、授权失败、断言违规）。在发送任何消息之前，该命令会被同步拒绝。不涉及其他节点。
验证拒绝：确认参与者发现一致性、授权、一致性或时限违规。它发送拒绝 MR。根据确认策略，单次拒绝可能足以拒绝整个交易。
超时：在决策时间之前没有足够的参与者做出响应。调解员拒绝交易。如果参与者离线、超载或无法联系，则可能会发生这种情况。
歧义检测：如果提交者向不同参与者发送不一致的视图（与根哈希不匹配的视图），诚实的参与者会在根哈希验证期间检测到不一致并拒绝。

在所有失败情况下，状态都不会改变。每个参与者的 ACS 都保持在提交交易之前的状态。

本文由 CC Privacy Club 根据 Canton Network 官方文档（CC-BY-4.0）整理翻译，仅供学习；实现细节以官方最新版本为准。