Canton 多重签名

Canton 中的去中心化命名空间、Party 托管与多重签名提交。

去中心化的命名空间、去中心化 Party托管以及在 Canton 中提交的去中心化签名。

简介

在 Canton 协议中，在高层，有三种类型的交易需要签名：提交、确认和拓扑交易。提交是由一方或多方提交的更改账本状态的请求。确认是交易对手对已提交交易的批准，证明交易有效且可以提交。最后，拓扑交易修改网络的共享全局拓扑状态：它们确定哪些验证者托管一方，该方授予验证者哪些权限（提交、确认或观察），以及该方将使用哪个公私密钥对来授权交易。

多重签名或去中心化的理念（其中一个操作需要多个签名）可以应用于每种类型的交易。本文档将引导您完成设置选项：

1. 去中心化命名空间（对拓扑事务应用去中心化控制）
2. 去中心化Party托管（用于去中心化交易验证和确认）
3. 给定方交易提交的去中心化签名，包括用于实现 Daml 交易多重签名工作流程的 Daml 模型，以及使用外部Party的多重签名提交。

1：分散控制拓扑变化

Canton 的信任根源是私人交易签名密钥（或多个密钥），它为交易生成签名，证明给定方已授权该交易。 *将签名密钥与Party相关联的交易是“拓扑”交易的一个示例。授予验证者节点代表一方创建和存储数据的权限（确认和观察权）的交易“也是”拓扑交易的示例。

因此，Canton 的去中心化的第一个层次是是否将拓扑交易的控制权下放给某一方。如果单个私钥-公钥对控制此关联，则该密钥对中私钥的签名可以更改该方的签名密钥。

如果密钥与一方的关联需要来自多组密钥的签名，则对该方本身的控制是分散的。我们将Party签名密钥的去中心化控制称为“去中心化命名空间”：也就是说，去中心化命名空间将 partyID 映射到密钥，而不依赖于单一权限。

创建去中心化命名空间

要创建一个由去中心化命名空间控制密钥到Party映射的Party，您可以构建、授权并提交一组特定的拓扑交易：

1. 命名空间委托交易

创建 N 个NamespaceDelegation 交易，每个交易都注册一个公钥，该公钥将作为去中心化命名空间的基础。要获得授权，每笔交易都必须由各自的密钥进行签名（其作用类似于自签名根证书）。

2. 去中心化命名空间的形成创建DecentralizedNamespaceDefinition交易。这是指在上一步中建立的N个密钥，它定义了一个小于或等于N的有效性阈值T。要获得授权，这个DecentralizedNamespaceDefinition交易必须由所有N个命名空间所有者密钥签名。

在去中心化命名空间（由其控制）中创建并创建 Party

创建一个PartyToParticipant transaction，说明Party的举办地点。该交易在 Canton 3.4 中具有三个不同的目的：

• 授权Party举办：PartyToParticipant交易规定Party将在哪里举办以及拥有什么权利（提交、确认、观察）
  • 必须由 N 个命名空间所有者中的至少 T 个签名
• 注册密钥：在Canton 3.4中，Party的协议签名密钥（或多个密钥）也可以而且应该在PartyToParticipant交易中注册。
• 证明所有权：该交易还必须由其注册的协议密钥进行签名，以证明相应私钥的所有权。

有了上述交易和相应的签名，这些拓扑交易就可以提交到 Ledger API 上的 allocateExternalParty 端点，从而创建去中心化方。交易中指定的所有托管节点必须批准该交易才能生效。

在此设置中，Party在两个不同的阈值层受到保护：

1.身份控制：Party的命名空间由命名空间所有者通过DecentralizedNamespaceDefinition进行管理（需要T签名） 2. 操作控制：Daml 交易的授权由PartyToParticipant 交易中定义的协议密钥控制。

有关设置去中心化命名空间或跨多个确认节点分配一方的更多详细信息，请参阅 Canton 文档。

无论您是否通过分散的命名空间分散对拓扑事务的控制，您都可以选择使用一个或多个签名密钥来签署给定方的提交。我们将在第 3 节中介绍这一点。

2：去中心化确认

由于 Canton 的隐私模型，每笔交易都需要由托管交易利益相关方的参与者确认。拓扑状态中的partyToParticipant映射定义了网络中的每一方由哪些参与者托管，因此应该为所述Party签署确认。在 partyToParticipant 映射中拥有多个验证者的一方称为“多托管方”。*当与高于 1 的确认阈值相结合时，多托管方可称为“去中心化方”。该阈值定义了在确认被视为由该方签名之前，需要有多少个验证节点对确认进行签名。每笔需要该方确认的交易都会发送给其partyToParticipant映射中列出的所有参与者，一旦来自不同参与者的确认数量超过阈值，则该交易被视为已被该方确认。

3：分散对命令提交的控制Canton 账本状态通过参与者提交命令来更改，该命令将命令扩展为 Daml 交易。每个命令提交均由授权并提交该命令的一方（或多方）签名。对于广州的标准（非去中心化）Party来说，这很简单：该Party托管在参与者节点上，并通过该节点提交命令。对于去中心化的一方来说，这变得更加复杂，因为需要弄清楚谁（即哪个用户，通过哪个参与者）执行实际的提交，以及他们如何证明来自一定数量的用户的权限来代表去中心化的一方行事。

代表去中心化一方提交的方法主要有三种，每种方法都有自己的优点和缺点：

1. 使用Daml工作流程通过委派收集权限 2.Daml内签名验证
2. 多重签名的外部签名

通过委托 Daml 工作流程收集权限

Daml 中的一个常见模式是授权代表其他方执行操作。例如，提议-接受工作流程可能包含多个步骤，这些步骤收集资产发送者和接收者的委托以执行特定交易。根据具体的工作流程，任何一方都可以在另一方的授权下提交交易以进行转移。

这种模式可以用于将权力委托给“简单”的人，即非去中心化Party提交交易，然后由去中心化方确认。在这种情况下，您通常会与去中心化方作为签署人签订一份“规则”合同，并在该合同中选择定义不同参与者可以执行的操作。 “规则”通常包括可以采取实际行动的Party名单以及在何种条件下采取行动。

以 Canton Coin 应用程序为例，dsoParty 是一个去中心化方，是 [dsoRules 上的签名者合同]（https://github.com/hyperledger-labs/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L441））。该合约有一个超级验证者列表（`svs`参与申请的[字段]（合约中的https://github.com/hyperledger-labs/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L444）。

假设某些条件成立，任何 SV 都可以采取某些行动。这些条件是通过 Daml 工作流程本身中的断言来强制执行的。例如，任何 SV 都可以执行 DsoRules_Amulet_Expire选择 存档 Amulet 合约其有效期已过。其他操作需要从其他 SV 收集足够的确认。这也在Daml中实现。例如，任何 SV 都可以调用 [DsoRules_RequestVote选择]（https://github.com/hyperledger-labs/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L674C34-L674C43）。然后任何 SV 都可以通过调用 [DsoRules_CastVote选择]（https://github.com/hyperledger-labs/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L712）。然后，任何 SV 也可以调用 DsoRules_CloseVoteRequest 选择完成该过程。在Daml中编码的条件下（例如，有足够的“Yay”票，并且已达到一定时间），dsoParty可以采取投票的行动。请注意，该过程中的所有提交都是由“简单”、非去中心化的Party（例如 Canton Coin 中的 SV 方）执行的。

在文档的最后，我们将首先回到引导问题，即如何创建去中心化方拥有的“规则”合约。

这种方法的优点：

• 所有操作（特别是投票和操作提交）都作为单独的账本交易可见。
• 它不需要托管去中心化方的各个节点的运营商之间进行任何账外通信。他们在账本上观察彼此的行为，并拥有在账本上采取相应行动所需的所有信息。

这种方法的缺点：

• 由于每个步骤（例如每次投票）都是账本上的交易，因此同步器上的流量相对昂贵。根据操作频率，这可能不切实际。

Daml 内签名验证

在这种方法中，与前一种方法一样，单方（“不是”去中心化方）代表去中心化方提交命令。然而，收集签名的过程是在账本之外进行的。收集到的签名作为 Daml 选择的参数提交，签名验证作为 Daml 断言实现。

断言签名有效性的 Daml 选择示例可以在 Daml 测试代码 中找到。然后，这可以扩展到断言签名阈值的存在和有效性的选择。它仍然是去中心化方拥有的“规则”合约上的选择，其中选择的控制者是另一方，但收集签名（或“投票”）的过程不再在该合约中实现。

通过这样的选择收集签名和提交交易的过程将是：* 每个成员（签名密钥的控制者）签署一些商定的账外“编码命令”。例如，这可能是一些商定的 JSON 结构，用于对要执行的命令的详细信息进行编码。

• 签名通过某种账外通道收集到将提交交易的节点。
• 提交节点通过上述选择构建单个 Daml 交易，包括收集的签名作为参数。
• Daml 代码中的断言确认有效性，并且执行操作。

这种方法的优点：

• 可审计性仍然很高，与第一种方法类似，因为提交的交易文件已收集签名的账本上。
• Daml 工作流程更简单，因为签名收集（例如“投票”）是在账本外进行的。
• 账本流量更便宜
• 签署证明和在账本上验证证明之间没有超时。启用可以在提交时间之前很久就给出授权签名的工作流程，例如气隙离线签名

这种方法的缺点：

• 需要额外的账外通道来收集签名，确保签名不会丢失等。
• 可审计性稍低，因为未提交的签名不会记录在账本上

Daml 交易提交的外部多重签名

您可以将外部方配置为需要签名阈值（多重签名）才能提交 Daml 交易。此设置将签名协调转移到账本外，同时保持账本上的 Daml 代码更简单。

首先通过 PartyToParticipant 拓扑事务将多个协议签名密钥与Party关联起来。此配置规定：

• 主办： 哪些节点主办Party。
• 提交权利： 公钥（协议签名密钥）列表和授权提交所需的阈值（例如 5 中的 3）。

准备和提交需要多个外部签名的交易的过程：

• 准备： 参与节点准备交易有效负载（受全局超时限制，通常为 24 小时）。
• 分发： 有效负载被带外发送给所需的签名者。
• 签名： 每个成员在本地验证并签署有效负载。
• 收集并提交： 提交节点收集签名。一旦满足 PartyToParticipant 中定义的阈值，它就会构建最终的信封并将其提交到分类帐。

另请注意，外部多重签名可以保护密钥不被窃取，但不能防止恶意托管节点忽略签名要求。为了防止恶意节点，Party必须是多托管（如第 2 节中所述），确认阈值 > 1。这迫使多个节点独立验证外部签名。

这种方法的优点：* 更简单的 Daml – 无需更改 Daml 模型；该方的行为与代码中的任何其他实体一样。

• 标准身份——去中心化的本质是从应用程序逻辑中抽象出来的。

这种方法的缺点：

• 复杂的协调——需要强大的账外基础设施来分发有效负载并收集签名。
• 复杂的验证 – 签名者必须在签名之前解码并检查原始交易二进制文件。
• 有限的可审计性 – 单个签名由协议验证，但在 Daml 模型历史记录中不可见。

选择命令提交方法的指南

上述优点和缺点将指导您首选的实施方式，总结一下：

• 如果您预计去中心化方的提交相对较少，并且愿意编写更复杂的 Daml 协调逻辑，您可能需要选择“通过委托 Daml 工作流程收集权限”。您将受益于无需建立账本外渠道和账本上的完全可见性。
• 如果您仍然想要账本可见性，但需要不太复杂的 Daml 工作流程，并且可以在节点之间建立（或已经拥有）账本外通道，那么“Daml 内签名验证”可能是一个不错的选择。
• 最后，如果不需要签名的账本可见性，并且您对更复杂的账外流程和节点之间的通信感到满意，那么您可能需要考虑“外部多重签名”。

其他主题

引导多重签名 Daml 工作流程

前两种方法都要求存在去中心化方拥有的“规则”合约，这提出了引导问题，或者更简单地说，如何到达该合约存在的地步？

这个问题有两个可能的答案：

• 最初将去中心化方引导为中心化方，并在去中心化方之前创建此合约。这是更简单的方法，因为引导交易的提交是简单的非去中心化提交，但在某些情况下可能会导致对引导节点的信任和责任的担忧。
• 使用多重签名外部签名来创建“规则”合约。这基本上利用了第三种方法，即外部多重签名，来签署单个交易，该交易仅通过创建初始合约来引导流程。以下工作流程可以遵循其他任一选项来从该合同中获取权限。

如果你开始集中化，那么单一的钥匙持有者就拥有绝对的权力。要过渡到去中心化，单个密钥持有者必须签署DecentralizedNamespaceDefinition。这是一种“可信设置”方法。

密钥管理

根据您的设置，上面可能会使用四组按键。任何给定的设置都将使用其中的两组或三组按键。* 参与者内部密钥，参与者用来签署确认书

• 命名空间成员密钥，用于签署拓扑交易。强烈建议创建这些单独的密钥，如文档中所示。
• 如果使用外部签名，则还需要外部签名密钥。通常可以接受这些密钥重复使用与名称空间密钥相同的密钥，但也可以将它们设置为不同的以提高安全性。
• 同样，如果使用 in-Daml 签名验证，则需要用于此签名的密钥。 In-Daml 签名可以重用与命名空间密钥相同的密钥，但它们也可以是不同的密钥，以提高安全性。

与拓扑变化相关的风险

在具有确认权限的附加节点上创建 Party（加入附加节点）

可以通过称为离线Party复制的过程来更改托管去中心化命名空间和Party的参与者集以及相应的阈值。

请注意，当前的离线派对复制过程会给新托管该派对的节点带来一些风险，并且当前流程中的某些错误可能会导致该节点出现错误状态。

具体来说，新节点可以确认不应批准的新交易，并且还可以在Party复制期间在某些条件下创建重复的合约。这两个已知问题都将在未来的 Canton 版本中得到解决。

在这些问题得到解决之前，在扩展去中心化方托管的节点池时，您应该始终使用新节点。如果加入过程产生上述错误情况之一，导致节点无法使用，您可以轻松更换新节点。

一旦去中心化方加入到新节点，就可以安全地将该节点用于其他目的，因为在 Canton 3.3 和 Canton 3.4 中，将去中心化方从节点脱离被认为是安全的过程。

从托管该方的节点中删除/卸载该方

从 Canton 3.4 开始，如果满足以下条件，则可以安全地从验证者节点中删除一方：

1. 验证者仅连接到单个同步器，并且该节点上尚未安装多同步器应用程序。
2. 该方永远不会重新加入该验证者节点。

关闭拥有（提交、确认、观察？）权限的一方的节点

完全关闭（“关闭”或“退役”）托管一个或多个参与去中心化确认池的验证者节点是安全的。

在Sequencer修剪窗口内（例如，全局同步器上的 30 天）将此节点带入网络也是安全的。在Sequencer修剪窗口之后，可能会发生许多目前尚无已知解决方案的故障。

对恶意托管参与者的影响只要有足够有效的参与者可以达到法定人数，托管多重签名方的恶意或故障节点就不会影响交易处理的完整性或可用性。

然而，恶意或故障节点可能会发送无效的 ACS 承诺。这些承诺是参与节点之间交换的定期检查点，以使彼此对当前状态放心。这些承诺不会影响交易处理，但如果两个参与节点开始出现分歧，它们会向节点操作员发出警报，并阻止节点的修剪，直到分歧得到解决或明确忽略。

如需进一步阅读，请参阅去中心化。

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