拓扑

Canton 网络拓扑模型与拓扑管理参考。

Canton 拓扑管理：命名空间、加密密钥、参与方映射、授权链和拓扑事务。

所有参与者节点和同步器组件必须知道同步器的拓扑状态，其中包括同步器上的所有身份及其关联键。因此，同步器上的两阶段提交协议可以假设身份和密钥是常识，从而省略在协议消息中包含此类信息。拓扑状态的更新通过同步器进行分发，以便节点通过状态机复制来维护同步的拓扑状态。

在同步器中建立这种共享理解的机制称为“拓扑管理”。每个 Canton 节点（参与者节点和同步器组件）在本地复制确定性状态机以验证拓扑状态的更改。这意味着每个 Canton 节点根据授权规则独立决定哪些拓扑变化被正确授权。状态机的确定性本质导致连接到同步器的所有 Canton 节点在任何给定时间计算有关该同步器的拓扑状态的相同结论。

要求

以下非详尽的要求列表推动了 Canton 拓扑管理的设计和实施决策。

• 无中央机构：拓扑事务不受只能由单个实体运行的组件控制。
• 授权规则：每种类型的拓扑事务都指定规则，节点可以通过这些规则确定特定拓扑事务所需的签名才能生效。
• 无重放攻击：恶意行为者以后不得重放拓扑事务。
• 共识：在同步器上观察到相同排序时间的所有节点必须就该同步器上该排序时间的拓扑状态得出相同的结论。
• 不阻止Daml事务处理：拓扑事务处理不得阻止Daml事务处理。

设计原则

为了理解 Canton 的拓扑管理方法，需要介绍一些关键原则。

与不存在用于同步 Daml 交易的单一全局可信实体类似，也不存在用于建立身份的单一全局可信实体，这使我们得出第一个原则：

通过公钥的指纹可以唯一地识别加密密钥对。通过拥有关联的私钥，实体始终可以通过签名明确地证明该实体是公钥的所有者。我们在我们的系统中大量使用这一原则来验证和授权 Canton 密钥持有者在 Canton 同步器上的活动。因此，我们可以引入第二个原则：

原则2：Canton密钥持有者是一个可以授权行为并且其授权行为可以被验证的实体。

简而言之，每个 Canton 钥匙持有者都拥有一把钥匙或一组已知属于在一起的钥匙。然而，前面的定义并不意味着我们一定知道谁拥有密钥。所有权是现实世界的一个抽象方面，与同步本身无关。现实世界的所有权仅与某些共享数据的含义的解释相关，但与数据处理本身无关。

因此，我们引入第三个原则：

*原则3：我们将系统身份和合法身份的认证分开（或将密码身份和元数据分开）*使用密钥，我们可以通过让密钥签署证书来证明某些所有权或与另一个密钥关联的某些事实来构建信任链。然而，此类链的根源始终是根密钥。根密钥本身没有经过认证，也无法验证合法所有权：我们只需要相信它。举个例子，如果我们查看设备上的本地证书存储，那么我们只是相信某个根由指定的证书颁发机构拥有。我们的信念植根于对我们的操作系统提供商的信任，他们只包含合法的密钥。

因此，通过证书将合法身份与加密密钥之间的任何联系都基于这样的信念：控制根密钥的实体是诚实的，并确保附加到信任根的每个人都经过适当的审查。因此，我们只能相信合法身份是适当关联的，但绝对意义上的验证是非常困难的，尤其是在网上更是不可能。

另一个相关方面是身份要求是不对称的属性。虽然大公司希望以其名称（银行）为人所知，但个人往往更加封闭，并且希望仅在必要时才透露其身份（GDPR、HIPAA、机密信息、银行保密）。此外，例如，通过查看不记名债券，所有者对债务人身份的兴趣比债务人对所有者的兴趣要高得多。如果债务人被证明是坏人或欺诈者，所有者可能会损失所有的钱。相比之下，除了某些监管原因外，债务人并不关心他们向谁偿还债券。因此，我们总结出第四条原则

原则 4：账本上的身份是一个不对称问题，需要根据具体情况仔细权衡隐私和公开性。

身份

Canton身份代表Canton同步器上的参与者，例如Canton节点或政党。 Canton 身份由加密证书支持，这样一个身份可以证明它授权了一项操作，而其他人可以验证该操作确实是由该身份授权的。

命名空间

命名空间由根证书定义，该根证书声明允许具有指纹abc123的签名公钥代表命名空间abc123签署拓扑事务。根证书由指纹abc123的公钥对应的私钥签名。这表明命名空间abc123的根证书的颁发者确实拥有相应的私钥。自签名根证书与私钥一起充当命名空间的“信任根”或“信任锚”。

Canton 还可以在没有单一控制密钥的情况下引导多重签名命名空间（参见decentralization）。

与其他公钥基础设施系统类似，Canton 支持中间证书，将代表命名空间的授权权委托给其他密钥（参见topology-authorization-chains）。

唯一标识符

唯一标识符（UID）代表 Canton 同步器上的身份，例如 Canton 节点或一方。它由一个称为标识符的字符串和一个命名空间组成。只要命名空间不同，两个 UID 就可以具有相同的标识符。拥有命名空间的 Canton 密钥持有者控制该命名空间内的所有 UID，并且通常选择引用 UID 角色的标识符。例如，命名空间 abc123 的 Canton 密钥持有者为他们认识的一个名为 Jane Doe 的特定人创建了一个 UID jane_doe:::abc123 的政党。

Canton节点的身份

默认情况下，所有 Canton 节点都会在首次启动时创建一个新身份，除非未显式关闭自动初始化。该身份还充当协议消息（拓扑事务、提交请求）中使用的 UID 的命名空间，以引用该节点。

一方身份参与方标识符与 UID 相同，即命名空间 (abc123) ​​内的标识符 (alice)。默认情况下，参与方标识符是在托管参与者节点 (abc123) 的命名空间内创建的。这将参与方的所有权置于参与者节点名称空间的所有者手中。但是，也可以为一方创建单独的命名空间，将其所有权与托管参与者节点解耦。这是通过为不同的私钥 (xyz789) 创建根证书并在该命名空间 (alice::xyz789) 中创建参与方标识符来完成的。即使参与者节点和聚会不共享相同的命名空间，参与者节点仍然可以托管聚会。

提醒：LAPI 用户与各方（参见 protocol.rst）

拓扑交易的结构

拓扑事务构成了拓扑状态，它以键值映射的形式进行维护。单个拓扑事务总是只影响一个键。只要格式正确且授权良好，他们就会修改值。如果一个拓扑交易通过了所有可以独立于当前拓扑状态进行检查的检查，则该拓扑交易被认为是格式良好的；如果它通过了截至拓扑交易有效时间的所有依赖于拓扑状态的检查，则被认为是经过良好授权的（参见topology-effectiveness）。

拓扑映射

拓扑事务保存或修改有关同步器拓扑状态的某个方面的状态。例如，这可能是某个 Canton 节点使用的所有签名和加密密钥，或者是托管特定方的参与者节点的列表。拓扑事务的内容也称为映射。

每个映射类型都定义了如何根据映射的内容计算唯一键。在任何给定时间，每个唯一键最多可以有一个拓扑事务处于活动状态。例如，PartyToParticipantMapping映射的唯一键由partyId组成。这意味着每个同步器对于给定的 partyId 最多只能有一个活动的 PartyToParticipantMapping 拓扑事务。

所有映射和各自唯一键的定义，请参考topology.proto。

连续剧

拓扑事务的序列用于演化特定唯一键的映射。唯一密钥的第一个序列始终从 1 开始。任何后续拓扑事务都必须将同一键的前一个拓扑事务的序列加一。不得有间隙（不允许从1到3）或重复（相同序列但内容不同）。但是，可以将预期授权者的附加签名添加到已经完全授权且当前有效的拓扑事务中。稍后会详细介绍。

拓扑事务上的串行可防止重放攻击。恶意行为者不能简单地获取先前完全授权的交易并再次提交，因为同步器上的 Canton 节点检测到意外的序列，因此拒绝拓扑交易。

改变操作

拓扑事务指定它是替换 (REPLACE) 还是删除 (REMOVE) 先前的映射。在使用序列号1进行第一次映射的情况下，替换操作充当创建或添加。删除映射时，它必须与前一个序列的拓扑事务具有相同的内容。具有REMOVE操作的事务必须遵循与具有REPLACE操作的事务相同的序列号规则，因为它只是事务日志中的一个条目。实际上没有从拓扑状态中删除任何数据。因此，通常也可以通过使用REPLACE操作提交拓扑事务以及使用REMOVE操作提交拓扑事务序列的后继来“重新激活”先前删除的映射。

签名所有拓扑映射都精确定义了哪些身份必须在拓扑事务被视为获得良好授权之前提供授权。在 Canton 中，身份通过向同步器的所有成员提供拓扑事务的加密签名来表达其授权。

例如，在参与者节点（p1::xyz789）上托管一方（alice::abc123）需要该方所有者和参与者节点所有者的授权和签名。该方必须授权其希望参与者节点处理该方的敏感数据。另一方面，参与者节点必须承担托管一方的操作职责，例如接收和处理该方的交易。如果双方和参与者节点拥有相同的身份，则一个签名就足够了。

拓扑事务的加密签名涵盖映射、串行和更改操作。因此，篡改拓扑事务的任何这些属性都会使现有签名无效。同样，先前拓扑事务的签名不能用于任何其他拓扑事务，因为签名所覆盖的数据不相同，即使对于相同的唯一密钥和相同的内容也是如此。至少序列必须在唯一密钥的值的后续演变中改变。

拓扑映射的类型

命名空间定义和委托

如topology-namespaces部分所述，命名空间由自签名根证书定义。具体来说，根证书是自签名的NamespaceDelegation（NSD），其中命名空间、目标密钥和用于签署交易的密钥相同。这表示为NSD(namespace=ROOT_KEY, target=ROOT_KEY, signedBy=ROOT_KEY)。该密钥可用于代表该命名空间签署所有其他拓扑事务。

Canton 钥匙持有者还可以将授权权委托给其他钥匙。有关这些主题的更多详细信息，请参阅topology-authorization-chains和topology-key-revocation。

NamespaceDelegation 拓扑映射允许您将目标签名密钥限制为仅用于某些拓扑交易。限制分为三种：

• CanSignAllMappings：允许目标密钥对当前已知的所有拓扑映射以及可能在未来 Canton 版本中添加的任何拓扑映射进行签名。
• CanSignAllButNamespaceDelegations：允许目标密钥对当前已知的所有拓扑映射进行签名，但其他NamespaceDelegation映射以及未来 Canton 版本中可能添加的任何拓扑映射除外。此限制通常用于充当日常使用的根密钥替代品的密钥，以便出于安全原因可以将实际的根密钥移至冷存储。
• CanSignSpecificMappings(mappings)：目标密钥只能用于对mappings参数中显式列出的拓扑映射进行签名。这有助于实施严格的安全方案，以划分影响区域，以防密钥被泄露。

加密密钥

Canton 密钥持有者在通过 Sequencers 通过共享账本相互通信时使用加密签名和加密密钥。签名允许接收者验证每条消息的发起者，而加密则确保这些消息中的敏感数据保持机密。

Canton 密钥持有者声明他们想要在拓扑映射中使用哪些密钥； OwnerToKeyMapping适用于 Canton 节点，PartyToKeyMapping适用于外部各方（参见overview_canton_external_parties）。 Canton 密钥持有者将这些拓扑映射中列出的密钥用于跨 Canton 通信协议层的各种用例（参见protocols），拓扑管理除外。具体来说，OwnerToKeyMapping和PartyToKeyMapping中的签名密钥不能用于签名拓扑交易，除非相同的密钥也是NamespaceDelegation的目标。出于安全原因，强烈建议不要这样做。

拓扑状态中的各方各方通过PartyToParticipant拓扑映射声明，它定义了托管该方的参与者节点。托管一方赋予参与者节点为该方处理 Daml 交易的权利（如果不是义务）。这使参与者节点可以访问该方的合同。因此，一方的所有者（即该方名称空间的密钥持有者）必须仔细选择哪些参与者节点值得信赖来处理该方的敏感数据。

从参与者节点的角度来看，举办派对意味着对该派对有一定的责任和义务。最值得注意的是，参与者节点应参与该方事务的两阶段提交协议，并将数据存储在本地，以便应用程序可以代表该方访问数据。

当事人的所有者和参与者节点都必须同意通过授权各自的PartyToParticipant拓扑交易来进入这种关系。

• 观察：参与者节点仅收到托管方作为利益相关者的交易通知。
• 确认：作为两阶段提交协议的一部分，参与者节点确认或拒绝 Daml 事务。此权限包含观察权限。
• 提交：参与者节点被授权为该方提交Daml交易。此权限包含确认权限。

提交和确认之间的区别仅在参与者节点中强制执行。具有某一方确认权限的恶意参与者节点可以以该方名义提交Daml交易。这是由于 Canton 的高度隐私性，验证者不知道提交参与者节点的身份。因此，将确认权限委托给参与节点的一方应该充分信任该参与节点。

一方的所有者可以决定将该方托管在多个参与者节点上（请参阅decentralized-parties）。

包审查

验证 Daml 交易最终意味着运行第三方编写的 Daml 代码。这使参与者节点面临一定的风险，因为 Daml 代码可以运行任意长的时间并消耗大量内存。因此，参与者节点的所有者必须明确声明他们同意在其参与者节点上运行哪些包。他们通过拓扑映射VettedPackages来做到这一点。参与者节点的所有者可以将对包的审查限制在特定的时间范围内，该时间范围在任何一方都是开放的。此外，VettedPackages拓扑映射决定了将使用哪个版本的Daml模板来解释Ledger API命令。

具有同步器的会员资格

要将 Canton 节点加载到同步器，它必须提供其身份拓扑交易，其中至少包括节点的根证书NamespaceDelegation 和节点OwnerToKeyMapping 拓扑交易中的加密密钥。这种特定的拓扑事务包称为“身份事务”。对于三种节点类型，Canton节点的实际成员资格的表达方式有所不同：

• 参与者节点：当连接到同步器时，参与者节点会提交其身份交易以及自动生成的同步器TrustCertificate拓扑交易，该拓扑交易特定于参与者节点的UID和同步器的同步器Id的组合。因此，不能从一个同步器获取并在另一同步器上重放，因为拓扑映射中包含的同步器Id将与目标同步器不匹配。因此，同步器TrustCertificate是一个明确的信号，表明参与者节点的所有者希望参与者节点成为同步器的成员。* Sequencer：如果 同步器 的拓扑状态包含 Sequencer 的身份事务，并且 同步器 所有者已将 Sequencer 添加到 同步器 的Sequencer同步器State 拓扑映射中，则 Sequencer 被视为 同步器 的成员。该映射列出了同步器的所有定序器，并由同步器所有者控制。 Sequencer 不需要授权将其添加到Sequencer同步器State 映射中的原因有多种：

  1. 同步器所有者有兴趣为参与者节点提供良好的服务。如果 Sequencer 尚未准备好或不愿意为其他会员提供服务，那么它的广告就无法实现良好服务的目标。无论如何，同步器所有者可能都有法律合同来管理与同步器上运行的第三方定序器的关系。
  2. 一个 Sequencer 只能服务于一个 同步器，这意味着 Sequencer 是为了成为某个 同步器 的成员这一特定目的而被引导和设置的。
  3. 考虑到 同步器 所有者和 Sequencer 所有者的目标是一致的，不需要 Sequencer 所有者授权将 Sequencer 添加到拓扑状态，从而显着简化了 Sequencer 的加入过程。

  有关如何将定序器加载到同步器的更多信息，请参阅dynamically_adding_sequencers。

• Mediator：Mediator 的成员身份与 Sequencer 的成员身份类似：其身份交易必须处于拓扑状态，并且 同步器 所有者已将 Mediator 添加到Mediator同步器State 拓扑映射中。可以有多个这样的映射，以防 同步器 所有者决定允许将 Mediator 工作负载分配给多个 Mediator 组（请参阅optimize-mediator）。调解员只能属于单个调解员组。有关如何加入调解员的更多信息，请参阅dynamically_adding_mediators。

演化拓扑映射

提案

Canton节点将授权不足的拓扑交易视为提案，并且在计算特定时间戳的拓扑状态时不考虑它们。但即使签名不足，提案也必须格式良好，就好像它是完全授权的交易一样。

当 Canton 节点收到提案时，它首先将同一拓扑交易的任何先前成功验证的提案的签名合并到提案中，然后才继续使用所有已知签名验证生成的提案。这对本地已存储的提案没有影响。一旦足够数量的身份提交了提案的签名，如果所有验证均成功通过，则该提案将成为完全授权的拓扑交易。

提案没有过期时间戳。这意味着提案处于待处理状态，直到提交足够的签名以使其完全授权，或者 Canton 节点成功验证同一唯一密钥的完全授权的拓扑交易。

示例

起点是参与方 Alice::abc123 及其在串行 1 处的托管参与者节点 P1::abc123 的 PartyToParticipant 映射。聚会的所有者现在希望参与者节点P2::xyz789也主持聚会。因此，该方的所有者提交了一个映射提案，其中包括P2::xyz789作为具有序列号2的托管参与者节点。根据PartyToParticipant映射定义的授权规则，命名空间abc123和xyz789的密钥持有者必须授权此更改。由于该方的所有者只能提供命名空间abc123的签名，因此Canton节点将序列号为2的拓扑交易存储为提案。一旦新的托管参与者节点的密钥持有者将此拓扑交易的签名提交给同步器，Canton 节点就会合并签名并在成功验证后存储现在完全授权的PartyToParticipant 映射。

<图片src=“https://mintcdn.com/cantonfoundation/zmlOjLpKuDjnaObr/images/docs_website/topology-simple-proposal.svg?fit=max&auto=format&n=zmlOjLpKuDjnaObr&q=85&s=1b5291fc4e2746386169ec1645392029” className=“align-center” style={{width: “80.0%”}} alt=“image” width=“1062” height=“502” data-path=“images/docs_website/topology-simple-proposal.svg” />

并发/竞争提案

当 Canton 节点提交具有相同唯一键、相同序列但内容不同的映射提案时，它们会产生竞争提案。这些拓扑事务是提案，因为它们尚未完全授权，并且它们正在竞争，因为第一个获得完全授权的提案会自动使相同唯一密钥和相同序列的所有其他提案无效。

示例

为了说明这一点，请考虑参与者节点 P1::abc123 托管参与方 Alice::abc123 的场景。 abc123 的密钥持有者正在与参与节点 P2::xyz789 和 P3::jkl456 的另外两个密钥持有者进行谈判。其他两位关键持有者决定提交他们的提案来主办Alice::abc123。两者都发送带有串行2的拓扑事务，以将自己添加为托管参与者节点。由于需要abc123的签名才能满足授权要求，因此在abc123决定签署其中一笔交易之前，这两笔交易都被视为提案。在这个例子中，abc123选择允许在P3::jkl456上托管Alice并签署相应的提案，将其转变为完全授权的交易。 P2::xyz789的提案自动失效，因为现在存在序列号为2的完全授权交易。 P2::xyz789的提案不可能有效，因为对于给定序列的唯一密钥最多可能只有一个完全授权的拓扑交易。

<图片src=“https://mintcdn.com/cantonfoundation/zmlOjLpKuDjnaObr/images/docs_website/topology-competing-proposals.svg?fit=max&auto=format&n=zmlOjLpKuDjnaObr&q=85&s=295178e51b3c4e56b24aeddc0444c4ec” className=“align-center” style={{width: “80.0%”}} alt=“image” width=“1062” height=“942” data-path=“images/docs_website/topology-competing-proposals.svg” />

有效性/有效性

在验证从排序器接收到的拓扑事务后，Canton 节点根据拓扑事务的排序时间确定性地计算拓扑事务的所谓“有效时间”。更多关于有效时间的计算，请参考topology-sequential-validation和topology-future-dating章节。序列号为n的唯一密钥的拓扑交易的有效时间标记了拓扑交易有效期的唯一开始，同时标记了序列号为n-1的相同唯一密钥的前一个拓扑交易以及序列号为n的相同唯一密钥的所有提案的包含结束时间戳。序列号为n的完全授权拓扑交易会触发序列号为n的提案“过期”，因为它会阻止这些提案获得完全授权，因为下一个完全授权的拓扑交易必须具有序列号n+1。相反，序列号为n+1的提案验证成功并不能确定序列号为n的完全授权拓扑交易的有效期结束。

作为有效期定义的结果，唯一密钥的所有完全授权的拓扑交易都会构建一个没有间隙的“有效性时间线”，它明确定义了哪个拓扑交易在任何给定时间点被认为是有效的。

传播拓扑交易

本节介绍 Canton 参与者节点和同步器组件如何了解同步器上拓扑状态的更改。由于没有管理和验证拓扑状态的集中式组件，因此每个同步器组件和参与者节点自行接收并验证拓扑状态的所有更改。

广播拓扑变化连接到同步器的 Canton 节点将发送给广播接收组AllMembersOf同步器的拓扑事务提交给定序器。该组地址到具体成员的解析是由排序器使用事务的排序时间作为参考时间来完成的。节点必须拒绝未发送至广播接收组的拓扑事务，因为接受此类拓扑更改可能会因拓扑状态发散而导致分类帐分叉。

Canton 节点的操作员可以使用 gRPC 管理 API 或管理控制台命令来发出新的拓扑事务。

顺序验证

Canton节点以严格顺序的方式一个接一个地验证拓扑事务。该系统目前不跟踪拓扑事务之间的依赖关系或冲突，这是一项非常容易出错且脆弱的复杂任务。如果没有这种跟踪，并行处理拓扑事务将使验证状态机变得不确定，并导致 Canton 节点之间的拓扑状态出现分歧。因此，为了确保同步器所有成员的拓扑状态的完整性，必须按顺序完全处理所有拓扑事务。

Canton 协议的各个层（参见protocols）依赖于拓扑快照来访问处理该层的相应事件或消息所需的拓扑状态。拓扑快照由拓扑更新通过拓扑事务驱动，并且为了计算拓扑快照，Canton 节点必须确保截至该时间戳的所有拓扑事务都已被处理。否则，拓扑状态将不完整，并且可能会错过与该层消息处理相关的重要更改，例如，对参与方托管或审查包的更改，或对 Sequencer 签名密钥的更改。因此，各个协议层必须仔细选择拓扑快照的时间戳以避免死锁。

一般消息处理和拓扑状态之间的依赖性主要是由于需要验证每条消息上的定序器签名。

解决这种依赖性的一个简单方法是将拓扑事务与其他事件分离到专用块中，以便它们获得单独的排序时间并单独处理。

这种简单方法的缺点是任何拓扑事务都会暂时停止其他消息的处理，无论时间多么短暂。这会损害延迟和吞吐量。

未来约会

解决拓扑事务暂停各个协议层中的消息处理问题的一种方法是使拓扑事务在未来的某个时刻生效。 有效时间的概念已在topology-effectiveness节中介绍过。虽然拓扑事务在时间t排序，但只有在拓扑更改延迟ε之后才生效。时间t+ε给出了有效时间的下限。如果拓扑变化延迟最近没有发生变化，则有效时间等于下限t+ε。拓扑更改延迟是拓扑状态中的动态 同步器 参数，可由 同步器 所有者更改。因此，用于计算有效时间的实际拓扑变化延迟必须在拓扑交易验证期间从拓扑状态中读取。

这种机制使得t和t+ε之间的其他消息和事件能够正常处理，而无需等待拓扑处理层。拓扑变化延迟ε应该有多大？权衡是在不阻塞其他消息的处理和不等待太长时间拓扑事务生效之间进行。拓扑更改延迟应该略大于处理拓扑事务所需的延迟。当拓扑更改延迟为 0 ms 时，拓扑事务会立即生效，但如上一节所述，其他消息的处理需要等待，直到 Canton 节点可以确定该消息所需的拓扑快照没有待处理的拓扑事务。另一方面，由于拓扑更改延迟为 30 秒，Daml 交易不太可能被阻止处理，但需要相当长的时间才能真正在交易中使用一方。

为了说明未来约会的好处，请考虑以下示例。 t3 时拓扑事务的有效时间计算为 t5。因此，一旦拓扑事务的处理完成，t4处的Daml事务处理就可以访问t4处的拓扑快照，因为Canton节点知道，它已经看到了与直到t5的快照相关的拓扑状态的所有变化。

<img src=“https://mintcdn.com/cantonfoundation/zmlOjLpKuDjnaObr/images/docs_website/topology-change-delay.svg?fit=max&auto=format&n=zmlOjLpKuDjnaObr&q=85&s=cd3af34a3511214df8fc8a504c59a907” className=“align-center” style={{width: “80.0%”}} alt=“image” width=“722” height=“282” data-path=“images/docs_website/topology-change-delay.svg” />

授权

第 topology-signatures 节提到拓扑映射定义了确定拓扑事务所需的授权者被视为完全授权的规则，并指出密钥持有者通过将拓扑事务上的加密签名传播到同步器来表达此授权。

本节将更详细地介绍这些方面。

授权规则

每种类型的拓扑映射都会更改同步器拓扑状态的某个方面，这必须由受该更改影响或负责该更改的密钥持有者授权。换句话说，只有密钥持有者才能在其职责范围内更改拓扑状态。例如，只有参与者节点的密钥持有者可以更改由该参与者节点审查的包列表。类似地，只有同步器的密钥持有者可以改变同步器的动态参数。

所有映射的定义以及各自的授权规则请参考topology.proto。

某些拓扑映射为某些更改定义了多个所需的授权者。一种常见的情况是，一方在参与者节点上托管，但该节点不属于与该方相同的密钥持有者。这种场景在演化拓扑映射的示例中有所展示（参见topology-proposals-example）。一方面，托管一方使参与者节点能够访问属于该方的 Daml 事务中的数据。因此，该方的密钥持有者必须表示同意其希望参与节点接收并处理该方的Daml交易。另一方面，参与节点的密钥持有者必须同意托管该方，因为托管该方会产生网络和存储成本，并且有义务遵守涉及该方的 Daml 事务的两阶段提交协议。

授权链如topology-namespaces和topology-delegation部分所述，命名空间的根证书充当信任锚。出于安全原因，建议将根命名空间密钥保存在安全冷存储中，以降低未经授权访问密钥的风险。这一点尤其重要，因为根命名空间密钥无法滚动，因为生成新密钥将有效地创建新的命名空间。因此，Canton 支持实施这一建议的安全实践，允许 Canton 密钥持有者将授权权限委托给非根命名空间密钥的其他密钥。

仅使用命名空间的根证书，第一个命名空间委托必须由根密钥：NamespaceDelegation(namespace=ROOT_KEY, target=KEY1, signedBy=ROOT_KEY) 签名。 ROOT_KEY 代表的命名空间的密钥持有者现在可以使用 KEY1 签署其他拓扑事务，包括进一步将命名空间委托给其他密钥，并将私钥 ROOT_KEY 从实时系统中移出。

每当 Canton 节点验证拓扑交易的签名时，它都会验证签名本身是否正确地签署了拓扑交易，但它也会检查是否存在从签名密钥到根命名空间密钥之间没有间隙的证书或委托链。

考虑以下场景，其中命名空间abc123的密钥持有者为密钥def456创建根证书和“根替代”证书。根替代的密钥又被限制为只能签署其他命名空间委托并签署“主拓扑签名密钥”ghi789。此签名密钥无法签署其他命名空间委托，但可用于签署任何其他拓扑事务。

继续这个例子，假设命名空间abc123的密钥持有者在同步器上广播由密钥ghi789签名的参与方alice::abc123的PartyToParticipant映射。当验证此拓扑交易时，同步器上的所有 Canton 节点都会为命名空间abc123构建所有命名空间委托的有向无序图，并验证在拓扑交易生效时拓扑快照中是否存在从根证书abc123到密钥ghi789的有效证书链。确实有这样一条链abc123 -> def456 -> ghi789。

密钥撤销

Canton 密钥持有者可以通过使用 REMOVE 操作广播该密钥的命名空间委托来撤销中间证书。此撤销不会使使用现在撤销的证书的密钥签名的先前验证的拓扑事务无效，因为在验证时它仍然是有效的证书。撤销生效后，Canton节点必须拒绝该密钥代表命名空间所做的签名。此外，由已撤销证书的密钥签名的所有证书现在都被视为“悬空”。尽管它们本身没有被撤销，但它们和根证书之间现在不存在有效证书链。与吊销证书的情况类似，证书处于悬空状态的事实不会使由现在悬空证书的密钥签名的先前验证的拓扑事务无效，因为它在成功验证时不是悬空的。

继续上一节的示例，abc123 的密钥持有者撤销了密钥 def456 的证书，这使得密钥 ghi789 的证书悬空。因此，Canton 节点必须拒绝代表命名空间 abc123 由密钥def456 或ghi789 进行的未来拓扑交易的任何签名。

<图片src=“https://mintcdn.com/cantonfoundation/zmlOjLpKuDjnaObr/images/docs_website/topology-broken-certificate-chain.svg?fit=max&auto=format&n=zmlOjLpKuDjnaObr&q=85&s=a320d00fd39768acdb0169d187c53b04” className=“align-center” alt=“image” width=“1361” height=“502” data-path=“images/docs_website/topology-broken-certificate-chain.svg” />

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