Canton 开发者文档 / 概览

完整文档页面（中文翻译）。文末附有来源说明。

阅读英文版

overviewreferencedecentralization

去中心化

Canton 中的去中心化命名空间、去中心化 Party 与去中心化 Synchronizer 所有权。

去中心化

在 Canton 语境下，去中心化主要指将特定实体的权力或所有权分散给多个所有者或受托人，使任一受托人都不能单方面代表该实体做出变更。

此类去中心化实体可以是命名空间、Party 与 Synchronizer。下文分述各类实体。

所有权分散的一面是信任分散：与单一所有者的实体交互须完全信任该所有者，或完全不交互。与去中心化实体交互时，只需按与达成共识所需所有者数量成反比信任每个所有者。该数量称为去中心化实体的阈值（threshold）。当至少 threshold 个所有者同意采取同一行动时，称所有者已形成法定人数（reached a quorum）。

去中心化信任有用乃至必需的原因包括：

  • 安全：单一所有者被攻破则整个实体及全部数据沦陷；若六名所有者中仅一人被攻破，仍有五名可控制实体，被攻破者无法单方面变更。
  • 监管限制：例如监管要求 Synchronizer 须在其司法管辖区有物理存在；或关键国家网络须由多个独立公共机构与私营企业运营以保证整体独立。
  • 四眼原则：将阈值设为 2 可强制关键实体遵循四眼原则，有助于防范用户输入错误等。
  • 法人实体：多个个人所有者构成 juridical person。

去中心化命名空间

如 topology-namespaces 一节所述，命名空间最终由私钥支撑；掌握私钥者即可自称命名空间所有者并如此行事。因此标准命名空间不适合表示去中心化命名空间。

Canton 通过 DecentralizedNamespaceDefinition 拓扑映射实现去中心化命名空间：定义一组命名空间作为所有者及由 founders 计算得出的去中心化 Namespace。定义 DecentralizedNamespaceDefinition 时，founders 须就所用阈值达成一致。

去中心化命名空间的所有权不固定。当前所有者可增删所有者或变更阈值。初始拓扑交易之后的所有权变更不会改变去中心化命名空间自身的 Namespace。

每当拓扑交易需要唯一标识符时，该 UID 的命名空间可以是 NamespaceDelegation 根证书定义的简单命名空间，或由 DecentralizedNamespaceDefinition 定义的去中心化命名空间。后者要求所有者法定人数签署后续 UID 拓扑交易；在达到法定人数前，拓扑交易仍为提案。

去中心化 Synchronizer

Synchronizer 可通过多种方式去中心化：

  • 所有权去中心化：SynchronizerId 的命名空间作为去中心化命名空间创建，多个所有者且阈值大于 1。
  • Mediator 组去中心化：Synchronizer 所有者可配置含多个 Mediator 且阈值大于 1 的 Mediator 组。即该组中至少 threshold 个 Mediator 对两阶段提交协议中的确认请求达成相同裁决后，Sequencer 才将裁决投递给 Participant。
  • Sequencer 去中心化：Canton 支持在 BFT 排序层上运行多个 Sequencer。
  • Sequencer 连接去中心化：Participant 可配置连接多个 Sequencer 并设阈值大于 1，从多个 Sequencer 订阅事件流；仅当 threshold 个 Sequencer 对同一事件提供相同数据时才处理，否则警告运营方。Participant 还可使用写放大（write amplification）向多个 Sequencer 提交以克服故障或恶意 Sequencer 的审查；Sequencer 会去重，最终至多向接收方投递一条消息。

去中心化 Party

去中心化所有权

Party 的所有权与治理可像 Synchronizer 一样去中心化：建立用于 Party UID 的去中心化命名空间。

去中心化 Active Contract 管理

从 Party 视角，Active Contract 管理分三项功能：

  • Participant 作为 Canton 协议一部分验证并确认交易
  • Party 应用经 Participant 的 Ledger API 提交交易
  • Party 应用从 Ledger API 读取活跃合约与交易流

因单一实体运营 Participant，这些功能仅能在法定人数的 Participant 上执行，即 Party 多宿主于多个 Participant。

去中心化验证

多宿主 Party 的所有者可指定须有多少 Participant 代 Party 确认或拒绝每笔交易。例如 Party P 托管于 p1、p2、p3，阈值 2。若交易需该 Party 确认（如其为所用合约 c 的 signatory），Mediator 等待其中两个 Participant 发送匹配响应（两确认或两拒绝）。达阈值后，Mediator 将该响应视为 Party 响应。

当任何 Party 的未决响应都无法改变结果时，Mediator 发出交易裁决。例如合约 c 另有 signatory Q，托管于 p5–p8，阈值 2。则 P 与 Q 均须确认。若 P 拒绝（如 p1、p2 拒绝），Mediator 立即裁决「拒绝」。若 P 确认，Mediator 等待 Q 从 p5–p8 获得两匹配响应。对 Q，可能两结果均达阈值（如 p5、p6 确认而 p7、p8 拒绝），此时 Mediator 取先达阈值的结果。

若在 participant-response-timeout 内某需确认 Party 未达阈值，Mediator 发出超时裁决（如 P 仅 p1 确认、p2 拒绝、p3 超时无响应）。

Canton 确保托管该 Party 的所有 Participant 无论其确认是否被采纳都会获知交易，从而在 Ledger API 上发出相同交易并一致更新 ACS。

确认方 Participant 会检查例如合约是否活跃（对 signatory）及顶层操作是否正确授权（对 controller）。因此，托管该 Party 的任意 threshold 个串谋 Participant 可：

  • 确认非活跃合约的活跃性从而双花。
  • 确认 Party 权威从而创建以该 Party 为 signatory 的合约，即使 Party 此前未同意。

后者尤其意味着确认阈值应与 Daml 模型中显式编码的治理规则对齐：若 Daml 治理要求阈值 t，则确认阈值 ct 亦应至少为 t，否则 ct 个串谋 Participant 运营方可不经治理直接提交治理动作效果。

去中心化 Party 的提交

PartyToParticipant 映射中阈值大于 1 的 Party 不能提交 Ledger API 命令。因命令提交总经单一 Participant，且 Party 提交与结果交易之间无密码学链接，命令提交将违反去中心化原则——即单一实体（此处的 Participant 运营方）不能单方面变更去中心化 Party 的活跃合约。

Party 所有者可两种方式化解：

  1. 以 externally signed submission 提交交易
  2. 在 Daml 中去中心化授权

推荐第一种。

外部提交

所有者可授权 Party 的 PartyToKeyMapping 拓扑映射，将 Party 与一组签名密钥关联。所有者可用这些密钥在经 Participant 提交前直接签署并授权 Daml 交易。此类提交称为外部提交。 analogous 于 PartyToParticipant 的阈值，PartyToKeyMapping 的 threshold 定义签署提交所需最少密钥数。

详见 overview_canton_external_parties。

Daml 中去中心化授权

跨多个 Participant 协调命令 提交是分布式工作流，Daml 比协议中固定模式更适合建模。

因此确认阈值大于一的 Party P 在 Daml 模型内将 choice 委托给（足够多的）其他 Party。通常 P 背后的实体自有 Daml Party，以 P 为 signatory 的合约将 choice 的 controller 设为实体 Party 的法定人数。该模式模拟 juridical person（P）通过自然人的法定人数（controller）行事。

问题在于：Party 如何首先成为合约 signatory？仅当其提交创建该合约的命令，或此前创建了（传递）委托该权利的合约。

为解决，Party 起初在单一 Participant 上以阈值 1 分配，经该 Participant 提交初始设置命令在 Daml 合约中创建「创世状态」。设置成功后，将 Party 分布到多个 Participant 并提高阈值。缺点是状态只能按预定义方式从创世演化；未预见变更须暂时中心化，除非可用 Daml 智能合约升级表达——此类升级无法覆盖所有情况，例如 Daml 语言大版本升级可能有问题。

应用从多个 Participant 读取

第三项是 Party 应用如何理解链上代其发生的事。多数应用由个人运营，与其使用的 Participant 运营方有信任关系，无需质疑数据正确性，从单一 participant 读取即可。

若无此信任（如应用由实体群组运营），只从单一 Participant 读取违反去中心化原则——该 Participant 可提供错误数据。此类应用应从多个 Participant 请求活跃合约数据并检查一致性。

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