智能合约共识

Canton 智能合约（Daml）侧共识与验证流程。

Canton 的利益相关者共识证明——点对点验证、隐私保护共识和信任域分析

Canton 的智能合约共识层决定谁验证交易以及他们的确认如何产生具有约束力的结果。该机制称为“利益相关者证明”：只有在受影响合约中拥有权益的托管方参与节点才能参与验证和确认。不需要状态或计算的全局复制。

该页面指定了智能合约共识层的验证逻辑、确认策略和安全属性。有关交易排序和排序器机制，请参阅排序共识。有关端到端消息流，请参阅事务生命周期。

利益相关者证明

在完全复制的区块链中，每个节点都会验证每笔交易。Canton 采取不同的方法。交易的利益相关者（交易创建、使用或引用的合约的签署者和观察者）是其参与节点验证和确认交易的唯一各方。这是利益相关者的证明。

原理很简单：如果 Alice 和 Bob 之间存在合约，则只有 Alice 和 Bob 的参与节点需要确认该合约的状态更改是有效的。 Charlie 的参与节点没有理由看到交易、验证它，甚至知道它发生了。

利益相关者范围的验证同时产生两个属性：

• 隐私：非利益相关者不会收到有关交易的任何信息 - 有效负载内容仍然是私有的。
• 可扩展性：任何给定交易的验证工作负载均受利益相关者数量的限制，而不是网络中节点总数的限制。

排序层（排序器和中介器）处理全局一致性——防止双花并建立状态更改的总顺序。智能合约共识层负责处理正确性——确保 Daml 逻辑得到忠实执行并满足授权规则。这种分离就是Canton协议规范 所说的两层共识。

点对点验证

当提交参与者准备交易时，它会构建交易视图 - 完整交易树的子集，每个子集都对有权查看该子集的各方进行加密。定序器将这些加密视图分发到适当的参与者节点。然后每个接收者独立验证。

每个确认参与者做什么

接收交易的一个或多个视图的确认参与者节点会执行以下检查：

1. 解密和反序列化 - 参与者解密发送给它的视图并重建其托管方可见的交易树部分。

2. Daml 解释 — 参与者为其视图中的操作重新执行 Daml 智能合约逻辑。计算结果（创建的合同、存档的合同、选择结果）必须与提交参与者声称的相符。

3. 授权验证 — 参与者检查是否有正确的签名者授权创建合约、正确的控制者是否执行了选择以及是否存在所有必需的签名。

4. 与本地 ACS 的一致性 — 参与者检查交易中引用的输入合约在其本地活动合约集中是否处于活动状态。已存档或使用的合约代表冲突（从该参与者的角度来看，潜在的双重支出）。

5. 确认或拒绝 - 根据这些检查的结果，参与者向中介者发送加密签名的确认（批准）或拒绝（拒绝）响应，并通过排序器进行路由。

没有任何一个参与者需要看到整个交易。每个仅验证其收到的视图。托管 Alice 的参与者验证 Alice 的观点；主持 Bob 的参与者验证了 Bob 的观点。如果交易跨越两者，则每个交易都独立确认，并且中介者汇总结果。

调解员的角色调解员收到交易的通知者列表（各方必须确认）以及确认参与者签署的确认或拒绝响应。它不会接收解密的交易内容 - 它只会看到：

• 每个观点的知情者（签署者和观察者）是哪些方
• 每个确认参与者是否批准或拒绝
• 适用的确认政策

一旦收到足够的确认（请参阅下面的确认策略），调解器就会发出判决：提交或中止。排序器将此判决分发给所有相关参与者，然后参与者根据其本地账本状态自动应用（或丢弃）该交易。

中介者执行协议，但无法独立验证 Daml 逻辑——它依赖于确认参与者。其权限仅限于根据所需政策统计确认信息并宣布结果。

共识如何实现隐私

利益相关者证明和子交易隐私是相辅相成的。由于验证仅分布在受影响的利益相关者之间，而不是在全球范围内复制，因此 Canton 将隐私作为协议的结构属性而不是附加组件来实现。

各方只能看到自己的视图。 涉及 Alice、Bob 和 Charlie 的交易被分解为视图。 Alice 的视图包含 Alice 作为利益相关者时的操作。查理的观点仅包含查理的部分。爱丽丝和查理甚至可能不知道彼此参与了同一个原子交易。

**定序器仅看到加密的有效负载。**定序器根据接收者元数据（哪些参与者节点应接收哪些加密的 blob）路由消息。它无法解密有效负载，因此无法了解合约内容、交易中的各方关系或业务逻辑。

调解器看到被通知者列表和确认结果，而不是合同数据。 调解器知道某些方需要确认特定交易，并收到他们的批准/拒绝响应。它看不到 Daml 代码、合约有效负载或选择参数。

**没有全局状态复制意味着没有全局可见性。**每个参与者节点仅存储其托管方是利益相关者的合约。不存在可以查询或泄露的共享全局状态。

最终效果：了解有关交易的任何信息的实体集受到其利益相关者集的限制，即使在该集内，每一方的可见性也仅限于其有权查看的视图。

确认政策

确认策略定义了中介者在发出提交判决之前需要多少次确认。 Canton 使用 基于签名者的确认政策：对于交易中涉及的合同的每个签名者，调解者要求托管该签名者的参与节点进行确认。

单一主办方

在最简单的情况下，签名者恰好托管在一个参与者节点上。调解员需要该单个参与者确认。如果交易涉及与签名者 Alice 和 Bob 的合约，调解者会等待 Alice 的参与者和 Bob 的参与者的确认。双方都必须批准交易才能提交。

多方主办方和阈值

一方可以同时托管在多个参与者节点上，这种配置称为多托管或方复制。当一方是多主机时，一方到参与者的拓扑映射指定：

• 哪些参与者节点是该方的确认参与者节点（CPN）
• 确认阈值：必须确认的 CPN 的最小数量

例如，如果 Alice 托管在三个参与者节点上，确认阈值为 2，则中介者需要这 3 个 CPN 中至少有 2 个才能代表 Alice 批准交易。这是一个 m-of-n 方案，其中 m 是阈值，n 是 CPN 的数量。

该阈值在安全性和可用性之间进行权衡：

• 更高的阈值（例如，3-of-3）：更强的安全性，因为必须损害更多节点才能伪造确认，但任何单个节点的不可用性都会阻止确认。
• 较低的阈值（例如，3 中的 1）：更高的可用性，因为只要任何一个 CPN 在线，该方就可以确认，但单个受损的 CPN 可以代表该方进行批准。

聚合规则调解员独立地为参与交易的每个签名者应用确认政策。仅当满足所有签名者的确认阈值时，交易才会提交。未达到阈值的单个签名者（无论是由于拒绝还是超时）都会导致整个交易中止。

观察者出于信息目的接收交易视图，并可以在本地验证它们，但提交交易不需要它们的确认。提交决定完全取决于签名者的确认。

信任域比较

下表将 Canton 的利益相关者证明方法与其他两种架构在与协议设计者和安全审核员相关的六个维度上进行了比较。

Canton 的设计将“数据正确性”的信任集中在利益相关者群体中，同时将“排序和可用性”的信任委托给同步器基础设施。以太坊将所有信任维度集中在全球验证者集中。 Corda 非常信任公证人的排序、最终确定性和防止双重支出，而交易方则负责验证。

一个关键区别：Canton 的排序器和中介器永远看不到解密的交易内容，因此排序层无法从其排序的交易中提取商业智能。在以太坊中，每个验证者都可以完全了解每笔交易。在 Corda 中，公证人看到交易哈希，但看不到内容（在非验证公证人模型中）或完整交易（在验证公证人模型中）。

安全属性

假设底层加密原语和排序层健全，利益相关者证明提供以下保证：

确认完整性。 仅当所有必需的签名者的参与节点都确认该事务时，该事务才会提交。调解人无法伪造确认——每个确认都由确认参与者以加密方式签名。

参与者隔离。 恶意参与者无法伪造非其主办方的确认。拓扑状态（参与方到参与者的映射）通过定序器进行身份验证和分发，因此中介器知道哪些参与者是每一方的授权 CPN。

隐私保护。 非利益相关者对交易一无所知。排序器只能看到加密的有效负载和路由元数据。调解员可以看到被通知者列表和确认结果，但看不到合同数据。不接待任何利益相关方的参与者不会收到任何意见。

授权执行。 确认参与者独立验证是否满足 Daml 授权规则 - 正确的签名者、正确的控制者、有效的选择练习。构建违反这些规则的交易的提交参与者将在确认过程中被拒绝。

原子性。 调解员的裁决是全有或全无。事务中的每个操作要么都提交，要么都不提交。没有部分提交状态。活跃性。 交易进度取决于排序器（用于消息排序和分发）、调解器（用于判决聚合）和足够多的确认参与者（以满足每个签名者的确认阈值）的可用性。如果这些组件中的任何一个在协议超时后不可用，则事务将中止。排序层的活跃度在排序共识中进行了分析。

一致性。 双花保护在两个层面上运行。每个确认参与者根据其本地 ACS 检查已消费的合约。排序器的总排序可确保对冲突的事务进行排序，以便参与者观察到一致的历史记录。如果两个交易尝试使用同一个合约，则第二个排序的交易将发现该合约已存档并拒绝。

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