CN113196270A - 隐私保护验证和提交架构 - Google Patents

Abstract

一种调度和验证多参与者过程的方法(400)，该方法包括：由与多参与者过程中的参与者相关联的提交节点(210)通过将受密码保护消息(140)发送到一个或多个接收方节点(120、122)来提交(420)拟议交易，其中受密码保护消息(140)至少包括外部节点(130)可读取的未加密子消息(142)，以及至少保护来自外部节点(130)的隐私的受密码保护子消息(144)；由外部节点确定(410)拟议交易相对于其它交易的顺序；通过接收方节点中的至少一些，验证受密码保护消息；从接收方节点中的至少一些接收(440)对受密码保护消息的有效性确认；基于从接收方节点中的至少一些接收满足确认条件的一个或多个确认，将拟议交易作为确认交易来完成(450)；以及根据由外部节点确定的顺序，将确认交易写入(460)到分布式账本中。

Description

隐私保护验证和提交架构

技术领域

本公开涉及一种计算机系统，其包括用于隐私保护验证和提交架构的多个节点。本公开还涉及一种验证多参与者过程以将交易提交到分布式账本的方法。

背景技术

在分布式计算中，确保一致性的问题称为状态机复制问题。拜占庭容错解决方案可以解决此问题，同时确保状态(即工作流)演化的有效性，即使在相互不信任的情况下也是如此。

诸如比特币和以太坊之类的加密货币系统可能至少对状态机复制问题有部分解决方案(还有其它“无许可”要求)。然而，这类现有解决方案不适用于许多应用。一种这样的应用程序是在多参与者过程中提供隐私，其中工作流的演变通常只对当事参与者可见。解决此问题的方案是使用集中式节点来验证，同步交易并将交易提交到分布式账本。然而，为此目的使用集中式节点可能不适合一些应用，因为必须信任该集中式节点，并且每个其它节点都必须向集中式节点显示其工作流演变。因此，需要一种隐私保护架构，该隐私保护架构避免为了同步和验证交易而使用集中式节点。

本说明书中已经包括的任何关于文件、动作、材料、设备、物品等的讨论都不应被认为是承认任何或所有这些事项构成现有技术基础的一部分或是在每个所附权利要求的优先权日之前存在的、与本公开相关的领域中的公知常识。

在整个说明书中，单词“包括”或诸如“包含”或“含有”之类的变体应理解为暗含包括陈述的元件、整数或步骤，或元件、整数或步骤组，但不排除任何其它元件、整数或步骤，或元件、整数或步骤组。

发明内容

提供了一种调度和验证多参与者过程的方法，该方法包括：由与多参与者过程中的参与者相关联的提交节点通过将受密码保护消息发送到一个或多个接收方节点来提交拟议交易，其中受密码保护消息至少包括能够由外部节点读取的未加密子消息，以及至少保护来自外部节点的隐私的受密码保护子消息；由外部节点确定拟议交易相对于其它交易的顺序；通过接收方节点中的至少一些，验证受密码保护消息；从接收方节点中的至少一些接收对受密码保护消息的有效性确认；基于从接收方节点中的至少一些接收满足确认条件的一个或多个确认，将拟议交易作为确认交易来完成；以及根据由外部节点确定的顺序，将确认交易写入到分布式账本中。

在一些实施例中，一个或多个接收方节点可以至少包括第一接收方节点和第二接收方节点，并且其中受密码保护子消息能够由第一接收方节点读取，而不能由第二接收方节点读取。

在一些实施例中，第一接收方节点可以有权访问解密密钥以解密受密码保护子消息，而第二接收方节点则不能。

在一些实施例中，可以将密码保护的消息发送到外部节点，并且外部节点将受密码保护消息发送到每个接收方节点。

在一些实施例中，一个或多个接收方节点可以使用匿名地址来向其它接收方节点隐藏其身份。

在一些实施例中，该方法可以进一步使用身份管理器，该身份管理器维持提交节点与匿名地址之间，以及接收方节点与匿名地址之间的关联。

在一些实施例中，可以基于未加密子消息来确定受密码保护消息的有效性。

在一些实施例中，基于未加密子消息来确定受密码保护消息的有效性可以包括：确定拟议交易的交易时间是否在外部节点提供的时间戳窗口内。

在一些实施例中，拟议交易的交易时间可以是时间戳范围。

在一些实施例中，可以基于受密码保护子消息来确定受密码保护消息的有效性。

在一些实施例中，基于受密码保护子消息来确定受密码保护消息的有效性可以包括：识别拟议交易是否与先前的交易冲突。

在一些实施例中，基于受密码保护子消息来确定受密码保护消息的有效性可以包括：确定拟议交易是否格式正确。

在一些实施例中，基于受密码保护子消息确定受密码保护消息的有效性可以包括：确定拟议交易是否符合一组一致性规则。

在一些实施例中，识别拟议交易是否与先前的交易冲突可以包括：检查拟议交易是否先前已经记录在分布式账本上。

在一些实施例中，可以基于未加密子消息和受密码保护子消息来确定受密码保护消息的有效性。

在一些实施例中，确定有效性可以包括：确定未加密子消息是否与受密码保护子消息一致。

在一些实施例中，确认条件可以是以下项中的一个或多个：从与多参与者过程中的参与者相对应的每个接收方节点接收确认；在指定的时间段内接收到指定量的确认；或者从指定子集的接收方节点中接收确认；或者从诸如密码证明程序或可信硬件之类的可验证认证机制接收确认。

在一些实施例中，该方法可以进一步使用仲裁节点，该仲裁节点确定一个或多个接收方节点是否没有根据针对该接收方节点的期望动作来进行动作。

在一些实施例中，仲裁节点可以确定以下项中的一个或多个：拟议交易是否格式正确；由一个或多个接收方节点提供的确认是否与一个或多个其它确认冲突；以及拟议交易是否错误地表明了容量承诺耗尽。

在一些实施例中，该方法可以进一步使用仲裁节点来执行争议解决过程。

在一些实施例中，确定拟议交易是否格式正确可以包括检查以下项中的一个或多个：拟议交易符合一致性规则；拟议交易是由所需子集的一个或多个接收方节点授权的；以及拟议交易具有正确的资源要求声明。

在一些实施例中，一个或多个接收方节点中的第一个可以将拟议交易转发到仲裁节点以发起争议解决过程。

在一些实施例中，可以通过仲裁对从提交节点或一个或多个接收方节点确定的行为异常节点施加惩罚来解决争议解决过程。

在一些实施例中，惩罚可以是以下项中的一个或多个：删除行为异常节点提交交易的能力；将与行为异常节点相关联的拟议交易标记为冻结；仲裁节点确定的对行为异常节点的自定义惩罚；以及域规则中定义的对行为异常节点的惩罚。

在一些实施例中，仲裁节点可以将争议解决过程的结果传达给提交节点或一个或多个接收节点。

在一些实施例中，可以在域规则中定义争议解决过程。

在一些实施例中，除了第一接收方节点之外，其它接收方节点可以向仲裁节点提供一个或多个消息作为争议解决过程的证据。

在一些实施例中，可以基于未加密子消息来确定与构成该过程的多个交易相对应的多个消息的顺序。

在一些实施例中，未加密子消息可以包含物理时间戳，该物理时间戳对应于外部节点接收到受密码保护消息的时间。

在一些实施例中，拟议交易相对于其它交易的顺序可以基于物理时间戳。

在一些实施例中，拟议交易的顺序可以基于分配给拟议交易的逻辑时间戳。

在一些实施例中，逻辑时间戳可以对应于物理时间戳的定义的时间窗内的时间。

在一些实施例中，受密码保护子消息可以是加密的子消息。

提供了一种调度和验证多参与者过程的方法，该方法包括：由与多参与者过程中的参与者相关联的提交节点通过将受密码保护消息发送到一个或多个接收方节点来提交拟议交易，其中受密码保护消息至少包括能够由外部节点读取的未加密子消息，以及至少保护来自外部节点的隐私的受密码保护子消息；由外部节点确定拟议交易相对于其它交易的顺序；通过外部节点基于未加密子消息确定与多参与者过程中的参与者相关联的一个或多个接收方节点；外部节点至少将受密码保护子消息发送给一个或多个接收方节点；由一个或多个接收方节点确定受密码保护子消息的有效性；由外部节点从一个或多个接收方节点接收对受密码保护子消息的有效性确认；由外部节点确定应接收确认的一个或多个节点；由外部节点将确认发送给一个或多个节点；由提交节点基于一个或多个接收方节点提供的确认是否满足确认条件，将拟议交易作为确认交易来完成；以及由提交节点根据外部节点确定的顺序，将确认交易写入到分布式账本中。

在一些实施例中，该方法还可以包括：由中介节点接收并汇总由一个或多个接收方节点提供的确认。

在一些实施例中，该方法还可以包括以下项中的一个或多个：存储一个或多个确认的汇总；将一个或多个确认的汇总发送到另一节点；以及基于确认的汇总来确认拟议交易。

一种非暂时性有形计算机可读介质，包括程序指令，该程序指令在被执行时使一个节点或一系列相关节点执行上述方法。

提供了一种调度和验证多参与者过程中的交易或一系列交易的方法，该方法包括：通过至少将部分加密消息发送到与多参与者过程中的参与者相关联的一个或多个接收方节点来提交拟议交易，其中部分加密消息至少包括能够由外部节点读取的未加密子消息，以及至少保护来自外部节点的隐私的加密子消息；从接收方节点接收部分加密消息的有效性确认；基于从接收方节点中的至少一些接收满足确认条件的一个或多个确认，将拟议交易作为确认交易来完成；从外部节点接收确认交易相对于其它交易的顺序；以及根据由外部节点确定的顺序，将确认交易写入到账本中。

在一些实施例中，一个或多个接收方节点可以至少包括第一接收方节点和第二接收方节点，并且该方法还可以包括将加密子消息发送到第一接收方节点，该加密子消息可以通过受第一接收方节点控制，但不受第二接收方节点控制的解密密钥进行解密。

在一些实施例中，可以不将加密子消息发送到第二接收方节点。

在一些实施例中，该方法还可以包括：确定每个接收方节点的匿名地址，其中每个匿名地址用于向其它接收方节点隐藏相应接收方节点的身份。

提供了一种非暂时性有形计算机可读介质，包括程序指令，该程序指令在被执行时使提交节点执行上述方法。

提供了一种调度和验证多参与者过程中的多个交易的方法，包括：

通过一个节点或一系列相关节点：

A.确定与组成多参与者过程的多个交易相对应的多个消息的顺序；

B.从与多参与者过程中的参与者相关联的提交节点接收拟议交易，该拟议交易包括部分加密消息，其中部分加密消息至少包括能够由该节点或该系列相关节点读取的未加密子消息；

C.基于未加密子消息确定与多参与者过程中的参与者相关联的接收方节点；

D.将部分加密消息发送到接收方节点；

E.从接收方节点接收对部分加密消息的有效性确认；以及

F.将确认发送到提交节点。

在一些实施例中，该方法还可以包括确定接收方节点的匿名地址，其中该匿名地址用于向其它节点隐藏接收方节点的身份。

在该方法的一些实施例中，分布式账本记录提交节点、外部节点和/或接收方节点之间的消息，其中写入到分布式账本中的确认交易包括记录的消息，从而从记录的消息中证明或可以得出由外部节点确定的顺序。

在该方法的一些实施例中，分布式账本包括多个不同的分类帐，每个分类帐维护分类帐的相应部分副本，其中分布式账本由多个不同分类帐的部分记录构成。

在一些实施例中，该方法还包括：将多参与者过程从与外部节点相关联的第一域更改为与目标外部节点相关联的目标域。该方法还可以包括：由第一域的外部节点从发起方节点接收转移请求，其中转移请求指定目标域和目标外部节点；由第一域的外部节点确定目标域和目标外部节点的有效性以托管拟议交易，其中基于确定目标域可以有效地托管拟议交易，向发起方节点发送授权以在目标节点处调度和验证拟议交易，其中对拟议交易进行排序的步骤由目标外部节点执行。

在其它实施例中，该方法包括：在提交节点和/或接收方节点处接收转移请求；在提交节点和/或接收方节点处确定目标域和目标外部节点的有效性以托管拟议交易，其中基于确定目标域可以有效地托管拟议交易，向发起方节点发送授权以在目标节点处调度和验证拟议交易。

在另一实施例中，对发起方节点的授权与指定的超时条件相关联，其中基于指定的超时条件，确定授权是有效的和/或排他的。

还提供了一种调度和验证多参与者过程的方法，该方法涉及：与第一外部节点、第一接收方节点和与多参与者过程中的参与者相关联的提交节点相关联的第一域；与第二外部节点、第二接收方节点和提交节点或单独的中继节点相关联的第二域，并且其中提交节点或中继节点与第一外部节点和第二节点两者通信，其中该方法包括：由提交节点确定第一域的第一拟议交易和第二域的第二拟议交易，其中第一拟议交易和第二拟议交易组合形成涉及第一接收方节点和第二接收方节点的拟议多参与者交易，其中第一拟议交易和第二拟议交易中的每一个都包括到相应接收方节点的受密码保护消息，并且受密码保护消息至少包括能够由相应域的外部节点读取的未加密子消息，以及至少保护来自外部节点的隐私的受密码保护子消息；由提交节点和/或中继节点将第一拟议交易提交到第一接收方节点，将第二拟议交易提交到第二接收方节点；由第一外部节点确定第一拟议交易的第一顺序；该方法还包括：由第二外部节点确定第二拟议交易的第二顺序；通过第一接收方节点和第二接收方节点，验证相应的受密码保护消息；从第一接收方节点和第二接收方节点接收受密码保护消息的有效性确认；基于从第一接收方节点和第二接收方节点接收到的满足确认条件的确认，将拟议的多参与者交易作为确认的第一交易和确认的第二交易的组合来完成；以及根据第一顺序，将第一确认交易写入到与第一域相关联的分布式账本中，并且根据第二顺序，将第二确认交易写入到与第二域相关联的分布式账本中。

在该方法的另一实施例中，提交者节点是在第一域与第二域之间接收和发送消息的中继，其中该方法还包括：由提交节点和/或中继节点从第一接收方节点向第二域的第二外部节点和/或第二接收方节点发送受密码保护消息的有效性确认；以及由提交节点和/或中继节点从第二接收方节点向第一域的第一外部节点和/或第一接收方节点发送受密码保护消息的有效性确认。

在该方法的另一实施例中，用于完成拟议多参与者交易的授权与指定时序条件相关联，其中基于指定时序条件，该授权是有效的和/或排他的。

在该方法的另一实施例中，拟议交易是跨多个域的拟议多参与者交易的一部分，该方法还包括：从拟议的多参与者交易中确定：第一域的第一拟议交易，该第一域包括一个或多个接收方节点和外部节点；以及另一域的至少另一拟议交易，该另一域包括一个或多个其它接收方节点和另一外部节点，通过至少将另一至少部分加密消息发送到与另一域中的多参与者过程中的参与者相关联的一个或多个其它接收方节点来提交另一拟议交易，其中另一部分加密消息至少包括能够由另一外部节点读取的未加密子消息，以及至少保护来自另一外部节点的隐私的加密子消息；从一个或多个其它接收方节点接收另一部分加密子消息的另一有效性确认；其中完成拟议交易的步骤还包括：基于从其它接收方节点中的至少一些接收满足确认条件的一个或多个确认，将另一拟议交易作为另一确认交易来完成；从另一外部节点接收另一确认交易相对于另一域中其它交易的顺序；以及根据另一外部节点确定的顺序，将另一确认交易写入到分类帐或另一账本中。

在另一实施例中，该方法还包括：从第一域中的接收方节点向另一域中的另一接收方节点发送受密码保护消息的有效性确认；以及从另一域中的另一接收方节点向第一域中的接收方节点发送受密码保护消息的另一有效性确认。

在另一实施例中，将完成拟议交易和另一拟议交易的授权与指定时序条件相关联，其中基于指定时序条件，授权是有效的和/或排他的。

在上述方法的其它实施例中，加密子消息包括期望确认数据，以对拟议交易中的所有期望确认进行密码验证，其中该方法还包括：执行加密功能以对接收到的一个或多个确认中的每一个进行密码验证，验证与期望确认数据相对应。

在该方法的其它示例中，期望确认数据是公钥的形式，并且其中期望确认包括具有与公钥相对应的隐私密钥的电子签名。

在该方法的一些示例中，拟议交易包括多个子交易，每个子交易都涉及至少一个接收方节点，并且每个子交易与对应的受密码保护子消息相关联，该受密码保护子消息具有隐私信息，该隐私信息能够由子交易中所涉及的接收方节点读取，但不能由子交易中不涉及的接收方节点读取，并且其中受密码保护子消息包括隐私信息验证数据，以验证至少部分代表拟议交易中至少一个其它子交易的隐私信息的确认，并且该方法还包括：验证至少一个其它子交易与隐私信息验证数据相对应的确认。

在该方法的一些其它示例中，子交易的确认至少部分地包括子交易的隐私信息的加密哈希。

在该方法的一些示例中，拟议交易具有带多个子树的树结构，其中子树包括多个子交易中的一个或多个。

在该方法的一些示例中，受密码保护子消息包括隐私信息验证数据，以对拟议交易中的多个子交易的确认中的任一个进行密码验证。

提供了一种非暂时性有形计算机可读介质，包括程序指令，该程序指令在被执行时使一个节点或一系列相关节点执行上述方法。

在一些实施例中，分类帐可以是共享分类帐。

附图说明

将参考以下附图描述本公开的示例：

图1是用于调度和验证包括多个交易的多参与者过程的示例系统。

图2a是用于调度和验证包括多个交易的多参与者过程的更复杂的示例系统。

图2b是图2a的带中介节点的示例。

图2c是将子消息分发到所有节点的示例。

图2d是将子消息分发到一些节点的示例。

图3是示例拟议交易的图示。

图4是调度和验证多参与者过程的示例方法。

图5是示例节点；

图6是从原域到目标域的域更改的示例的示意图；

图7是从原域到目标域的域更改的另一示例；

图8是跨两个域的多域交易的示例的示意图；

图9是示出图8的多域交易中的各种期限的图；

图10示出了涉及可以在单域中实现的多个参与者的交易的另一示例；

图11a示出了图10中的示例交易中的各种实体的视图；

图11b概念性地示出了图11a中的视图的隐藏视图；

图12是图10至图11b的交易和方法的示意图；

图13是图10至图12的交易和方法的状态转移图；

图14a示出了涉及参与者A、参与者B和银行的交易的视图；

图14b示出了在图14a的交易中银行可见的视图；

图15a是要记录在虚拟分类帐上的用于交易的消息的表示，其中缺少一个参与者P的细节；

图15b是要记录在虚拟分类帐上的用于交易的消息的表示，其中缺少参与者A的细节；

图16a示出了多参与者过程的完整交易视图；

图16b示出了图16b的第一视图的核心；

图17示出了表示多参与者过程和交易的完整数据结构；

图18示出了图17中的交易的子视图的表示，图17示出了子交易隐私；

图19示出了图17中的交易的全部利益相关者树的表示；以及

图20示出了对于利益相关者银行未隐藏的利益相关者树的表示。

具体实施方式

本公开涉及一种可以在分布式系统中将同步与有效性分开的系统。同步是分布式系统中的标准问题，通常通过某种形式的排序协议原语来解决，诸如全序广播或多播。本文公开了一种示例性系统，其基于接收方节点的概念来确保有效性，在该接收方节点中，可以将有效性检查移至接收方自身。在众多其它好处中，这可以消除对能够查看和处理所有数据的集中的提交者节点的需求，或者可以消除对能够共同查看和处理所有数据的多方提交者节点的需求，从而增加了系统中接收方节点的隐私。

在该系统中，参与者可以基于他们对交易的部分看法来执行本地有效性检查，并通过确认(例如，对等确认或通过系统的一个或多个组件或一个或多个节点路由的确认)交换其本地检查的结果。在示例中，各方可以将基于他们局部视图执行本地有效性检查的任务委派给参与者用户或其它参与者。在示例中，参与者可以基于他们对分布式账本的工作流规则的有限视图，将执行交易级别有效性检查的任务委派给参与方用户或其它参与者。

图1示出了用于调度和验证包括多个交易的多参与者过程的示例系统100。在该示例中，存在过程102，用于在节点、提交节点110、接收方节点120、外部节点130和分类帐160之间进行通信的网络104。可选地，可以存在第二接收方节点122(由图1中的虚线表示)和身份管理器170。

在该示例中，过程102可以在所有节点之间共享。该过程可以具有多个参与者，每个参与者可以与网络中的至少一个节点相关联。在最简单的示例中，可以有提交节点110、接收方节点120和外部节点130。外部节点130可以确定与组成涉及多个参与者的过程102的一个或多个交易相对应的多个消息的顺序。外部节点130可以包括实现外部节点的逻辑排序功能的多个物理系统。

提交节点110可以提交拟议交易140。提交拟议交易140可以包括通过网络104向与该过程中的参与者相关联的一个或多个接收方节点120、122发送受密码保护消息，其中受密码保护消息可以至少包括能够由外部节点130读取的未加密子消息142、以及至少保护来自外部节点130的隐私的受密码保护子消息144。在示例中，受密码保护消息可以是部分加密消息，其可以包括未加密子消息142和加密子消息144。在本说明书的其余部分，仅出于方便的目的，可以理解，分别将受密码保护消息和子消息称为部分加密消息和加密子消息，除加密外，其它受密码保护机制也可用于编码或混淆来自未授权节点的受密码保护消息或子消息(例如数据屏蔽、语义混淆等)。在该示例中，加密子消息144可以被认为是部分加密消息的提交的有效载荷。在示例中，可以使用对称加密(例如，高级加密标准(AES))、非对称加密(例如，RSA、椭圆曲线等)或集成加密(例如，ECIES)来加密部分加密消息并提交拟议交易140，并且可以在本文公开的所有交易中使用，如可以理解。

一旦提交节点110已经提交了拟议交易140，接收方节点120就可以接收拟议交易140并且通过扩展拟议交易140确定部分加密消息的有效性。在示例中，这种验证可以涵盖接收方节点120，验证部分加密消息的加密子消息144。例如，在某些实施例中，加密子消息144可以包含对于接收方节点120和提交节点110是隐私的并且不能由外部节点130读取的数据(例如，程序指令、信息等)(例如，因为提交节点110和接收节点120包含解密密钥，而外部节点130不包含)。

一旦确定了拟议交易140的有效性，则接收方节点120可以发出称为确认150的消息，该消息可以是来自接收方节点120的部分加密消息的有效性确认。在示例中，该确认可以确认接收方节点120已经在拟议交易140的背景下验证了加密子消息144，并且认为拟议交易140是准确和有效的。在一些示例中，在验证拟议交易140之前进行排序的步骤(即，相对于其它拟议交易对拟议交易140进行排序)可能是有利的。由于每个参与者都可以接收并验证相同的交易序列(或该序列的摘要)，因此此类参与者可以隐式验证拟议交易的相同顺序或序列，这可以使识别行为异常节点变得更加容易。

在该示例中，提交节点110可以基于从接收方节点120接收到的确认来接受拟议交易140作为确认交易，并且随后可以确定拟议交易140满足确认条件。在该示例中，确认条件可以是：与过程102中的参与者相对应的所有节点都接收到确认150。假设在该示例中只有一(1)个接收方120，则可能只需要有一(1)个确认由提交节点110接收以确认拟议交易140。下面讨论更复杂的示例。

在该示例中，提交节点110和/或接收方节点120可以根据由外部节点130确定的顺序将确认交易写入到分类帐160中。在示例中，分类帐可以是能够在所有节点之间共享的数据存储。在另一示例中，分类帐160可以是分布式账本，其中每个节点维护分类帐的部分或全部副本，并且提交110和/或接收方120节点可以相应地更新其分类帐副本。在另外其它示例中，分类帐160可以是仅概念上存在而实际上不存在的分布式账本。具体地，分类帐160可以是分布式“虚拟”分类帐，其包括在网络的节点之间交换的关于通过网络提交并输入到“虚拟”分类帐中的交易的多个消息。根据包含在多个消息中的数据，与网络中的节点相关联的参与者可以在任何时间点计算“虚拟”分类帐的状态，从而可以在那个时间点计算出他们对网络中其它参与者的义务和责任，但实际上可能不存在有状态的分布式账本(例如，类似于比特币或以太坊)。换句话说，网络的各个节点可能只存储多个消息，并且基于这些消息的内容来计算“虚拟”分类帐的状态。

图2a和图2b示出了更复杂的示例系统200。非常类似于图1的示例，过程102可以在所有节点之间共享。该过程可以有多个参与者，每个参与者都可以与网络中的一个或多个节点相关联。然而，与图1的示例不同，在该示例中，存在与系统中的参与者相关联的三(3)个节点：提交节点210和两个(2)接收方节点262、264。如在图1的示例中，外部节点230可以确定与构成涉及多个参与者的过程102的多个交易相对应的多个消息的顺序。通常，过程102由多个交易构成，如本公开中的其它示例中所述；然而，应当理解，一个过程可以涉及单个交易。为了清楚起见，已经从图示中移除了网络，但是要注意，如图1中所示，可以存在网络。

类似于图1，提交节点210可以提交拟议交易240。提交拟议交易240可以包括通过网络(未示出)将部分加密消息发送到与过程202中的参与者相关联的两个(2)接收方节点220、222，其中部分加密消息可以至少包括能够由外部节点230读取的未加密子消息242、以及至少保护来自外部节点230的隐私的加密子消息244。在图2a的示例中，可以将部分加密消息发送到外部节点230，并且外部节点可以确定一个或多个接收方节点以接收拟议交易240以进行确认。然后，外部节点230可以将部分加密消息发送到适当的接收方节点220、222。在一些情况下，外部节点230可以将加密子消息244发送到接收方节点，而不是整个拟议交易240，假设加密子消息244与相应的接收方节点220、222相关的话。在另一示例中，拟议交易240可以包括一组多个部分加密消息(对于相应接收方，具有对应的未加密子消息242和加密子消息244)，从而子消息(例如，加密子消息244)可以被划分并分配给相应的接收方节点220、222。这意味着拟议交易240的一部分对于授权的接收方节点可见，而对另一未授权的接收方节点则不可见，从而对于那些相应的部分，保留交易中对于未经授权的接收方节点不可见的部分的隐私。

在图2c中示出以上的示例，其描绘了具有附加接收方节点224的场景，其中部分加密消息被划分为子消息242至248，并且其中加密子消息244、246、248分别被分配给相应的接收方节点220、222、224。在图2c的示例中，加密子消息244可以由第一接收方节点220读取，但是不能由第二接收方节点222或第三接收方节点224读取。即，即使每个接收方节点220、222、224都接收到每个加密子消息244、246、248，加密子消息244的内容可以由第一接收方节点220读取并且可能进行验证，但不能由第二接收方节点222或第三接收方节点224读取和验证。这可能发生在许多示例中，其中一些消息内容对一个接收方节点是隐私的，因此不应与另一接收方节点共享。比第一接收方节点220、第二接收方节点222和第三接收方节点224更多的节点可以形成网络的一部分，并且特定的加密子消息244可以由有权查看加密子消息244的任何子集的接收方节点发送并且读取，而不能由无权查看加密子消息244的任何子集的接收方节点发送或读取。

在图2d的示例中描绘了与图2c中所示的示例类似的示例。在图2d的示例中，加密子消息244可以仅由第一接收方节点220接收，而不能由第二接收方节点222或第三接收方节点224接收。即，在该示例中，如果确定加密子消息244与第二接收方节点222或第三接收方节点224不相关，则外部节点230可以不将加密子消息244转发给第二接收方节点222或第三接收方节点224。这意味着即使第二接收方节点222设法获得对解密密钥的未授权访问，该节点也无法对加密子消息244进行解密，因为第二接收方节点222永远不会从外部节点230接收到加密子消息244。类似地，第三接收方节点224无法对加密子消息244进行解密，因为第三接收方节点224永远不会已从外部节点230接收到加密子消息244。同样，即使外部节点230错误地向第二接收方节点222或第三接收方节点224发送了加密子消息244，在没有恶意行为的情况下，第二接收方节点222或第三接收方节点224通常将不具有解密密钥来对加密子消息244进行解密。因此，本公开的系统可以保护节点之间的隐私，以确保即使在密钥或密码算法受损的情况下，仅有权查看拟议交易240的一部分的节点能够这样做。

在示例中，为了读取加密子消息，第一接收方节点220可以访问解密密钥以对提供给第一接收方节点220的加密子消息244进行解密。在该示例中，如图2c中所示，第二接收方节点222可以接收加密子消息244，但是无法访问解密密钥以对寻址到第一接收方节点220的加密子消息244进行解密以保护该特定加密子消息244的隐私。当然，访问解密密钥以对加密子消息244进行解密的权限可以扩展到网络中有权读取特定加密子消息244的任何数量或子集的接收方节点。

为了完整性，值得注意的是在图2d的示例中，加密子消息246被分发到第一接收方节点220和第二接收方节点222，并且加密子消息248被分发到第一接收方节点220、第二接收方节点222和第三接收方节点224。然后类似地，第一接收方节点220和第二接收方节点222将需要访问解密密钥以对加密子消息246进行解密，并且第一接收方节点220、第二接收方节点224和第三接收方节点226将需要访问解密密钥以对加密子消息246进行解密。

一旦每个接收方节点220、222确定了拟议交易240的有效性，每个接收方节点220、222就可以发出称为确认250、252的消息，该确认可以是来自接收方节点220、222的对部分加密消息的有效性确认。在该示例中，不同于图1的示例，来自每个接收方节点220、222的确认可以被发送到外部节点230。外部节点230可以确定可以是多个节点之一的提交节点210，并且可以将确认发送到适当的提交节点210。在一些未示出的变型中，有可能将确认直接从一个接收方节点发送到另一节点。即，确认可以对等发送，而不是经由外部节点或中介发送。对等确认可以在用于验证交易的适当规则下与外部或中介一起使用。

在示例中，提交节点210可以基于接收以下多个确认将拟议交易240作为确认交易来接受：来自接收方节点220的第一确认，以及来自接收方节点222的第二确认。如图1的示例，该示例中的确认条件为完全确认，以便可以确认交易。在本公开的其它地方讨论了除了完全确认之外的其它替代确认条件。

应注意，在该示例中，与系统中的参与者相关联的每个节点可以具有分类帐260、262、264，并相应地更新分类帐的部分或完整副本。例如，提交节点210可以具有分类帐260，第一接收方节点220可以具有分类帐262，而第二接收方节点222可以具有分类帐264。每个节点然后可以根据由外部节点230确定的顺序将确认交易写入其相应的分类帐260、262、264中。在一些示例中，账本是可以在所有节点之间共享的数据存储，在这种情况下，可能需要例如基于隔离数据的隐私模型来维护每个交易相对于每个参与者节点的隐私。在其它示例中，每个分类帐是如上所述的“虚拟”分类帐。

可选地，图2a中所示的系统变形可以使用中介280，如图2b中所示。在这种情况下，接收方节点220、222可以将确认250、252发送到中介节点280，该中介节点可以接收确认并确定汇合结果。提交节点210还可以将拟议交易240提交给中介280。在具有多于两(2)个接收方节点的情况下，使用中介节点280来计算有多少个接收方节点确认拟议交易240会更简单。另外，中介节点280可以用作有关特定接收方节点220、222是否发送确认的认证记录。换句话说，由于可以通过中介节点280进行确认，因此，中介节点280可以具有使用该系统发送的所有确认记录，并且接收方节点220、222不能否认已经发送或未发送确认。在一些示例中，中介节点280接收所有确认，将其汇合，并且将它们发送到对应的参与者节点(使得参与者节点彼此不直接交互。如果参与者节点参与影响到另一交易的交易，则这可能是有利的，但至少一个参与者节点需要与交易中的至少另一节点保持隐私，因为后两者没有直接交易。即，在一个参与者节点不应该了解另一参与者节点参与同一笔交易的情况下。

身份管理器

身份管理器节点170、270可以提供许多服务，例如：

a.会员管理。

b.匿名管理。

对于会员管理，身份管理器节点170、270可以允许节点加入和离开系统(诸如图1、图2a和图2b中定义的系统)。先前在图1和图2a至图2b中描述的系统也可以被称为域，并且单个节点可以是多个域的会员。身份管理器节点170、270可以允许节点注册、撤销和交替公钥。身份管理器节点170、270可以知晓由给定节点表示的参与者。它还可以定义每个节点的信任级别。例如，信任等级可以是强的，诸如对于域的运营商(例如，结算系统)，或者是弱的(例如，诸如对于结算系统的参与者)。可替代地，对于每个节点，可以将信任级别选择为相同。简而言之，身份管理器节点170、270可以允许节点注册、撤销和交替与特定节点的身份相关联的公钥，从而允许系统中的其它节点识别域内的特定节点。特定节点的身份在诸如争议解决之类的实例中可能是有用的，如本公开中其它地方所详述。

对于匿名管理，身份管理器节点170、270可以允许节点创建匿名密钥(例如，用于在不泄露签名者身份的情况下对消息进行签名的密钥)。如果有特权的参与者(诸如外部节点或仲裁节点)请求它，则身份管理器节点170、270可以隐瞒先前创建的匿名身份。匿名身份可以是匿名地址，该匿名地址隐藏了节点的真实身份，但同时，其它节点也可以将匿名身份用作标识符。

当使用身份管理器节点170、270时，接收方节点120、122、220、222不必了解提交节点110、210的身份，也不必了解其它接收方节点120、122、220、222的身份。在示例中，接收方节点仅在其它接收方节点是同一过程202的参与者的情况下才了解它们的身份；否则，接收方节点可能只会了解另一接收方节点的匿名。外部节点130、230可以允许使用匿名地址将消息传递到接收方节点，并且可以使用身份管理器节点170、270来解析匿名的参与者身份。

外部节点

外部节点130、230可以向与构成涉及多个参与者的过程的多个交易相对应的多个消息提供顺序。在示例中，外部节点130、230可以提供全局全序多播(用于域)，其中例如经由外部节点130、230提供的唯一时间戳来对消息进行唯一的排序。因此，全局排序可以根据时间戳推导。然而，应当理解，在一些示例中，多个消息的顺序可以至少部分地基于除时间戳之外的未加密子消息中的信息。在其它场景中，如其它地方所述，由外部节点130、230提供的时间戳可以是物理时间戳或逻辑时间戳。

在一些示例中，可以为单个交易提供顺序。即，因为外部节点130、230可以提供其中消息被唯一地排序的全局全序多播，所以即使尚不存在其它交易也可以建立顺序。作为示例，可以对第一拟议交易加盖时间戳，使得可以将尚未提交给外部节点的任何其它交易或拟议交易加盖稍后时间的时间戳。因此，在该示例中，第一拟议交易可以是某个过程可能存在的所有交易的全局全序中的第一个(即，时间上是第一个)。

如在本文的一些示例中所指出，外部节点130、230可以代替传递单个消息，而提供精细消息传递。即，子消息142、242、144、244的列表可以被传递到接收方节点220、222。所有子消息都可以接收与其所包含的消息140、240相同的时间戳。应注意，每个子消息可以具有一组不同的接收方节点，并且每个接收方节点可以按照原始消息140、240推导的顺序来接收子消息。

外部节点130、230还可以提供提交证明。即，提交节点110、210可以从外部节点130、230接收关于拟议交易140、240或确认250、252的提交的证明。该证明可以用作争议中的证据，这可以例如在缺少确认的情况下使用。对应于提交证明，可能进一步需要消息的不可否认性，使得节点不能拒绝已发送交易或确认的消息。最后，外部节点130、230的传递证明可以向接收方节点提供关于消息顺序的证据。

在一些示例中，外部节点130、230可以提供(或者如果被查询的话，可能被要求提供)外部节点传递的每个消息或消息批次的真实性的加密证明。这些可以用作发送到提交节点(或其它节点，诸如中介节点280)的密码“收据”。

中介

中介节点280可以形成系统的一部分，如图2b中所示。在具有中介节点280的系统中，中介节点280可以从接收方节点接收确认并汇总确认，以确定是否对所拟议交易的确认达成共识。这意味着，在一些情况下，可以使用中介节点280来减少跨更广网络发送的确认总数。在示例中，中介节点280可以接收消息，该消息阐述了对于被认为被接受/确认的交易，中介节点280应该期望接收到的所有期望确认。中介节点280可以将其接收到的确认与期望确认进行比较，以确定是否应当接受/确认交易。

此外，中介节点280可以是在关于是否发送或接收确认存在争议的情况下使用的节点。由于中介节点280可以汇总来自接收方节点的所有确认，因此它可以用作无争议的记录，由特定节点发送确认，或者在应发送确认时未发送确认，并且适当的被所有相关的接收方节点接收确认。

当汇总确认时，中介可以考虑确认策略，该确认策略可以确定验证和确认拟议交易所需的节点，以及可以可选地验证和确认拟议交易但可能确认拟议交易不需要这样做的节点。即，在一些确认策略中，可能需要接收方节点子集来响应确认。其余子集的接收方节点可以是可选的验证器，其中可以将从可选的验证器接收到的确认信息汇总起来，作为确定对拟议交易进行确认的共识的一部分，但是可以不需要确认来确认拟议交易和将其输入分类帐。使用中介节点汇合确认还可以起到保护过程或拟议交易中涉及的节点身份的作用。换句话说，中介节点可以用作代理来汇总确认并确定是否已满足确认条件或策略，而不必共享提供特定确认的节点身份，甚至不必共享确认消息本身。

可能还有更复杂的确认策略。例如，在具有多个节点的系统中可能存在确认策略，其中必须从至少第一节点接收确认，但是不必从两个节点接收确认。应当理解，可以实施确认策略的许多其它变体。

在一些示例中，确认策略可以基于批准交易的确认方的数量(或集)来指定动作的法定人数(即使一些或所有其余方都拒绝了该动作)。在其它示例中，VIP确认策略为一些参与者节点提供了VIP状态，使他们可以代表一个或多个其它利益相关者验证操作和/或使他们成为强制确认方(VIP的更多详细信息在单独的标题下进行了讨论)。

确认策略可以依赖于一个或多个节点的证明，例如经由加密证明程序(例如，zkSNARK、zkSTARK)或受信任的执行环境(例如，Intel SGX)的证明。

在一些情况下，提交节点可以经由中介节点280提交拟议交易，然后该中介节点可以从接收方节点220、222接收并汇总确认。可能存在一个或多个中介节点，每个节点可能有不同接收方节点。此外，并非每个接收方节点都需要与中介节点相关联。在一些情况下，例如，第一接收方节点可以照常将其确认传达给外部节点，提交节点或其它接收方节点，而另一子集的接收方节点可以经由中介节点传达其构象。在其它情况下，可能需要网络中的所有节点都经由中介节点或多个互连的中介节点提交确认，以确保整个网络对网络中的节点发送或接收的确认具有一致的看法。

中介节点280可以存储从接收方节点接收到的确认和其它消息。这允许进行审核，因为如果需要执行审核，审核员可以检索确认或消息。存储API可以允许审核员从存储中检索接收到的消息。存储API可以通知审核员是否已为特定交易或拟议交易发送了结果消息。

域消息传递API和属性

域消息传递API暴露给该域中的每个参与者节点和系统实体(例如，提交节点110、接收方节点120等)。现在将描述非限制性示例，其中域消息传递API具有用于“发送”消息的单个命令和三种事件类型，即“接收”、“传递”和“心跳”。

·命令Send(messageId，b，Sig(b，sk_sender))，其中messageId是消息标识符，b是批处理，包含n个元组(m_i，receivers_i)的列表，其中m_i是消息，而receives_i是m_i的接收方列表，0＜＝i＜n。批处理b必须由发送参与者的密钥sk_sender签名。发送命令可用于批量发送消息，以便多个消息(在不同接收方的情况下)在同一时间戳下。

·事件Receipt(messageId，ts，proof(sender，messageId，ts，b))，

其中messageId是消息标识符，ts是时间戳，sender是节点的标识符，而b是批处理。接收事件为接收方提供了他们已提交消息的加密证据。该证明可以包括签名。

·事件Deliver(ctr，ts，b’，proof(recipient，ctr，ts，b’))，其中ctr为每个接收方单调递增的计数器，ts为定义顺序的时间戳，b’为消息批处理，并且proof为包括接收方身份的加密传递证明。直观地，该节点将学习发给该节点的所有消息以及每个消息的其它接收方(这是可能的，因为b是批处理)。

·事件Heartbeat(ctr，ts，proof(recipient，ctr，ts))，其中ctr为非递减计数器，ts为时间戳，并且proof为心跳发射的加密证明。

在一些示例中，期望用于具有以下一个或多个属性或在一些情况下具有所有属性的节点的域消息传递API：

·可靠的传递：所有消息最终都会传递给其所有接收方。如果由功能正常的节点发送方调用了Send(messageId，b，Sig(b，sk_sender))，则存在ts和ctr，使得Deliver(ctr，ts，b’，proof(p，ctr，ts，b’))事件最终在接收方集合中的每个节点p处触发(即，recipients_i中所有元素的并集)，其中：

b’＝[(m，recipients)∈b|p|∈recipients]

·不创建：对于在节点p上触发的每个Deliver(ctr，ts，b’，proof(p，ctr，ts，b’))，先前已调用某个节点的Send(messageId，b，Sig(b，sk_sender))与一些messageId使得

b’＝[(m，recipients)∈b|p∈recipients]

此外，对提交事件的诱导映射传递是内射的(即，没有比对应的提交事件更多的传递事件)。应注意，由于发送命令需要签名，因此可以验证此属性。因此，发送方无法拒绝发送消息。

·按顺序传递：如果在节点上触发了Deliver(ctr，ts，-，-)，则以下条件中的一个成立：

οctr＝0，并且该节点上没有触发任何较早的传递或心跳事件。

ctr等于ctr’+1，其中ctr’是先前的传递或心跳事件的计数器。此外，ts必须大于任何先前的传递或心跳事件的ts。时间戳排序与批处理内部排序一起提供了全局全序。这与加密证明一起确保了消息不能追溯地插入到消息流中，并且接收方可以检测到省略的消息。

·协议：如果分别在节点p1和p2触发了Deliver(ctr，ts，b，proof(recipient，ctr，ts，b))和Deliver(ctr’，ts，b’，proof(recipient，ctr，ts，b’))

filter bothReceiveb＝filter bothReceiveb’

其中

·真实的传递证明：没有人可以生成proof(p，ctr，ts，b)，除非先前已在节点p触发了Deliver(ctr，ts，b，proof(p，ctr，ts，b))。实际上，这是通过使用签名作为证明来实现的。

·提交证明：如果节点发送方调用了Send(messageId，b，Sig(b，sk_sender))，并且发送方没有崩溃，则存在ts，使得Receipt(messageId，ts，proof(sender，messageid，ts，b))最终在发送方处触发。时间戳ts必须与对应于发送的传递事件的时间戳相同。

·因果关系：如果功能正常的节点发送方调用了Send(messageId，b，-)，则接收Receipt(messageId，ts，_)中的时间戳ts必须严格大于在发送方节点上触发的任何先前的传递或心跳事件中的时间戳。

·常规心跳：定期在每个参与者110、120上触发传递或心跳事件。

·按顺序心跳：只要在参与者处触发Heartbeat(ctr，ts，proof(ctr，ts))事件，则下列条件中的一个成立：

οctr＝0，并且该参与者没有触发过任何较早的传递或心跳事件。

ctr等于ctr’+1，其中ctr’是先前的心跳或传递事件的计数器。此外，ts必须大于任何先前的传递或心跳事件的ts。增加心跳事件的计数器确保了每个计数器都精确映射到一个时间戳。

拟议交易

提交节点110可以通过提交拟议交易来提交交易。通常，交易协议将要求提交节点指定需要向其告知有关动作/交易的当事方(即，已声明的利益相关者)。拟议交易可以寻址到其它接收方节点(它也可以解决系统的其它方面，诸如容量监测器、费用或资源计费单位、外部节点、中介等)。拟议交易中的信息可以包括未加密子消息和加密子消息。加密子消息可以以加密的形式包括向其利益相关者(例如，受拟议交易影响的接收方节点)描述交易的实际有效载荷。

在一些示例中，交易协议要求提交节点110指定提交节点的信息。这可以包括要求提交节点110对交易和/或拟议交易的一部分进行签名。在一些示例中，这可能需要交易的每个顶级动作的提交节点签名。在其它示例中，这包括提交节点110签名并将签名转发给当事利益相关者。

图3示出了拟议交易302的示例300。在该示例中，参与者A 330希望参与者P(油漆工)340为参与者A的房子粉刷，并且愿意使用参与者A从银行342持有的借据来为此支付费用。参与者A通过油漆要约过程302向参与者P要约。

在该示例的背景下，系统执行许多动作。首先是创建定义拟议交易的合同(并将定义记录在账本中)的动作。第二种类型的动作是对合同执行动作，该动作可以包括交易中的多个动作。例如，参与者对合同的接受是顶级动作，其导致多个子动作310(其本身可以被认为是动作)。例如，这可能包括从参与者A的银行借据进行价值转移，而另一项动作包括为参与者P的利益创建新借据。从系统角度来看，此类动作必须(i)得到交易协议对该行动的批准；并且(ii)符合基础系统模型-以便可以将行为有效地记录在分类帐中。

在交易根中，参与者P 340在粉刷报价上行使其选择；这继而可能导致参与者A330在借据310上行使其转移选择，从而对参与者P的利益创建了新借据312，并由同一家银行342支持。同时，创建了协议，参与者P同意为参与者A的房子320进行粉刷。在本公开的背景下，进行选择可以意味着节点在智能合约上执行该节点有权执行的代码段。因此，例如，在以上示例中，参与者P 340可以通过在记录参与者P接受油漆要约的油漆要约智能合约内执行代码段，来行使其接受粉刷报价的选择。可以在本公开的系统中使用的与行使选择和/或智能合约有关的更多细节可以在美国专利公开第2017/0316391号、WO 2017/189027、WO2017/187394(均要求US 62/329,888的优先权)以及澳大利亚专利第2019200933号、WO2019/082142(均要求AU 2017904367的优先权)中找到，它们中的每一个整体均通过引用方式并入本文中。

各个节点330、340、342可能仅需要学习影响该节点是利益相关者的合同的交易部分。由于整个交易是通过油漆要约进行的，因此其利益相关者(参与者A和参与者P)可能需要学习整个交易。相反，银行和参与者A可能只需要了解借据转移310，并且参与者P可能只需要了解产生的借据312。这可能导致交易的不同部分分解，如图3中所示。

为了完整性，如果将拟议交易发送给所有利益相关者，这可能就足够了。然而，这不足以保护隐私。幸运的是，并不是所有的利益相关者都需要对整个交易有完全的可见性；他们的观点只需要公开足够的信息，以确保当事方之间的完整性和同步性。

图3中的每个实心矩形表示该交易部分的隐私范围(相关当事方用斜体和下划线标出)。应注意，PaintAgree 320没有单独的实心矩形；由于参与者A和P已经了解了油漆要约运用，因此他们不需要分别了解PaintAgree 320的创建，这是因为可以隐式推论得出。

然而，对于新创建的借据312而言，情况可以是不同的。银行342不应了解关于矩形302的转移背景的任何情况。特别地，银行342不能假定并且不应了解参与者P 340是交易中任何其它合同的参与者。这就是为什么存在在银行342和参与者P 340之间共享的单独实心矩形312的原因，即使银行342和参与者P 340都已经通过了解外部矩形310至少部分地学习了该实心矩形312的内容。银行342不应该知道其它矩形302或320是什么(即，A正在支付什么)，或者它的利益相关者是谁。

交易

本领域普通技术人员将认识到，如本公开中所使用，交易可以具有树状结构。交易可以具有利益相关者和/或观察者，因此不同的利益相关者可见的这种树状结构的部分(例如，子树)可以更改。在它们的物理传输存储形式中，这些交易子树称为子视图。在示例中，每个接收方节点120、122、220、222仅获得其有权查看的交易部分，从语义上作为交易子树的子集，而在物理上作为所传输的交易消息的子视图的子集。

诸如图3中所示的交易(作为交易302)本质上可以是原子的。换句话说，它可以作为一个单元来完成或失败。由于各当事方通常只能查看交易的一部分，因此参与者可能无法自行决定交易的有效性或接受性。另外，在示例中，由于意图可以委派交易有效性的方式，即使是查看整个交易的参与者也无法做出该确定。例如，尽管参与者P 340的节点可以查看以上整个交易，但是银行342发行给参与者A 330的节点不是借据310的参与者。为了评估交易的有效性或接受性，参与者P 340的节点可能需要银行342的确认。

未加密子消息

诸如图2a和图2b中的240之类的拟议交易可以包含未加密子消息242。未加密子消息可以包括与拟议交易240有关的信息，该信息可公开获得或可用于交易过程中的所有参与者，并且通常不包含任何一个参与者专有的信息。例如，未加密子消息可以包括交易时间，或者可以包括选择分类帐的利益相关者之间商定的(隐式或显式的，可能并发的)物理时间规则的分支版本(例如，可以使用哪种容量或分片模型)。通常，此类信息可以是与交易有关的公开可用信息。

在一些示例中，外部节点通过提供时间戳来在未加密子消息中提供交易时间。在其它示例中，提交节点可以基于由提交节点提供的时间戳来拟议交易时间。交易时间可以只是外部节点230接收拟议交易240的时间戳或时间的数字记录。该时间戳可以给出日期和时间、通用时间或精确到几分之一秒的任何时间度量，即使在几乎同时将交易发送到外部节点的情况下，也可以帮助对交易进行排序。

在示例中，时间戳可以不是指定外部节点230何时接收拟议交易240的物理时间戳，而可以是逻辑时间戳。逻辑时间戳可以是物理时间戳与一些逻辑时间偏移的组合，外部节点230通过该物理时间戳接收拟议交易240。例如，逻辑时间戳可以是指定外部节点230接收拟议交易240的时间的物理时间戳加上一些逻辑时间偏移的组合，从而使逻辑时间戳晚于物理时间戳。在示例中，可以由提交拟议交易240的提交节点210提供逻辑时间偏移。因此，在一些情况下，由外部节点230提供的物理时间戳和由提交节点210提供的逻辑时间偏移的级联可以形成逻辑时间戳。在其它情况下，外部节点230或网络中的另一节点可以提供逻辑时间偏移。

在某种程度上，允许提交节点210提供逻辑时间偏移可以允许提交节点210控制确认响应期限，接收方节点220、222必须在该确认响应期限之前发送对拟议交易240的确认，并且/或在某种程度上控制拟议交易240相对于其它交易的顺序。例如，在示例中，本公开的系统可以提供确认响应期限，相关接收方节点220、222必须在该确认响应期限之前发送对拟议交易240的确认，以使其被确认并被输入到账本中。确认响应期限可以参考逻辑时间戳来计算。例如，可以通过将一些预设时间段添加到拟议交易240的逻辑时间戳来计算确认响应期限。通过允许提交节点210提供逻辑时间偏移，系统可以允许提交节点210在某种程度上设置拟议交易240的逻辑时间戳，这可以影响确认响应期限。仅作为示例，因此提交节点210可以通过更改逻辑时间偏移来调整其确认响应期限，使得相关的接收方节点220、222可以满足确认响应期限并且在适当的期限内不会发送确认。例如，如果提交节点210确定接收方节点220、222可能需要更大量的时间来确认特定拟议交易240，则它可以提供丰厚的逻辑时间偏移，以便在某种程度上将拟议交易240的逻辑时间戳设置为比外部节点230提供的物理时间戳晚。相反的示例也是可能的。

另外，在示例中，逻辑时间戳可以用作拟议交易240的限定交易时间，这可以影响拟议交易240相对于其它交易的排序。换句话说，可以通过检查所有交易的逻辑时间戳并使用逻辑时间戳及时地对这些交易进行排序来确定包括拟议交易240的交易的全局全序。如此，通过提供逻辑时间偏移，提交节点210还可以在合理的范围内在某种程度上指示拟议交易240相对于其它交易的排序。具体地，如果提交节点210关注拟议交易240的优先级，则它可以将逻辑时间偏移设置为相对较短，从而确保拟议交易240接收最佳的逻辑时间戳，并有可能在交易的全局全序中获得优先级。

在一些情况下，可以给定交易时间，该交易时间更改了包括拟议交易240在内的交易的顺序。本文中，这种重新排序有时被称为逻辑重新排序，因为该重新排序可以基于交易的逻辑时间戳。通过逻辑重新排序，如上所述，可以给拟议交易240逻辑时间戳，该逻辑时间戳在某些示例中基于外部节点230的物理时间戳和逻辑时间偏移。在一些情况下，逻辑时间偏移可以被视为物理时间戳与逻辑时间戳之间的差。根据以下考虑，可以选择逻辑时间偏移，以使其不会太大或太小。如果逻辑时间偏移大，则拟议交易240可能倾向于提前运行。即，仅作为示例，在交易tx₁已经被提交并且接收到(例如，由提交节点210一定程度地规定的)逻辑时间戳之后，网络中的另一参与者节点可以稍后提交冲突的拟议交易tx₂，该冲突的拟议交易接收到较早逻辑时间戳(例如，由于此类参与者节点提供的逻辑时间偏移)。如果稍后拟议的交易tx₂被确认并被输入到分类帐中，则tx₁可能会被拒绝，因为它与tx₂发生了冲突，即使根据其物理时间戳tx₁首先出现也是如此。因此，实际上，提交节点可能会发现，将逻辑时间偏移设置为最短，可能给定了其它节点的资源限制和验证交易所需的时间，以便使提交节点的拟议交易得以确认并被输入到分类帐中而没有其它冲突交易“跳过队列”。

可替代地，如果在较早交易tx₁的确认响应期限之后拒绝了较晚拟议交易tx₂，则由于对tx₁的确认响应期限已经过去，因此也可以拒绝tx₁。在这种情况下，最终两个交易都将被拒绝。相反，如果逻辑时间偏移较小，则接收方节点可能由于计算或网络约束条件而无法在确认响应期限之前简单地发送确认。因此，如果逻辑时间偏移设置得太小，则交易可能会被拒绝。

在又一种情况下，拟议交易tx₁可以由提交节点提交，分配逻辑时间戳，由相关接收方节点确认并被输入到分类帐中。后续拟议交易tx₂可以由相同或另一提交节点提交，分配早于tx₁的逻辑时间戳的逻辑时间戳，由相关的接收方节点确认并被输入到分类帐中。由于tx₂的交易时间(例如，逻辑时间戳)早于tx₁的交易时间(例如，逻辑时间戳)，因此可能会发生逻辑重新排序，即使交易tx₁首先提交，在交易的全局全序中，tx₂也优先于tx₁。

加密

可以使用对称加密或非对称加密或两者来对加密子消息进行加密。非对称加密使用多个密钥、公钥和私钥来对数据进行加密和解密。可以使用任何合适的加密方法，例如可以使用RSA或椭圆曲线加密。

对于加密，可能有以下操作：

·确定性非对称加密方案E_pub(pk，m)，该方案使用给定的公钥pk(例如，称为公钥加密)对任意消息m进行加密。

·对称认证的加密方案E_sym(symk，m)，该方案使用给定的对称密钥symk对任意消息m进行加密。认证可以防止由外部节点230进行的潜在修改(称为对称加密)。

·匿名推导方案，匿名(参与者，令牌)，该方案使用给定令牌导出给定参与者的匿名。

加密子消息

为了准备加密子消息144、244，提交节点110、210可以首先获得秘密令牌tok_a(在示例中，来自身份管理器170)并为每个动作“a”准备新的现时key_a。令stkh_a表示动作a的利益相关者。Subsa是按顺序遍历a所获得的a(包括a自身)的子视图的列表。

在示例中，然后可以按如下方式得出用于动作a的加密子消息：

1.加密动作是E_sym(keya，(bound(a)，desc(a)))，其中bound是表示当事利益相关者将自己绑定到的可选的预先规定的共享物理-临时约束条件的函数。例如，bound可以估计动作a的资源消耗(由资源模型提供)，而desc(a)可以是描述a的某种完整方式(例如，模型表达式或评估轨迹，以及泄露的输入)。

2.令密钥为与a的子视图相关联的密钥列表([key a’|a＜-subs_a]，将其理解为“对子视图进行解密的密钥列表”)。然后，保护密钥以包装密钥的形式作为密钥列表的公共加密列表进行存储和传输，并为每个交易利益相关者提供条目([E_pub(pk(stkh)，keys)|stkh＜-stkh_a])。换句话说，加密子消息的这部分可以例如是与交易的每个利益相关者相对应的加密公钥列表，其中相关的利益相关者已知对应的私钥(例如，允许利益相关者对加密子消息进行解密)。

3.用于生成该动作的期望确认者的匿名的令牌为[tok_a’|a’＜-subs_a]。换句话说，加密子消息的这部分可以例如包括令牌列表，可以从令牌中导出需要确认特定动作的每个期望确认者的匿名(例如，十六进制地址)。例如，此类信息可用以允许网络中的节点(例如，外部节点230)确定网络中的哪些节点需要确认特定动作。

因此包含拟议交易有效载荷的加密子消息可以用数据类型来描述(在此处用Haskell编写，但是可以用多种其它语言实现)：

期望确认

假定对于每个拟议交易(例如，图2a至图2b中的拟议交易240)，可能存在接受/确认拟议交易所需的确认，并且节点可以确定如下确认：节点应该期望接收到交易。期望确认可以是参与者节点在拟议交易被接受/确认并被输入到分类帐中的过程中的必要肯定响应。在一些实施例中，每个节点可以确定需要哪些节点来提供确认(例如，根据该特定节点的交易范围的视图)。即，节点210、220、222可以评估要求接收方节点220、222中的哪一个提供确认以便接受或确认拟议交易240。例如，以完全确认的确认条件提交拟议交易240的提交节点210可以确定期望的确认是来自过程中的所有参与者节点，并且已经接收到所有确认。

在一些示例中，协议可以指定确认策略。在其它示例中，确认策略(可能包括在单独标题下说明的确认条件)至少部分地由提交节点在拟议交易中指定。

期望确认可以全部或部分确定。即，在一些情况下，节点可以确定该节点有权查看的交易的可见部分而不是整个交易需要哪些期望确认。在这种情况下，节点可以基于节点已针对节点有权查看的交易部分接收到的确认，来确定接受/确认了交易部分。

在示例中，拟议交易240可以在加密子消息244中包括描述所有有效的期望确认的信息(诸如期望确认数据)。此类信息可以用于验证接收到的确认，这可以包括使用密码功能以利用期望确认数据来验证接收到的确认。在一些示例中，期望确认可以是公钥的形式以及需要这些密钥签名的交易部分的哈希。如果正在使用身份管理器270，则密钥可以是已知密钥的匿名，并且哈希可能会加盐以保护参与者节点的隐私。因此，可以通过以下数据类型(用Haskell编写)给出整个交易的期望确认：

type ExpectedConfirmations＝[([Pseudonym]，SaltedHashActionDescription)]

系统的其它特性

在一些示例中，为了确保确认150、152、250、252及时发生，使用了超时的概念。例如，如果在超时参数之后无法确定交易的有效性，超时参数可以由域规则定义(请参阅下文)，则可以拒绝该交易。

此外，在一些示例中，节点做出并宣布物理或时间交易承诺，诸如交易容量承诺(例如，所需的计算和大小)或结构使用承诺(例如，与存储分片模型对齐)。通常，这可以由提交节点在提交拟议交易时完成。承诺可以按流程进行，提供按流程和按交易对手方的担保。物理或临时交易要求可能会延长交易超时。

如果存在无响应的节点，则可以将这些节点标记为此类。本公开可以使用争议解决机制来消除无响应性并且不维护容量承诺。

确定有效性

节点可以执行许多检查以确定交易的有效性。交易有效性检查的示例如下：

a.冲突

i.此检查涉及确定是否有任何先前的交易已经消耗了相关合同(例如，DAML合同)或构成过程部分的输入。

b.授权

i.此检查涉及基于授权规则确定允许提交节点来提交该交易。

c.一致性

i.这涉及确定交易是否符合一致性规则。

d.时间约束条件

i.这涉及确定交易时间是否满足时间约束条件。

e.物理-临时约束条件

i.这涉及确定物理或临时交易承诺是否满足账本利益相关者之间商定的物理-时间要求规则的分支版本的选择(例如，可以使用哪种容量或分片模型)。

f.资源检查

i.这涉及检查是否正确指定了交易资源要求。例如，节点可以读取作为交易部分指定的交易资源要求，然后，如果节点使用的资源在指定的资源要求之内，则节点可以执行交易。在示例中，如果节点用于执行交易的资源超过指定的资源要求，则该节点可能会使交易失败。这样做的好处是可以防止网络中的节点无条件地提交超出节点指定资源要求的交易。

冲突

节点110、120、122、210、220、222可以执行的检查中的一个是确定拟议交易140、240是否与先前的拟议交易或先前确认的交易冲突。此类冲突是系统并发性所固有的，并且不必由于故意的不良行为(恶意)或操作问题而出现。冲突可包括合同(例如，DAML合同)或作为过程部分的输入先前是否已被一个或多个交易消耗。

在一些示例中，节点110、120、122、210、220、222可以执行的检查中的一个是确定拟议交易140、240是否与当前或即将到来的拟议交易，或当前正在验证或将在不久的将来被验证的交易冲突。此类冲突是系统并发性所固有的，在该系统中，可以做出不一致的物理实现选择(例如，分片)，或者使用无序的交易逻辑(例如，对于大笔交易，诸如类似批处理的活动)，或通常针对所有缓存或类似锁的分类帐支持逻辑(例如，出于优化目的而维护或支持另一账本功能)，并且不必由于故意的不良行为(恶意)或操作问题而出现。冲突可包括先前是否已经发起一项合同(例如，DAML合同)以供一个或多个交易消耗。

授权

节点110、120、122、210、220、222可以执行的另一项检查是确定拟议交易140、240是否被充分授权。这包括确定提交节点是否被分类帐的状态和规则授权来提交交易。

一致性规则

节点110、120、122、210、220、222可以执行的另一项检查是确定拟议交易140、240关于每个节点的账本一致性规则是否格式正确。确定拟议交易是否格式正确可以包括确定拟议交易是否符合该拟议交易的一组一致性规则。例如，这可能包括确定拟议交易是否遵守指定的格式或特定的账本工作流程，或者拟议交易是否包含所有必要的数据。规则之一可以包括拟议交易是否被授权。例如，这可能还包括确定拟议交易的物理-临时要求(在下文中进一步详细讨论)是否符合利益相关者先前定义或商定的规则。因此，如果请求未能通过一致性标准(例如，执行不当的分类帐工作流程选择或物理-临时要求)或授权标准(例如，节点的分类帐工作流程不允许拟议交易的提交者提交交易)，则该请求在某种程度上可能被视为格式错误(也称为格式错误)。这通常仅是由于参与者的平台组件的恶意或正确性问题(例如，软件漏洞)而发生。

一致性的特定情况可能是遵守以智能合约语言(例如，DAML)定义的程序或脚本。

时间约束条件

节点可以执行的另一项检查是确定交易时间以及它是否在时间约束条件内。例如，节点可以确定拟议交易中的交易时间是否与拟议交易的外部节点的时间戳相距太远。将交易的期望资源消耗添加到拟议交易中的情况下，允许的偏差窗口可能取决于资源消耗，因为提交者可能需要在提交交易之前处理该交易。即，可以在域规则内将其定义为超过规定的期望资源消耗的因素。

换句话说，确定拟议交易的有效性可以包括确定当前时间是否在拟议交易的交易时间的超时窗口内(例如，当前时间是否大于拟议交易的交易时间加上某个预设时间值)。在示例中，交易时间可以被认为是逻辑时间戳，可以与交易的未加密子消息一起提供。验证拟议交易的节点可以将当前时间与拟议交易的交易时间进行比较，并确定当前时间是否在超时窗口内(例如，当前时间是否在确认响应期限之前)。如果是这样，则如果其它有效性检查也通过，那么节点可以继续处理拟议交易并相应地发送确认响应。如果当前时间在超时窗口之后，则该节点可能会使交易失败。

物理-临时约束条件

节点可能执行的另一项检查是确定物理或临时交易承诺是否满足交易或域的利益相关者之间商定的物理-临时要求规则的分支版本。例如，节点可以确定交易成本计算与指定的物理-临时要求规则不兼容。例如，提交者节点可以表达其用来将拟议逻辑时间与交易的所述资源消耗联系起来的规则，或者提交者可以表达所利用的分片模型如何与外部节点和中介节点的多个实例的选择联系在一起。

确认条件

为了在信任、完整性和可用性之间进行权衡，系统可以考虑不同的确认条件。如下面更详细解释，确认条件可以是足以确定交易被接受或确认并且可以被输入到账本中的确认阈值。

确认条件可以是对拟议交易被接受或确认并适当地被输入到账本中的限制或先决条件。确认条件可以涉及从接收方节点接收一个或多个确认(例如，确认的阈值量)。

可以有多种类型的确认条件，并且要使用的适当确认条件可能取决于所涉及的各当事方、过程以及潜在的考虑因素，诸如网络条件。例如，如果网络条件良好，则可能需要完全确认条件，但是如果网络上出现流量拥塞，则乐观的确认条件可能会令人满意，直到网络有所改善。

使用完全确认条件，可以要求从与该过程中的参与者相对应的每个接收方节点接收到确认。

使用签名确认条件，可以要求从与该过程中的签名参与者相对应的每个接收方节点接收到确认。

使用乐观的确认条件，可以要求最近的确认流满足指定的标准。例如，相关节点在分配的时间段内接收到指定量的确认。

使用“VIP”确认条件，确认标准可以取决于接收方节点的属性。例如，VIP确认条件可以指示从与该过程中的参与者相对应的指定子集的接收方节点(例如，指定为VIP节点)接收到确认。即，可能有一些节点必须提供确认，而其它节点不一定需要提供确认，这可以反映在确认条件中。

“VIP”确认可以通过加密证明程序(例如，zkSNARK、zkSTARK)或受信任的执行环境(例如，Intel SGX)的证明来实现。换句话说，在示例中，网络中的节点可以充当证明程序(例如，当使用VIP确认策略时)，该证明程序可以向作为拟议交易的当事方的其它节点证明，该拟议交易满足所有有效性检查，如本文中描述(例如，以上段落[134]中描述)。在示例中，证明程序节点可以向拟议交易的各当事方提供加密证明(例如，zkSNARK、zkSTARK)，以加密方式证明拟议交易满足所有有效性检查并且可以被接受为确认交易。如上所述，加密证明可以是零知识类型的证明，可以将其提供给拟议交易的所有各当事方，以便所有各当事方可以对拟议交易的有效性充满信心，但也不能访问有关相关当事方通常无法访问的拟议交易的隐私细节。类似地，可将诸如Intel SGX之类的受信任执行环境与加密证明程序一起使用或代替加密证明程序使用。

通常，在可以信任节点而没有恶意(即，故意的不良行为)的情况下采取行动的域中，乐观的确认条件可能足以确保交易接受性。即，为了提高效率，可以假定节点的行为没有恶意，并且接收方节点都不是恶意的。然而，仍然可以检测和证明恶意。在一些情况下，恶意行为的后果可能会在系统外部处理。

在一些示例中，确认条件还可以要求提交节点及时接收(和/或由接收节点发送)对拟议交易的响应(可以认为是对有效性请求的确认)。这包括在下面的其它示例中讨论超时和期限。

域规则

域规则是域的所有参与者都已商定的一组规则。域规则可以控制争议解决过程或诸如惩罚之类的结果。

例如，如果节点120、122、220、222没有在指定的时间范围内发送确认，则可以通过将该节点暂时从网络中排除或通过使用某些其它惩罚来对该节点进行惩罚。在一些情况下，可能需要先建立良好的行为，然后才能再次完全访问网络。例如，节点120、122、220、222可能会暂时从网络中排除，无法提交交易，然后被允许处于“仅确认”模式，直到受惩罚的节点接收到一系列按时确认为止。

拒绝交易

由于多种原因，可以拒绝拟议交易140、240。拒绝的一种理由可能是拟议交易140、240具有多个域而没有这样表示，意味着拟议交易140、240试图使用驻留在不同域上的过程102、202或合同(例如，DAML合同)而未指明拟议交易140、240是多域交易。在一些情况下，可以允许这样做，但是一般规则可以是拟议交易140、240应该具有单域。

在示例中，域规则建立确认条件。在这种情况下，有可能在超时窗口内接收到的确认信息不足，无法根据域规则将交易声明为最终接受。

拒绝拟议交易140、240的另一原因可以是拟议交易140、240与一个或多个其它交易不一致；即，它与先前接受/确认的交易冲突。

在一些示例中，交易协议要求所有利益相关者被告知交易是否被批准，以及相反地，交易是否被拒绝。在一些示例中，协议要求将声明的决策原因告知交易的已声明利益相关者。

任何节点都可以提出争议，这可能导致将有问题的节点标记为离线。然而，提出无效争议也会使节点受到惩罚。因此，如果提出了争议，拟议交易也可以被拒绝。如果接收方节点确定拟议交易格式错误，或者不同的节点对同一交易部分的有效性给出了相互矛盾的响应，则可能会发生这种情况。在示例中，这两种情况都可能由于恶意或软件漏洞而发生。即，在大多数情况下，可以期望节点正常工作。

确认心跳

共享构成交易的有效合同102、202(或过程)的每对参与者之间有时会交换那些合同上的已签署的声明，本文中称为确认心跳，以便参与者可以在双边(或多边)上确认合同/交易的状态。声明的形式为“在时间戳t_s上，这些都是已最终确认的所有有效相互合约”。它们可用于解决争议。例如，参与者A可以通过显示来自B的最新心跳(包括c)，即在时间戳t_s上的心跳中，向仲裁证明与参与者B的合同c在某个时间t仍然有效，并且公开t_s与t之间发生的所有交易。通过精心设计动作描述和消息传递层的传递证明，除了从已公开交易中获得的合同ID之外，仲裁无需了解任何信息。

为了保护参与者的隐私，在一些示例中，声明可以仅包含有效合同上的默克尔树的根。为了确保参与者可以检查彼此的声明，树的构造必须是确定性的，并且两个参与者都可以复制。

隐私

所公开的系统可以包括以下隐私特征中的一个或多个。

要求(不向不相关的参与者公开)。交易协议可以仅向动作的利益相关者参与者公开已提交的交易(包括其利益相关者和确认者)中的行为。在这种背景下，动作是指与利益相关者参与者有关的权利的创建或行使，该权利被记录在分布式账本中，而利益相关者参与者又对该动作予以承认(这固有地意味着：(i)交易协议批准该动作；以及(ii)符合基础系统模型)。将参考图14a和图14b在所示的示例来描述该隐私方面，反映了图3中所示的交易。

参考图14a，托管A的参与者节点可以查看整个交易(第一方框1410)，因为A是根动作的利益相关者。出于相同的原因，托管P的参与者节点也查看整个交易(第一方框1410)。注意，托管P的参与者节点可以查看第二动作(第二方框1420)，但它并不是严格意义上的利益相关者。它仍然查看第二动作，因为它是第一动作“Exe P(油漆要约AP)“接受”的子动作。

托管银行的参与者节点仅查看第二动作(第二方框1420)。注意，该要求允许交易协议向银行公开第一动作1410的结构。这由图14b中的方框1410’示出。

1410’中的问号“？？？”表示传递给银行的消息包含该动作的隐藏哈希，但是该银行无法从该哈希中导出该动作。

要求(不公开提交者)。在一些示例中，交易协议可能仅向交易的顶级操作的利益相关者参与者公开交易的提交节点或提交者。

在油漆栅栏交易中，A和P的参与者可以了解提交节点，因为他们对整个动作具有可见性。然而，银行的参与者节点可能不会(或在必要时不得)了解提交节点或提交者的身份。

要求(不向消息代理和中介公开)。交易协议不得向外部节点230或中介280公开已提交交易的内容(即加密子消息144的内容)。

限制(公开利益相关者和确认者)。交易协议可以向外部节点230或中介280公开已提交交易的利益相关者和确认者。此信息可以从未加密子消息142中导出。

限制(公开加密交易)。交易协议可以向外部节点公开所提交交易的加密版本，例如，不能由外部节点解密的加密子消息144。

限制(被不诚实的参与者公开)。交易协议不会阻止不诚实的参与者向第三方公开交易。

限制(向审计师公开)交易协议不会阻止参与者向审计师公开交易。

交易视图

可以从下面描述的各个节点的角度通过交易视图进一步说明系统的隐私。

交易协议可建议系统应针对交易中的每个动作分别获取确认响应。在更复杂的示例中，这导致发送过多的消息。因此，交易视图的概念可以用来减轻这种负担。即，如何将多利益相关者交易分解为一组最小的不同视图，使得每个节点仅查看他们需要查看的内容，并最大程度地减小数据结构大小。

交易视图-给定交易tx，交易tx的视图是满足以下属性中的一个的交易的子动作：

1.子动作在tx中没有父动作。

2.与该子动作相比，tx中该子动作的父动作具有不同的利益相关者或不同的确认方。

视图的核心是从视图中删除所有子视图(视图本身除外)。

这在图16a和图16b中得到最好的说明。假定已经制定了完全确认策略；因此，每个利益相关者都是确认方。如图16a中所示，接受油漆要约和创建油漆协议属于相同的第一视图1610，因为这两个动作具有相同的利益相关者(因此也具有相同的确认方)。借据转移属于单独的第二视图1620，因为银行不是第一视图1610的利益相关者。创建P的借据再次属于单独的第三视图1630，因为油漆工P不是第二视图1620的利益相关者。

图16b示出了第一视图1610’的核心。因此，视图的核心从该视图中删除了可以减小消息大小的无关信息以及存储此类信息(诸如对应子消息的某些部分)的数据要求。这可以包括将与交易视图有关的信息存储在分布式账本中。应当理解，第二视图1620和第三视图1630具有相应的核心，其可以涉及不同的利益相关者、确认方(以及相应的节点)。因为只有那些有权查看视图的人才能查看相应的信息，所以这可以有助于子交易的隐私。

应当理解，可以构建数据结构来表示上述交易和视图。这可以包括交易树，该交易树是表示交易的可隐藏的默克尔树，可以包括：交易、交易的每个视图的利益相关者，以及分类帐有效时间和确认策略。可能的要求是即使内容相同，两个不同的子树也具有不同的Merkle根哈希。

交易树

图17示出了代表油漆栅栏交易1701的候选数据结构1700。这可以包括以下组：

(1)由1710和1711表示油漆要约的接受

(2)由1720和1721表示借据的转移

(3)由1730表示创建新的借据作为转移的一部分

在此背景下，术语“可隐藏的默克尔树”表示以下特征或具有以下特征：

·每个子树具有哈希。

·如果子树被其哈希替换，则整个树的哈希将保持不变。

·实际上，攻击者不可能从其哈希推导子树的内容。为此，哈希必须取决于隐藏因素，这些因素包括在交易树中。

子树哈希的唯一性是必需的，因为子树的哈希将用作子树的唯一标识符。还需要避免可以查看一个子树的参与者可以推断出另一子树是否具有相同的内容。子树哈希的唯一性可以通过应用唯一的隐藏因素来实现。

定义(交易和视图的哈希)。交易树的交易哈希是树的Merkle根哈希。交易视图的交易视图哈希是表示交易视图的交易树的子树的Merkle根哈希。

图18示出了油漆栅栏交易的子视图1730的候选表示1800，该油漆栅栏交易创建了油漆工拥有的借据。关于其它视图的信息(诸如油漆要约的接受1710、1711和借据的转移1720、1721)不可见。这可用于提供子交易隐私。

利益相关者树-交易的利益相关者树是该交易树的部分隐藏版本，具有以下属性：

(1)交易视图的内容是隐藏的。

(2)分类帐有效时间是隐藏的。

(3)确认策略是未隐藏的。

(4)所选交易视图的哈希是未隐藏的。

(5)如果未隐藏交易视图的哈希，则视图的利益相关者被隐藏。

在交易的整个利益相关者树中，交易的所有视图的哈希都是未隐藏的。图19是油漆栅栏交易的整个利益相关者树的候选表示1900。利益相关者的信息1913、1923、1933是可见的，而其它信息1950是隐藏的。

在对参与方p1、……、pn未隐藏的利益相关者树中，对那些p1、……、pn是利益相关者的视图的哈希正好是隐藏的。图20示出了对于油漆栅栏交易的银行未隐藏的利益相关者树的候选表示2000。与图19不同，利益相关者1913是隐藏的2013(因为银行不是参与者A与P之间的油漆协议(要约/接受)的利益相关者。利益相关者信息2023、2033对于银行是可见的，因为它们是利益相关者。

上面的示例说明了在交易的不同级别上维护隐私的机制，同时允许利益相关者查看其作为利益相关者的信息(或有权查看此类信息)。换句话说，根据所描述的隐私模型，前面的示例说明了如何将交易发送给多个利益相关者，而同一笔交易的不同部分对相关利益相关者是隐藏的。如此，多个利益相关者可以接收同一笔交易，但具有该交易的不同隐私视图。此类构造允许在保持网络中各种节点之间的隐私的同时将交易提交和记录到共享账本。

虚拟共享分类帐

在一些示例中，交易协议隐式地创建虚拟共享分类帐。虚拟共享分类帐的属性由交易协议强制执行。虚拟共享分类帐是虚拟概念。通常，没有一个参与者可以存储整个虚拟共享分类帐。然而，如果所有参与者都公开了与交易协议交互产生的消息，则可以从这些消息推导虚拟共享分类帐。

首先，定义虚拟共享分类帐上的该组动作。理想情况下，当且仅当协议已批准基础交易时，动作才属于虚拟共享分类帐。如果交易的所有利益相关者参与者都是诚实的，则实际上该属性成立。

然而，如果一些利益相关者参与者不诚实，即使根据验证算法应拒绝该动作，他们也可能会批准该动作。特别地，不诚实的参与者可能会使交易协议批准不符合基础DAML模型(或替代系统模型)的交易。因此，如果动作是协议已批准的交易的一部分，则该动作必须满足其它属性才能成为虚拟共享分类帐的一部分。

对虚拟共享分类帐的动作-如果以下属性成立，则该动作是虚拟共享分类帐的一部分：

i.该动作是交易协议已批准的交易的一部分。

ii.该动作符合基础系统模型(例如，用于DAML系统的DAML模型)。

iii.对于该动作的每个子动作A(包括该动作本身)，根据系统语义(例如，DAML语义)，声明的A利益相关者正好是A的利益相关者。

在油漆栅栏交易的示例中说明了该示例定义。假定基础系统模型(在本例中为DAML模型)包含示例中使用的所有动作，使得交易符合基础系统模型。还假定已使用完全确认策略提交了交易。首先，考虑例如根据DAML语义正确声明利益相关者的情况。如果整个交易已被批准，则交易中的每个动作都是虚拟共享分类帐的一部分。否则，即，如果交易已被拒绝，则交易中的任何动作都不是虚拟共享分类帐的一部分。

图15a示出了以下情况：A而不是P提交了油漆栅栏交易，并且A没有声明P为第一动作1510的利益相关者。另外，假设协议已经批准了该交易。

第一动作1510不是虚拟共享分类帐的一部分，因为尚未将P声明为利益相关者。这是有道理的，因为P是“接受”选择的控制者，但它甚至没有查看动作。

由于A和P已被正确声明为利益相关者，因此油漆协议的创建(1520)是虚拟共享分类帐的一部分。由于A和P都已通过其参与者节点批准了该动作，因此将动作添加到虚拟共享分类帐中很有意义。

出于相同的原因，从A到P的借据转移(动作1530和1540)是虚拟共享分类帐的一部分。从虚拟共享账本中排除借据转移是不可行的，因为需要向世界银行告知有关情况。

图15b示出了未将A声明为创建油漆协议(1520’)的行为的利益相关者的情况。同样，假设协议已批准交易。

由于尚未将A声明为利益相关者，因此油漆协议的创建(1520)不属于虚拟共享分类帐。这是有道理的，因为该动作会在不通知A的情况下创建油漆协议。油漆要约的接受(1510)也不是虚拟共享分类帐的一部分。如果它是虚拟共享分类帐的一部分，则虚拟共享分类帐将不符合DAML模型(或替代系统模型)，因为DAML模型不允许在未创建有效的油漆协议(1520)的情况下接受油漆要约。

像以前一样，借据转移(1530和1540)是虚拟共享分类帐的一部分。没有理由进行反对，因为A和银行都批准了该交易。

已经解释了在什么条件下动作是虚拟共享账本的一部分，现在将解决“何时”交易是虚拟共享账本的一部分的问题。

虚拟共享分类帐上的交易。如果以下属性中的一个成立，则交易tx是虚拟共享分类帐的一部分：

1.交易tx已经由交易协议提交，并且tx中的所有动作都是虚拟共享分类帐的一部分。

2.交易tx已作为另一交易ptx的一部分经由交易协议提交。交易tx是由于从ptx中删除了不是虚拟共享分类帐的一部分的那些动作而导致的。

最后，如下定义虚拟共享分类帐的示例。

虚拟共享分类帐在一些示例中，虚拟共享分类帐可以包括以下属性：

i.虚拟共享分类帐是一系列交易。如上所述，它包含那些属于“虚拟共享分类帐的一部分”的交易。

ii.虚拟共享账本上的交易顺序与提交顺序相对应。可替代地，按照根据协议指定的顺序，诸如根据“逻辑重新排序”讨论的顺序)。

iii.虚拟共享分类帐上的每个记录的动作都用其确认方和确认方的签名(例如，接收节点的签名)进行修饰。

iv.如果虚拟共享账本上的交易与已提交的交易相符，则该交易将以其提交者和提交节点的签名进行修饰。

如上所述，通常没有单个参与者存储整个虚拟共享账本。然而，如果所有参与者都根据交易协议公开了彼此之间交互产生的消息，则可以通过组合这些消息来推导出虚拟共享分类帐。

示例方法

图4示出了由系统200执行的示例方法。应当理解，该方法也可以使用系统100来执行。

在该示例中，外部节点230可以确定410与构成涉及多个参与者的过程的多个交易相对应的多个消息的顺序。应当理解，确定步骤410可以在以下描述的一些步骤之前，之间或之后执行。

与该过程中的参与者相关联的提交节点210可以提交420拟议交易(诸如图2a中的240)，其中提交拟议交易可以包括将部分加密消息(诸如，受密码保护消息)发送给与该过程中的参与者相关联的一个或多个接收方节点(诸如接收方节点220)，部分加密消息至少包括能够由外部节点230读取的未加密子消息242以及至少保护来自外部节点230的隐私的加密子消息244(诸如受密码保护子消息)。

接收方节点220然后可以确定430部分加密消息的有效性。这可以涉及对拟议交易240执行有效性检查，然后，如果有效性检查通过，则向提交节点和接收方节点220确定期望或需要确认的任何其它节点发送确认。在示例中，接收方节点220可以通过中介节点280发送确认。在其它示例中，接收方节点220可以对等发送确认。

然后提交节点210可以从接收方节点220接收440部分加密消息的有效性确认。

然后提交节点210可以基于从一个或多个接收方节点接收满足确认条件的一个或多个确认，将拟议交易作为接受或确认的交易来完成450。如上所述，确认条件可以例如是完全确认条件、VIP确认条件或设置为系统参数的某些其它确认条件。

在这种情况下，然后作为提交节点210的节点可以根据外部节点230确定的顺序将接受/确认的交易写入460到分类帐中。分类帐可以是本文详述的任何分类帐，包括分布式“虚拟”分类帐。在示例中，作为交易的一部分的接收方节点220(或节点220、222)可以在(一个或多个)此类节点接收到足够的确认250、252以满足确认条件之后，也将接受/确认的交易写入到账本260、262、264自身的副本中。在某种意义上，在示例中，交易的节点210、220可以在节点之间形成“虚拟”共享账本，这些账本专用于节点210、222之间发生的任何数量的交易。

应当理解，每个节点110、120、122、130、210、220、222、230、330、340、342可以执行所述方法的对应部分。

示例节点

图5示出了示例节点，其可以是本文公开的节点110、120、122、130、210、220、222、230、330、340、342中的任何一个。图5中所示的节点210包括处理器502、存储器503、网络接口设备508、510、与账本260对接的分布式账本接口设备509、以及用户界面512。存储器503可以存储指令504和数据506，并且处理器502可以执行来自存储器503的指令以实现如图3所示的过程。

处理器502可以通过用户界面512从用户(诸如参与者516)接收输入。处理器502可以基于分布式账本152中记录的当前执行状态来确定指令。指令可以是要执行的函数。处理器502可以执行存储在程序代码504中的指令以向参与者516指示任何输出514或结果。

资源模型

拟议交易140、240可以在资源单元方面包含一个或多个资源要求，这些资源要求表示对预定的共享物理-临时约束条件(处理时间、存储器、网络、存储)的选择，在示例中，每个请求消息可确认子块有一个资源要求以供每个接收方验证和确认交易。

每个节点110、120、122、130、210、220、222、230、330、340、342都可以保证在指定的时间段内提供指定资源量。此类容量保证可以限于一个过程或一组节点。所有资源要求均根据适用的最具体的容量承诺进行收费。节点可以立即拒绝资源要求超过其未使用容量要求的交易。节点可能会回复以指示其资源容量超出津贴。诸如仲裁节点之类的容量监测器可以基于超出其资源容量的津贴来确认所有拒绝。因此，容量监测器可以根据相关节点做出的容量承诺进行检查。

在一些示例性系统中，已经通过节点的先前交易或拟议交易以及涉及节点及其参与者的接受来创建并可能更新了节点的容量承诺。可以使用本公开中描述的交易来实现这种容量保留交易。在一些示例性系统中，容量承诺被保留用于特定子集的交易类型。这可以允许一些示例性系统具有专门承诺的容量以处理容量创建和更新交易。

可以在交易中声明资源要求，但不能声明交易本身的内容。因此，提交节点理论上可以声明比通过处理和验证交易消耗的实际资源低的资源要求。接收方节点可以检测到这种不匹配，并基于提交节点在欺骗资源消耗方面提出争议。

资源津贴

与资源模型有关，在一些情况下，可能需要由提交节点110、210(提交费)和在交易中对合同(例如DAML合同)进行选择的适用的接收方节点120、122、220、222(验证费)支付提交费或资源津贴。可以向运行域的运营商和/或交易的利益相关者支付费用。可以将费用确定为交易成本的函数，交易成本由交易、过程和域所需使用的资源量决定。为了轻松做到这一点，每个节点都可以有费用帐户，在该费用帐户中扣除费用并将其记入费用帐户。

核算组件可以为每个参与者维护一个帐户。当消息代理(例如，外部节点230)给交易加盖时间戳时，可以将提交费用记入提交者的帐户。当交易完成时，可以转移验证费。参与者可以使用专用的工作流程为自己的费用帐户充值。

在一些示例性系统中，可以使用本公开中描述的交易来实现费用核算和交易逻辑。在这种情况下，操作员或操作员代表可以是域中节点的参与者。然后，可以在账本逻辑内实现费用核算规则和费用支付逻辑，而无需其它核算组件。此外，可以在拟议交易和确认消息(无论是否加密)内传输费用数据或支持数据，而无需其它交易逻辑。这可以允许参与者创建和更新用于通过交易进行费用计算的费用规则，和/或允许费用计算专用于参与者和交易内容。例如，当参与者节点在账本过程中的唯一作用是进行验证时，可能无需支付验证费用。

争议

当参与者行为异常或失败时，诸如当参与者未在商定的时间范围内确认交易，系统地请求未通过验证的交易或声明资源要求不足时，可能引发争议。

仲裁节点可以形成系统的一部分，并可以存储评估争议的证据；即，可能需要存储发送的交易和确认。可能要求涉及争议的节点提供证据，即它们的未隐藏交易，使得可以解决争议。为了维护隐私，节点可以以仅仲裁节点可以对交易进行解密的方式对交易进行重新加密。

在一些示例性系统中，使用本公开中描述的交易来实现争议解决过程。在这种情况下，仲裁可以是域中节点的参与者。然后，可以在账本逻辑中实施争议解决流程，而无需其它核算组件。无需其它交易逻辑即可提出争议，提供证据并确定解决结果。这可以使参与者通过交易提出争议，提供证据并解决争议。

超时争议

如上所述，在一个示例中，确认条件要求参与者及时响应拟议交易。如果参与者未及时响应，则该交易的参与者节点(或委托人)可以向仲裁节点发起超时争议。这可用于确定不合规，并且更重要的是，确定导致不合规的特定参与者节点。处理此类超时争议的示例可以包括以下项中的一个或多个：

·将当事确认请求的时间戳以及未响应的消息传递API和(匿名参与者的匿名)提供的关联证据提交给仲裁节点。如果已知，还将发送匿名后面的身份。

·如果未提供身份，则仲裁节点请身份管理器170取消隐藏。确定被告参与者的身份后，仲裁节点向参与者发送请求，以证明他们(特别是参与者的各自节点)已做出响应。证据是来自消息传递服务的带有时间戳的消息，其中包含来自被告参与者或容量监测器的确认响应(在请求被OutOfQuota响应拒绝的情况下)。

·如果提供了证据，则请求的发起方将永久地进入“仅确认”模式：禁止他们向系统发送进一步的确认请求，但是我们仍然允许他们接收消息并发送确认响应。

·如果被告参与者没有响应，则会播放一条消息，将其标记为离线。将离线参与者移到仅确认模式，并且允许其它参与者拒绝其确认请求。由于在当前方案中提交者是匿名的，因此可以由容量监控器或津贴核算师完成拒绝。在被告参与者重新联机之后，他们可以发出请求以再次由仲裁节点进行标记。该请求可能仅在一定的“冷静”期之后才被批准，以激励参与者保持与他们保持联系。

·如果被告参与者以无效证据做出响应，则他们将永久(或在指定的惩罚期内)移到仅确认模式。

检测并证明参与者的行为异常

参与者的行为异常可能是由于恶意动作引起的。示例包括：

·参与者提交的交易不符合基础系统模型(例如，DAML系统中的DAML模型)。

·参与者代表该参与者未托管的提交方提交交易。

·参与者提交的交易需要获得提交方以外的其它方的授权。

·参与者提交了格式错误的交易。

·参与者根据DAML(或其它替代系统)语义，分别从利益相关者参与者中定义已声明的利益相关者参与者。因此，错误的参与者会被告知该动作。

·确认交易的接收方节点未应用协议指定的算法来验证动作。例如，尽管该动作使用存档的合同，但它仍批准该动作。或者拒绝根据验证算法应批准的动作。

·外部节点传递的消息中的接收方节点列表不正确，或者无法将消息传递到接收方节点。

行为异常及其在系统中的表现形式包括：

1.确认请求(例如，提交的拟议交易)被标记为格式错误；

2.冲突的响应(从接收方节点到期望响应)到达确认请求；

3.因虚假声明容量承诺耗尽(例如，资源不足)而拒绝交易。

由此可以确定：

1.如果双方在同一确认请求上发出冲突的确认，则其中一方是恶意的(或其参与者节点发生故障的方式不同于崩溃的方式)。

2.在仲裁节点的帮助下，诚实的当事方将有足够的数据来查明谁在作弊。

确认请求可能格式错误，原因是：

1.如前所述，不符合一致性和授权检查。

2.提交节点110声明的资源不正确。

接收到格式错误的确认请求的诚实参与者将其转发给仲裁节点以发起争议。然后，仲裁节点可以执行与争议发起方参与者节点相同的检查。如果检查失败(即，提交节点的拟议交易不符合规则)，则提交者的身份将被伪装，并且提交者将被永久地移到仅确认模式。否则，将争议的发起方设置为仅确认。

只有当一方拒绝(即，一个接收方节点)，而另一方(即，另一接收方节点)确认交易时，才会发生冲突响应。拒绝方必须首先向仲裁节点提供拒绝的证据：

1.如果由于授权或一致性问题而拒绝了交易，则确认请求本身将成功；或者

2.如果由于一致性检查而拒绝交易，则它应提供与当前交易相冲突的较早的最终确认交易。

争议中的失败者由于恶意行为而被永久(或在惩罚期内)移到仅确认模式。

检测并证明集中式消息服务行为异常

如果我们使用集中式消息传递代理(例如，外部节点230)，则消息传递代理的异常行为可能会导致违反所需的消息传递层属性。凭直觉，代理的任何相关异常行为都会导致参与者的状态出现分歧。当参与者交换确认和/或心跳或尝试提出争议时，就会检测到分歧，因为他们将有足够的证据表明代理的异常行为。在两种情况下，当事方可以检测到异常行为，但无法证明：(i)当代理保留参与者的所有消息时，以及(ii)当代理拒绝参与者的消息时。

其它示例方法

现在将描述其它三个示例方法。第一个是单域中方法的示例。第二和第三示例涉及多域。特别地，第二个涉及域更改协议。第三个涉及多域交易。

单域中的其它示例方法

图10至图13示出了单域1000中的交付兑付款(DvP)1001的示例。Alice 1010和Bob1012想要将银行1014给予Alice 1010的借据交换Bob 1012所拥有的一些股份。我们分为四个当事方：Alice(又名A)1010、Bob(又名B)1012、银行和股份登记处SR 1016。合同也有三种类型：

1.借据合同1031，始终以银行1014作为支持者

2.股份合同1033，始终以SR 1016作为登记处

3.Alice 1010和Bob 1012之间的DvP合同1035

假定Alice在DvP合同1035实例上具有“交换”选择，该实例将她拥有的借据1031交换为Bob拥有的股份1033。我们假定借据和股份合同实例已在DvP中分配。Alice希望提交执行此交换选择的交易；该交易具有如下图10所示的结构。

提交此示例交易涉及两个步骤：

第一步-Alice的参与者节点1010(作为提交节点)准备1040交易确认请求1041(参见图12)。请求1041提供有关交易的不同视图；参与者仅查看行使、获取或创建其当事方为其利益相关者的合同的子交易(更确切地说，这些当事方被告知的子交易)。图11a中示出了DvP及其接收方的视图(如方框右下方所示)。Alice的参与者节点1010将请求提交给定序器1018(即，外部节点1018)，该定序器对该单域1000中的所有确认请求进行排序；并且每当两个参与者查看相同的两个请求时，他们都将按照此定序器(外部节点1018)的顺序查看它们。在该示例中，定序器(外部节点1018)仅具有两个功能：对消息进行排序并将其传递给他们指定的接收方1012、1014、1016。有效载荷消息内容是加密的，并且对定序器(外部节点1018)不可见。

第二步-然后接收方节点1012、1014、1016检查其接收的视图的有效性。有效性检查1051、1053、1055、1057可以涵盖三个方面：

1.分类帐模型中定义的有效性：一致性(主要是：没有双重支出)、顺应性(视图是有效的DAML解释的结果)和授权(确保允许参与者和提交者执行视图的动作)

2.真实性(确保参与者和提交者是他们声称的人员)。

3.透明性(确保应通知的参与者得到通知)。

一致性、授权、真实性和透明性问题仅是由于提交者1010恶意而引起的。没有恶意就可能出现一致性问题。例如，要转移到Bob 1012的借据可能已经花光了(假定我们在DAML中未使用“锁定”技术)。基于检查的结果，称为确认者的接收方1014、1016子集然后分别为每个视图准备(肯定或否定)确认响应。与请求关联的确认策略会在通知交易的情况下指定哪些参与者为确认者。

确认者将他们的响应1061、1062、1063、1064发送到中介1020，中介1020是另一特殊实体，将响应汇总为整个确认请求的单个决策。中介1020用于彼此隐藏参与者的身份(以便银行1014和SR 1016不需要知道它们是同一交易的一部分)。像定序器(外部节点1018)一样，中介1020也不会了解交易内容。相反，Alice的参与者节点1010除了发送请求1041之外，还同时将每个视图的信息通知1042给中介1020。中介接收的交易版本中仅视图的通知是可见的，并且隐藏的内容1032、1034在图11b中在概念上可视化。

据此，中介1020推导出哪些(肯定的)确认响应1061、1062、1063、1064是必要的，以便确定确认请求是否被批准。

恶意参与者提交的请求1041可能包含虚假视图。由于参与者只能查看部分请求(由于隐私原因)，因此在接收到请求的批准后，每个参与者都会在本地过滤掉可见的虚假视图，并接受批准的确认请求的所有其余有效视图。在确认策略的信任假定下，协议确保诚实参与者的本地决策与他们共同查看的所有视图相匹配。因此，该协议在参与者之间提供了虚拟的共享账本，参与者的交易包括此类有效视图。一旦批准后，接受的视图即为最终视图，即永远不会从参与者的记录或虚拟账本中删除它们。

返回到图12中的示例，定序器(即，外部节点1018)和中介1020与标识(未示出但在其它地方描述)一起形成单域1000的示例。域1000内的所有消息在定序器(外部节点1018)上交换，以确保域1000中交换的所有消息之间的全序。

完全排序确保了参与者以相同的顺序查看所有确认请求1041和响应。该协议还确保了所有非拜占庭式参与者(即非恶意或未受损害的参与者)即使是拜占庭式提交者也能以相同顺序查看他们的共享视图(诸如，在银行与A参与者之间共享的借据转移)。这具有以下含义：

1.每个视图的正确确认响应始终是唯一确定的，因为在一些使用DAML模型的示例中，它是确定性的。然而，出于性能原因，当参与者开始以拜占庭方式或处于争议状态时，我们偶尔会出现不正确的否定回答。该系统为诚实的参与者提供其响应正确性或错误拒绝原因的证据。

2.全局排序在域内创建(虚拟)全局时间，该全局时间在定序器(外部节点1018)处测量；每当参与者1010、1012、1014、1016从定序器1018接收到消息时，他们就知道时间已经过去。该全局时间用于检测和解决冲突并确定何时发生超时。尽管每个参与者101、1012、1014、1016在不同的物理时间执行步骤，但从概念上讲，我们可以说与该全局时间同时在多个参与者上发生该步骤。例如，在图12的消息序列图中，Alice 1010、Bob 1012、银行1014和股份登记处1016的参与者在不同的物理时间接收到确认请求1071、1072、1073、1074，但是从概念上讲，这发生在全局时间的时间戳tsl上，并且类似地结果消息1081发生在时间戳ts6上。

图10至图13的示例示出了单域。然而，这将被修改并适于支持多域，这将在后面的示例中进行讨论。

考虑到参与者节点可能超载、离线或只是拒绝响应，系统中的一些考虑因素是在确保完整性和隐私问题的同时确保基于确认的设计的进展。解决这些考虑因素的示例方法包括：

·使用超时：如果超时后无法确定交易的有效性(这是域范围的常数)，则拒绝该交易。

·如果确认请求超时，则系统会向提交1010请求的参与者通知参与者未能发送确认响应。这使提交参与者可以对异常行为采取带外动作。

·灵活的确认策略：为了在信任、完整性和活跃性之间进行权衡，一些域可能会根据其相应的确认策略进行定制。确认策略指定哪些参与者需要确认哪些视图。这使中介1020能够确定充分的条件来声明批准的请求。特别令人感兴趣的是VIP确认策略，该策略适用于涉及受信任(VIP)当事方作为每个操作的被告的交易。VIP当事方的示例是市场运营商。假定VIP参与者的行为正确，则该策略可确保分类帐的有效性；在这种情况下，仍然可以检测到并验证不正确的行为，但是必须在系统外部处理附带后果。另一重要的策略是签署人确认策略，其中要求所有签署人和参与者进行确认。与托管签署人或参与者的参与者无响应时要牺牲活跃度的VIP确认策略相比，这需要较低级别的信任。另一策略(已弃用)是完全确认策略，其中要求所有通知都进行确认。这要求最低级别的信任，但是当一些参与的参与者没有响应时会牺牲活跃度。

·证明程序节点。可以将证明程序节点视为按需VIP参与者。代替构建DAML模型以使VIP当事方被通知每项动作，仅按需使用证明程序节点。希望进行交易的参与者必须公开足够的历史记录，以向证明人节点提供子交易有效性的明确证据。然后，证明人的陈述将替代无响应的参与者的确认。

图13示出了确认请求的状态转变图1300；除“已提交”外，所有状态均为最终状态。如其它地方所述，可以由于多种原因而拒绝确认请求，包括：请求当前域1000之外的交易(除非它是允许的多域交易的一部分，这将单独描述)、超时、与先前的请求或其它请求不一致和冲突。

域更改和可组合性

在一些示例中，系统具有可组合性，因为该系统将支持多个域以及跨不同域的交易。可组合性为同步层(而不是应用程序层)的域间交易提供了原子性保证。这可以允许在应用程序级别将多个域组成一个概念分类帐。域间交易的方法包括：

1.域更改协议。这是将合同从一个域转移到另一域的协议。通过将所有必需的合同移至单域，可以使用此类协议将多域交易减少为单域交易。即，它要求所有当事合同的所有利益相关者都必须连接到该公共域。

2.多域交易的协议。该方法涉及一些参与者节点，这些节点可以充当不同域之间的中继。该方法不需要将所有利益相关者都连接到单域。然而，在此类系统中，重要的是要有利益相关者的积极参与，这样交易才能在所有领域中原子地执行。

现在将详细讨论这两种方法。

域更改协议

域更改协议将单个合同从一个域(源)移动到另一目标。合同可能出于不同的原因而被移动：

·作为确保后续交易可以对单域的合同进行操作的准备步骤。

·平衡不同域之间的负载(由利益相关者完成)。

·利用更好的市场规则、补贴或服务质量(也由利益相关者完成)。域更改协议的示例可以包括以下一个或多个特征：

·合同仅位于一个域中，或正在转移到另一域中。合同最终必须位于合同所在的域中。合同的所有利益相关者必须直接连接(或通过中继间接连接)到所在域。

·所有利益相关者必须知道他们所有合同的位置，并且可以将此信息作为元数据保存在他们相应的合同存储中。

·当所在位置更改时，合同编号不变。

域更改分为两个步骤：在原始域上转出和在目标域上转入。域更改可以使用转移中止来中止。

目前，参与者了解域更改的发起方的身份，并且消息代理(即，外部节点)查看已转移合同的ID和目标域。更好的隐私保证将在以后的工作中进行研究。

在一些示例中，域更改协议方法可能是特别有利的，因为它不一定需要所有域之间的协作，而是仅需要与该合同和交易有关的参与者。域更改协议由发起方节点614发起。在一些示例中，发起方节点613是提交节点110或与提交节点110相关联。在其它示例中，发起方节点可以是其它节点，包括接收方节点120。

现在将参考图6和图7描述域更改的两个示例。在第一示例中，存在与利益相关者I和P驻留在域1中的合同ID cid。发起方I 614将合同转移到域2，如图6中所示。

1.发起方I 614将转出请求621发送到原始域的消息代理610(即，外部节点)。转出请求TO包含合同ID、提交者、目标域以及来自目标域的时间戳ts0。

2.源消息代理610在时间ts1处对请求TO加时间戳，并将其发送623、624给利益相关者612和发起方614。他们认为合同cid是从时间tsl开始转移的。

3.发起方614将转入请求TI 625发送到目标域的消息代理616(即，目标域的外部节点)，该请求包括带时间戳的转出请求。

4.目标消息代理616在时间ts2处对转入请求加时间戳，并将其发送627、629到利益相关者612(即，与接收方节点和/或提交节点相关联的利益相关者)和发起方614。然后，利益相关者612考虑从时间ts2开始，合同就驻留在目标域中。

转出请求621包含来自目标域的时间戳ts0，以在目标域上建立排他性超时630的基线。在排他性超时630之前，只有发起方节点614可以将转入请求或转入中止消息发送到目标域，以完成或中止域更改。该排他性超时630为发起方614提供了时间，以启动可能在不同原始域上的不同合同的多个域更改，并将其与交易一起以单个转入消息的形式提交给目标域(未在图中示出)。

如果发起方614在排他性超时630之前未能完成或中止域更改，则合同的其它利益相关者612可以这样做。这确保了发起方节点614不能无限期地保持合同转移，从而剥夺了其它利益相关者612对其进行选择的权利。

如图7中所示，第二示例具有与前面示例相同的设置，但是在步骤2之后，发起方不会在排他性超时630之前发送转入请求。相反，这些步骤包括以下步骤：

3.利益相关者P612向目标域616发送731转移中止消息。

4.目标域616在时间ts2处标记转移中止的时间戳，并将其转发给利益相关者和发起方733、735。

因此，发起方节点614和利益相关者612知道目标域上没有较早的转入消息。合同本身仍在转移中，因为原始域尚无时间戳。因此，

5.利益相关者P 612将带时间戳的转移中止作为转移中止通知转发737到原始域消息代理610。

6.原始消息代理610在时间ts1’对该通知加时间戳，并将其转发739、741到利益相关者612和发起方节点614。他们认为合同从ts1’起再次驻留在原始域中。

7.当接收到735来自域2的转移中止消息时，发起方节点614检查目标域时间戳是否在排他性超时630之后，以确保利益相关者P 612没有削减其排他性时间段。

利益相关者P可以通过发送转入消息来完成域更改，而不是中止域更改。然后，该协议将像在第一示例中那样继续进行，除了发起方节点614检查排他性超时630之后是否已对利益相关者P的转入消息加了时间戳。相反，在第一示例中，发起方614可能中止了域转移，而不是通过发送转移中止消息来进行域转移。

以上是域更改协议的示例，并且应当理解，协议的其它类型和变体可以实现该结果。现在将描述图6和图7中大体描述的协议的一个示例的另外细节。

并非所有人都可以将合同转移到另一域。每个利益相关者(可以是与提交节点、接收方节点或其它当事节点相关联的利益相关者)始终可以转移其合同；唯一的限制是所有利益相关者必须事先发出信号，表示他们接受(或同意)新域。在此基本设计中，我们假定每个参与者在开始时就声明同意了哪个域，并且每个参与者都知道这些声明。

为了发起域更改，发起方614向合同的所在域发送621转出请求621(诸如，经由消息代理域1610)。这样的请求包含要转移的合同ID、发起方的身份以及可能的代理发起方节点、目标域、目标域的最新时间戳(例如，来自代理的心跳)以及获得更改域权利的理由。时间戳设置时间窗口的基线，在该时间窗口期间，发起方614拥有中止域更改或在目标域上提交转入消息的专有权。(当发起方614未连接到合同的原始域时，则他必须要求利益相关者612代表他发起域转移。在那种情况下，实际的发起方将成为代理发起方，并成为发起方的利益相关者。)转出请求被发送给消息传递层上的所有合同利益相关者612。转出请求的示例包括：

data TransferOutRequest＝TransferOutRequest

{contractID：：ContractID

，initiator：：Party

，proxiedInitiator：：Maybe Party

，targetDomainID：：SiriusD0mainID

，targetTimestamp：：Signature SiriusDomainID Timestamp

，justification：：(ProvenanceProof，Randomness)}

原始消息中介610对请求加时间戳，将提交确认发送623到发起方614，并将转出请求连同时间戳一起转发624到所有利益相关者612。原始域的津贴核算组件减去发起方帐户的域更改津贴。

利益相关者P 612对转出请求执行以下项中的一个或多个或全部检查：

i.利益相关者列表612已完成。

ii.提交者是请求中指定的发起方614。

iii.目标域对所有利益相关者都是可以接受的。

iv.目标时间戳已由目标域签名。

v.理由是有效的。

vi.合同驻留在原始域。

vii.没有竞争性的域更改或具有较小物理时间戳的交易，并且目标域上没有针对相同转出请求的转移中止消息。

如果检查(i)至(v)失败，则转出请求的格式错误，并且参与者612报告恶意行为(转移协议的带外)。如果检查(vi)失败，则利益相关者612拒绝转出请求624。该拒绝包括合同的当前所在域。如果由于竞争域的更改而当前正在转移合同，则拒绝会这样表述。当发起方614不是利益相关者612时，检查(vi)也可能在没有竞争的情况下失败，因为随后没有将域更改通知给发起方614。在这种情况下，拒绝将新的所在位置通知给发起方612。如果检查(vii)失败，则利益相关者612拒绝转出请求624。如果所有检查都通过，则合同从转出请求的原始时间戳开始变为进行转移。转移合同(临时地)不驻留在任何域上，并且不能对它们执行任何选择。

利益相关者612在域规则所定义的转移确认超时中，经由原始域的消息代理610将转移请求确认到发起方614。所有检查仅依赖于所有利益相关者612都同意的数据。因此，利益相关者612必须全部得出相同的结果。因此，无需在其中发送确认信息。

转入步骤在目标域上注册合同。具有带有原始消息代理时间戳和签名的转出请求的利益相关者612和(代理)发起方614可以通过向目标消息代理616提交转入消息625来这样做。在转出621和排他性超时630之间的时间段，发起方614独有该权利。单个转入消息625可以同时注册多个合同，即使来自不同的原始域，也可以视情况包括DAML交易(形式为请求有效载荷；必须提前发送资源请求消息)。转移请求的示例包括：

data TransferInMessage＝TransferInMessage

{inContracts：：[TransferInRequest]

，submitter：：Party

，transaction：：Maybe RequestPayload}

data TransferInRequest＝TransferInRequest

{out：：TransferOutRequest

，originTimestamp：：Timestamp

，originSignature：：Signature}

当目标消息代理616接收到转入消息625时，所有转入请求在目标域中获得相同的时间戳，并且作为转入确认请求被发送629到相应利益相关者612。如果转入消息中包含交易，则它将获得下一个时间戳。

当参与者612接收到629转移确认请求时，它等到接收到624并处理了来自原始域610的相应转出请求为止。(通常，转出请求624在转入消息629之前到达，但是如果网络延迟有所变化，则不必是这种情况。)然后，它执行以下检查：

(i)已经确认了在原始域上的转出请求，如转出步骤中所述。

(ii)尚未查看该转出请求的转入确认请求或带有较早时间戳的转移中止通知。

(iii)转出请求指定了正确的目标域。

(iv)如果转入消息的提交者不是转出请求的发起方，则在转出请求中的目标时间戳与转入确认请求中的目标代理的时间戳之间至少已经有排他性超时630。

(v)如果发起方614不是所转移合同的利益相关者，则参与者记得检查来自消息代理的下一个时间戳将在对所转移合同进行选择的交易上。

如果这些检查中的任何一个失败，则参与者612报告争议解决部分所述的异常行为。否则，它认为合同从转入确认请求中目标消息代理的时间戳所指示的时间点开始驻留在目标域上。如此，合同就停止了转移(即，它驻留在目标域中)。它经由目标消息代理616向发起方614和代理发起方发送确认。否则，向发起方和所有利益相关者发送拒绝。

如果(被代理的)发起方节点不是合同的利益相关者，则参与者612检查带有下一个时间戳的来自目标消息代理616的消息包含对已转移合同进行选择的交易并且出处证明包含参与者和选择。如果不是这种情况，则会报告行为异常。

将多个转出请求捆绑到单个转入消息中并不能确保所有转移的原子性。一些可能成功，而一些可能失败。捆绑仅确保所有后续转移都具有相同的时间戳。如此，交易所需的一捆合同可以同时占用其所在位置。如果要在单个转入中完成，则存在这样的危险，即较早的合同会在所有合同都驻留在同一域之前被转出。如果域更改中的一个失败，则该交易也将失败，除非它不对未转移的合同进行选择，因为合同的利益相关者将由于合同不在该交易的域上而拒绝交易。在(最早)排他性超时之前，发起方知道所有域更改是否都会成功，但前提是他接收到了他不是利益相关者的每份合同的转出确认。

每个域都为域更改指定了排他性超时630，如图7中所示。在排他性超时630期间，仅允许域更改的发起方614发送转入或转移中止消息。超时630基线由目标域时间戳确定，发起方614在转出请求621中使用该目标域时间戳。因此，发起方614有动机使用最近的时间戳，因为这延长了其推进域更改的专有权。

在排他性时间窗口期间，发起方614可以收集转出请求确认623，并将多个转出捆绑到单个转入中625。因此发起方614可以确保交易所需的所有合同被移到相同的域，或者如果一些失败则决定中止域更改。通过将交易包括在转入请求625中，任何竞争性转出都无法将一些合同移除。用于交易的资源请求消息应在排他性时间窗口期间(即在排他性超时630之前)发送。因此，排他性期应足够长，以使发起方614在提交转入消息625之前也可以等待容量拒绝超时。

在排他性超时630之后，其它利益相关者可以发起域更改的中止，以防止发起方无限期地保持合同的转移并释放资源。

多域交易协议

多域交易跨多个域的合同，并且不需要显式合同域更改。本节描述具有以下属性和假定的多域交易协议：

·提交者必须连接到交易中使用或创建的合同所在的所有域。

·如果参与者是子交易的利益相关者，并且其输入合同驻留在一个域中，并且其本身具有在另一域中发生的子交易，则该参与者称为中继。

·多域交易的提交者始终是中继。所有中继必须连接到所有域。

·所有其它利益相关者仅需要连接到其合同所在的域。特别地，不需要所有参与方都连接到一个域。

·连接到多个域的参与者可能已在不同域的身份管理器中注册了不同的密钥。

·除非所有中继或消息代理中的一个未及时采取行动，或者所有中继与消息代理中的一个之间发生连接问题，否则多域交易将在所有域中自动执行。

·在所有域中使用相同的分类帐有效时间。

·不同域之间的时钟差异与时钟漂移之间存在已知界限。

·多域交易与确认请求规则悲观拒绝和有条件判决一起工作。

·所有涉及的域必须遵循相同的最终模型(完全确认或乐观VIP确认)。

·单域交易可以预先运行多域交易。

·每个合同都驻留在单域中，所有利益相关者都连接到该域，并且合同的所有利益相关者始终知道其驻留位置。

提交者(与提交节点110相关联)知道它是利益相关者的交易的所有输入合同的所在域。就像在域更改协议中一样，对于提交者不是利益相关者的输入合同，提交者知道过去某个时间的所在位置。对于在交易中创建的合同，提交者还知道要在何处创建这些合同。这可以在交易本身中指定(例如，在DAML交易或DAML扩展中)，也可以由提交者自行决定。交易中涉及的域是该交易的输入合同所在的域或该交易创建合同的所有域。

参考图8，对于每个域803、805，将多域交易分成一个部分。每个部分的执行就像部分单域交易一样，其中在确认请求中缺少一些视图有效载荷，即那些其它域上的当事合同。然而，必须将所有视图的所有确认发送到所有域。为此，中继将确认从一个域转发到另一域。

图8示出了简单的两个域交易的消息流，该交易在两个合同cid1和cid2上进行选择。下表给出了域分配：

域	连接的参与者	驻留的合同
			D1	S，P1	利益相关者S，P1的cid1
D2	S，P2	利益相关者S，P2的cid2

因此，交易涉及三个参与者：提交节点815、参与者1 811和参与者2 819以及两个域D1和D2(以及充当外部节点的域1(D1、803)和域2(D2、805)的相应消息代理813、817)。没有涉及交易的所有参与者都连接到的域，但是提交者(提交节点)815连接到所有域，因此充当中继。提交者815将整个交易的确认请求分成两个部分的单域交易，每个视图一个。然后，它同时将每个部分发送到适当的消息代理813、817(即，相应域D1和D2的两个外部节点)。每个部分都包含两个消息：资源请求831、835和请求有效载荷833、837，其中提交者815必须确保在没有参与者拒绝任何域803、805上的资源请求831、835之后，才确保发送有效载荷833、837(例如，通过等到所有容量拒绝超时都过去)。除以下例外情况外，每个部分单域交易都像在单域情况下一样进行处理：

1.期望确认851、852还包括其它域上的匿名参与者。然后，中继(在该示例中为提交者节点815)负责将确认信息经由另一域的消息代理813、817转发给期望的接收方811、819。

2.确定参与者811、819必须将其确认响应851、852发送到本地消息代理817、813的时间的确认期限845、846早于决策时间847、848(即使相对于消息代理的时钟)达确认期限偏移，提交者815选择的确认期限偏移受到一些限制条件。来自远程域的确认851、852必须在决策时间848、847之前已到达域的消息代理(外部节点)813、817。确认期限与决策时间之间的偏移使中继有时间从一个域收集确认并转发到另一域，并在域803、805之间隐藏时钟偏斜和变化的确认响应超时。

图9示出了如何确定各种期限并一起工作。提交者(提交节点)815选择：

·用于评估的分类帐有效时间(LET)909。

·逻辑时间偏移911、913。

·确认期限偏移915、917。

整个多域交易中的LET必须相同。可以为每个域803、805分别选择偏移911、913、915、917。

当部分交易发送831、835到各个域时，每个交易都接收物理时间戳，该物理时间戳确定特定域上的所有时间点，如下所示：

·逻辑时间＝物理时间+逻辑时间偏移911、913。

·决策时间847、848＝逻辑时间+确认响应超时915、917。

·确认期限845、846＝决策时间848、847-确认期限偏移915、917。

每个时间点都与其域803、805相关联。因此，这些时间点的绝对时间在各个域之间都不同。在图9中，提交者815已经为域1、803选择了更长的逻辑时间偏移911(例如，因为它期望资源请求传输在域2、805上要花费更长的时间)，而在域1、803上的逻辑时间921相对于挂钟时间确实是在域2805上的逻辑时间923之后。

提交者815应基于其对域的网络延迟的经验来选择逻辑时间偏移911、913，以使所有域最终都具有相似的逻辑时间。这是因为在所有域上相同的分类帐有效时间909必须接近每个域的逻辑时间921、923，这由域规则的容差925、927确定。

提交者(提交节点)815应该选择确认期限偏移915、917，使得每个中继在源域的确认期限845、846与转发目标域的决策时间847、848(对于源域和目标域的所有组合)之间的时间内有足够的时间转发853、854确认响应。然而，偏移915、917必须足够小，以使每个域中的每个参与者都有足够的时间检查951在从域中观察到逻辑时间戳时与必须发出确认响应时之间是否存在冲突，使得确认响应可以在确认期限845、846之前到达代理813、817。

由于提交者815选择这些时间，所以它可能比其它中继具有优势。为了防止这种情况，提交者815必须选择确认容限953，其限制确认期限845、846可以在任意两个域上分开多远。容限越大，确认期限偏移915、917就越长。

多域交易的用例示例：全局抵押

现在将在用于多域交易的全局抵押的背景下描述多域交易的示例。在通用原子交换中捕获了全局抵押的关键同步和隐私要求。

在全局抵押用例中，A和B两个当事方要原子交换A和B分别拥有的两份资产X和Y。为简单起见，假定每个当事方都运行自己的参与者节点。资产X的所有权由交易所的资产登记处R1记录在一个交易所EX₁上。资产Y的所有权由另一交易所的资产登记处R₂记录在另一交易所EX₂上。每个交易所EX_i都运行自己的域D_i，而交易所的资产登记处仅连接到对应的交易所域，即Ri仅连接到Di。当事方A和B都连接到两个域。

在DvD(交付与交付)合同中捕获原子交换，其中两个合同中的一个(即A)可以进行选择来执行交换。该选择带有两个子交易：其中分别是A将X转移到B；并且B将Y转移到A。该合同可以驻留在另一域D₃上，因为A和B都是利益相关者，所以两者都必须连接到该域。

该交易满足多域交易的要求：资产登记处R₁和R₂不是中继，因为它们各自在其交易所域上仅查看单次转移，因此不必连接到其它域。实际上，他们不在乎交易是否在所有域中原子执行。相反，A和B是中继，并且它们都连接到所有三个域。原子性对两者都至关重要。因为如果A的X到B的转移成功，但B的Y到A的转移失败，则A便没有资产。

B的情况是对称的。因此，他们两个都对及时在域之间中继消息很关注。

无法使用“域更改协议”(如上所述)执行该交易，因为没有所有利益相关者都连接到的域。

本节的其余部分描述了多域交易的详细信息以及它们与单域交易的区别。

交易提交

在以下方面，提交与单域交易不同的多域交易：

视图形成将合同所在位置考虑在内。当交易树的遍历访问顶级交易的子交易时，在以下情况下会创建新框：

·子交易的合同(输入或创建)驻留在与父节点的输入合同不同的域上，或者

·利益相关者设置不同的对象(例如在单域情况下)。每个框带有与其关联的域的注释。

参考图8，提交者为交易中涉及的每个域准备确认请求，该确认请求由资源请求831、835和有效载荷消息833、837组成。对于域D的每个资源请求和有效载荷消息都是像在单域情况下那样进行准备，进行了以下修改：

·资源请求中的资源和津贴字段仅汇总经由D发送的视图的资源要求和津贴。另外，每个中继都被分配了在所有域上绑定的资源，用于中继确认响应。

·带宽是指经由D发送的有效载荷的大小。

·有效载荷数据仅包含经由D发送的视图的动作描述。

·列表“allStakeholders”仅包含经由D发送的框的利益相关者的匿名。如果一些中继P(包括提交者)不在其中但仍连接到D，则提交者将为P、创建匿名，并将其添加到“allStakeholders”

·期望确认列表包含所有域所需的确认。对于每个确认，即使确认是通过将向其发送有效载荷消息的域所发送的，都将设置域ID。

·如下所述，在资源请求中设置了“multiDomain”字段。该字段特别定义了确认期限偏移和容限，下面对此进行了说明。

data MultiDomainData＝MultiDomainData

{confirmationDeadlineOffset：：TimeDistance

，confirmationTolerance：：TimeDistance

}

·logTimeOffset会因确认期限偏移而增加

·使用其它域上的资源ID列表设置请求有效载荷元数据中的“MultiDomain”字段。

data MultiDomainPayloadData＝MultiDomainPayloadData

{remoteRequestIds：：[(DomainID，RequestID)]

}

资源请求中的多域交易元数据包含以下信息：

·提交者为每个域选择确认期限的偏移。指定域的参与者必须在以下情况之前发送确认信

logical time+crt＝confirmationDeadLineOffset

而不是

logical time+crt

其中crt是单域情况下的确认响应超时。确认期限偏移必须满足以下约束条件：

ConfirmationDeadLineOffset＜crt-2*Δ

其中Δ是与域的消息代理进行通信的期望网络延迟。此外，必须满足

2*Δmax+confirmationTolerance+skew≤confirmationDeadLineOffset

其中Δmax是从任何参与的参与者到其连接到的任何参与域的最大期望网络延迟，并且偏斜是任意两个域之间时钟偏斜的上限。

·确认期限偏移为提交者(和其它参与者)提供了时间来充当将确认从一个域转发到另一域的中继。上限确保所有参与者观察到逻辑时间后都有足够的时间发送确认响应。下限使中继有时间在域之间转发确认响应。

·确认容限指定了不同域上的确认期限可能相距多远。提交者可以更好地预测不同域上的物理时间戳，实际的确认期限越近，选择的容限就越低。

代替有效载荷请求，提交者815可以中止交易。如果发生以下情况，则需要中止：

·资源请求在其中一个域上被拒绝。因此，必须拒绝整个交易。

·物理时间戳偏离太远，以致超出了确认容限。

当消息代理接收到资源请求或请求有效载荷时，它像处理单域交易一样处理它们。特别地，提交者必须支付每个域的提交津贴。

处理确认请求

确认请求831、833、835、837的处理方式类似于单域交易，但以下方面除外。

·参与者检查“RemoteRequestIDs”字段中是否包含重复的域ID，并且对于期望确认中提到的每个域仅包含一个条目。每个参与者都从有效载荷请求中给出的请求ID和远程请求ID中推导出新的请求标识符。推导必须独立于远程请求ID的顺序。新的请求标识符用于确认响应。

·交易的确认期限由以下确定

phys_ts+logTimeOffset+crt-confimationDeadlineOffset

·容量监测器使用修改后的确认期限来确定交易是否符合容量承诺。

·参与者检查

2*Δmax+confirmationTolerance+skew≤confirmationDeadlineOffset＜crt-2*Δ-skew

对于请求有效载荷833、837，参与者还检查以下内容：

·资源请求831、835和请求有效载荷833、837已经由相同的域803、805发送。为执行任务，输入合同驻留在发送确认请求的域上。对于创建而言，请求有效载荷的域能够由所有利益相关者接受。

·对于每个动作，参与者在发送确认响应时会检查是否已接收到所有作为利益相关者的子交易的框。

·如果视图的子动作作用于不同的域，则参与者将自己视为中继。

·如果视图的子操作作用于不同的域，则参与者在发送其确认之前会检查以下所有内容：

-在视图的确认期限之前，“remoteRequestiDs”中所有远程请求ID的物理时间戳至少为

confirmationTolerance+Δmax+skew。

-它已接收到“remoteRequestIDs”中列出的所有域上的资源请求。

-所有这些请求的每对确认期限最多都只有“confirmationTolerance”。

·为发送给参与者的动作框的期望确认设置正确的域ID。

·当交叉检查元数据和动作框时，参与者检查同一域上的所有子操作。如果参与者是中继，则它还会通过经由对应域发送的“allStakeholders”列表来对其它域上的所有子动作执行该交叉检查。(在任何情况下，都将检查所有子动作的期望确认者列表。)

参与者将确认响应发送给“allStakeholders”列表中的匿名。它检查他们是否接收到了所有域的期望确认。生成确认响应时的多域数据md包含确认容限。

data MultiDomainConfirmationData＝MultiDomainConfirmationData

{confirmationTolerance：：TimeDistance

}

在竞争交易的情况下，即使有条件判决用于单域交易，也总是根据悲观拒绝规则处理多域交易。

因此，如果多域交易的逻辑时间戳介于逻辑时间与另一(单域或多域)交易的确认期限之间，则多域交易将被完全拒绝。这使多域交易成为第二等公民，尤其是因为多域交易通常具有更长的逻辑时间。

处理确认响应

确认者(诸如，作为接收节点操作的参与者的节点811、819)对确认响应的处理与单域交易相同，除了每个参与者都另外检查该确认中的多域数据是否包含已在资源请求831、835中接收到的相同确认容限。如果所有期望确认都已经由该域到达，则参与者认为交易将在给定域803、805上最终批准。特别地，如果参与者在不同的域中使用不同的匿名，则其必须在最终批准方面采取行动，就好像它是两个单独的实体一样。因此，参与者可以考虑在一个域(例如803)上最终批准的交易，而在另一域(例如805)上仍在等待批准。特别地，参与者可以基于一个域的最终批准来进行后续确认，而不能在其它域中进行最终确认。然而，单域交易的语义确保合同的所有利益相关者都同意其状态，因为合同只能驻留在一个域中。此外，在最后的决策时间过去之后，关于财务状况的不同状态将趋于一致，除非发生超时、争议和崩溃。

如果参与者节点将自身视为已接收到的任何视图的中继，则将其视为中继。当中继从一个域接收到确认响应时，它会执行与单域情况相同的检查。此外，它还执行以下操作：

·它从所有域收集确认响应。

·当来自一个域的足够多的确认响应到达时(由期望确认列表确定)，中继将所有确认发送给其它域中的所有参与者。即使匿名参与者是合同的利益相关者，中继在其它域中也不能省略匿名参与者，因为连接到多个域的每个参与者的行为就像是每个域中的单独实体一样。

由于提交者为所有域上的所有中继创建了匿名，因此所有中继都接收所有确认响应，因此可以转发它们。中继也可以立即转发确认响应，而不是先收集它们然后分单批发送。为了避免不必要的通信，中继应仅将确认响应转发到尚未接收到确认响应的域。当所有转发相互竞争时，相同的确认响应可能会在带有不同时间戳的域中多次发送。每个人都可以忽略带有稍后时间戳的确认响应转发。

跨域原子性

在一些示例中，确认响应851、852必须由本地确认期限845、846发送。来自其它域的响应仅需要在决策时间847、848之前到达。这两个时间戳表示两阶段提交协议中两个阶段的结尾：所有参与者必须在确认期限之前将准备提交给提交者，并且他们可以在决策时间847、848之前期望提交或中止。

经典的两阶段提交协议不能将硬超时与原子性结合起来。因此，如果在域专用决策时间847、848之前未将一些确认响应转发到所有域803、805，则多域交易可能会非原子地执行。在介绍性示例中，提交者815延迟参与者1的811的转发854和提交者对域805的PL1的确认，直到在域805上的决策时间847之后。然后，参与者1811和提交者815认为在域D1上的交易被批准。相反，参与者2819认为域D2上的确认PL1854已超时，因此可以对提交者提出争议。取决于第二域805争议规则，交易可能会在域805上被拒绝。因此，该交易尚未原子性地执行。然而，在这样的示例中，我们认为只有提交者815关心原子性，并且违反原子性是提交者的过错。因此，没有人可以抱怨没有原子性地执行交易。

通常，只有某些方面关心交易(部分)的原子性，而不关心整个系统。更正式地说，令tx＝[a₁，a₂，…，a_n]表示受关注的交易。每个动作a_i本身会创建合同或对合同c_i上的ch_i进行选择。每个运用a_i本身都包含其它动作a_i，j的子交易tx_i和其它子交易tx_i，j，依此类推。运用a_i的授权者可能会关心子交易tx_i是原子执行的，因为在创建运用的输入合同时已向他们承诺了原子性。同样，a_i，j的授权者也关心tx_i，j的原子性。由于t_xi，j是tx_i的子交易，因此a_i的授权者也(间接地)关心tx_i，j是原子性地执行的。对于顶级交易tx，提交者关心其原子性。总之，对于(子)交易tx…，从根到子交易的路径上的提交者815和所有授权者811、819关心它的原子性。任何其它当事方都不必关心tx…是否原子性地执行。特别地，如果一方是子交易tx_i1的利益相关者，但不是子交易tx_i2的利益相关者，那么它就不关心tx_i2是否原子性地执行，因为由于DAML的隐私模型，它甚至不知道tx_i2。只有提交者才关心原子性地执行的所有顶级操作。

另外，如果一方是a_i，j和a_i，k的授权者，且

但不是a_i的授权者，则它不必关心两个子动作是否原子性地执行。特别地，这类当事方的参与者不必是中继。

鉴于这种原子性的概念，每个参与者都可以确保自己关心的子交易的原子性，如以下论点所示。

·如果在某个域(例如，第一域D₁)上批准了tx的一个子交易tx₁，而在另一域(例如，第二域D₂)上拒绝了tx的另一子交易tx₂，则参与者认为违反了多域(子)交易tx的原子性。

·无需考虑D₁＝D₂或tx₁＝tx₂，即，在单域或单个子交易上发生冲突，因为单域子协议确保一个域内的完整性和原子性。特别地，我们可以忽略不是中继的参与者。

·因此，

并因此是

仅当整个交易tx的所有期望确认都到达域D₁而不是D₂时，才会发生原子性违规。结果表明，参与者可以通过及时转发确认响应来避免这种情况。

·令tx_i为其确认响应已到达D₁而不是D₂的任何子交易。令D_i表示发送tx_i的域。由于中继连接到交易中涉及的所有域，因此中继尤其连接到D_i。由于它已经由D_i接收到资源请求和有效载荷请求，因此它是经由D_i发送的“allStakeholders”列表的一部分。由于tx_i的确认已到达D₁，因此它们必须在确认期限之前通过域D_i发送。假定消息代理正确实现了消息传递API，则中继已及时接收到了这些确认。它将这些响应转发到所有域，尤其是D₂。因此，响应将到达域D₂。

·仍然表明中继可以及时转发确认响应。中继会在以下时间之前从域Di接收它们(由D₂的消息代理测量)

confirmationDeadlinei+Δmax+skew

因此，如果参与者立即转发它们，它们将在以下之前到达D₂的消息代理

confirmationDeadline_i+2*Δmax+skew

中继在处理确认响应时进行了检查

confirmationDeadline_i≤confirmationDeadline₂+confirmationTolerance

2*Δmax+confirmationTolerance+skew≤confirmationDeadlineOffset₂

由于decisionTime₂＝con fi rmationDeadline₂+con firmationDeadlineOffset₂，我们具有所需的关系

confirmationDeadline_i+2*Δmax+skew≤decisionTime₂

多域交易中的超时

提交者815选择在各个域803、805上选择超时的参数。因此，它负责在域之间转发853、854确认响应，因为它应选择以下参数使得它将能够在提交者节点815为其自身设置的超时时间内实际实现转发。交易的所有其它参与者811、819仅检查提交者815是否已经选择了时序参数，使得他们很可能能够及时完成其各自的任务并增强他们对交易的兴趣。

然而，可能会发生超时。参与者811、819仅在他们接收到确认有效载荷833、837时才知道交易的多域性质，因为这是在发送期望确认列表和请求ID列表时。因此，本节仅关注确认响应851、852的超时，而忽略请求有效载荷的超时。

如果参与者811、819在确认期限845、846上发现参与者缺少对同一域的确认，则参与者811、819可以在适当域上提出争议，就像单域交易一样。如果参与者注意到另一域缺少确认响应，则参与者811、819可以对本地域803、805上的提交者815提出争议。这使提交者815成为跨域803、805转发853、854确认的主要负责节点。相反，所有其它中继都可能出于自己的关注而这样做，但并非必须这样做。即使不是提交者的过错，例如由于另一域上的参与者未及时发送其确认，争议也将针对提交者815。

然后，提交者815本身可以在另一域上提出争议。即使提交者在后一个争议中胜诉而在前一个争议中败诉，也冒着两个争议的影响没有抵消的风险。

如果发生超时，则交易可能不会原子性地执行。如上一节所述，每个参与者811、819都能确保其关注的原子度。然而，参与者811、819可能涉及多域交易的多个域803、805，但对其原子性不关注(例如，因为其所有视图都在单域上执行，因此不是中继)。在这种情况下，参与者811、819可以观察到交易不是原子的。

取决于争议规则，参与者811、819可能不得不考虑交易成功与失败。更准确地说，交易的每一个效果(合同的创建或归档)都与所在域相关。交易一经在所在域获得批准，便立即生效，而与其它域的结果无关。

然而，超时不会为双重支付创造机会：由于每个合同仅位于单域803、805，因此双重支付所涉及的两个交易必须在同一域上执行。由于所有利益相关者总是就合同的状态达成一致，因此所有利益相关者都将不得不谎称第二笔交易未支付该合同。

检测多域交易中的异常行为

与单域交易一样，参与者可能在多域交易中行为异常。本节识别了多域交易专有的异常行为。防止单域交易可能发生的异常行为的措施保持不变。

i.信息不一致

由于资源请求831、835和请求有效载荷833、837消息在域803、805之间拆分，因此消息传递API无法再确保所有参与者都接收到相同的消息部分。详细地，提交者815可以将不一致的信息发送到不同的域803、805。参与者的节点811、819可以检测以下不一致并且在其域上引发适当的争议。争议规则仍需要扩展以涵盖所有这些情况。

·LET：每个参与者在其确认响应中都包含有效载荷请求中的LET。当参与者处理确认响应时，它会检查LET是否与其所查看的LET相同。如果提交者发送LET以获取不同的视图，则至少所有中继都将注意到该差异。(如果没有一个中继进行检查，那么没有一个诚实的参与者会关心原子性，即不关心LET一致性。)

·远程请求ID：所有参与者都从所有请求ID中获取交易标识符，他们在确认响应中使用这些交易标识符。如果参与者接收到不同的请求ID列表，则推导的交易标识符将不同。因此，其它参与者不会批准这些确认，也不会针对参与者(相同域)或提交者(其它域)提出争议(由于格式错误或缺少确认)。仅当消息代理未实现指定的消息传递API时，才会发生相同域的情况。

·期望确认：每个确认响应都包含期望确认的哈希。期望确认的不同列表具有不同的哈希，因此将引起有关格式错误的确认响应的争议。

·确认容限：确认容限包括在确认响应中，并且参与者检查确认值是否与他们接收到的资源请求中的相同。因此，不同的确认容限将引起有关格式错误的确认响应的争议。

ii.形式错误的参数

在多域交易中，除了单域交易的参数外，提交者还指定了以下参数：

·时间参数“confirmationDeadlineOffset”(每个视图)和“confirmationTolerance”

·期望验证的域ID

·远程请求ID

为每个域选择“confirmationDeadlineOffset”，而为整个交易选择其它参数。这些参数受到每个参与者在处理确认请求时检查的约束条件。如果违反了约束条件，则由于域中格式错误的消息，参与者会对提交者提出争议，经由该域发送格式错误的消息。

大多数检查仅涉及参与者的本地知识，因此可以肯定地执行。唯一的例外是中继对具有不同域的子视图的视图执行的检查。如果中继在确认期限之前未从其它域接收到它需要进行检查的消息，则中继将发送拒绝消息。然而，检查物理时间戳是否在所有确认期限之前至少有skew+“confirmationTolerance”+Δmax，可以确保在正常网络操作下，中继将在确认期限之前接收到所有必要的消息。如果不是如此，则中继可以针对提交者提出有关缺失请求有效载荷的争议。该检查还确保所有诚实的中继都得出相同的判决，而与网络延迟无关。(如果资源请求花费的时间超过从消息代理传递到中继的skew+“confirmationTolerance”+Δmax时间，则中继应向消息代理或其ISP提出SLA争议。)

合同的每个利益相关者还检查是否经由正确的域发送了视图。对于运用，可能会发生输入合同不在域上的情况。这可能在正常操作下发生，即没有恶意。如果该检查失败，则不会引起任何争议。相反，利益相关者发送拒绝，其中包括合同的当前所在位置，就像在域更改协议中一样。

与域更改的相互作用

原子性给多域交易的中继带来了负担，因为它们必须积极确保及时转发确认。因此，参与者811、819可能希望避免在任何多域交易中充当中继。然而，除非参与者仅连接到单域，否则它不能确保这一点。

身份管理器和多个域

可以提供一个或多个身份管理器节点170、270，并且在一些示例中，不同的域具有相应的身份管理器170、270。身份管理器节点(通常是身份管理系统)可以具有与同步系统相同的信任和拓扑。可以配置系统，使得可以由任何节点创建域，并且任何参与者节点都可以连接到任何域，只要参与者从域运营商获得授权即可。即，系统没有或不需要单个全局身份管理器。

参与者节点110、120、210、220、811、815、819、外部节点130、230、813、817和/或中介280中的每一个都可以具有称为身份提供服务客户端(IPS客户端)的本地组件。IPS客户端与域的身份管理器170、270建立连接，以读取并验证域(和/或参与者)的身份信息。IPS客户端公开读取的API，该读取的API提供对由一个或多个域的身份管理器170、270提供的域拓扑信息和公钥的聚合访问。

身份管理器170、270在将信息呈现给参与者节点或其它域实体的IPS客户端之前，通过某些过程接收密钥和证书并评估理由。IPS客户端验证信息。IPS客户端读取API的本地使用者在不验证理由的情况下信任提供的信息，从而导致同步和身份管理分离。

身份管理器170、270和IPS客户端可以设计为具有以下项中的一个或多个考虑因素：

·当事方对参与者的映射。在特定时间查询状态，并订阅更新流，该更新流将一方的已知标识符与一组参与者相关联，以及将本地参与者与一组托管方相关联。映射到一组参与者可以满足使用多个参与者的各方的高级要求。

·参与者资格。在特定时间查询状态并订阅更新流，该更新流向我通知参与者的信任级别，指示不信任(信任级别0)或受信任(信任级别1)。

·参与者关系资格。参与者关系的一方有资格且仅限于提交(包括确认)、确认和观察(只读)。这也满足了只读参与者的高级要求。

·参与者到密钥的域感知映射。在特定时间查询状态，并订阅将参与者映射到每个同步域的一组密钥的更新流。

·域实体密钥。查询当前状态，并订阅域实体密钥上的更新流。

·密钥的寿命和目的。了解接收到的任何密钥，以了解它的用途，它所指的是什么加密协议以及何时到期。

·签名检查。给定Blob、从IPS获得的密钥和签名，请验证该签名是否是给定blob的有效签名，并在特定时间使用相应的密钥进行签名。

·不变性。在与审核日志相同的时间范围内保留的所有密钥的历史记录，以便可以用来审核参与者或域实体日志。

·证据。对于从身份管理器接收到的任何数据，请获取该组相关证据来证明法律争议中的论点。相关证据包含可用于在文档中阅读有关不透明blob的定义的描述符。

·竞争条件自由。确认关于交易的密钥有效性的确定性，以使不会因飞行中的密钥更改而对交易的有效性产生分歧。

·查询当事方。使用不透明的查询语句查询当事方的身份管理器，并且将基于特定参与者节点/IPS客户端未知的隐私策略接收结果。

·当事方元数据。访问与当事方关联的元数据以进行显示。

·等效信任假定。参考身份管理服务的联合协议需要基于等效信任假定(例如互操作性协议)，以使两者的功能之间不存在不匹配的情况。

身份管理器系统可以通过以下进一步的考虑因素来构造。同步协议与身份协议分离。然而，为了利用同步协议的可组合性属性，对于身份需要等效的方法。因此，鉴于在一些情况下不存在可以依靠其进行同步的单个全局信任的实体，类似地，在一些情况下，也不可能有单个全局信任的实体来建立身份，这导致我们遵循第一原则：

为了使全局同步在现实中起作用，不能有单个信任锚。

可以通过公钥的指纹唯一地识别加密密钥对。通过拥有关联的私钥，实体始终可以通过签名明确证明该实体是公钥的所有者。该原则在系统中用于验证和授权参与者的活动。因此，我们可以引入第二原则：

参与者是指可以授权并且可以验证其授权的人(具有已知密钥的人)

即，参与者是具有密钥或一组已知属于一起的密钥的实体/节点。然而，这不一定等同于知晓谁拥有密钥。所有权是现实世界的抽象方面，与同步本身无关。现实世界的所有权仅与某些共享数据含义的解释有关，而与数据处理本身无关。这导致了第三原则：

系统身份和法律身份的单独认证(或密码身份和元数据的分离)

通过使密钥带有证书，以证明某些所有权或某些事实与另一密钥相关联，可以使用加密密钥来建立信任链。然而，这类链的根始终是根密钥。根密钥本身未经认证，并且无法验证合法所有权：参与者只需要相信便可。例如，如果实体查看实体设备上的本地证书存储，则他们需要信任某个根由命名证书颁发机构拥有。这种信任根植于操作系统提供者对他们仅包含合法密钥的信任。

如此，通过证书的法律身份与加密密钥之间的任何链接都基于如下信念，即控制根密钥的实体是诚实的，并确保已对附着于信任根的每个人都进行了适当的审查。因此，实体可能需要相信合法身份已正确关联，但是从绝对意义上进行验证非常困难，尤其是无法在线进行。

另一相关方面是身份要求是非对称性质。大型公司希望以自己的名字(BANK)为名，但个人往往更封闭，他们希望只有在确实必要时才公开其身份(GDPR、HIPAA、机密信息、银行保密)。另外，例如，通过查看不记名债券，所有者对债务人的身份的关注度要比债务人对所有者的关注度高得多。如果债务人证明是坏人或欺诈，则所有者可能会损失其金钱和投资。相比之下，债务人并不真正在乎他向谁偿还了债券，除非出于某些监管原因。因此，我们得出第四原则：

分类帐上的身份是不对称的问题，需要基于具体情况仔细权衡隐私和公开性。

为了构建全局可组合身份系统，身份方案需要产生全局唯一标识符。这允许全局系统避免联盟，而联盟则需要身份提供者之间的合作或所有参与者之间的共识，并且难以与同步协议一体化。

我们将使用

来指某些加密方案的公钥/私钥对，其中上标x将提供密钥用法的上下文，而下标k将用于区分密钥。

在下文中，我们将使用公钥I_k＝fingerpriht(p_k)的指纹来指密钥对(p_k，s_k)。基于此，我们将分别使用I_k，(p_k，s_k)作为以下的身份根密钥对。可以有多个倍数，并且我们不对此类密钥的所有者是谁进行任何声明。

现在，我们引入全局唯一标识符作为元组(X，I_k)，其中I_k指的是先前引入的身份根密钥的指纹，并且X原则上是某种抽象标识符，使得我们可以验证相等性。因此，如果X＝Y并且I_k＝I_l，则(X，I_k)＝(Y，I_l)。标识符在定义上是全局唯一的：不会发生冲突，因为如果两个标识符冲突我们将它们定义为相等。如此，身份密钥I_k跨越名称空间，并保证在其名称空间中按照定义不存在冲突。

在Scala代码的一个示例中，项目内的唯一标识符定义为：

/**A namespace spannedby the fingerprint of a pub-key

*

*This is based on the assumption that the fingerprint is unique tothe public-key*/

final case class Namespace(fingerprint：Fingerprint)

/**a unique identifier within a namespace*/

final case class UniqueIdentifier(id：Identifier，namespace：Namespace){

将使用全局唯一标识符来标识参与者节点N＝(N，I_k)，当事方P＝(P，I_k)和域实体D＝(D，I_k)(这意味着X是(X，I_k)的缩写)。对于当事方P和参与者节点N，出于隐私原因，我们应使用足够长的随机数。对于域D，我们使用可读的名称。

替代域构造

前述公开内容指定每个域可以包含用于在该域内或跨该域进行交易的一组组件。例如，域可以包含定序器或外部节点(例如，节点130、230、813、817、1018)，用于对域中的参与者节点(例如，节点110、120、210、220、811、815、819)提交的交易进行排序，以及中介节点280，用于汇合并确保域内确认的保真度。应当理解，对于域的替代构造是可能的，并且由本公开设想到。

在一些示例中，可以以上述替代方案的形式实现中介节点280的功能。在一个示例中，中介节点的功能由复制服务器上的容错服务复制(诸如，使用拜占庭式容错状态机复制)。在另一示例中，中介节点的功能可以在一个或多个节点中的软件保护扩展(SGX)安全区内运行，以提供更强的隐私和机密性。在一些示例中，这样的程序集可以与外部节点相关联。

本公开设想每个域或域的子集可以包括运行其自己的共识协议的分布式系统(例如，区块链)。在这种情况下，代替依赖定序器或外部节点(例如，节点130、230、813、817、1018)来对交易进行排序，域中的参与者节点(例如，节点110、120、210、220、811、815、819)可以依赖于分布式系统(例如，区块链)的交易排序协议来对在该域中提交的交易进行排序和/或验证。此外，如前所述，交易可以发生在不同的域上或跨域(例如，多域交易)。因此，本文公开的同步协议可以用于跨不同的分布式系统(例如，区块链)同步虚拟账本。从这个意义上讲，本文公开的同步协议可以以一种方式来构造，以同步不同的分布式系统，从而形成不同分布式系统的网络，每个系统运行自己的共识和/或交易排序协议。

应注意，这类示例不仅仅是不同领域与系统之间的互操作性。交易协议可以保持相同以形成虚拟分类帐，使得可以交换或更改域的域基础结构，并且可以连接域的不同实现方式。

在示例中，上述分布式系统的共识协议可以是拜占庭容错协议(例如，BFT、PBFT、aBFT等)，它可以是与抗sybil特征一起使用的共识协议，例如在工作量证明(POW)或权益证明(POS)中，或者也可以是本领域公认的另一种共识协议。如此，可以设想，本文公开的同步协议可以与其它分布式系统(例如，区块链)结合使用，以在不同的分布式系统之间同步交易，并形成不同的分布式系统的虚拟账本。

Claims (62)

1.一种调度和验证多参与者过程的方法，所述方法包括：

由与所述多参与者过程中的参与者相关联的提交节点通过将受密码保护消息发送到一个或多个接收方节点来提交拟议交易，其中，所述受密码保护消息至少包括能够由外部节点读取的未加密子消息、以及至少对于所述外部节点保护隐私的受密码保护子消息；

由所述外部节点确定所述拟议交易相对于其它交易的顺序；

通过所述接收方节点中的至少一些，验证所述受密码保护消息；

从所述接收方节点中的至少一些接收对所述受密码保护消息的有效性确认；

基于从所述接收方节点中的至少一些接收到满足确认条件的一个或多个确认，将所述拟议交易作为确认交易来完成；以及

根据由所述外部节点确定的所述顺序，将所述确认交易写入到分布式账本中。

2.根据权利要求1所述的方法，其中，所述一个或多个接收方节点至少包括第一接收方节点和第二接收方节点，并且其中，所述受密码保护子消息能够由所述第一接收方节点读取，而不能由所述第二接收方节点读取。

3.根据权利要求2所述的方法，其中，所述第一接收方节点有权访问解密密钥以解密所述受密码保护子消息，而所述第二接收方节点无权访问解密密钥。

4.根据权利要求1所述的方法，其中，将所述受密码保护消息发送到所述外部节点，并且所述外部节点将所述受密码保护消息发送到所述一个或多个接收方节点。

5.根据前述权利要求中任一项所述的方法，其中，所述一个或多个接收方节点使用匿名地址来对其它接收方节点隐藏其身份。

6.根据权利要求5所述的方法，还包括身份管理器，所述身份管理器维护所述提交节点与匿名地址之间的关联、以及所述一个或多个接收方节点与匿名地址之间的关联。

7.根据前述权利要求中任一项所述的方法，其中，基于所述未加密子消息来确定所述受密码保护消息的有效性。

8.根据权利要求7所述的方法，其中，基于所述未加密子消息来确定所述受密码保护消息的有效性包括：确定所述拟议交易的交易时间是否在由所述外部节点提供的时间戳窗口内。

9.根据权利要求8所述的方法，其中，所述拟议交易的交易时间是时间戳范围。

10.根据前述权利要求中任一项所述的方法，其中，基于所述受密码保护子消息来确定所述受密码保护消息的有效性。

11.根据权利要求10所述的方法，其中，基于所述受密码保护子消息来确定所述受密码保护消息的有效性包括：识别所述拟议交易是否与先前的交易冲突。

12.根据权利要求10或11所述的方法，其中，基于所述加密子消息来确定所述受密码保护消息的有效性包括：确定所述拟议交易是否格式正确。

13.根据权利要求10至12中任一项所述的方法，其中，基于所述受密码保护子消息来确定所述受密码保护消息的有效性包括：确定所述拟议交易是否符合一组一致性规则。

14.根据权利要求11所述的方法，其中，识别所述拟议交易是否与所述先前的交易冲突包括：检查所述先前的交易是否已经被记录在所述分布式账本上。

15.根据前述权利要求中任一项所述的方法，其中，基于所述未加密子消息和所述受密码保护子消息来确定所述受密码保护消息的有效性。

16.根据权利要求15所述的方法，其中，确定有效性包括：确定所述未加密子消息是否与所述受密码保护子消息一致。

17.根据前述权利要求中任一项所述的方法，其中，所述确认条件是以下项中的一个或多个：

从与所述多参与者过程中的参与者相对应的每个接收方节点接收确认；

在分配的时间段内接收到指定量的确认；

从所述一个或多个接收方节点中的指定子集接收确认；或者

根据诸如密码证明程序或可信硬件之类的可验证认证机制来接收确认。

18.根据前述权利要求中任一项所述的方法，还包括仲裁节点，所述仲裁节点确定所述一个或多个接收方节点是否没有根据针对相应接收方节点的期望动作来进行动作。

19.根据权利要求18所述的方法，其中，所述仲裁节点确定以下项中的一个或多个：

所述拟议交易是否格式正确；

由所述一个或多个接收方节点提供的所述确认是否与一个或多个其它确认冲突；以及

所述拟议交易是否错误地表明容量承诺耗尽。

20.根据权利要求18所述的方法，还包括：所述仲裁节点执行争议解决过程。

21.根据权利要求19所述的方法，其中，确定所述拟议交易是否格式正确包括检查以下项中的一个或多个：

所述拟议交易符合所述一致性规则；

所述拟议交易是由所述一个或多个接收方节点中的所需子集授权的；以及

所述拟议交易具有正确的资源要求声明。

22.根据权利要求18至21中任一项所述的方法，其中，所述一个或多个接收方节点中的第一接收方节点将所述拟议交易转发到所述仲裁节点以发起所述争议解决过程。

23.根据权利要求22所述的方法，其中，由所述仲裁节点对从所述提交节点或所述一个或多个接收方节点确定的行为异常节点施加惩罚来解决所述争议解决过程。

24.根据权利要求23所述的方法，其中，所述惩罚是以下项中的一个或多个：

删除所述行为异常节点提交交易的能力；

将与所述行为异常节点相关联的所述拟议交易标记为冻结；

由所述仲裁节点确定的对所述行为异常节点的自定义惩罚；以及

在域规则中定义的对所述行为异常节点的惩罚。

25.根据权利要求22至24中任一项所述的方法，其中，所述仲裁节点将所述争议解决过程的结果传达给所述提交节点和/或所述第一接收方节点。

26.根据权利要求22至25中任一项所述的方法，其中，在域规则中定义所述争议解决过程。

27.根据权利要求22至26中任一项所述的方法，其中，除了所述第一接收方节点之外，其它接收方节点也向所述仲裁节点提供一个或多个消息作为所述争议解决过程的证据。

28.根据前述权利要求中任一项所述的方法，其中，基于所述未加密子消息来确定所述拟议交易的顺序。

29.根据权利要求28所述的方法，其中，向所述拟议交易给予物理时间戳，所述物理时间戳对应于由所述外部节点接收到所述受密码保护消息的时间。

30.根据权利要求29所述的方法，其中，所述拟议交易相对于所述其它交易的顺序基于所述物理时间戳。

31.根据前述权利要求中任一项所述的方法，其中，所述拟议交易的顺序基于分配给所述拟议交易的逻辑时间戳。

32.根据权利要求31所述的方法，当从属于权利要求29至30中任一项时，其中，所述逻辑时间戳对应于所述物理时间戳的定义的时间窗内的时间。

33.根据前述权利要求中任一项所述的方法，其中，所述受密码保护子消息是加密的子消息。

34.一种调度和验证多参与者过程的方法，所述方法包括：

由与所述多参与者过程中的参与者相关联的提交节点通过将受密码保护消息发送到一个或多个接收方节点来提交拟议交易，其中，所述受密码保护消息至少包括能够由外部节点读取的未加密子消息、以及至少对于所述外部节点保护隐私的受密码保护子消息；

由所述外部节点确定所述拟议交易相对于其它交易的顺序；

由所述外部节点基于所述未加密子消息来确定与所述多参与者过程中的参与者相关联的一个或多个接收方节点；

由所述外部节点至少将所述受密码保护子消息发送给所述一个或多个接收方节点；

由所述一个或多个接收方节点确定所述受密码保护子消息的有效性；

由所述外部节点从所述一个或多个接收方节点接收对所述受密码保护子消息的有效性确认；

由所述外部节点确定应接收所述确认的一个或多个节点；

由所述外部节点将所述确认发送给所述一个或多个节点；

由所述提交节点，基于由所述一个或多个接收方节点提供的所述确认是否满足确认条件，将所述拟议交易作为确认交易来完成；以及

由所述提交节点根据由所述外部节点确定的顺序，将所述确认交易写入到分布式账本中。

35.根据前述权利要求中任一项所述的方法，还包括：

由中介节点接收并汇总由所述一个或多个接收方节点提供的所述确认。

36.根据权利要求35所述的方法，还包括以下项中的一个或多个：

存储所述确认的所述汇总；

将所述确认的所述汇总发送到另一节点；以及

基于所述确认的所述汇总来确认所述拟议交易。

37.一种包括程序指令的非暂时性有形计算机可读介质，所述程序指令在被执行时使一节点或一系列相关节点执行根据前述权利要求中任一项所述的方法。

38.一种调度和验证多参与者过程中的交易或一系列交易的方法，包括：

通过至少将部分加密消息发送到与所述多参与者过程中的参与者相关联的一个或多个接收方节点来提交拟议交易，其中，所述部分加密消息至少包括能够由外部节点读取的未加密子消息、以及至少对于所述外部节点保护隐私的加密子消息；

从所述接收方节点接收所述部分加密消息的有效性确认；

基于从所述接收方节点中的至少一些接收满足确认条件的一个或多个确认，将所述拟议交易作为确认交易来完成；

从所述外部节点接收所述确认交易相对于其它交易的顺序；以及

根据由所述外部节点确定的顺序，将所述确认交易写入到分类帐中。

39.根据权利要求38所述的方法，其中，所述一个或多个接收方节点至少包括第一接收方节点和第二接收方节点，并且所述方法还包括将所述加密子消息发送到所述第一接收方节点，所述加密子消息能够通过受所述第一接收方节点控制而不受所述第二接收方节点控制的解密密钥进行解密。

40.根据权利要求39所述的方法，其中，不将所述加密子消息发送到所述第二接收方节点。

41.根据权利要求38至40中任一项所述的方法，还包括：确定每个接收方节点的匿名地址，其中，每个匿名地址用于向其它接收方节点隐藏相应接收方节点的身份。

42.一种包括程序指令的非暂时性有形计算机可读介质，所述程序指令在被执行时使提交节点执行根据权利要求38至41中任一项所述的方法。

43.一种调度和验证多参与者过程中的多个交易的方法，包括：

通过一节点或一系列相关节点：

A.确定与组成所述多参与者过程的所述多个交易相对应的多个消息的顺序；

B.从与所述多参与者过程中的参与者相关联的提交节点接收拟议交易，所述拟议交易包括部分加密消息，其中，所述部分加密消息至少包括能够由所述一节点或所述一系列相关节点读取的未加密子消息；

C.基于所述未加密子消息来确定与所述多参与者过程中的参与者相关联的接收方节点；

D.将所述部分加密消息发送到所述接收方节点；

E.从所述接收方节点接收对所述部分加密消息的有效性确认；以及

F.将确认发送到所述提交节点。

44.根据权利要求42所述的方法，还包括确定所述接收方节点的匿名地址，其中，所述匿名地址用于向其它节点隐藏所述接收方节点的身份。

45.一种包括程序指令的非暂时性有形计算机可读介质，所述程序指令在被执行时使一节点或一系列相关节点执行根据权利要求42至44中任一项所述的方法。

46.根据权利要求1至36中任一项所述的方法，其中，所述分布式账本记录所述提交节点、外部节点和/或接收方节点之间的消息，其中，写入到所述分布式账本中的所述确认交易包括所记录的消息，从而根据所记录的消息来证明或能够得出由所述外部节点确定的顺序。

47.根据权利要求1至36和46中任一项所述的方法，其中，所述分布式账本包括多个不同的账本，每个账本维护所述账本的相应部分副本，其中，所述分布式账本是由所述多个不同账本的部分记录构成的。

48.根据权利要求1至36中任一项所述的方法，还包括：将所述多参与者过程从与所述外部节点相关联的第一域更改为与目标外部节点相关联的目标域，所述方法包括：

由所述第一域的外部节点从发起方节点接收转移请求，其中，所述转移请求指定所述目标域和所述目标外部节点；

由所述第一域的外部节点确定所述目标域和所述目标外部节点托管所述拟议交易的有效性，

其中，基于确定所述目标域能够有效地托管所述拟议交易，向所述发起方节点发送授权以在所述目标节点处调度和验证所述拟议交易，其中，对所述拟议交易进行排序的步骤由所述目标外部节点执行。

49.根据权利要求48所述的方法，还包括：

在所述提交节点和/或所述接收方节点处，接收所述转移请求；以及

在所述提交节点和/或所述接收方节点处，确定所述目标域和目标外部节点托管所述拟议交易的有效性，

其中，基于确定所述目标域能够有效地托管所述拟议交易，向所述发起方节点发送授权以在所述目标节点处调度和验证所述拟议交易。

50.根据权利要求48或49所述的方法，其中，对所述发起方节点的授权与指定的超时条件相关联，其中，基于所述指定的超时条件，所述授权是有效的和/或排他的。

51.一种调度和验证多参与者过程的方法，所述多参与者过程涉及：

第一域，与第一外部节点、第一接收方节点和提交节点相关联，所述提交节点与所述多参与者过程中的参与者相关联；

第二域，与第二外部节点、第二接收方节点、和所述提交节点或单独的中继节点相关联，并且其中，所述提交节点或所述中继节点与所述第一外部节点和所述第二节点两者通信；

其中，所述方法包括：

-由所述提交节点确定所述第一域的第一拟议交易和所述第二域的第二拟议交易，其中，所述第一拟议交易和所述第二拟议交易组合地形成涉及所述第一接收方节点和所述第二接收方节点的拟议多参与者交易，

其中，所述第一拟议交易和所述第二拟议交易中的每一个都包括到相应接收方节点的受密码保护消息，并且所述受密码保护消息至少包括能够由相应域的外部节点读取的未加密子消息、以及至少对于所述外部节点保护隐私的受密码保护子消息；

-由所述提交节点和/或所述中继节点将所述第一拟议交易提交到所述第一接收方节点，并将所述第二拟议交易提交到所述第二接收方节点；

-由所述第一外部节点确定所述第一拟议交易的第一顺序；

-由所述第二外部节点确定所述第二拟议交易的第二顺序；

-通过所述第一接收方节点和所述第二接收方节点，验证相应的受密码保护消息；

-从所述第一接收方节点和所述第二接收方节点接收所述受密码保护消息的有效性确认；

-基于从所述第一接收方节点和所述第二接收方节点接收到满足确认条件的确认，将所述拟议的多参与者交易作为确认的第一交易和确认的第二交易的组合来完成；以及

-根据所述第一顺序，将第一确认交易写入到与所述第一域相关联的分布式账本中，并且根据所述第二顺序，将第二确认交易写入到与所述第二域相关联的分布式账本中。

52.根据权利要求51所述的方法，其中，所述提交者节点是在所述第一域与所述第二域之间接收和发送消息的中继，其中，所述方法还包括：

由所述提交节点和/或所述中继节点从所述第一接收方节点向所述第二域的第二外部节点和/或第二接收方节点发送所述受密码保护消息的有效性确认；以及

由所述提交节点和/或所述中继节点从所述第二接收方节点向所述第一域的第一外部节点和/或第一接收方节点发送所述受密码保护消息的有效性确认。

53.根据权利要求51或52所述的方法，其中，用于完成所述拟议多参与者交易的授权与指定时序条件相关联，其中，基于所述指定时序条件，所述授权是有效的和/或排他的。

54.根据权利要求38至41中任一项所述的方法，其中，所述拟议交易是跨多个域的拟议多参与者交易的一部分，所述方法还包括：

从拟议多参与者交易中确定：第一域的所述第一拟议交易，所述第一域包括所述一个或多个接收方节点和所述外部节点；以及另一域的至少另一拟议交易，所述另一域包括一个或多个其它接收方节点和另一外部节点；

通过至少将另一部分加密消息发送到与所述另一域中的所述多参与者过程中的参与者相关联的所述一个或多个其它接收方节点来提交所述另一个拟议交易，其中，所述另一部分加密消息至少包括能够由所述另一外部节点读取的未加密子消息、以及至少对于所述另一个外部节点保护隐私的加密子消息；

从所述一个或多个其它接收方节点接收所述另一部分加密子消息的另一有效性确认；

其中，完成所述拟议交易的步骤还包括：基于从所述其它接收方节点中的至少一些接收满足所述确认条件的一个或多个确认，将所述其它拟议交易作为另一确认交易来完成；

从所述另一个外部节点接收所述另一个确认交易相对于所述另一个域中的其它交易的顺序；以及

根据由所述另一个外部节点确定的所述顺序，将所述另一个确认交易写入到分类帐或另一个账本中。

55.根据权利要求54所述的方法，还包括：

从所述第一域中的所述接收方节点向所述另一个域中的所述另一个接收方节点发送所述受密码保护消息的所述有效性确认；以及

从所述另一个域中的所述另一个接收方节点向所述第一域中的所述接收方节点发送所述受密码保护消息的所述另一个有效性确认。

56.根据权利要求54或55所述的方法，其中，将完成所述拟议交易和另一个拟议交易的授权与指定时序条件相关联，其中，基于所述指定时序条件，所述授权是有效的和/或排他的。

57.根据权利要求1至36、38至41和43至56中任一项所述的方法，其中，所述加密子消息包括期望确认数据，以对所述拟议交易中的所有期望确认进行密码验证，其中，所述方法还包括：

执行加密功能以加密验证接收到的一个或多个确认中的每一个确认与所述期望确认数据相对应。

58.根据权利要求57所述的方法，其中，所述期望确认数据是公钥的形式，并且其中，所述期望确认包括具有与所述公钥相对应的私钥的电子签名。

59.根据权利要求1至36、38至41和43至56中任一项所述的方法，其中，所述拟议交易包括多个子交易，每个子交易都涉及至少一个接收方节点，并且每个子交易与对应的受密码保护子消息相关联，所述受密码保护子消息具有隐私信息，所述隐私消息能够由所述子交易中所涉及的接收方节点读取，但不能由所述子交易中不涉及的接收方节点读取，并且

其中，所述受密码保护子消息包括隐私信息验证数据，以验证至少部分代表所述拟议交易中至少一个其它子交易的隐私信息的确认，并且所述方法还包括：

验证对至少一个其它子交易的确认与所述隐私信息验证数据相对应。

60.根据权利要求59所述的方法，其中，对子交易的确认至少部分地包括所述子交易的所述隐私信息的加密哈希。

61.根据权利要求60所述的方法，其中，所述拟议交易具有带多个子树的树结构，其中，子树包括所述多个子交易中的一个或多个。

62.根据权利要求59至61中任一项所述的方法，其中，所述受密码保护子消息包括隐私信息验证数据，以对所述拟议交易中的所述多个子交易的所述确认中的任一个进行密码验证。

Images