Privacy-preserving verify-and-commit architecture

Abstract

To provide a computer system including multiple nodes for verification to protect privacy and a commitment architecture.SOLUTION: A computer system for verification to protect privacy includes the steps of: submitting a transaction proposed by transmitting a protected message (140) by encryption to recipient nodes (120, 122) using a submission node (210) related to participants of a process with multiple participants; determining the order of the transaction proposed for other transactions by an external node; verifying the protected message encrypted by the recipient nodes; receiving the confirmation of the message validity protected by the encryption from the recipient nodes; confirming the proposed transaction as the confirmed transaction by receiving one or multiple confirmations from the recipient nodes satisfying the confirmation condition; and writing the confirmed transaction to a distributed ledger according to the order determined by the external node.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a computer system including multiple nodes for a privacy-preserving verification and commit architecture. The present disclosure also relates to a method for verifying a multi-participant process for committing transactions to a distributed ledger. [Background technology]

[0002] In distributed computing, the problem of ensuring consistency is known as the state-machine replication problem. Byzantine fault-tolerant solutions can solve the problem while guaranteeing the validity of the evolution of state (i.e., workflow) even by parties that do not trust each other.

[0003] Cryptocurrency systems such as Bitcoin and Ethereum may have at least partial solutions to the state machine replication problem (with additional "permissionless" requirements). However, such existing solutions are inapplicable to many applications. One such application is providing privacy in multi-participant processes where workflow evolution should typically be visible only to affected participants. A solution to this problem is to utilize a centralized node that validates, synchronizes, and commits transactions to a distributed ledger. However, because the centralized node must be trusted and each other node must reveal their own workflow evolution to the centralized node, using a centralized node for this purpose may not be suitable for some applications. Therefore, there is a need for a privacy-preserving architecture that avoids the use of a centralized node for the purpose of synchronizing and validating transactions.

[0004] Any discussion of documents, acts, materials, devices, articles, or the like which has been included in this specification should not be construed as an admission that any or all of such formed part of the prior art document or was common general knowledge in the art relevant to the present disclosure because it existed prior to the priority date of each of the appended claims.

[0005] Throughout this specification the word "comprise" or variations such as "comprises" or "comprising" shall be understood to imply the inclusion of a stated element, integer, or step, or group of elements, integers, or steps, but not the exclusion of any other element, integer, or step, or group of elements, integers, or steps. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] U.S. Patent Publication No. 2017 / 0316391 [Patent Document 2] WO 2017 / 189027 [Patent Document 3] WO 2017 / 187394 [Patent Document 4] U.S. Patent Application No. 62 / 329,888 [Patent Document 5] Australian Patent No. 2019200933 [Patent Document 6] WO 2019 / 082142 [Patent Document 7] AU 2017904367 Summary of the Invention [Means for solving the problem]

[0007] A method for scheduling and validating a multi-participant process is provided, the method including: submitting a proposed transaction by a submitting node associated with a participant in the multi-participant process by sending a cryptographically protected message to one or more recipient nodes, the cryptographically protected message including at least an unencrypted sub-message readable by external nodes and at least a cryptographically protected sub-message for privacy from the external nodes; determining, by the external node, an order of the proposed transaction relative to other transactions; verifying, by at least some of the recipient nodes, the cryptographically protected message; receiving confirmations of the validity of the cryptographically protected message from at least some of the recipient nodes; confirming the proposed transaction as a confirmed transaction based on receiving one or more confirmations from at least some of the recipient nodes that satisfy a confirmation condition; and writing the confirmed transactions to a distributed ledger according to the order determined by the external node.

[0008] In some embodiments, the one or more recipient nodes may include at least a first recipient node and a second recipient node, and the cryptographically protected sub-message is readable by the first recipient node but not by the second recipient node.

[0009] In some embodiments, a first recipient node may have access to a decryption key for decrypting a cryptographically protected sub-message, but a second recipient node does not have access to the decryption key.

[0010] In some embodiments, the cryptographically protected message may be sent to an external node, which sends the cryptographically protected message to each recipient node.

[0011] In some embodiments, one or more recipient nodes may use pseudonymous addresses to hide the identity of the one or more recipient nodes from other recipient nodes.

[0012] In some embodiments, the method may further employ an identity manager that maintains associations between submitting nodes and pseudonymous addresses and between recipient nodes and pseudonymous addresses.

[0013] In some embodiments, determining the validity of a cryptographically protected message may be based on unencrypted sub-messages.

[0014] In some embodiments, determining the validity of a cryptographically protected message based on an unencrypted sub-message may include determining whether the transaction time of the proposed transaction is within a timestamp period provided by an external node.

[0015] In some embodiments, the transaction time of the proposed transaction may be a range of timestamps.

[0016] In some embodiments, determining the validity of a cryptographically protected message may be based on cryptographically protected sub-messages.

[0017] In some embodiments, determining the validity of a cryptographically protected message based on a cryptographically protected sub-message may include identifying that a proposed transaction conflicts with a previous transaction.

[0018] In some embodiments, determining the validity of the cryptographically protected message based on the cryptographically protected sub-message may include determining that the proposed transaction is well-formed.

[0019] In some embodiments, determining the validity of the cryptographically protected message based on the cryptographically protected sub-message may include determining whether the proposed transaction complies with a set of compliance rules.

[0020] In some embodiments, identifying that a proposed transaction conflicts with a previous transaction may include checking whether the proposed transaction has already been recorded in the distributed ledger.

[0021] In some embodiments, determining the validity of a cryptographically protected message may be based on an unencrypted sub-message and a cryptographically protected sub-message.

[0022] In some embodiments, determining validity may include determining whether the unencrypted sub-message is consistent with the cryptographically protected sub-message.

[0023] In some embodiments, the confirmation condition may be one or more of the following: receiving confirmation from each recipient node corresponding to a participant in a multi-participant process; receiving a specified amount of confirmation within an allotted time period; receiving confirmation from a specified subset of recipient nodes; or receiving confirmation from a verifiable attestation mechanism such as a cryptographic prover or trusted hardware.

[0024] In some embodiments, the method may further employ a referee node that determines whether one or more recipient nodes fail to act in accordance with expected actions for the recipient nodes.

[0025] In some embodiments, the arbitrator node may determine one or more of the following: whether the proposed transaction is well-formed; whether confirmations provided by one or more recipient nodes conflict with one or more other confirmations; and whether the proposed transaction falsely indicates exhaustion of a capacity arrangement.

[0026] In some embodiments, the method may further employ an arbitrator node to perform the dispute resolution process.

[0027] In some embodiments, determining that the proposed transaction is well-formed may include verifying one or more of the following: that the proposed transaction complies with compliance rules; that the proposed transaction is authorized by a required subset of one or more recipient nodes; and that the proposed transaction has a correct declaration of resource requirements.

[0028] In some embodiments, a first recipient node of one or more recipient nodes may forward the proposed transaction to an adjudicator node to initiate the dispute resolution process.

[0029] In some embodiments, the dispute resolution process may be resolved by an arbitrator node imposing penalties on a cheating node as determined by the submitting node or one or more recipient nodes.

[0030] In some embodiments, the penalty may be one or more of the following: removing the ability of the misbehaving node to submit transactions; flagging proposed transactions related to the misbehaving node as frozen; a custom penalty for the misbehaving node determined by an adjudicator node; and a penalty for the misbehaving node defined in the rules of the domain.

[0031] In some embodiments, the arbitrator node may communicate the results of the dispute resolution process to one or more of the submitting node or recipient node.

[0032] In some embodiments, the dispute resolution process may be defined in the rules of the domain.

[0033] In some embodiments, other recipient nodes in addition to the first recipient node may provide one or more messages to the arbitrator node as evidence for the dispute resolution process.

[0034] In some embodiments, determining the order of multiple messages corresponding to multiple transactions that make up the process may be based on unencrypted sub-messages.

[0035] In some embodiments, the unencrypted sub-message may include a physical timestamp corresponding to the time the cryptographically protected message is received by the external node.

[0036] In some embodiments, the proposed order of a transaction relative to other transactions may be based on a physical timestamp.

[0037] In some embodiments, the order of proposed transactions may be based on logical timestamps assigned to the proposed transactions.

[0038] In some embodiments, the logical timestamp may correspond to a time within a defined time period of the physical timestamp.

[0039] In some embodiments, the cryptographically protected sub-message may be an encrypted sub-message.

[0040] A method for scheduling and validating a multi-participant process is provided, comprising the steps of: submitting a proposed transaction by a submitting node associated with a participant in the multi-participant process by sending a cryptographically protected message to one or more recipient nodes, the cryptographically protected message including at least an unencrypted sub-message readable by an external node and a cryptographically protected sub-message for privacy from at least the external node; determining, by the external node, an ordering of the proposed transaction relative to other transactions; determining, by the external node, one or more recipient nodes associated with the participant in the multi-participant process based on the unencrypted sub-message; and the external node to transmit at least a cryptographically protected sub-message to one or more recipient nodes; determining, by the one or more recipient nodes, the validity of the cryptographically protected sub-message; receiving, by the external node, a confirmation of the validity of the cryptographically protected sub-message from the one or more recipient nodes; determining, by the external node, one or more nodes that should receive the confirmation; transmitting, by the external node, the confirmation to the one or more nodes; confirming, as a confirmed transaction, a transaction proposed by the submitting node based on whether the confirmation provided by the one or more recipient nodes satisfies a confirmation condition; and writing the transactions confirmed by the submitting node to the distributed ledger in an order determined by the external node.

[0041] In some embodiments, the method may further include receiving and aggregating, by a mediator node, the confirmations provided by one or more recipient nodes.

[0042] In some embodiments, the method may further include one or more of the following: storing an aggregation of one or more confirmations; transmitting the aggregation of one or more confirmations to another node; and confirming the proposed transaction based on the aggregation of confirmations.

[0043] A tangible computer readable medium containing program instructions that, when executed, cause a node or a series of associated nodes to perform the method described above.

[0044] Provided is a method for scheduling and validating a transaction or series of transactions in a multi-participant process, the method comprising: submitting a proposed transaction by sending a partially encrypted message to one or more recipient nodes associated with at least participants in the multi-participant process, the partially encrypted message including at least an unencrypted sub-message readable by external nodes and at least an encrypted sub-message for privacy purposes from the external nodes; receiving confirmations of the validity of the partially encrypted message from the recipient nodes; confirming the proposed transaction as a confirmed transaction based on receiving one or more confirmations from at least some of the recipient nodes that satisfy a confirmation condition; receiving from the external node an order of the confirmed transaction relative to other transactions; and writing the confirmed transactions to a ledger according to the order determined by the external node.

[0045] In some embodiments, the one or more recipient nodes may include at least a first recipient node and a second recipient node, and the method may further include sending an encrypted sub-message to the first recipient node, wherein the encrypted sub-message is decodable by a decryption key controlled by the first recipient node but not by a decryption key controlled by the second recipient node.

[0046] In some embodiments, the encrypted sub-message may not be sent to the second recipient node.

[0047] In some embodiments, the method may further include determining a pseudonymous address for each recipient node, each pseudonymous address being used to hide the identity of each recipient node from other recipient nodes.

[0048] A tangible computer readable medium is provided that contains program instructions that, when executed, cause a submitting node to perform the above-described method.

[0049] 1. A method for scheduling and validating multiple transactions in a multi-participant process, comprising: By a node or a series of related nodes, A. Determining the order of multiple messages corresponding to multiple transactions that make up a process with multiple participants; B. receiving a proposed transaction including a partially encrypted message from a submitting node associated with a participant in a multi-participant process, the partially encrypted message including at least an unencrypted sub-message readable by the node or a set of associated nodes; C. determining a recipient node associated with a participant in a multi-participant process based on the unencrypted sub-message; D. sending the partially encrypted message to a recipient node; E. receiving confirmation of the validity of the partially encrypted message from the recipient node; F. sending a confirmation to the submitting node.

[0050] In some embodiments, the method may further include determining a pseudonymous address of the recipient node, the pseudonymous address being used to hide the identity of the recipient node from other nodes.

[0051] In some embodiments of the method, the distributed ledger records messages between the submitting node, the external node, and / or the recipient node, and confirmed transactions written to the distributed ledger include the recorded messages, such that the order determined by the external node can be verified or derived from the recorded messages.

[0052] In some embodiments of the method, the distributed ledger includes multiple different ledgers, each holding a respective partial copy of the ledger, and the distributed ledger is constructed from partial records of the multiple different ledgers.

[0053] In some embodiments, the method further includes modifying a process with multiple participants from a first domain associated with the external node to a target domain associated with the target external node. The method further includes receiving a transfer request from an initiator node by the external node of the first domain, the transfer request specifying the target domain and the target external node, determining, by the external node of the first domain, the appropriateness of the target domain and the target external node for hosting the proposed transaction, and sending, to the initiator node, authorization to schedule and validate the proposed transaction at the target node based on determining that the target domain may legitimately host the proposed transaction, wherein ordering the proposed transaction is performed by the target external node.

[0054] In a further embodiment, the method includes receiving a transfer request at the submitting node and / or recipient node; determining, at the submitting node and / or recipient node, the appropriateness of the target domain and the target external node for hosting the proposed transaction; and, based on determining that the target domain can legitimately host the proposed transaction, sending authorization to the initiator node to schedule and validate the proposed transaction at the target node.

[0055] In another embodiment, authorization to an initiator node is associated with a specified timeout condition, and the authorization is valid and / or exclusive based on the specified timeout condition.

[0056] 1. A method for scheduling and validating a multi-participant process, the multi-participant process including a first domain associated with a first external node, a first recipient node, and a submitting node associated with a participant of the multi-participant process, a second external node, a second recipient node, and a second domain associated with the submitting node or a separate relay node, the submitting node or relay node communicating with both the first external node and the second node, the method including: determining, by the submitting node, a first proposed transaction for the first domain and a second proposed transaction for the second domain, the first proposed transaction and the second proposed transaction being associated with a multi-participant process including the first recipient node and the second recipient node; Also provided is a method including the steps of: jointly forming a first proposed transaction and a second proposed transaction, each of which includes a cryptographically protected message to a respective recipient node, the cryptographically protected message including at least an unencrypted sub-message readable by external nodes of the respective domain and at least a cryptographically protected sub-message for privacy from the external nodes; submitting, by a submitting node and / or a relay node, the first proposed transaction to the first recipient node and the second proposed transaction to the second recipient node; and determining a first order for the first proposed transactions by the first external node.The method further includes determining a second order for the second proposed transaction by the second external node; verifying the respective cryptographically protected messages by the first and second recipient nodes; receiving confirmations of the validity of the cryptographically protected messages from the first and second recipient nodes; finalizing the proposed multi-participant transaction as a combination of the first confirmed transaction and the second confirmed transaction based on receiving confirmations from the first and second recipient nodes that satisfy a confirmation condition; and writing the first confirmed transaction to a distributed ledger associated with the first domain according to the first order and the second confirmed transaction to a distributed ledger associated with the second domain according to the second order.

[0057] In a further embodiment of the method, the submitter node is an intermediary for receiving and transmitting messages between the first domain and the second domain, and the method further comprises the steps of transmitting, by the submitter node and / or the relay node, a confirmation of the validity of the cryptographically protected message from the first recipient node to a second external node and / or the second recipient node in the second domain, and transmitting, by the submitter node and / or the relay node, a confirmation of the validity of the cryptographically protected message from the second recipient node to the first external node and / or the first recipient node in the first domain.

[0058] In another embodiment of the method, an authorization to confirm a proposed multi-participant transaction is associated with specified timing conditions, and the authorization is valid and / or exclusive based on the specified timing conditions.

[0059] In another embodiment of the method, the proposed transaction is part of a proposed multi-participant transaction spanning multiple domains, and the method includes the steps of determining from the proposed multi-participant transaction a first proposed transaction for a first domain that includes one or more recipient nodes and an external node, and another proposed transaction for another domain that includes at least one or more other recipient nodes and another external node; and submitting the another proposed transaction by sending another partially encrypted message to at least one or more other recipient nodes associated with participants in the multi-participant process of the other domain, wherein the another partially encrypted message is encrypted to be readable by at least the other external node. and receiving another confirmation of validity of the another partially encrypted sub-message from one or more other recipient nodes, wherein the step of confirming the proposed transaction further includes confirming the another proposed transaction as another confirmed transaction based on receiving one or more confirmations from at least some of the other recipient nodes that satisfy the confirmation condition, and the method further includes receiving from the other external node an ordering of the another confirmed transaction relative to other transactions in the other domain, and writing the another confirmed transaction to the ledger or other ledger according to the order determined by the other external node.

[0060] In a further embodiment, the method further comprises the steps of sending a confirmation of the validity of the cryptographically protected message from the recipient node in the first domain to other recipient nodes in another domain, and sending another confirmation of the validity of the cryptographically protected message from the other recipient nodes in the other domain to the recipient node in the first domain.

[0061] In a further embodiment, the authorization to confirm the proposed transaction and another proposed transaction is associated with specified timing conditions, and the authorization is valid and / or exclusive based on the specified timing conditions.

[0062] In other embodiments of the above-described method, the encrypted sub-message includes expected confirmation data for cryptographically verifying all expected confirmations of the proposed transaction, and the method further includes performing a cryptographic function to cryptographically verify that each of the one or more received confirmations matches the expected confirmation data.

[0063] In a further example of the method, the expected confirmation data is in the form of a public key, and the expected confirmation includes a digital signature by a private key corresponding to the public key.

[0064] In some example methods, the proposed transaction includes multiple sub-transactions, each involving at least one recipient node, and each sub-transaction is associated with a corresponding cryptographically protected sub-message having confidential information readable by the recipient node involved in the sub-transaction but not readable by recipient nodes not involved in the sub-transaction, the cryptographically protected sub-message including confidential information verification data for verifying a confirmation that at least partially represents the confidential information of at least one other sub-transaction of the proposed transaction, and the method further includes verifying that the confirmation of the at least one other sub-transaction matches the confidential information verification data.

[0065] In some further examples of the method, the verification of the sub-transaction includes, at least in part, a cryptographic hash of the sub-transaction's confidential information.

[0066] In some examples of the method, the proposed transaction has a tree structure with multiple sub-trees, and the sub-trees include one or more of the multiple sub-transactions.

[0067] In some example methods, the cryptographically protected sub-message includes confidential information verification data for cryptographically verifying any one of the confirmations of multiple sub-transactions of the proposed transaction.

[0068] A tangible computer readable medium is provided that contains program instructions that, when executed, cause a node or a series of associated nodes to perform the above-described method.

[0069] In some embodiments, the ledger may be a shared ledger.

[0070] Examples of the present disclosure are described below with reference to the figures. [Brief explanation of the drawings]

[0071] [Figure 1] FIG. 1 is a diagram of an exemplary system for scheduling and validating a multi-participant process involving multiple transactions. [Figure 2a] FIG. 1 is a diagram of a more complex exemplary system for scheduling and validating a multi-participant process involving multiple transactions. [Figure 2b] FIG. 2b is a diagram of the example of FIG. 2a with an intermediary node. [Figure 2c] FIG. 10 is a diagram of an example of distributing sub-messages to all nodes. [Figure 2d] FIG. 10 is a diagram illustrating an example of distributing sub-messages to some nodes. [Figure 3] FIG. 1 is a diagram of an exemplary proposed transaction. [Figure 4] FIG. 1 illustrates an exemplary method for scheduling and validating a multi-participant process. [Figure 5] FIG. 2 is a diagram of an exemplary node. [Figure 6] 1 is a schematic diagram of an example of a change of domain from a source domain to a destination domain; [Figure 7] FIG. 10 is a diagram illustrating another example of a domain change from a source domain to a destination domain. [Figure 8] FIG. 1 is a schematic diagram of an example of a multi-domain transaction spanning two domains. [Figure 9] FIG. 9 illustrates various deadlines for the multi-domain transaction of FIG. [Figure 10] FIG. 1 illustrates another example of a transaction involving multiple participants that may be conducted in a single domain. [Figure 11a] FIG. 11 illustrates a view of the various entities of the example transaction of FIG. [Figure 11b] FIG. 11b conceptually illustrates a blinded view of the view of FIG. 11a. [Figure 12] FIG. 11 is a schematic diagram of the transactions and methods of FIGS. 10 to 11b. [Figure 13] FIG. 13 is a state transition diagram for the transactions and methods of FIGS. 10 to 12. [Figure 14a] FIG. 1 illustrates a view of a transaction involving participant A, participant B, and a bank. [Figure 14b] FIG. 14b shows the view visible by the bank in the transaction of FIG. 14a. [Figure 15a] A diagram of a message for a transaction being recorded in a virtual ledger, without the details of one participant P. [Figure 15b] A diagram of a message for a transaction being recorded in a virtual ledger, without details of participant A. [Figure 16a] FIG. 1 illustrates a complete transaction view of a process with multiple participants. [Figure 16b] FIG. 16b shows the core of the first view of FIG. 16a. [Figure 17]FIG. 1 illustrates a complete data structure representing processes and transactions with multiple participants. [Figure 18] FIG. 18 is a diagram of a sub-view of the transaction of FIG. 17 illustrating privacy of the sub-transaction. [Figure 19] FIG. 18 is a diagram of the complete stakeholder tree for the transaction of FIG. 17. [Figure 20] FIG. 1 is a diagram of a stakeholder tree that is not blinded with respect to stakeholder banks. DETAILED DESCRIPTION OF THE INVENTION

[0072] The present disclosure relates to a system that can separate synchronization from validity in a distributed system. Synchronization is a common problem in distributed systems and is usually solved by some form of order-agreement primitive, such as total-order broadcast or multicast. An exemplary system is disclosed herein that ensures validity based on the concept of receiver nodes, where validity checking can be moved to the receivers themselves. Among myriad benefits, this can eliminate the need for a centralized committer node that has the ability to see and process all data, or the need for multi-party committer nodes that together have the ability to see and process all data, thereby improving the privacy of receiver nodes in the system.

[0073] In the system, participants can perform local validation based on their partial view of a transaction and communicate the results of their local validation through confirmations (e.g., peer-to-peer confirmations or confirmations routed through components or nodes of the system). In one example, participants can delegate the task of performing local validation based on their partial view to their users or other actors. In one example, participants can delegate the task of performing transaction-level validation based on their limited view of the rules of the distributed ledger's workflow to their users or other actors.

[0074] 1 shows an exemplary system 100 for scheduling and validating a multi-participant process involving multiple transactions. In this example, there is a process 102, a network 104 for communication between nodes, a submitting node 110, a recipient node 120, an external node 130, and a ledger 160. Optionally, there may be a second recipient node 122 (shown by a dashed line in FIG. 1) and an identity manager 170.

[0075] In this example, the process 102 may be shared by all nodes. A process can have multiple participants, each of which may be associated with at least one node in the network. In the simplest example, there may be a submitting node 110, a receiving node 120, and an external node 130. The external node 130 determines the order of multiple messages corresponding to one or more transactions that make up the process 102, which includes multiple participants. The external node 130 may be composed of multiple physical systems that implement the external node's logical ordering function.

[0076] The submitting node 110 may submit a proposed transaction 140. Submitting the proposed transaction 140 may include transmitting a cryptographically protected message over the network 104 to one or more recipient nodes associated with participants in the process, where the cryptographically protected message may include at least an unencrypted sub-message 142 readable by the external node 130 and a cryptographically protected sub-message 144 for privacy purposes from at least the external node 130. In one example, the cryptographically protected message may be a partially encrypted message that may include the unencrypted sub-message 142 and the encrypted sub-message 144. For the remainder of this specification, we will refer to the cryptographically protected message and sub-message as the partially encrypted message and encrypted sub-message, respectively, merely for convenience, although it will be understood that other cryptographic protection mechanisms other than encryption (e.g., data masking, semantic obfuscation, etc.) may be utilized to encode or obscure the cryptographically protected message or sub-message from unauthorized nodes. The encrypted sub-message 144 in this example may be considered the submitted payload of the partially encrypted message. In one example, symmetric encryption (e.g., Advanced Encryption Standard (AES)), asymmetric encryption (e.g., RSA, elliptic curves, etc.), or integrated encryption (e.g., ECIES) may be used to encrypt the partially encrypted message and submit the proposed transaction 140, and as will be understood, may be used in all transactions disclosed herein.

[0077] When the submitting node 110 submits the proposed transaction 140, the recipient node 120 may receive the proposed transaction 140 and determine the validity of the partially encrypted message and, therefore, the validity of the proposed transaction 140. In one example, such verification may involve the recipient node 120 verifying the encrypted sub-message 144 of the partially encrypted message. For example, in particular embodiments, the encrypted sub-message 144 may include data (e.g., program instructions, information, etc.) that is confidential to the recipient node 120 and the submitting node 110 and not readable by the external node 130 (e.g., because the submitting node 110 and the recipient node 120 contain a decryption key, while the external node 130 does not have the decryption key).

[0078] Once the validity of the proposed transaction 140 is determined, the recipient node 120 can send a message called a confirmation 150, which can be a confirmation of the validity of the partially encrypted message from the recipient node 120. In one example, the confirmation can confirm that the recipient node 120 validated the encrypted sub-message 144 against the proposed transaction 140 and believes the proposed transaction 140 to be correct and valid. In some examples, it can be advantageous to sequence the proposed transaction 140 (i.e., order the proposed transaction 140 relative to other proposed transactions) before it is validated. Because every participant can receive and verify the same sequence of transactions (or snippets of a sequence), such participants can implicitly verify the same order or sequence of proposed transactions, which can make it easier to identify misbehaving nodes.

[0079] In this example, the submitting node 110 can accept the proposed transaction 140 as a confirmed transaction based on receiving a confirmation from the recipient node 120 and can further determine that the proposed transaction 140 satisfies a confirmation condition. The confirmation condition in this example may be that confirmation 150 be received by all nodes corresponding to participants in the process 102. Given that there is only one recipient 120 in this example, only one confirmation may need to be received by the submitting node 110 to confirm the proposed transaction 140. A more complex example is discussed below.

[0080] In this example, the submitting node 110 and / or the recipient node 120 can write confirmed transactions to the ledger 160 according to the order determined by the external node 130. In one example, the ledger can be a data store that can be shared by all nodes. In another example, the ledger 160 can be a distributed ledger in which each node maintains a partial or complete copy of the ledger, and the submitting node 110 and / or the recipient node 120 can update their copy of the ledger accordingly. In yet other examples, the ledger 160 can be a distributed ledger that exists only conceptually and not physically. Specifically, the ledger 160 can be a distributed “virtual” ledger that is composed of messages exchanged between nodes of the network regarding transactions that are submitted over the network and entered into the “virtual” ledger. From the data contained in multiple messages, participants associated with nodes of the network can calculate the state of a "virtual" ledger at any point in time, and thus their obligations and liabilities to other participants in the network at that time, although a stateful distributed ledger (similar to, for example, Bitcoin or Ethereum) may not actually exist. In other words, only multiple messages may be remembered by various nodes of the network, and the state of the "virtual" ledger may be calculated based on the content of those messages.

[0081] 2a and 2b illustrate a more complex example system 200. Much like the example of FIG. 1, a process 202 may be shared by all nodes. A process can have multiple participants, each of which may be associated with one or more nodes in the network. However, unlike the example of FIG. 1, there are three nodes associated with the participants in the system: a submitting node 210 and two receiving nodes 220 and 222. Similar to the example of FIG. 1, an external node 230 can determine the order of multiple messages corresponding to multiple transactions that make up the process 202, which includes multiple participants. While the process 202 generally consists of multiple transactions as described in other examples of this disclosure, it should be understood that a process may include a single transaction. For clarity, the network has been removed from the diagram, but it should be noted that a network may exist similar to that of FIG. 1.

[0082] Similar to FIG. 1 , a submitting node 210 may submit a proposed transaction 240. Submitting the proposed transaction 240 may include transmitting a partially encrypted message over a network (not shown) to two recipient nodes 220, 222 associated with participants in the process 202, where the partially encrypted message may include at least an unencrypted sub-message 242 readable by an external node 230 and an encrypted sub-message 244 to protect privacy from at least the external node 230. In the example of FIG. 2 a, the partially encrypted message may be transmitted to the external node 230, which may determine one or more of the recipient nodes that will receive the proposed transaction 240 for confirmation. The external node 230 may then transmit the partially encrypted message to the appropriate recipient nodes 220, 222. In some cases, the external node 230 may transmit the encrypted sub-message 244 instead of the entire proposed transaction 240 to the recipient nodes if the encrypted sub-message 244 is relevant to the respective recipient node 220, 222. In another example, the proposed transaction 240 may include a set of multiple partially encrypted messages (with corresponding unencrypted sub-messages 242 and encrypted sub-messages 244 for each recipient), whereby the sub-messages (e.g., encrypted sub-messages 244) may be separated and delivered to each recipient node 220, 222. This allows portions of the proposed transaction 240 to be visible to authorized recipient nodes but not to other unauthorized recipient nodes, thereby preserving the privacy of those portions of the transaction that should not be visible to unauthorized recipient nodes.

[0083] An example of the above is shown in Figure 2c, which illustrates a scenario with an additional recipient node 224 in which the partially encrypted message is split into sub-messages 242 to 248 and the encrypted sub-messages 244, 246, and 248 are delivered to the respective recipient nodes 220, 222, and 224, respectively. In the example of Figure 2c, the encrypted sub-message 244 is readable by the first recipient node 220, but may not be readable by the second recipient node 222 or the third recipient node 224. That is, even though each recipient node 220, 222, and 224 receives the respective encrypted sub-messages 244, 246, and 248, the contents of the encrypted sub-message 244 may be readable and potentially verified by the first recipient node 220, but not readable and potentially verified by the second recipient node 222 or the third recipient node 224. This may occur in many instances where the contents of some messages are confidential to one recipient node and therefore should not be shared with another recipient node. Additional nodes other than the first, second, and third recipient nodes 220, 222, 224 may form part of the network, and a particular encrypted sub-message 244 may be sent to and readable by any subset of recipient nodes entitled to view the encrypted sub-message 244, but may not be sent to or readable by any subset of recipient nodes not entitled to view the encrypted sub-message 244.

[0084] An example similar to the example shown in Figure 2c is shown in the example of Figure 2d. In the example of Figure 2d, the encrypted sub-message 244 may be received only by the first recipient node 220, and not by the second recipient node 222 or the third recipient node 224. That is, in this example, if the external node 230 determines that the encrypted sub-message 244 is not relevant to the second recipient node 222 or the third recipient node 224, the external node 230 may not forward the encrypted sub-message 244 to the second recipient node 222 or the third recipient node 224. This means that even if the second recipient node 222 somehow gains unauthorized access to the decryption key, the second recipient node 222 will not be able to decrypt the encrypted sub-message 244 because it would not have received the encrypted sub-message 244 from the external node 230. Similarly, the third recipient node 224 would not be able to decrypt the encrypted sub-message 244 because it would not have received the encrypted sub-message 244 from the external node 230. Similarly, even if the external node 230 mistakenly sends the encrypted sub-message 244 to the second recipient node 222 or the third recipient node 224, the second recipient node 222 or the third recipient node 224 would typically not have the decryption key to decrypt the encrypted sub-message 244 unless they are behaving fraudulently. Thus, the disclosed system may preserve privacy among nodes, ensuring that only nodes entitled to see their portion of the proposed transaction are able to do so, even if keys or cryptographic algorithms are broken.

[0085] In one example, to read the encrypted sub-message, the first recipient node 220 has access to a decryption key to decrypt the encrypted sub-message 244 provided to the first recipient node 220. In this example, the second recipient node 222 may receive the encrypted sub-message 244 as shown in FIG. 2c, but does not have access to the decryption key to decrypt the encrypted sub-message 244 addressed to the first recipient node 220 to protect the privacy of that particular encrypted sub-message 244. Of course, access to the decryption key to decrypt the encrypted sub-message 244 may be provided to any number of recipient nodes or any subset of recipient nodes within the network that are entitled to read the particular encrypted sub-message 244.

[0086] For completeness, it is worth noting that in the example of Figure 2d, encrypted sub-message 246 is distributed to first and second recipient nodes 220 and 222, and encrypted sub-message 248 is distributed to first, second, and third recipient nodes 220, 222, and 224. Similarly, first recipient node 220 and second recipient node 222 then need to have access to a decryption key to decrypt encrypted sub-message 246, and first recipient node 220, second recipient node 224, and third recipient node 226 need to have access to a decryption key to decrypt encrypted sub-message 246.

[0087] Once the validity of the proposed transaction 240 is determined by each recipient node 220, 222, each recipient node 220, 222 can send a message called a confirmation 250, 252, which can be a confirmation of the validity of the partially encrypted message from the recipient node 220, 222. In this example, unlike the example of FIG. 1, the confirmation from each recipient node 220, 222 can be sent to the external node 230. The external node 230 can determine the submitting node 210, which can be one of multiple nodes, and can send the confirmation to the appropriate submitting node 210. In some variations not shown, the confirmation can be sent directly from one recipient node to another. That is, the confirmation can be sent peer-to-peer rather than through an external node or intermediary. Peer-to-peer confirmations can be used in conjunction with an external node or intermediary using appropriate rules to verify the transaction.

[0088] In one example, the submitting node 210 can accept the proposed transaction 240 as a confirmed transaction based on receiving multiple confirmations, i.e., a first confirmation from the recipient node 220 and a second confirmation from the recipient node 222. The confirmation condition in this example is full confirmation, similar to the example of Figure 1, and thus the transaction can be confirmed. Other alternative confirmation conditions besides full confirmation are discussed elsewhere in this disclosure.

[0089] In particular, in this example, each node associated with a participant in the system may have a ledger 260, 262, 264 and update its partial or complete copy of the ledger accordingly. For example, the submitting node 210 may have ledger 260, the first recipient node 220 may have ledger 262, and the second recipient node 222 may have ledger 264. Each node may then write confirmed transactions to its respective ledger 260, 262, 264 according to an order determined by the external node 230. In some examples, the ledger is a data store that may be shared among all nodes, in which case, for example, a privacy model based on isolated data may be required to preserve the privacy of each transaction associated with each participant node. In other examples, each ledger is a “virtual” ledger, as described above.

[0090] Optionally, a variation of the system shown in FIG. 2a can be to use an intermediary 280, as shown in FIG. 2b. In this scenario, recipient nodes 220, 222 can send confirmations 250, 252 to the intermediary node 280, which can receive the confirmations and determine an aggregated result. The submitting node 210 can also submit the proposed transaction 240 to the intermediary node 280. If there are three or more recipient nodes, it can be easier to count how many recipient nodes confirm the proposed transaction 240 using the intermediary node 280. Furthermore, the intermediary node 280 can act as an authoritative record of whether a confirmation was sent by a particular recipient node 220, 222. In other words, because confirmations can be routed through the intermediary node 280, the intermediary node 280 can have a record of all confirmations sent using the system, and recipient nodes 220, 222 cannot deny that they did or did not send a confirmation. In some examples, the intermediary node 280 receives all confirmations, aggregates them, and sends them to the corresponding participant nodes (so that the participant nodes do not interact directly with each other). This can be advantageous when a participant node is involved in a transaction that affects another node, but at least one participant node needs to maintain privacy with at least another node in the transaction when the latter two do not have a direct relationship. That is, when one participant node should not know that another participant node is involved in the same transaction.

[0091] Identity Manager The identity manager nodes 170, 270 may provide several services, e.g. a. Membership Management b. Pseudonym Management can be provided.

[0092] For membership management, identity manager nodes 170, 270 may enable nodes to join and leave a system (such as the system defined in Figures 1, 2a, and 2b). The systems already shown in Figures 1 and 2a-2b may also be referred to as domains, and a single node may be a member of multiple domains. Identity manager nodes 170, 270 may enable nodes to register, revoke, and rotate public keys. Identity manager nodes 170, 270 may know the participants represented by a given node. Identity manager nodes 170, 270 may also define a trust level for each node. For example, the trust level may be strong with respect to the operator of a domain (e.g., a payment system) or weak (e.g., with respect to participants in the payment system). Alternatively, the trust level may be selected to be the same for each node. In short, the identity manager node 170, 270 may enable nodes to register, revoke, and rotate public keys associated with particular node identities, allowing other nodes in the system to identify particular nodes within a domain, which may be useful in cases such as dispute resolution, as described in detail elsewhere in this disclosure.

[0093] For pseudonym management, the identity manager node 170, 270 may enable a node to generate pseudonymous keys (e.g., keys for signing messages without revealing the signer's identity). If an authorized participant (such as an external node or an adjudicator node) requests it, the identity manager node 170, 270 can reveal an already generated pseudonymous identity. A pseudonymous identity can be a pseudonymous address that hides the node's true identity but can simultaneously be used as an identifier by other nodes.

[0094] When using the identity manager node 170, 270, the recipient node 120, 122, 220, 222 does not need to know the identity of the submitting node 110, 210 or the identities of the other recipient nodes 120, 122, 220, 222. In one example, a recipient node knows the identities of other recipient nodes only if those other recipient nodes are participants in the same process 202; otherwise, the recipient node may only know the pseudonyms of the other recipient nodes. An external node 130, 230 may allow message delivery to a recipient node using a pseudonymous address and can use the identity manager node 170, 270 to resolve the identities of the pseudonymous participants.

[0095] External Node An external node 130, 230 can order messages corresponding to transactions that constitute a process involving multiple participants. In one example, the external node 130, 230 can provide global total order multicast (with respect to the domain), where messages are uniquely ordered by, for example, a unique timestamp provided by the external node 130, 230. Thus, global ordering can be derived from the timestamp. However, it should be understood that in some examples, the order of messages can be based at least in part on unencrypted sub-message information other than the timestamp. In other scenarios, as described elsewhere, the timestamp provided by the external node 130, 230 can be a physical or logical timestamp.

[0096] In some examples, it is possible to impose an order on a single transaction. That is, an external node 130, 230 can provide a globally totally ordered multicast in which messages are uniquely ordered, so that an order can be established even if no other transactions yet exist. As an example, a first proposed transaction can be timestamped such that any other transactions or proposed transactions not yet submitted to the external node can be timestamped with a later time. Thus, in this example, the first proposed transaction can be first (i.e., first in time) in the globally totally ordered order of all transactions that may exist for the process.

[0097] As shown in some of the examples herein, instead of delivering a single message, the external node 130, 230 may provide fine-grained message delivery. That is, a list of sub-messages 142, 242, 144, 244 may be delivered to the recipient node 220, 222. All sub-messages may receive the same timestamp as the message 140, 240 in which they are included. In particular, each sub-message may have a different set of recipient nodes, and each recipient node may receive the sub-messages in an order derived from the original message 140, 240.

[0098] The external node 130, 230 may also provide proof of submission. That is, the submitting node 110, 210 may receive a proof from the external node 130, 230 upon submission or confirmation 250, 252 of a proposed transaction 140, 240. The proof may serve as evidence in the event of a dispute, which may be used, for example, if a confirmation is missing. Corresponding to proof of submission, there may also be a need for non-repudiation of the message, so that a node cannot deny having sent a transaction or confirmation. Finally, proof of delivery by the external node 130, 230 may provide the recipient node with evidence regarding the order of the messages.

[0099] In some examples, external nodes 130, 230 may provide (and may be required to provide, if queried) cryptographic proofs of authenticity for any message or group of messages they deliver, which may act as cryptographic "receipts" that are sent to the submitting node (or other nodes, such as intermediary node 280).

[0100] intermediary The intermediary node 280 may form part of a system as shown in FIG. 2b. In a system with an intermediary node 280, the intermediary node 280 may receive confirmations from recipient nodes and aggregate the confirmations to determine whether there is agreement regarding the validation of a proposed transaction. This means that in some cases, the intermediary node 280 may be used to reduce the total amount of confirmations sent across the wider network. In one example, the intermediary node 280 may receive a message listing all expected confirmations that the intermediary node 280 should expect to receive in order for a transaction to be considered accepted / confirmed. The intermediary node 280 can compare the confirmations it receives with the confirmations it expects to receive to determine whether the transaction should be accepted / confirmed.

[0101] Additionally, the intermediary node 280 can be the node used when there is a dispute about whether an acknowledgment was sent or received. Because the intermediary node 280 can aggregate all acknowledgments from recipient nodes, the intermediary node 280 can act as an indisputable record that an acknowledgment was sent by a particular node, or that an acknowledgment was not sent when it should have been sent, and that the acknowledgment was properly received by all relevant recipient nodes.

[0102] When aggregating confirmations, the intermediary may take into account a confirmation policy, which may determine which nodes are required to verify and confirm the proposed transaction and which nodes may optionally verify and confirm the proposed transaction but may not be required to do so in order for the proposed transaction to be confirmed. That is, under some confirmation policies, a subset of recipient nodes may be required to respond with a confirmation. The remaining subset of recipient nodes may be optional verifiers, in that confirmations received from optional verifiers may be aggregated as part of determining agreement on the validation of the proposed transaction, but confirmations may not be required to confirm the proposed transaction and enter the proposed transaction into the ledger. Using an intermediary node to aggregate confirmations may also have the effect of protecting the identities of the nodes involved in the process or proposed transaction. In other words, the intermediary node may act as a proxy that aggregates confirmations and determines whether a confirmation condition or policy has been met, without necessarily sharing the identities of the nodes providing the particular confirmations or even the confirmation messages themselves.

[0103] More complex confirmation policies may exist, for example, a confirmation policy for a system with multiple nodes that requires receipt of confirmation from at least the first node, but not both nodes. It should be understood that there are many further variations of confirmation policies that may be implemented.

[0104] In some examples, a confirmation policy may specify a quorum for an action based on the number (or set) of confirmers who approve a transaction (even if some or all of the remaining stakeholders reject the action). In other examples, a VIP confirmation policy may grant some participant nodes VIP status, allowing them to verify actions on behalf of one or more other stakeholders and / or making them required confirmers (further details of VIPs are discussed under another heading).

[0105] The verification policy may rely on attestation by one or more nodes, for example, through attestation by a cryptographic prover (e.g., zkSNARK, zkSTARK) or a trusted execution environment (e.g., Intel SGX).

[0106] In some cases, an submitting node may submit a proposed transaction through an intermediary node 280, which can then receive and aggregate confirmations from recipient nodes 220, 222. There may be one intermediary node, or there may be multiple intermediary nodes, each with potentially different recipient nodes. Furthermore, not every recipient node is necessarily associated with an intermediary node. In some cases, for example, a first recipient node may communicate its confirmation to external nodes, the submitting node, or other recipient nodes as usual, while a further subset of recipient nodes may communicate their confirmations through the intermediary node. In other cases, all nodes in the network may be required to submit confirmations through the intermediary node or multiple interconnected intermediary nodes to ensure that the entire network has a consistent view of confirmations sent or received by nodes in the network.

[0107] The intermediary node 280 may store confirmations and other messages received from recipient nodes. This provides auditability because an auditor can retrieve confirmations or messages if required to perform an audit. The storage API may allow the auditor to retrieve received messages from storage. The storage API may inform the auditor whether a result message has been sent for a particular transaction or proposed transaction.

[0108] Domain Messaging APIs and Properties A domain messaging API is exposed to each participant node and system entity within the domain (e.g., submitting node 110, receiving node 120, etc.). A non-limiting example is described below in which the domain messaging API has a single command to "Send" a message and three event types: "Receipt," "Deliver," and "Heartbeat." messageId is the message identifier and b is the batch, i.e., m for 0 <= i < n. i is the message and the recipients i m i A list of recipients of the n-tuple (m i , recipients i ) command Send(messageId, b, Sig(b, sk sender )) Batch b is sent using the private key sk of the sending participant. sender The send command can be used to send messages in batches so that multiple messages (with different recipients) can be sent under the same timestamp. An event Receipt(messageId, ts, proof(sender, messageId, ts, b)) where messageId is the message identifier, ts is a timestamp, sender is the node's identifier, and b is the batch. The receipt event gives the recipient a cryptographic proof of the message they submitted. The proof may include a signature. An event Deliver(ctr, ts, b', proof(recipient, ctr, ts, b')) where ctr is a monotonically increasing counter for each recipient, ts is a timestamp defining the order, b' is a message batch, and proof is a cryptographic proof of delivery including the recipient's identity. Intuitively, a node knows all messages addressed to it and the other recipients of each message (this is possible because b is a batch). An event Heartbeat(ctr, ts, proof(recipient, ctr, ts)) where ctr is a non-decreasing counter, ts is a timestamp, and proof is a cryptographic proof of the heartbeat's origin.

[0109] In some instances, it is desirable for the domain messaging API for a node to have one or more, or possibly all, of the following properties: Guaranteed delivery: All messages are eventually delivered to all recipients of those messages. Send(messageId, b, Sig(b, sk sender )) is called by a properly functioning node sender, the Deliver(ctr, ts, b', proof(p, ctr, ts, b')) event will eventually be delivered to a set of recipients (i.e., recipients i There are ts and ctr that trigger at each node p in b' = [ (m, recipients)∈b | p∈recipients ] is. No creation: for any Deliver(ctr, ts, b', proof(p, ctr, ts, b')) triggered at node p, b' = [ (m, recipients)∈b | p∈recipients ] A node sends a message using a messageId in the form of Send(messageId, b, Sig(b, sk sender )) has already been called. Furthermore, the triggered mapping of Deliver events to Submit events is injective (i.e., there are no more Deliver events than corresponding Submit events). Note that this property can be verified thanks to the signature required for the Send command. Therefore, the sender cannot deny having sent the message. In-order delivery: When Deliver(ctr, ts,-,-) is triggered at a node, exactly one of the following holds: ctr = 0 and no Deliver or Heartbeat events have been triggered earlier on this node. ○ctr is equal to ctr' + 1, where ctr' is the counter of the previous Deliver or Heartbeat event. Furthermore, ts must be greater than the ts of any previous Deliver or Heartbeat event. The timestamp ordering, together with the ordering within a batch, provides a global total order. This, together with the cryptographic proof, guarantees that messages cannot be retroactively inserted into the message stream and that omitted messages can be detected by the receiver. Agree: If Deliver(ctr, ts, b, proof(p1, ctr, ts, b)) and Deliver(ctr', ts, b', proof(p2, ctr', ts, b')) are triggered at nodes p1 and p2, respectively, filter bothReceive b = filter bothReceive b' and bothReceive (m, recipients) = {p1, p2}⊆recipients is. Genuine proof of delivery: No one can generate proof(p, ctr, ts, b) unless Deliver(ctr, ts, b, proof(p, ctr, ts, b)) has already been triggered at node p. In practice, this is achieved by using signatures for proof. Proof of submission: Send(messageId, b, Sig(b, sk sender )) is called by node sender and sender does not crash, then there exists ts such that Receipt(messageId, ts, proof(sender, messageId, ts, b)) is eventually triggered in sender. The timestamp ts must be the same timestamp as for the Deliver event corresponding to Send. Causality: If Send(messageId, b,-) is called by a properly functioning node sender, the timestamp ts of the receipt Receipt(messageId, ts, _) must be strictly greater than the timestamp of any previous Deliver or Heartbeat event triggered at the sender node. Regular Heartbeat: At regular intervals, either a Deliver event or a Heartbeat event is triggered in each participant 110, 120. · In-Order Heartbeat: Whenever a Heartbeat(ctr, ts, proof(ctr, ts)) event is triggered at a participant, exactly one of the following is true: ctr = 0 and no previous Deliver or Heartbeat events have been triggered for this participant. ctr is equal to ctr' + 1, where ctr' is the counter of the previous Heartbeat or Deliver event. Furthermore, ts must be greater than the ts of any previous Deliver or Heartbeat event. Incrementing the counter in the heartbeat event ensures that every counter maps to exactly one timestamp.

[0110] Proposed Transaction A submitting node 110 may submit a transaction by submitting a proposed transaction. Generally, transaction protocols require the submitting node to specify the parties (i.e., declared stakeholders) that need to be informed of the action / transaction. The proposed transaction may be addressed to other recipient nodes (the proposed transaction could also address other parts of the system, such as a capacity monitor, a fee or resource accounting unit, an external node, an intermediary, etc.). Information in the proposed transaction may include unencrypted and encrypted sub-messages. The encrypted sub-messages may contain the actual payload, in encrypted form, that indicates the transaction to the stakeholders of the transaction (e.g., recipient nodes affected by the proposed transaction).

[0111] In some examples, the transaction protocol requires the submitting node 110 to specify the submitting node's information. This may include requiring the submitting node 110 to sign the transaction and / or portions of the proposed transaction. In some examples, this may require the submitting node's signature for every top-level action of the transaction. In other examples, this includes the submitting node 110 signing and forwarding the signature to affected stakeholders.

[0112] 3 shows an example 300 of a proposed transaction 302. In the example, participant A 330 wants participant P (a painter) 340 to paint participant A's house and wants to pay for this using an IOU held by participant A from a bank 342. Participant A makes an offer to participant P via a PaintOffer process 302.

[0113] In the context of this example, the system performs several actions. The first is the action of generating a contract that defines the proposed transaction (and recording the definition on the ledger). The second type of action is the action of performing an action on the contract, which may include multiple actions in a transaction. For example, the acceptance of the contract by a participant is a top-level action that results in several sub-actions 310 (which may be considered actions in themselves). This could include, for example, performing a transfer of value from participant A's IOU with a bank, and another action including generating a new IOU for participant P's benefit. From the system's perspective, such an action must (i) be approved by the transaction protocol for that action and (ii) conform to the underlying system model—so the action can be validly recorded on the ledger.

[0114] At the root of the transaction, participant P 340 fulfills participant P's election regarding the painting offer, which in turn can cause participant A 330 to fulfill participant A's transfer election regarding the IOU (310), generating a new IOU 312 for participant P's benefit, backed by the same bank 342. Simultaneously, an agreement is generated whereby participant P agrees to paint participant A's house (320). In the context of this disclosure, fulfilling an election may mean that a node executes a code segment related to a smart contract that the node is entitled to execute. Thus, for example, in the above example, participant P 340 can fulfill participant P's election to accept the painting offer by executing a code segment in the PaintOffer smart contract that records participant P's acceptance of the painting offer. Further details regarding selection and / or smart contract execution that may be usable by the systems of the present disclosure can be found in U.S. Patent Publication Nos. 2017 / 0316391, WO 2017 / 189027, WO 2017 / 187394 (all of which claim priority from U.S. Patent Application No. 62 / 329,888), and Australian Patent Nos. 2019200933, WO 2019 / 082142 (both of which claim priority from AU 2017904367), each of which is incorporated herein by reference in its entirety.

[0115] Each node 330, 340, 342 may only need to know the parts of the transaction that affect the contract in which it is a stakeholder. Since the entire transaction results from the fulfillment of PaintOffer, the stakeholders in the transaction (Participant A and Participant P) may need to know the entire transaction. Conversely, the bank and Participant A may only need to know about the transfer of IOUs 310, and Participant P may only need to know about the generated IOUs 312. This may lead to a decomposition of the different parts of the transaction, as shown in FIG. 3.

[0116] For completeness, it may be sufficient if the proposed transaction is sent to all of the stakeholders of the transaction. However, this is insufficient for privacy. Fortunately, not all stakeholders necessarily require full visibility of the entire transaction; their views only need to disclose enough information to ensure completeness and synchronization between the parties.

[0117] Each solid rectangle in Figure 3 represents a scope of privacy for that part of the transaction (with the relevant parties shown in italics and underlined). Note that there is no separate solid rectangle for PaintAgree 320, and participants A and P do not need to know about the generation of PaintAgree 320, as this can be implicitly inferred when participants A and P already know about the fulfillment of PaintOffer.

[0118] However, the situation may be different for newly created IOUs 312. Bank 342 should not know anything about the context of the transfer of rectangle 302. In particular, Bank 342 cannot assume, and should not know, that participant P 340 was a participant in any of the transaction's other agreements. This is why there is a separate solid rectangle 312 shared between Bank 342 and Participant P 340, even though both Bank 342 and Participant P 340 already know, at least in part, the contents of that solid rectangle 312 by knowing the outer rectangle 310. Bank 342 should not know what the other rectangles 302 or 320 are (i.e., what A is paying for) or who their stakeholders are.

[0119] transaction Those skilled in the art will recognize that, as used in this disclosure, a transaction may have a tree-like structure. A transaction may have stakeholders and / or observers, and accordingly, the portions (e.g., subtrees) of this tree-like structure that are visible to different stakeholders may vary. In their physical forwarded storage form, these transaction subtrees are called subviews. In one example, each recipient node 120, 122, 220, 222 obtains only the portions of the transaction that it is entitled to see, semantically as a subset of the transaction subtree and physically as a subset of the forwarded transaction message subview.

[0120] A transaction such as that shown in FIG. 3 (as transaction 302) may be atomic. In other words, the transaction may complete or fail as a single unit. Because participants generally may have visibility of only a portion of the transaction, participants may not be able to determine the validity or acceptance of the transaction on their own. Furthermore, in one example, this determination may not even be made by a participant that sees the entire transaction due to the intended way in which transaction validity may be delegated. For example, participant P 340's node can see the entire transaction above, but participant P 340's node is not a participant in the IOU 310 that bank 342 issued to participant A 330's node. To evaluate the validity or acceptance of the transaction, participant P 340's node may need confirmation from bank 342.

[0121] Unencrypted sub-message A proposed transaction, such as 240 in Figures 2a and 2b, may include an unencrypted sub-message 242. The unencrypted sub-message may include information about the proposed transaction 240 that is publicly available or available to all participants in the transaction process, and generally may not include confidential information of any of the participants. For example, the unencrypted sub-message may include the transaction time or the selection of a branch version of physical-temporal rules (e.g., which capacity or sharding model may be used) agreed upon (implicit or explicit, possibly concurrent) among the ledger stakeholders. Generally, such information may be publicly available information about the transaction.

[0122] In some examples, the external node provides the transaction time in the unencrypted sub-message by providing a timestamp. In other examples, the submitting node may propose a transaction time based on a timestamp provided by the submitting node. The transaction time may simply be a timestamp or digital record of the time the external node 230 received the proposed transaction 240. The timestamp may provide a date and time, universal time, or any measure of time with precision finer than a second that may help order transactions even if they are sent to the external node simultaneously.

[0123] In one example, the timestamp may not be a physical timestamp indicating when the external node 230 received the proposed transaction 240, but may be a logical timestamp. The logical timestamp may be a combination of the physical timestamp at which the external node 230 received the proposed transaction 240 and some logical time offset. For example, the logical timestamp may be a combination of the physical timestamp indicating when the external node 230 received the proposed transaction 240 and some logical time offset, thereby making the logical timestamp later than the physical timestamp. In one example, the logical time offset may be provided by the submitting node 210 that submits the proposed transaction 240. Thus, the concatenation of the physical timestamp provided by the external node 230 and the logical time offset provided by the submitting node 210 may form the logical timestamp in some cases. In other cases, the external node 230 or another node in the network may provide the logical time offset.

[0124] Enabling the submitting node 210 to provide a logical time offset may allow the submitting node 210 to some extent control the acknowledgement deadline by which the recipient nodes 220, 222 must send an acknowledgement for the proposed transaction 240 and / or to have some control over the ordering of the proposed transaction 240 relative to other transactions. For example, in one example, the system of the present disclosure may provide an acknowledgement deadline by which the associated recipient nodes 220, 222 must send an acknowledgement for the proposed transaction 240 in order for the proposed transaction 240 to be confirmed and entered into the ledger. The acknowledgement deadline may be calculated with reference to a logical timestamp. For example, the acknowledgement deadline may be calculated by adding some predetermined period of time to the logical timestamp of the proposed transaction 240. By allowing the submitting node 210 to provide a logical time offset, the system may allow the submitting node 210 to some extent set the logical timestamp of the proposed transaction 240, which may affect the acknowledgement deadline. By way of example only, the submitting node 210 may therefore adjust its acknowledgement deadline by changing the logical time offset so that the associated recipient node 220, 222 can meet its acknowledgement deadline and not fail to send an acknowledgement within the appropriate deadline. For example, if the submitting node 210 determines that the recipient node 220, 222 may need a large amount of time to acknowledge a particular proposed transaction 240, the submitting node 210 may provide a generous logical time offset to set the logical timestamp of the proposed transaction 240 somewhat later than the physical timestamp provided by the external node 230. The reverse example is also possible.

[0125] Furthermore, the logical timestamp, in one example, can serve as a final transaction time for the proposed transaction 240, which can influence the ordering of the proposed transaction 240 relative to other transactions. In other words, a global total order of transactions, including the proposed transaction 240, can be determined by examining the logical timestamps of all transactions and using the logical timestamps to temporally order such transactions. Thus, by providing a logical time offset, the submitting node 210 can still determine, within reasonable limits, the ordering of the proposed transaction 240 relative to other transactions. In particular, if the submitting node 210 is concerned about the priority of the proposed transaction 240, the submitting node 210 can set the logical time offset relatively short, thereby ensuring that the proposed transaction 240 receives the best logical timestamp and has a chance of being prioritized in the global total order of transactions.

[0126] In some cases, transaction times may be assigned that reorder transactions, including proposed transaction 240. Such reordering may be referred to herein as logical reordering because the reordering may be based on the logical timestamps of the transactions. With logical reordering, proposed transaction 240 may, in certain examples, be assigned a logical timestamp based on a physical timestamp and a logical time offset by external node 230, as described above. In some cases, the logical time offset may be considered the difference between the physical timestamp and the logical timestamp. The logical time offset may be selected so that the logical time offset is not too large or too small in light of the following considerations: If the logical time offset is large, proposed transaction 240 may tend to front-run. That is, merely by way of example, after transaction tx1 is submitted and receives a logical timestamp (e.g., determined in part by submitting node 210), another participant node in the network may later submit a competing proposed transaction tx2 that receives an earlier logical timestamp (e.g., due to a logical time offset assigned by such participant node). If later proposed transaction tx2 is confirmed and entered into the ledger, tx1 may be rejected because it conflicts with tx2, even though tx1 came first according to its physical timestamp. In practice, therefore, submitting nodes may find it advantageous to set the logical time offset as short as possible, taking into account the resource limitations of other nodes and the time required to validate the transaction, so that their proposed transaction can be confirmed and entered into the ledger without another conflicting transaction "cutting the queue."

[0127] Alternatively, if a later proposed transaction, tx2, is rejected after the acknowledgment deadline of an earlier transaction, tx1, then tx1 may also be rejected because the acknowledgment deadline for tx1 has already passed. In this scenario, both transactions are ultimately rejected. Conversely, if the logical time offset is small, the recipient node may simply not be able to send an acknowledgment by the acknowledgment deadline due to computational or network constraints. As a result, transactions may be rejected if the logical time offset is set too small.

[0128] In yet another scenario, proposed transaction tx1 may be submitted by an submitting node, assigned a logical timestamp, confirmed by an associated recipient node, and entered into the ledger. A subsequent proposed transaction tx2 may be submitted by the same or a different submitting node, assigned a logical timestamp that precedes the logical timestamp of tx1, confirmed by an associated recipient node, and entered into the ledger. Because the transaction time (e.g., logical timestamp) of tx2 precedes the transaction time (e.g., logical timestamp) of tx1, a logical reordering may occur that prioritizes tx2 over tx1 in the global total order of transactions, even though tx1 was submitted first.

[0129] encryption The encrypted sub-messages may be encrypted using symmetric encryption, asymmetric encryption, or both. Asymmetric encryption utilizes multiple keys, a public key and a private key, to encrypt and decrypt data. Any suitable encryption method may be used, for example, RSA or elliptic curve cryptography.

[0130] For encryption, the following operations may be available: A deterministic asymmetric encryption scheme E (e.g., called public key encryption) that encrypts any message m with a given public key pk pub (pk, m). A symmetric authenticated encryption scheme E that encrypts any message m with a given symmetric key symk sym (symk, m). The authentication can be protected from potential modification by external nodes 230 (called symmetric encryption). The pseudonym derivation method pseudonym(participant, token) derives a pseudonym for a given participant using a given token.

[0131] Encrypted sub-message To prepare the encrypted sub-message 144, 244, the submitting node 110, 210 first receives (in one example from the identity manager 170) a secret token tok a For each action "a" we get a new nonce key a can be prepared. a Let denote the stakeholders of action a. a is the list of subviews of a (including a itself) obtained by traversing a in order.

[0132] In one example, the encrypted sub-message for action a can then be derived as follows: 1. Encrypted actions are sym (key a , (bound(a), desc(a))), where bound is a function representing any pre-specified shared physical-temporal constraints to which affected stakeholders bind themselves. For example, bound can estimate the resource consumption of action a (given by a resource model), and desc(a) can be some complete means of describing a (e.g., a model representation with revealed inputs or an eval trace). 2. Let keys be the list of keys associated with the subviews of a ([ key a' | a' <- subs a ], read as "list of keys that decrypt subviews"). The keys are then protected for storage and transmission in the form of a key wrapped as a publicly encrypted list of key lists with an entry for each stakeholder in the transaction ([E pub (pk(stkh), keys) | stkh <- stkh a ]). In other words, this part of the encrypted sub-message could be, for example, an encrypted list of public keys corresponding to each stakeholder in the transaction, with the corresponding private key known to the relevant stakeholder (e.g., allowing the stakeholder to decrypt the encrypted sub-message). 3. The token used to generate the pseudonym of the expected confirmer of the action is [tok a' | a' <- subs a ]. In other words, this portion of the encrypted sub-message may include, for example, a list of tokens from which the pseudonyms (e.g., hexadecimal addresses) of each of the expected verifyers that should verify a particular action may be derived. Such information may be useful, for example, to enable a node in the network (e.g., external node 230) to determine which nodes in the network should verify a particular action.

[0133] The encrypted sub-message containing the payload of the proposed transaction can therefore be described by a data type (written here in Haskell, but implementable in many other languages). type RequestPayload = { metadata :: RequestMetadata , stakeholders :: [Pseudonym] , descriptions :: [(EncryptedActionDescription, [Participant])] }

[0134] Expected confirmation For each proposed transaction (e.g., proposed transaction 240 in FIGS. 2a-2b), assume there is a confirmation that may be required to accept / confirm the proposed transaction, and that the node determines the confirmation that it should expect to receive for the transaction. The expected confirmation may be a necessary positive response from a participant node in the process for the proposed transaction to be accepted / confirmed and entered into the ledger. In some embodiments, each node may determine which nodes are required to provide confirmation (e.g., by that particular node's view of the scope of transactions). That is, nodes 210, 220, 222 may evaluate which of the recipient nodes 220, 222 are required to provide confirmation in order to accept or confirm the proposed transaction 240. For example, a submitting node 210 submitting a proposed transaction 240 with a confirmation condition of all confirmations may determine that confirmations are expected from all participant nodes and that all confirmations have been received.

[0135] In some instances, the protocol may specify the verification policy, while in other instances, the verification policy (which may include verification conditions described under other headings) is specified at least in part within the transaction proposed by the submitting node.

[0136] Expected confirmations may be determined in whole or in part. That is, in some cases, a node may make a decision as to which expected confirmations are required for the visible portions of a transaction that the node is entitled to see, rather than the entire transaction. In this case, the node may decide that a portion of the transaction will be accepted / confirmed based on the confirmations it receives for the portions of the transaction that the node is entitled to see.

[0137] In one example, proposed transaction 240 may include information (such as expected confirmation data) describing all valid expected confirmations in encrypted sub-message 244. Such information may be used to verify received confirmations, which may include verifying received confirmations with expected confirmation data using a cryptographic function. In some examples, expected confirmations may be in the form of public keys and hashes of the parts of the transaction that these keys are required to sign. If an identity manager 270 is used, the keys may be pseudonyms of known keys, and the hashes may be salted to protect the privacy of participant nodes. Thus, the expected confirmations for the entire transaction may be given by the following data type (written in Haskell):

[0138] type ExpectedConfirmations = [([Pseudonym] , SaltedHash ActionDescription)]

[0139] Further features of the system In some examples, a timeout concept is used to ensure that the checks 150, 152, 250, 252 are performed in a timely manner. For example, if the validity of the transaction cannot be determined after a timeout parameter that may be defined by the rules of the domain (see below), the transaction may be rejected.

[0140] Additionally, in some examples, nodes make and advertise physical or temporal transaction agreements, such as transaction capacity agreements (e.g., required computation and size) or structural usage agreements (e.g., aligned with a storage sharding model). Generally, this may be done by the submitting node when submitting a proposed transaction. The agreements can be per process, providing per process and per counterparty guarantees. Physical or temporal transaction requirements may extend transaction timeouts.

[0141] If an unresponsive node exists, the node may be marked as such. The present disclosure may utilize a dispute resolution mechanism to discourage unresponsiveness and non-compliance with capacity agreements.

[0142] Determining validity A node can perform several checks to determine the validity of a transaction. Examples of checks for transaction validity are: a. Competition i. This check involves determining whether there is an associated contract (e.g., a DAML contract) that forms part of the process or any previous transaction that has already consumed the input. b. Authorization i. This check involves determining that the submitting node is allowed to submit the transaction based on authorization rules. c. Compliance i. This includes determining whether a transaction is well-formed in accordance with applicable rules. d. Time constraints i. This involves determining whether the transaction time meets the time constraint. e. Physical-time constraints i. This involves determining whether the physical or temporal transaction arrangement satisfies the branch version's selection of physical-temporal requirement rules agreed upon among the ledger stakeholders (e.g., which capacity or sharding model may be used). f. Resource Check i. This includes verifying whether the transaction's resource requirements were correctly specified. For example, a node can read the transaction's resource requirements specified as part of the transaction, and the node can execute the transaction if the resources used by the node are within the specified resource requirements; in one example, a node can not execute the transaction if the resources used by the node to execute the transaction exceed the specified resource requirements. This can have the beneficial advantage of preventing nodes in the network from submitting transactions that fall outside the resource requirements specified by the node, resulting in nothing happening.

[0143] competition One check that nodes 110, 120, 122, 210, 220, 222 can perform is to determine whether a proposed transaction 140, 240 conflicts with a previous proposed transaction or a previous confirmed transaction. Such conflicts are inherent in the concurrency of the system and do not necessarily arise due to intentional misbehavior (malice) or operational issues. Conflicts may involve whether a contract (e.g., a DAML contract) or input that is part of the process has already been consumed by one or more transactions.

[0144] In some examples, one of the checks that nodes 110, 120, 122, 210, 220, 222 can perform is to determine whether the proposed transaction 140, 240 conflicts with current or upcoming proposed transactions or transactions currently being validated or to be validated in the near future. Such conflicts may be inherent in the concurrency of the system due to uneven physical implementation choices (e.g., sharding), the use of out-of-order transaction logic (e.g., for large transactions such as batch-like activities), or generally due to ledger-backed logic such as caches or locks (e.g., for optimization purposes or to support additional ledger features), and do not necessarily arise due to intentional misbehavior (malice) or operational issues. Conflicts may include whether a contract (e.g., a DAML contract) has already been initiated for consumption by one or more transactions.

[0145] authorization Another check that a node 110, 120, 122, 210, 220, 222 can perform is to determine whether the proposed transaction 140, 240 is properly authorized, which involves determining whether the submitting node is authorized by the ledger state and rules to submit the transaction.

[0146] Compliance regulations Another check that nodes 110, 120, 122, 210, 220, 222 can perform is to determine whether the proposed transaction 140, 240 was well-formed with respect to each node's ledger compliance rules. Determining that a proposed transaction was well-formed may include determining whether the proposed transaction complies with a set of compliance rules for the proposed transaction. This may include, for example, determining whether the proposed transaction adhered to a specified format or a particular ledger's workflow, or whether the proposed transaction included all required data. One of the rules may include whether the proposed transaction was authorized. This may also include, for example, determining whether the proposed transaction's physical-temporal requirements (discussed in more detail below) adhere to rules already defined or agreed upon by stakeholders. Thus, if a request does not meet compliance criteria (e.g., improperly executes ledger workflow choices or physical-temporal requirements) or does not meet authorization criteria (e.g., a node's ledger workflow does not allow the proposed transaction submitter to submit the transaction), the request may be deemed to be malformed in some way (also known as ill-formed). This generally only occurs due to malicious intent or correctness issues (e.g., software bugs) in platform components at the participants.

[0147] A particular case of compliance could be faithfulness to a program or script defined in a smart contract language (e.g., DAML).

[0148] Time Constraints A further check that a node may perform is to determine the transaction time and determine whether the transaction time is within a time constraint. For example, a node may determine whether the transaction time of a proposed transaction is not too far from an external node's timestamp for the proposed transaction. If the expected resource consumption of the transaction is added to the proposed transaction, the period allowed for the deviation may depend on the resource consumption, as the submitter may need to process the transaction before submitting it. That is, the period allowed for the deviation may be defined within the domain rules as a factor for the specified expected resource consumption.

[0149] In other words, determining the validity of the proposed transaction may include determining whether the current time is within a timeout period of the proposed transaction's transaction time (e.g., whether the current time is greater than the proposed transaction's transaction time plus some preset time value). In one example, the transaction time may be considered a logical timestamp that may be provided by an unencrypted sub-message of the transaction. A node validating the proposed transaction may compare the current time with the proposed transaction's transaction time to determine whether the current time is within the timeout period (e.g., whether the current time is before the acknowledgment deadline). If so, the node may proceed with processing the proposed transaction and, if other validity checks also pass, send an acknowledgment accordingly. If the current time is after the timeout period, the node may not perform the transaction.

[0150] Physical-time constraints A further check that a node may perform is to determine whether the physical or temporal transaction arrangement satisfies a branch version of the physical-temporal rules agreed upon among the stakeholders of the transaction or domain. For example, a node may determine that the transaction's cost calculations do not conform to specified physical-temporal rules. For example, a submitter node may express the rules it uses to link proposed logical times to the transaction's specified resource consumption, and the submitter may express how the sharding model utilized links to the selection of multiple instances of external and intermediary nodes.

[0151] Verification conditions To provide a trade-off between trust, integrity, and availability, the system may allow for different confirmation conditions, which, as explained in more detail below, can be a threshold of confirmation sufficient to determine that a transaction can be accepted or confirmed and entered into the ledger.

[0152] A confirmation condition can be a constraint or prerequisite for a proposed transaction to be accepted or confirmed and properly entered into the ledger. A confirmation condition may relate to receiving one or more confirmations (e.g., a threshold amount of confirmations) from a recipient node.

[0153] Many types of confirmation conditions can exist, and the appropriate confirmation condition used may depend on considerations such as the parties involved, the process, and potentially even the condition of the network. For example, if the network condition is good, a full confirmation condition may be required, but if there is traffic congestion on the network, an optimistic confirmation condition may be sufficient until the network improves.

[0154] The use of a full confirmation condition may require that confirmation be received from each recipient node corresponding to a participant in the process.

[0155] The use of a signer confirmation condition may require that confirmation be received from each recipient node corresponding to a signer participant in the process.

[0156] The optimistic confirmation condition can be a requirement that the recent stream of confirmations meet a specified criterion, e.g., that a specified amount of confirmations be received by the relevant node within an allotted time period.

[0157] Using a "VIP" confirmation condition, the confirmation criteria may depend on the properties of the recipient nodes. For example, a VIP confirmation condition may dictate that confirmations be received from a specified subset of recipient nodes (e.g., designated as VIP nodes) that correspond to participants in the process. That is, there may be some nodes that must provide confirmation and other nodes that do not necessarily provide confirmation, and these may be reflected in the confirmation condition.

[0158] "VIP" verification may be implemented by attestation of a cryptographic prover (e.g., zkSNARK, zkSTARK) or a trusted execution environment (e.g., Intel SGX). In other words, in one example, a node in the network may act as an attestor (e.g., when a VIP verification policy is used), and the attestor may attest to other nodes that are participants in the proposed transaction that the proposed transaction satisfies all validity checks as described herein (e.g., as described in paragraph

[0106] above). In one example, the attestor node may provide the participants in the proposed transaction with a cryptographic proof (e.g., zkSNARK, zkSTARK) that cryptographically proves that the proposed transaction satisfies all validity checks and may be accepted as a verified transaction. The cryptographic proof, as described above, may be a zero-knowledge proof that may be provided to all participants in the proposed transaction so that all participants can trust the validity of the proposed transaction, but still cannot access confidential details about the proposed transaction that the relevant parties would not normally have access to. Similarly, a trusted execution environment such as Intel SGX may be used in conjunction with or in place of a cryptographic prover.

[0159] In general, in domains where nodes can be trusted to operate without malicious intent (i.e., intentionally misbehavior), optimistic confirmation conditions may be sufficient to guarantee acceptance of transactions. That is, for efficiency, it can be presumed that nodes operate without malicious intent and that none of the recipient nodes are malicious. However, malicious intent can still be detected and proven. In some cases, the consequences of malicious behavior can be handled outside the system.

[0160] In some examples, the confirmation conditions may also require that a response to the proposed transaction (which may be thought of as a confirmation of the request for validity) be received by the submitting node (and / or sent by the recipient node) in a timely manner, including having timeouts and deadlines, which are discussed in further examples below.

[0161] Domain Rules The rules of a domain are a set of rules agreed to by all participants in the domain. The rules of a domain may govern dispute resolution processes or outcomes such as punishments.

[0162] For example, if a node 120, 122, 220, 222 does not send a confirmation within a specified time frame, the node may be punished by being temporarily removed from the network or by using some other punishment. In some cases, good behavior may need to be established before full access to the network is again allowed. For example, a node 120, 122, 220, 222 may be temporarily removed from the network, unable to submit transactions, and then allowed to be in a "confirm only" mode until a sequence of on-time confirmations is received by the punished node.

[0163] Transaction Rejection A proposed transaction 140, 240 may be rejected for several reasons. One basis for rejection could be that the proposed transaction 140, 240 has multiple domains without so stating, i.e., that the proposed transaction 140, 240 attempts to use processes 102, 202 or contracts (e.g., DAML contracts) that are in different domains without indicating that the proposed transaction 140, 240 is a multi-domain transaction. In some cases, this may be permissible, but the usual rule may be that the proposed transaction 140, 240 should have a single domain.

[0164] In one example, the rules of the domain establish confirmation conditions, where insufficient confirmations may be received within a timeout period to declare the transaction conclusively accepted according to the rules of the domain.

[0165] Another reason for rejecting a proposed transaction 140, 240 may be that the proposed transaction 140, 240 is inconsistent with one or more other transactions, i.e., the proposed transaction 140, 240 conflicts with a previously accepted / confirmed transaction.

[0166] In some instances, transaction protocols require that all stakeholders be informed whether a transaction is approved and, conversely, whether a transaction is rejected. In some instances, protocols require that declared stakeholders in a transaction be informed of the reasons for the decision.

[0167] Any node can initiate a dispute, which can result in the node in question being marked offline. However, initiating an invalid dispute can also result in a node being penalized. Thus, when a dispute is initiated, a proposed transaction can still be rejected. This can happen if the recipient node determines that the proposed transaction is ill-formed, or if different nodes give conflicting responses regarding the validity of portions of the same transaction. In one example, both of these can occur due to malice or software bugs. That is, nodes can be expected to behave properly most of the time.

[0168] Confirmation Heartbeat Each pair of participants that share active contracts 102, 202 (or processes) that make up a transaction occasionally exchanges signed statements about those contracts, referred to herein as confirmation heartbeats, so that bilateral (or multilateral) participants can confirm the state of the contract / transaction. A statement is a "timestamp t" s These are all final confirmed active mutual agreements in the current agreement. Such statements can be used in dispute resolution. For example, participant A may receive the most recent heartbeat and timestamp t from B that contained agreement c. s indicates the say in the heartbeat at t s It is possible for participant A to prove to an adjudicator that a contract c that participant B has with participant B is still active at some time t by revealing all transactions that occurred between t and t. Through careful design of the action descriptions and proofs of delivery in the messaging layer, the adjudicator need not know anything from the disclosed transactions other than the contract ID.

[0169] To protect the privacy of participants, the statement in some instances may include only the root of the Merkle tree for the active contract. To ensure that participants can inspect each other's statements, the structure of the tree must be deterministic and reproducible by both participants.

[0170] privacy The disclosed system may include one or more of the following privacy features:

[0171] Requirement (Non-Disclosure to Unrelated Participants). A transaction protocol may disclose the actions of a submitted transaction only to the stakeholder participants of the action (including the transaction's stakeholders and confirmers). In this context, an action is the creation or fulfillment of a right associated with the stakeholder participant that is recorded in the distributed ledger, and also the creation or fulfillment of that right is recognized by the stakeholder participant with respect to that action (which essentially means that the creation or fulfillment of that right (i) is approved by the transaction protocol with respect to that action and (ii) conforms to the underlying system model). This privacy aspect is explained with reference to the example shown in Figures 14a and 14b, which reflect the transaction shown in Figure 3.

[0172] Referring to Figure 14a, the participant node hosting A may see the entire transaction (first box 1410) because A is a stakeholder in the root action. For the same reason, the participant node hosting P also sees the entire transaction (first box 1410). Note that the participant node hosting P may see the second action (second box 1420) even though it is not strictly a stakeholder. The participant node hosting P sees the second action anyway because it is a subaction of the first action, "Exe P (PaintOffer AP) "Accept"."

[0173] The participant node hosting the bank sees only the second action (second box 1420). Note that a requirement allows the transaction protocol to disclose the structure of the first action 1410 to the bank. This is indicated by box 1410' in Figure 14b.

[0174] The question marks "???" in 1410' indicate that the message delivered to the bank contains a blinded hash of the action, but the bank cannot derive the action from the hash.

[0175] Requirement (Non-Disclosure of Submitter): In some instances, a transaction protocol may disclose the submitting node or submitter of a transaction only to interested participants of the transaction's top-level action.

[0176] In a fence-painting transaction, participants A and P may know the submitting node because they have visibility into the entire action. However, the bank's participant node may not know (or, if required, should not know) the submitting node or the submitter's identity.

[0177] Requirement (Non-Disclosure to Message Brokers and Intermediaries): The transaction protocol must not disclose the contents of submitted transactions (i.e., the contents of encrypted sub-messages 144) to external nodes 230 or intermediaries 280.

[0178] Restrictions (Disclosure of Stakeholders and Confirmers): The transaction protocol may disclose the stakeholders and confirmers of a submitted transaction to external nodes 230 or intermediaries 280. This information may be derived from unencrypted sub-messages 142.

[0179] Restrictions (Disclosure of Encrypted Transactions): The transaction protocol may disclose encrypted versions of transactions submitted to external nodes, e.g., encrypted sub-messages 144 that cannot be decrypted by external nodes.

[0180] Restrictions (Disclosure by Dishonest Participants). The transaction protocol does not prevent dishonest participants from disclosing transactions to third parties.

[0181] Restrictions (Disclosure to Auditors). The transaction protocol does not prevent participants from disclosing transactions to auditors.

[0182] Transaction View The privacy of the system can be further illustrated by a transaction view from the perspective of various nodes, which is described below.

[0183] A transaction protocol may suggest that the system should get separate acknowledgments for every action in a transaction. In more complex cases, this can lead to an excessive amount of messages being sent. Therefore, the concept of transaction views can be used to reduce this burden: a transaction with multiple stakeholders is decomposed into a minimal set of different views, so that each node sees only what it needs to see and to minimize the size of data structures.

[0184] Transaction View - Given a transaction tx, a view of transaction tx is a subaction of the transaction that satisfies one of the following properties: 1. The subaction does not have a parent action in tx. 2. The parent action of a sub-action in tx has different stakeholders or different reviewers than the sub-action.

[0185] The core of a view is obtained by removing all subviews from the view (except the view itself).

[0186] This is best illustrated in Figures 16a and 16b. It is assumed that a full confirmation policy is in place, and therefore every stakeholder is also a confirmer. As shown in Figure 16a, the acceptance of the PaintOffer and the creation of the PaintAgreement belong to the same first view 1610 because these two actions have the same stakeholder (and therefore also the same confirmer). The transfer of the IOU belongs to a separate second view 1620 because the bank is not a stakeholder in the first view 1610. The creation of P's IOU also belongs to a separate third view 1630 because the painter P is not a stakeholder in the second view 1620.

[0187] FIG. 16b shows a first view core 1610′. Thus, the view core removes irrelevant information from the view, which can reduce the size of the message and the data requirements for storing such information (such as portions of corresponding sub-messages). This may include storing such information related to the transaction view in a distributed ledger. It should be appreciated that the second view 1620 and the third view 1630 have respective cores that may include different stakeholders, confirmers (and respective nodes). This may support finer-grained privacy than transactions, since only those entitled to view the view can see the respective information.

[0188] It should be understood that data structures can be constructed to represent the above transactions and views. This can include a transaction tree, which is a blindable Merkle tree representing transactions, potentially including the transaction, stakeholders for any view of the transaction, ledger effective time, and confirmation policy. A requirement can be that two different subtrees have different Merkle root hashes, even if their contents are the same.

[0189] Transaction Tree 17 shows a candidate data structure 1700 representing a fence painting transaction 1701. It may include the following groups: (1) Acceptance of PaintOffer represented by 1710 and 1711 (2) Transfer of IOUs represented by 1720 and 1721 (3) The generation of a new IOU as part of the transfer represented by 1730.

[0190] The term blindable Merkle tree in this context means or has the following characteristics: Every subtree has a hash. If a subtree is replaced by its hash, the hash of the entire tree remains the same. It is virtually impossible for an attacker to derive the contents of a subtree from its hash. To achieve this, the hash must depend on a blinding factor included in the transaction tree.

[0191] Uniqueness of the hashes of subtrees is required because the hashes of the subtrees are used as unique identifiers of the subtrees. It is also required to prevent a participant who can see one subtree from being able to infer whether another subtree has the same content. Uniqueness of the hashes of subtrees can be achieved by applying a unique blinding factor.

[0192] Definition (Hashes of Transactions and Views): The transaction hash of a transaction tree is the Merkle root hash of the tree. The transaction view hash of a transaction view is the Merkle root hash of the subtree of the transaction tree that represents the transaction view.

[0193] 18 shows a candidate representation 1800 of a subview 1730 of a fence painting transaction that generates an IOU owned by the painter. Information about other views, such as the PaintOffer acceptance 1710, 1711 and the IOU transfer 1720, 1721, is not visible. This can be used to provide finer-grained privacy than the transaction.

[0194] Stakeholder Tree - A transaction's stakeholder tree is a partially blinded version of the transaction tree with the following properties: (1) The contents of the transaction view are blinded. (2) Ledger validity time is blinded. (3) The verification policy is not blinded. (4) The hash of the selected transaction view is not blinded. (5) If the hash of a transaction view is not blinded, the stakeholders of the view are not blinded.

[0195] In a transaction's complete stakeholder tree, the hashes of all views of the transaction are unblinded. Figure 19 shows a candidate representation 1900 of the complete stakeholder tree for the fence painting transaction. Stakeholder information 1913, 1923, and 1933 is visible, and other information 1950 is blinded.

[0196] In a stakeholder tree that is not blinded with respect to participants p1,...,pn, the hashes of views in which exactly one of p1,...,pn is a stakeholder are not blinded. Figure 20 shows a candidate representation 2000 of a stakeholder tree that is not blinded with respect to the bank in the fence painting transaction. Unlike Figure 19, stakeholder 1913 is blinded (2013) (because the bank is not a stakeholder in the Paint agreement (offer / acceptance) between participant A and participant P). Stakeholder information 2023, 2033 is visible to the bank because they are stakeholders.

[0197] The above example illustrates a mechanism for preserving privacy at different levels of a transaction while still allowing stakeholders to see information about which they are interested (or are otherwise entitled to see such information). In other words, the above example shows how the described privacy model allows a transaction to be sent to multiple stakeholders such that different parts of the same transaction are blinded to the relevant stakeholders. That way, multiple stakeholders may receive the same transaction but have different privacy views of that transaction. Such a structure allows transactions to be submitted and recorded to a shared ledger in a private manner among various nodes in the network.

[0198] A virtual shared ledger In some instances, a transaction protocol implicitly generates a virtual shared ledger. The properties of the virtual shared ledger are enforced by the transaction protocol. The virtual shared ledger is a virtual concept. Generally, no single participant stores the entire virtual shared ledger. However, if all participants disclose messages resulting from their interactions with the transaction protocol, the virtual shared ledger can be derived from these messages.

[0199] First, a set of actions on a virtual shared ledger is defined. Ideally, an action belongs to the virtual shared ledger if and only if the protocol approves the underlying transaction. This property holds in practice if all stakeholder participants of a transaction are non-corrupt.

[0200] However, if some stakeholder participants are dishonest, they may approve an action even if it should be rejected by the validation algorithm. In particular, dishonest participants may cause the transaction protocol to approve transactions that do not conform to the underlying DAML model (or an alternative system model). For this reason, if an action is part of a protocol-approved transaction, the action must satisfy further properties in order to be part of the virtual shared ledger.

[0201] Actions on a Virtual Shared Ledger - An action is part of a virtual shared ledger if the following properties hold: i. The action is part of a transaction approved by a transaction protocol. ii. Actions conform to the underlying system model (e.g., the DAML model for a DAML system). iii. For every sub-action A of an action (including the action itself), the declared stakeholders of A are properly stakeholders of A according to the semantics of the system (e.g., the semantics of DAML).

[0202] An example definition of this is shown in the fence-painting transaction example. It is assumed that the underlying system model (in this case, a DAML model) contains all actions used in the example, and therefore the transaction conforms to the underlying system model. It is further assumed that the transaction was submitted with an all-confirmation policy. First, consider the case where stakeholders are correctly declared according to DAML semantics. If the entire transaction is approved, then every action in the transaction is part of the virtual shared ledger. Otherwise, i.e., if the transaction is rejected, then none of the actions in the transaction are part of the virtual shared ledger.

[0203] Figure 15a shows the case where A, rather than P, submits the fence-painting transaction, and A does not declare P as a stakeholder in the first action 1510. Assume also that the protocol approves the transaction.

[0204] The first action 1510 is not part of the virtual shared ledger because P was not declared as a stakeholder, which makes sense since P was the controller of the "accept" choice but did not even see the action.

[0205] The creation of the PaintAgreement (1520) is part of the virtual shared ledger because both A and P were properly declared as stakeholders. Since both A and P approved the action through their participant nodes, it makes sense to add the action to the virtual shared ledger.

[0206] For the same reason, the transfer of the IOU from A to P (actions 1530 and 1540) is part of the virtual shared ledger. Because the bank needs to be informed of the IOU transfer, it is infeasible to exclude the IOU transfer from the virtual shared ledger.

[0207] Figure 15b shows the case where A has not been declared as a stakeholder in the action that creates the PaintAgreement (1520'). Again, we assume that the protocol has approved the transaction.

[0208] The creation of the PaintAgreement (1520) is not part of the virtual shared ledger because A was not declared as a stakeholder. This makes sense because the action creates a PaintAgreement without informing A. The acceptance of the PaintOffer (1510) is also not part of the virtual shared ledger. The DAML model does not allow accepting a PaintOffer without creating a valid PaintAgreement (1520), so if the acceptance of the PaintOffer (1510) were part of the virtual shared ledger, the virtual shared ledger would not conform to the DAML model (or an alternative system model).

[0209] As mentioned above, the transfer of IOUs (1530 and 1540) is part of a virtual shared ledger. Both A and the bank approved the transaction, so there is no reason to object to it.

[0210] Having described under what conditions an action is part of a virtual shared ledger, the question of "when" a transaction is part of a virtual shared ledger is now addressed.

[0211] Transactions on a hypothetical shared ledger. A transaction tx is part of a hypothetical shared ledger if one of the following properties holds: 1. A transaction, tx, is submitted by a transaction protocol, and all actions in tx are part of a virtual shared ledger. 2. Transaction tx is submitted by the transaction protocol as part of another transaction ptx, which results from removing actions from ptx that are not part of the virtual shared ledger.

[0212] Finally, an example of a hypothetical shared ledger is defined as follows:

[0213] Virtual Shared Ledger: In some examples, the virtual shared ledger may include the following properties: i. A virtual shared ledger is a sequence of transactions, which sequence includes transactions that are "part of the virtual shared ledger" as discussed above. ii. The order of transactions on the virtual shared ledger corresponds to the order of submission, or alternatively, in a specified order according to the protocol, such as the order considered as a "logical sort." iii. Every recorded action on the virtual shared ledger is accompanied by the validator of that action and the validator's signature (e.g., the signature of the receiving node). iv. If a transaction on the virtual shared ledger matches the submitted transaction, the transaction is signed by its submitter and the submitting node.

[0214] As mentioned above, generally no single participant stores the entire virtual shared ledger, but if all participants disclose the messages resulting from their interactions with each other via transaction protocols, a virtual shared ledger can be derived by combining these messages.

[0215] Exemplary Methods 4 illustrates an exemplary method performed by system 200. It should be understood that the method may also be performed using system 100.

[0216] In this example, external node 230 may determine 410 the order of multiple messages corresponding to multiple transactions that make up a process involving multiple participants. It should be understood that determining 410 may be performed before, during, or after some of the steps described below.

[0217] A submitting node 210 associated with a participant in the process may submit (420) a proposed transaction (such as 240 in FIG. 2a), which may include sending a partially encrypted message (such as a cryptographically protected message) to one or more recipient nodes (such as recipient node 220) associated with the participant in the process, the partially encrypted message including at least an unencrypted sub-message 242 readable by external nodes 230 and an encrypted sub-message 244 (such as a cryptographically protected sub-message) to ensure privacy from at least external nodes 230.

[0218] The recipient node 220 may then determine 430 the validity of the partially encrypted message. This may include performing a validity check on the proposed transaction 240 and then, if the validity check is successful, sending a confirmation to the submitting node and any other nodes for which the recipient node 220 determines that a confirmation is expected or required. In one example, the recipient node 220 may send the confirmation through an intermediary node 280. In other examples, the recipient node 220 may send the confirmation peer-to-peer.

[0219] The submitting node 210 may then receive 440 confirmation of the validity of the partially encrypted message from the recipient node 220 .

[0220] The submitting node 210 may then confirm 450 the proposed transaction as an accepted or confirmed transaction based on receiving one or more confirmations from one or more recipient nodes that meet the confirmation conditions, which may be, for example, full confirmation conditions, VIP confirmation conditions, or any other confirmation conditions set as parameters of the system, as specified above.

[0221] The node, in this case the submitting node 210, can then write 460 the accepted / confirmed transactions to the ledger in the order determined by the external node 230. The ledger can be any ledger, as described in detail herein, including a distributed “virtual” ledger. In one example, a recipient node 220 (or node 220, 222) that is part of a transaction can also write the accepted / confirmed transactions to its copy 260, 262, 264 of the ledger once such node receives enough confirmations 250, 252 to satisfy the confirmation conditions. In a sense, the nodes 210, 220 of a transaction can form a “virtual” shared ledger between the nodes that is specific to any number of transactions occurring between the nodes 210, 222, in one example.

[0222] It should be understood that each node 110, 120, 122, 130, 210, 220, 222, 230, 330, 340, 342 is capable of performing a corresponding portion of the described method.

[0223] Example Node 5 illustrates an exemplary node, which may be any of the nodes 110, 120, 122, 130, 210, 220, 222, 230, 330, 340, 342 disclosed herein. The node 210 illustrated in FIG. 5 includes a processor 502, memory 503, network interface devices 508, 510, a distributed ledger interface device 509 that interfaces with the ledger 260, and a user interface 512. The memory 503 may store instructions 504 and data 506, and the processor 502 may execute instructions from the memory 503 to implement a process as illustrated in FIG.

[0224] The processor 502 may receive input from a user, such as a participant 516, through a user interface 512. The processor 502 may determine instructions based on the current state of execution recorded in the distributed ledger 152. The instructions may be functions to perform. The processor 502 may execute the instructions stored in the program code 504 and present any outputs 514 or results to the participant 516.

[0225] Resource Model The proposed transaction 140, 240 may include one or more resource requirements in resource units, in one example one per request message confirmable sub-block, representing a selection of pre-specified shared physical-temporal constraints (processing time, memory, network, storage) for each recipient to verify and confirm the transaction.

[0226] Every node 110, 120, 122, 130, 210, 220, 222, 230, 330, 340, 342 may subscribe to provide a specified amount of resources for a specified period of time. Such capacity subscriptions may be limited to a process or a group of nodes. All resource requirements are subject to the most specific capacity subscription that applies. A node may immediately reject a transaction whose resource requirements exceed the node's unused capacity requirements. A node may respond to indicate that the resource requirements are outside the node's resource capacity allocation. A capacity monitor, such as an arbiter node, may verify all denials based on exceeding the node's resource capacity allocation. The capacity monitor may then check against the capacity subscriptions made by the associated nodes.

[0227] In some example systems, node capacity arrangements are generated, and possibly updated, by previous or proposed transactions and acceptances involving the nodes and their participants. Such capacity reservation transactions may be implemented using the transactions described in this disclosure. In some example systems, capacity arrangements are reserved for a subset of specific transaction types. This may enable some example systems to have nodes negotiate capacity for processing capacity creation and update transactions.

[0228] Resource requirements may be declared within a transaction but not be part of the transaction itself. Thus, in theory, an submitting node could declare lower resource requirements than the actual resources consumed by processing and validating the transaction. A recipient node could detect such a discrepancy and file a dispute on the grounds that the submitting node is falsifying its resource consumption.

[0229] resource allowance In connection with the resource model, in some cases, a submission fee or resource allowance may be required to be paid by the submitting node 110, 210 (submission fee) and by the applicable recipient node 120, 122, 220, 222 that fulfills the selections related to the transaction agreement (e.g., the DAML agreement) (validation fee). The fee may be paid to the operator running the domain and / or the stakeholders in the transaction. The fee may be determined according to the cost of the transaction, which is determined by the amount of resources required for the transaction, process, and use by the domain. To facilitate this, each node may have a fee account from which fees are debited and paid.

[0230] An accounting component can maintain an account for each participant. When a transaction is timestamped by a message broker (e.g., external node 230), a submission fee can be charged to the submitter's account. When the transaction is finalized, a verification fee can be credited. Participants can credit their fee accounts using dedicated workflows.

[0231] In some example systems, fee accounting and transaction logic may be implemented using the transactions described in this disclosure. In such cases, the operator or a representative of the operator may be a participant with a node in the domain. Fee accounting rules and fee payment logic may then be implemented within the ledger's logic without requiring an additional accounting component. Furthermore, fee data or supporting data may be transferred within proposed transactions and confirmation messages (encrypted or not) without requiring additional transaction logic. This may allow participants to create and update the fee rules used by transactions for fee calculation and / or allow fee calculation to be specific to the participant and the transaction content. For example, participant nodes may not be charged verification fees when their only role in the ledger's process is to verify.

[0232] conflict Disputes can be raised when a participant is misbehaving or malfunctioning, such as when they do not confirm transactions within an agreed timeframe, systematically request transactions that do not pass validation, or declare insufficient resource requirements.

[0233] An adjudicator node may form part of the system and store evidence for adjudicating disputes, i.e., the adjudicator node may need to store submitted transactions and confirmations. Nodes involved in a dispute may be required to provide evidence, i.e., their unblinded transactions, so that the dispute can be resolved. To preserve privacy, nodes may re-encrypt their transactions in such a way that only the adjudicator node can decrypt them.

[0234] In some example systems, the dispute resolution process is implemented using transactions described in this disclosure. In such cases, the adjudicator can be a participant with a node in the domain. The dispute resolution process can then be implemented within the ledger logic without requiring an additional accounting component. Disputes can be raised, evidence can be provided, and a resolution outcome can be determined without requiring additional transactional logic. This may enable participants to raise disputes, provide evidence, and resolve disputes through transactions.

[0235] Timeout Dispute As mentioned above, in one example, a confirmation condition requires that a participant respond to a proposed transaction in a timely manner. If a participant does not respond in a timely manner, the participant node (or agent) of that transaction may initiate a timeout dispute with an adjudicator node. This may be used to determine the violation and, more importantly, the specific participant node that caused the violation. Examples of handling such a timeout dispute may include one or more of the following: Submit the timestamp of the affected confirmation request to the arbitrator node along with the associated proof delivered by the messaging API and the pseudonym of the responsible participant who failed to respond. If known, the identity behind the pseudonym is also sent. If no identity is provided, the arbiter node asks the identity manager 170 to reveal the identity. After determining the identity of the responsible participant, the arbiter node sends the participant a request for evidence to which the participant (specifically their respective node) responds. The evidence is a timestamped message from the messaging service containing an acknowledgement from either the responsible participant or the capacity monitor (if the request was rejected with an OutOfQuota response). If evidence is provided, the initiator of the request is permanently moved to "acknowledge-only" mode, i.e., the initiator is prohibited from sending further acknowledgement requests to the system, but we continue to allow the initiator to receive messages and send acknowledgements. If the responsible participant does not respond, a message is broadcast marking the participant as offline. Offline participants are moved to confirm-only mode, and other participants are allowed to reject their offline participants' confirmation requests. Since submitters are anonymous in the current scheme, rejection could be done by a capacity monitor or an allowance accountant. After the responsible participant comes back online, the participant can issue a request to be marked again, such as by an arbitrator node. Requests could be granted only after a certain "cooling off" period to encourage participants to remain available. · If the responsible participant responds with invalid evidence, they will be moved to verification-only mode permanently (or for a specified penalty period).

[0236] Detecting and proving participant misconduct Participant cheating can occur due to malicious actions. Examples include: A participant submits a transaction that does not conform to the underlying system model (e.g., the DAML model in a DAML system). A participant submits a transaction on behalf of a submitter that the participant does not host. A participant submits a transaction that must be authorized by a party other than the submitter. A participant submits a poorly formed transaction. A participant defines the declared stakeholder participants differently from the stakeholder participants according to the semantics of DAML (or other alternative systems), thus the wrong participants are informed of the action. The recipient node verifying the transaction does not apply the algorithm prescribed by the protocol to validate the action. For example, the action uses an archived contract, but the recipient node verifying the transaction approves the action. Or, the recipient node verifying the transaction rejects the action when it should be approved by the validation algorithm. An external node delivers a message with an incorrect list of recipient nodes or fails to deliver a message to a recipient node.

[0237] Examples of fraudulent activity and how it may manifest itself in the system include: 1. A confirmation request (e.g., a submitted proposed transaction) is flagged as malformed. 2. A conflicting response arrives to the confirmation request (to the one expected from the recipient node). 3. A transaction is rejected by falsely claiming exhaustion of capacity arrangements (e.g., lack of resources).

[0238] From this, the following can be determined: 1. If two parties issue conflicting confirmations for the same confirmation request, one of the two parties is malicious (or its participant node is malfunctioning in some way other than crashing). 2. The honest parties, with the help of the arbitrator node, have enough data to pinpoint who was cheating.

[0239] A verification request can be malformed for the following reasons: 1. Failing compliance and certification checks as described above. 2. Incorrect resource declaration by the submitting node 110.

[0240] An honest participant that receives a malformed confirmation request forwards it to an adjudicator node to initiate a dispute. The adjudicator node can then perform the same checks that the participant node of the dispute initiator performed. If the checks fail (i.e., the submitter's proposed transaction does not comply with the rules), the submitter's identity is revealed and the submitter is permanently moved to confirm-only mode. Otherwise, the dispute initiator is set to confirm-only.

[0241] Conflicting responses are only possible when one party denies a transaction (i.e., one of the recipient nodes) and another party (i.e., another recipient node) confirms the transaction. The denying party must first provide proof of denial to the arbitrator node. 1. If the denying party denies the transaction due to authorization or compliance issues, the confirmation request itself is sufficient, or 2. If a vetoing party vetoes a transaction due to consistency checking, the vetoing party should provide a previous, finally confirmed transaction that conflicts with the current transaction.

[0242] The loser of the dispute is moved to confirmation-only mode permanently (or for a penalty period) because he or she acted in bad faith.

[0243] Detecting and Proving Fraud in Centralized Messaging Services If we use a centralized messaging broker (e.g., external node 230), misbehavior of the messaging broker can cause violations of required messaging layer properties. Intuitively, any related misbehavior of the broker leads to deviations in the states of the participants. Deviations are detected when participants exchange acknowledgments and / or heartbeats, or when participants attempt to initiate a dispute, as participants have conflicting evidence pointing to broker misbehavior. There are two cases where misbehavior is detectable by the affected party but cannot be proven: (i) when the broker blocks all messages from the participant, and (ii) when the broker rejects the participant's messages.

[0244] Other exemplary methods Three other exemplary methods are described below. The first is a single domain example. The second and third examples relate to multiple domains. In particular, the second relates to a domain change protocol. The third relates to a multi-domain transaction.

[0245] Further Exemplary Methods in a Single Domain Figures 10 to 13 show a delivery-versus-payment (DvP) example 1001 in a single domain 1000. Alice 1010 and Bob 1012 want to exchange an IOU given to Alice 1010 by a bank 1014 for some shares held by Bob 1012. We have four parties: Alice (alias A) 1010, Bob (alias B) 1012, the bank, and a share registry SR 1016. There are also three types of contracts: 1. IOU Agreement 1031, always backed by Bank 1014 2. Share Agreement 1033, always with SR 1016 as the register 3. DvP contract 1035 between Alice 1010 and Bob 1012

[0246] Assume that Alice can make a "swap" election for an instance of a DvP contract 1035 to exchange her IOU 1031 for Bob's stock 1033. We assume that the IOU and stock contract instances have already been allocated in DvP. Alice wants to commit a transaction that executes this swap election, and the transaction has the following structure, shown in Figure 10:

[0247] Committing this example transaction involves two steps:

[0248] First step—Alice's participant node 1010 (as the submitting node) prepares 1040 a confirmation request 1041 for the transaction (see FIG. 12). The request 1041 provides a different view of the transaction, where participants see only the subtransactions that fulfill, fetch, or generate contracts in which they are stakeholders (or, more precisely, the subtransactions in which they are informees). The view of the DvP and its participants is shown in FIG. 11a (as shown in the bottom right of the box). Alice's participant node 1010 submits the request to a sequencer 1018 (i.e., external node 1018) that orders all confirmation requests within this single domain 1000; whenever two participants see the same two requests, they see them according to the order of this sequencer (external node 1018). In this example, the sequencer (external node 1018) has only two functions: to sequence messages and to deliver those messages to their specified recipients 1012, 1014, 1016. The contents of the payload messages are encrypted and invisible to the sequencer (external node 1018).

[0249] Second step - the receiver nodes 1012, 1014, 1016 then check the validity of the views they receive. The check of validity 1051, 1053, 1055, 1057 may encompass three points. 1. Validity defined within the ledger model: consistency (mainly, no double spending), compliance (the view is the result of a valid DAML interpretation), and authorization (ensuring that actors and submitters are allowed to perform the actions of the view). 2. Authenticity (ensuring that actors and submitters are who they claim to be) 3. Transparency (ensuring that participants who should be notified are notified)

[0250] Issues of compliance, authorization, authenticity, and transparency arise only due to malicious intent on the part of the submitter 1010. Consistency issues can arise even without malicious intent. For example, an IOU that should have been forwarded to Bob 1012 may simply have already been consumed (assuming we do not use DAML's "locking" technique). Based on the results of the check, a subset of the recipients 1014, 1016, called confirmers, then separately prepares confirmation responses (positive or negative) for each view. The confirmation policy associated with the request specifies which participants are confirmers, given the recipients of the transaction's information.

[0251] The confirmers send their responses 1061, 1062, 1063, 1064 to the intermediary 1020, another specialized entity that aggregates the responses into a single decision regarding the entire confirmation request. The intermediary 1020 works to hide the identities of the participants from each other (so that the bank 1014 and SR 1016 do not necessarily know that they are part of the same transaction). Like the sequencer (external node 1018), the intermediary 1020 is unaware of the contents of the transaction. Instead, in addition to sending the request 1041, Alice's participant node 1010 also simultaneously informs the intermediary 1020 of the recipients of each view's information (1042). The intermediary receives a version of the transaction that is visible only to the recipients of the view's information and whose contents are blinded (1032, 1034), as conceptually visualized in Figure 11b.

[0252] From this, the intermediary 1020 derives which (positive) acknowledgements 1061, 1062, 1063, 1064 are required to consider the confirmation request approved.

[0253] A request 1041 submitted by a malicious participant may contain a false view. Participants can only see part of the request (for privacy reasons) and receive acknowledgments on the request. Each participant locally filters out the false views visible to that participant and accepts all remaining valid views of the acknowledged confirmation requests. Under the assumption of trust in the confirmation policy, the protocol guarantees that the local judgments of honest participants agree on all views they see jointly. Thus, the protocol provides a virtual shared ledger among participants in which transactions consist of such valid views. Once acknowledged, accepted views become final, i.e., they are never deleted from the participant's records or the virtual ledger.

[0254] 12, the sequencer (i.e., external node 1018) and intermediary 1020, together with identities (not shown but described elsewhere), form an example of a single domain 1000. All messages within domain 1000 are exchanged through the sequencer (external node 1018), which guarantees total ordering among all messages exchanged within domain 1000.

[0255] Total ordering ensures that participants see all confirmation requests 1041 and responses in the same order. Furthermore, the protocol ensures that all non-fraudulent (i.e., non-malicious or non-malicious) participants see their shared view (such as completing the transfer of the IOU shared between participant bank and A), even in the presence of a fraudulent submitter. This has the following implications: 1. The correct acknowledgment for each view is always uniquely determined because in some instances using the DAML model, the acknowledgment is deterministic. However, for performance reasons, we allow occasional false negative responses when participants begin to cheat or act under conflict. The system provides non-cheating participants with evidence of either the correctness of their response or the reason for the false rejection. 2. Global ordering produces a (virtual) global time within the domain measured at the sequencer (external node 1018), and participants 1010, 1012, 1014, 1016 know that time has advanced whenever they receive a message from the sequencer 1018. This global time is used to detect and resolve conflicts and to determine when timeouts occur. Conceptually, we can therefore speak of a step occurring at several participants simultaneously with respect to this global time, but each participant 1010, 1012, 1014, 1016 performs this step at a different physical time. For example, in the message sequence diagram of Figure 12, participants Alice 1010, Bob 1012, Bank 1014, and Stock Registry 1016 receive confirmation requests 1071, 1072, 1073, 1074 at different physical times, but conceptually this occurs at timestamp ts1 in global time, and similarly at timestamp ts6 with respect to result message 1081.

[0256] The example of Figures 10 to 13 shows a single domain, but this can be modified and adapted to support multiple domains as discussed in later examples.

[0257] Some considerations for the system are balancing integrity and privacy issues while ensuring the evolution of a confirmation-based design, given that participant nodes may be overloaded, offline, or simply refusing to respond. Exemplary ways of addressing these considerations include the following: Use of a timeout: If the validity of a transaction cannot be determined after a timeout (which is constant across the domain), the transaction is rejected. If a confirmation request times out, the system informs the participant 1010 submitting the request that the participant failed to send an acknowledgment. This allows the submitting participant to take out of band action against fraud. Flexible Confirmation Policies: To provide a tradeoff between trust, integrity, and liveness, some domains may be tailored to their respective confirmation policies. Confirmation policies specify which participants must confirm which views. This allows the intermediary 1020 to determine the conditions sufficient to declare a request authorized. Of particular interest is the VIP confirmation policy, which can be applied to transactions involving trusted (VIP) parties as recipients of information for every action. An example of a VIP party is a market operator. The policy guarantees ledger validity by assuming VIP party participants behave correctly. Misbehavior, in this case, can still be detected and proven, but fallout must be handled outside the system. Another important policy is the signer confirmation policy, which requires all signers and actors to confirm. This requires a lower level of trust compared to the VIP confirmation policy, which sacrifices liveness when participants hosting signers or actors are unresponsive. Another (less-regarded) policy is the all confirmation policy, which requires all recipients of information to confirm. This requires the lowest level of trust, but sacrifices liveness when some of the participants involved are unresponsive. Attestator nodes. Attestator nodes can be thought of as on-demand VIP participants. Instead of constructing a DAML model where the VIP party is the recipient of information about every action, attestator nodes are used only on-demand. A participant wanting a transaction to commit must disclose enough history to the attestator node to provide unequivocal proof of the subtransaction's validity. The attestator's statement then serves as confirmation for non-responsive participants.

[0258] 13 shows a state transition diagram 1300 for a confirmation request, where all states except "Submitted" are terminal states. As described elsewhere, a confirmation request may be rejected for a variety of reasons, including requesting a transaction outside the current domain 1000 (unless it is part of an allowed multi-domain transaction, which is described separately), timeout, inconsistency, and conflict with previous or other requests.

[0259] Domain modification and composability In some examples, the system is composable in that it supports multiple domains and transactions across different domains. Composability provides atomicity guarantees for cross-domain transactions at the synchronization layer (rather than the application layer). This may allow several domains to be composed into one conceptual ledger at the application level. Approaches for cross-domain transactions include: 1. Domain Change Protocol. This is a protocol for transferring contracts from one domain to another. Such a protocol can be used to turn a multi-domain transaction into a single-domain transaction by moving many required contracts into a single domain. That is, it requires that all stakeholders of all affected contracts be connected to that one common domain. 2. Protocol for multi-domain transactions. This approach involves some participant nodes acting as intermediaries between different domains. This approach does not require all stakeholders to be connected to a single domain. However, it is important for such a system to have active participation by stakeholders so that transactions are executed atomically across all domains.

[0260] The two approaches are discussed in detail below.

[0261] Domain Change Protocol The domain change protocol moves individual contracts from one source domain to another destination domain. Contracts may be moved for different reasons: As a preparatory step to ensure that subsequent transactions can operate in terms of a single domain agreement. · To balance the load between different domains (done by stakeholders). · To access better market rules, allowances, or service quality (again, done by stakeholders).

[0262] An example domain change protocol may include one or more of the following features: A contract exists only in one domain or is in transit to another domain. A contract must ultimately reside in the domain where it resides. All stakeholders of a contract must be directly connected to the domain where it resides (or indirectly connected through intermediaries). All stakeholders must know where all of their contracts reside, and this information can be stored as metadata in their respective contract stores. The contract ID does not change when the residency location changes.

[0263] A domain change occurs in two steps: a transfer out in the source domain and a transfer in in the destination domain. A domain change can be aborted using abort transfer.

[0264] Currently, participants know the identity of the initiator of the domain change, and message brokers (i.e., external nodes) see the identity of the contract being transferred and the destination domain. Better privacy guarantees should be investigated in future research.

[0265] In some examples, the domain change protocol approach can be particularly advantageous because it does not necessarily require cooperation between all domains, but instead only the participants relevant to the agreement and transaction. The domain change protocol is initiated by an initiator node 614. In some examples, the initiator node 613 is or is associated with the submitting node 110. In other examples, the initiator node can be other nodes, including the recipient node 120.

[0266] Two examples of changing domains are described below with reference to Figures 6 and 7. In the first example, there is a contract with ID cid residing in Domain 1, with stakeholders I and P. Initiator I 614 transfers the contract to Domain 2 as shown in Figure 6. 1. Initiator I 614 sends a transfer request 621 to the message broker 610 of the source domain (i.e., an external node). The transfer request TO includes the contract ID, submitter, destination domain, and the timestamp ts0 of the destination domain. 2. The source message broker 610 timestamps the request TO at time ts1 and sends (623, 624) the request TO to the interested party 612 and the initiator 614, who consider the contract cid to be in transit since time ts1. 3. The initiator 614 sends a transfer-in request TI 625 containing a time-stamped transfer-out request to the message broker 616 of the destination domain (ie, an external node of the destination domain). 4. The destination message broker 616 timestamps the transfer-in request at time ts2 and sends (627, 629) the transfer-in request to the stakeholders 612 (i.e., stakeholders associated with the recipient node and / or the submitting node) and the initiator 614. The stakeholders 612 then consider the contract to be in the destination domain from time ts2 onwards.

[0267] The transfer-out request 621 includes a timestamp ts0 from the destination domain to establish a reference for the destination domain's exclusivity timeout 630. Prior to the exclusivity timeout 630, only the initiator node 614 may send a transfer-in request or transfer-abort message to the destination domain to complete the domain change or to abort the domain change. This exclusivity timeout 630 gives the initiator 614 time to initiate several domain changes, possibly for different contracts in different source domains, and submit them together with the transaction (not shown) to the destination domain in a single transfer-in message.

[0268] If the initiator 614 is unable to complete or abort the change of domain before the exclusivity timeout 630, other stakeholders 612 in the contract may do so. This ensures that the initiator node 614 cannot leave the contract in transit indefinitely, thereby depriving other stakeholders 612 of their right to exercise their choices regarding them.

[0269] 7 has the same settings as the previous example, but after step 2, the initiator does not send a transfer-in request before the exclusivity timeout 630. Instead, the steps include: 3. Interested party P 612 sends a transfer abort message to the destination domain 616 (731). 4. The destination domain 616 timestamps the transfer abort at time ts2 and forwards the transfer abort to the interested parties and initiator (733, 735).

[0270] Thus, the initiator node 614 and the stakeholder 612 know that there are no earlier transfer-in messages in the destination domain. The contract itself is still in transit because there is no timestamp yet in the source domain. Therefore, 5. Stakeholder P 612 forwards the time-stamped abort transfer to the message broker 610 of the source domain as an abort transfer notification (737). 6. The source message broker 610 timestamps this notification at time ts1' and forwards (739, 741) this notification to the interested parties 612 and the initiator node 614, who also consider the contract to be in the source domain from ts1' onwards. 7. Upon receiving the abort transfer message from domain 2 (735), the initiator node 614 checks that the destination domain's timestamp is after the exclusivity timeout 630 to ensure that stakeholder P 612 did not interrupt their exclusivity time period.

[0271] Instead of aborting the domain change, stakeholder P could have completed the domain change by sending a transfer-in message. The protocol would then have continued as in the first example, except that the initiator node 614 would have checked that stakeholder P's transfer-in message was timestamped after the exclusivity timeout 630. Conversely, in the first example, the initiator 614 could have instead aborted the domain transfer by sending an abort transfer message.

[0272] It should be understood that the above is an example of a domain change protocol, and that other types and variations of protocols may achieve this result. Further details of an example protocol generally shown in Figures 6 and 7 are provided below.

[0273] Not everyone is allowed to transfer a contract to another domain. Any stakeholder (who can be a submitting node, a recipient node, or a stakeholder associated with any other affected node) can always transfer their contract; the only constraint is that all stakeholders must have signaled in advance that they will accept (or otherwise consent to) the new domain. In this basic design, we assume that every participant declared at the beginning of time which domains it will accept, and that every participant knows these declarations.

[0274] To initiate a domain change, the initiator 614 sends 621 a transfer-out request 621 to the destination domain of the contract (e.g., via message broker domain 1 610). Such a request includes the contract ID to be transferred, the initiator's identity and possibly a proxied initiator node, the destination domain, a recent timestamp for the destination domain (e.g., from the broker's heartbeat), and a justification for the right to change domain. The timestamp establishes a period of time during which the initiator 614 has the exclusive right to either abort the domain change or submit a transfer-in message for the destination domain. (When the initiator 614 is not connected to the source domain of the contract, the initiator 614 must ask a stakeholder 612 to initiate the domain transfer on the initiator's 614's behalf. In that case, the actual initiator becomes the proxiedInitiator, and the stakeholder becomes the initiator.) The transfer-out request is addressed at the messaging layer to all the contract's stakeholders 612. Examples of transfer-out requests include: data TransferOutRequest = TransferOutRequest { contractID :: ContractID , initiator :: Party , proxiedInitiator :: Maybe Party , targetDomainID :: SiriusDomainID , targetTimestamp :: Signature SiriusDomainID Timestamp , justification :: (ProvenanceProof, Randomness)}

[0275] The source message broker 610 timestamps the request, sends a submission confirmation to the initiator 614 (623), and forwards the transfer request along with the timestamp to all stakeholders 612 (624). The source domain's allowance accounting component debits the domain change allowance from the initiator's account.

[0276] Stakeholder P 612 performs checks on the transfer request, including one or more or all of the following: i. The list of stakeholders 612 is complete. ii. The submitter is the initiator 614 specified in the request. iii. The destination domain is acceptable to all stakeholders. iv. The destination timestamp was signed by the destination domain. v. The justification is reasonable. vi. The subscription exists in the source domain. vii. There are no conflicting domain modifications or transactions with a smaller physical timestamp and no abort transfer messages in the destination domain for the same transfer-out request.

[0277] If checks (i) through (v) fail, the transfer-out request is malformed and the participant 612 reports malicious behavior (out-of-band in the transfer protocol). If check (vi) fails, the stakeholder 612 rejects the transfer-out request 624. The rejection includes the contract's current residence domain. If the contract is currently in transfer due to a racing domain change, the rejection states so. When the initiator 614 is not a stakeholder 612, check (vi) can still fail even without a race, since the initiator 614 is not informed about the domain change at that time. In such a case, the rejection informs the initiator 612 about the new residence. If check (vii) fails, the stakeholder 612 rejects the transfer-out request 624. If all checks pass, the contract becomes in transfer starting from the transfer-out request's destination timestamp. Contracts in (temporary) transfer do not exist in any domain, and no selection can be performed with respect to those contracts.

[0278] The stakeholders 612 confirm the transfer request via the message broker 610 of the source domain to the initiator 614 within the transfer confirmation timeout defined by the domain's rules. All checks rely only on data that all stakeholders 612 agree on. Therefore, all stakeholders 612 must arrive at the same result. Therefore, there is no need to send confirmations between stakeholders 612.

[0279] The transfer-in step registers a contract in the destination domain. An interested party 612 and (deputized) initiator 614 with a transfer-out request timestamp and signature of the source message broker can do so by submitting a transfer-in message 625 to the destination message broker 616. This right resides exclusively with the initiator 614 during the time period between the transfer-out 621 and the exclusivity timeout 630. A single transfer-in message 625 can simultaneously register several contracts, even from different source domains, and can optionally contain a DAML transaction (in the form of the payload of the request) (a resource request message must be sent beforehand). Examples of transfer-in requests include: data TransferInMessage = TransferInMessage { inContracts :: [TransferInRequest] , submitter :: Party , transaction :: Maybe RequestPayload} data TransferInRequest = TransferInRequest { out :: TransferOutRequest , originTimestamp :: Timestamp , originSignature :: Signature}

[0280] When the destination message broker 616 receives the transfer-in message 625, all transfer-in requests are stamped with the same timestamp by the destination domain and sent 629 as transfer-in confirmation requests to the respective stakeholders 612. If the transfer-in message contains a transaction, it is stamped with the following timestamp:

[0281] When participant 612 receives 629 the transfer-in confirmation request, participant 612 waits until participant 612 receives 624 and processes the corresponding transfer-out request from source domain 610. (Typically, the transfer-out request 624 arrives before the transfer-in message 629, but this is not necessarily the case when network latency varies.) Then participant 612 performs the following checks: (i) The participant 612 confirmed the transfer-out request at the source domain as described in the transfer-out step. (ii) The participant 612 did not see a transfer-in confirmation request or transfer-cancel notification with an earlier timestamp for this transfer-out request. (iii) The transfer request specifies the correct destination domain. (iv) If the submitter of the transfer in the message is not the initiator of the transfer-out request, at least the exclusivity timeout 630 has elapsed between the targetTimestamp in the transfer-out request and the destination broker's timestamp on the transfer-in confirm request. (v) If the initiator 614 is not a stakeholder in the contract being transferred, the participant remembers to check that the next timestamp from the message broker is in the transaction to make a selection regarding the contract being transferred.

[0282] If any of these checks fail, participant 612 reports fraud as described in the Dispute Resolution section. Otherwise, participant 612 considers the contract to be in the destination domain from the time indicated by the destination message broker's timestamp for the transfer-in confirmation request. This causes the contract to no longer be in transit (i.e., the contract is in the destination domain). Participant 612 sends a confirmation to initiator 614 and any delegated initiators via destination message broker 616. Otherwise, participant 612 sends a denial to the initiator and all stakeholders.

[0283] If the (deputized) initiator node is not a stakeholder in the contract, the participant 612 includes a transaction fulfilling a selection for the contract to which the message from the destination message broker 616 with the next timestamp is forwarded, and verifies that the provenance proof includes the actor and selection. If this is not the case, fraud is reported.

[0284] Bundling several transfer-out requests into a single transfer-in message does not guarantee atomicity of all transfers. Some may succeed, and some may fail. Bundling only guarantees that all successful transfers will have the same timestamp. Thus, a bundle of contracts needed for a transaction may occupy their residence simultaneously. If they were done in separate transfers, there was a risk that an older contract would be transferred out before all contracts were in the same domain. If one of the domain changes fails, the transaction will also fail, unless it exercises a choice regarding the untransferred contracts, as the contract's stakeholders will reject the transaction because the contract is not in the transaction's domain. Before the (earliest) exclusivity timeout, the initiator will know whether all domain changes will be successful, provided that it has received one transfer-out confirmation for each contract in which it is not a stakeholder.

[0285] Each domain specifies an exclusivity timeout 630 for a change of domain, as shown in Figure 7. During the exclusivity timeout 630, only the initiator 614 of the change of domain is allowed to send a transfer-in or transfer-abandon message. The criteria for the timeout 630 is established by the timestamp of the destination domain used by the initiator 614 in the transfer-out request 621. Thus, the initiator 614 has an incentive to use the most recent timestamp, as this prolongs the initiator's 614's exclusive right to propose a change of domain.

[0286] During the exclusivity time period, the initiator 614 can collect transfer-out request confirmations 623 and combine several transfers into a single transfer-in 625. Thus, the initiator 614 can ensure that all contracts needed for the transaction are moved to the same domain, or decide to abort the domain change if some fail. By including the transaction in the transfer-in request 625, any conflicting transfer-outs cannot transfer out parts of the contracts. Resource request messages for the transaction are sent during the exclusivity time period (i.e., before the exclusivity timeout 630). Therefore, the exclusivity period should be long enough so that the initiator 614 can also wait for a capacity denial timeout before submitting the transfer-in message 625.

[0287] After the exclusivity timeout 630, other stakeholders may initiate an abort of the domain change to prevent the initiator from leaving the contract in transit indefinitely and to free up resources.

[0288] A protocol for multi-domain transactions Multi-domain transactions span contracts from multiple domains and do not require explicit contract domain changes. This section describes a protocol for multi-domain transactions with the following properties and assumptions: The submitter must be connected to all domains where contracts used or generated in the transaction exist. A participant is called an intermediary if it is a stakeholder in a subtransaction whose input contracts are in one domain and which itself has subtransactions occurring in another domain. The submitter of a multi-domain transaction is always the intermediary. All intermediaries must be connected to all domains. All other stakeholders must be connected only to the domain in which they have contracts. In particular, there is not necessarily a single domain to which all included participants are connected. Participants connected to multiple domains may have registered different keys with custodians of identities in different domains. Multi-domain transactions are executed atomically across all domains unless one of the intermediaries or message brokers fails to operate in a timely manner or there is a connectivity issue between one of the intermediaries and message brokers. The same ledger validity period is used across all domains. There are known limits on clock differences and clock drift between different domains. Multi-domain transactions work with pessimistic reject and conditional verdicts in confirmation demand rules. All included domains must follow the same finality model (full confirmation or optimistic VIP confirmation). A single-domain transaction may precede a multi-domain transaction. Every contract lives in a single domain where all stakeholders are connected, and all stakeholders in a contract always know where the contract is located.

[0289] The submitter (associated with the submitting node 110) knows the domains in which all input contracts of a transaction in which the submitter is a stakeholder reside. Similar to the domain change protocol, for input contracts in which the submitter is not a stakeholder, the submitter knows where they resided at some point in the past. For contracts generated in a transaction, the submitter also knows where these contracts will be generated. This can either be specified in the transaction itself (e.g., in a DAML transaction or DAML extension) or can be determined independently by the submitter. The domains involved in a transaction are all domains in which the transaction's input contracts reside or in which the transaction generates contracts.

[0290] Referring to Figure 8, a multi-domain transaction is split into parts, one for each domain 803, 805. Each part is executed like a partial single-domain transaction, where the payloads of some views, i.e., views that affect the contracts of other domains, are not present in the confirmation request. Nevertheless, all confirmations for all views must be sent to all domains. For that purpose, intermediaries forward confirmations from one domain to the other.

[0291] Figure 8 shows the message flow for a simple two-domain transaction that performs a selection on two contracts, cid1 and cid2. The domain allocation is given by the table below.

[0292] [Table 1]

[0293] Thus, the transaction involves three participants: a submitting node 815, participant 1 811, and participant 2 819, as well as two domains D1 and D2 (and message brokers 813, 817 in domain 1 (D1, 803) and domain 2 (D2, 805), respectively, acting as external nodes). While there is no domain to which all participants involved in the transaction are connected, the submitter (submitting node) 815 is connected to all domains and acts as an intermediary. The submitter 815 splits the confirmation request for the entire transaction into two partial single-domain transactions, one for each view. The submitter 815 then simultaneously sends each part to the appropriate message brokers 813, 817 (i.e., the two external nodes in each of domains D1 and D2). Each part consists of two messages, a resource request 831, 835 and a request payload 833, 837, and the submitter 815 must ensure that it sends the payloads 833, 837 only after it has verified that no participants in any domain 803, 805 have rejected the resource request 831, 835 (e.g., by waiting until all capacity denial timeouts have passed). Each partial single-domain transaction is processed the same as the single-domain case, with the following exceptions: 1. When an expected confirmation 851, 852 includes pseudonymous participants in other domains, an intermediary (in this example the submitter node 815) is responsible for forwarding (853, 854) the confirmation to the intended recipient 811, 819 via the message brokers 813, 817 in the other domains. 2. The acknowledgment deadline 845, 846, which determines the time by which participants 811, 819 must have sent their acknowledgments 851, 852 to their local message broker 817, 813, is subject to some constraint that it be earlier than the decision time 847, 848 (even with respect to the message broker's clock) by the offset of the acknowledgment deadline chosen by the submitter 815. Acknowledgments 851, 852 from remote domains must arrive at the domain's message broker (foreign node) 813, 817 by the decision time 848, 847. The offset between the acknowledgment deadline and the decision time gives intermediaries time to collect acknowledgments from one domain and forward them to the other, as well as to hide clock skew and varying acknowledgment timeouts between the domains 803, 805.

[0294] Figure 9 shows how the various deadlines are determined and work together: The submitter (submit node) 815 selects: Ledger Effective Time for Evaluation (LET) 909 Logical time offsets 911, 913 Confirmation deadline offsets 915, 917

[0295] The LET must be the same throughout the multi-domain transaction. The offsets 911, 913, 915, 917 may be chosen differently for each domain 803, 805.

[0296] As partial transactions are sent to individual domains (831, 835), each partial transaction is marked with a physical timestamp that determines the point in time of all transactions in a particular domain as follows: Logical time = physical time + logical time offset 911, 913 Decision time 847, 848 = logical time + acknowledgement timeout 915, 917 Confirmation deadline 845, 846 = Decision time 848, 847 - Confirmation deadline offset 915, 917

[0297] Each point in time is tied to its domain 803, 805. Thus, the absolute times of these points in time vary from domain to domain. In Figure 9, the submitter 815 selected a longer logical time offset 911 for domain 1 803 (e.g., because the submitter 815 expected that sending a resource request would take longer in domain 2 805), and the logical time 921 in domain 1 803 does come after the logical time 923 in domain 2 805 in terms of total elapsed time (wall-clock time).

[0298] The submitter 815 should select the logical time offset 911, 913 based on that submitter's 815 experience of the domain's network latency so that all domains end up with similar logical times. This is because the ledger effective time 909, which is the same for all domains, must be close to each domain's logical time 921, 923, as determined by the domain's rule tolerances 925, 927.

[0299] The submitter (submitting node) 815 should choose the confirmation deadline offset 915, 917 so that every intermediary (for all combinations of source and destination domains) has enough time to forward (853, 854) the acknowledgment within the time between the source domain's confirmation deadline 845, 846 and the destination domain's decision time for forwarding 847, 848. However, the offset 915, 917 must be small enough so that every participant in every domain has enough time to check (951) for a conflict between when that participant observes the logical timestamp from the domain and when that participant must send the acknowledgment so that it arrives at the broker 813, 817 before the confirmation deadline 845, 846.

[0300] Because the submitter 815 chooses these times, the submitter 815 may have an advantage over other intermediaries. To prevent this, the submitter 815 must choose a confirmation tolerance 953 that limits how far apart the confirmation deadlines 845, 846 can be for any two domains. The larger the tolerance, the longer the confirmation deadline offset 915, 917 must be.

[0301] Example of a multi-domain transaction use case: global collateral An example of a multi-domain transaction is described below in the context of global collateral for multi-domain transactions, where the key synchronization and privacy requirements of global collateral are captured in a general atomic swap.

[0302] In the global collateral use case, two parties A and B want to atomically swap two assets, X and Y, owned by A and B, respectively. For simplicity, we assume that every party runs its own participant node. Ownership of asset X is recorded on one exchange, EX1, by an exchange asset register, R1. Ownership of asset Y is recorded on another exchange, EX2, by another exchange asset register, R2. Each exchange, EX i is its own domain D i and the asset registers of the exchanges are connected only to the corresponding exchange domains, i.e. Ri is connected only to Di. Parties A and B are connected to both domains.

[0303] An atomic swap is captured in a DvD (delivery versus delivery) contract where one of two parties, say A, can choose to execute a swap. This choice involves two sub-transactions: A transfers X to B and B transfers Y to A, respectively. This contract can be in another domain D3 where A and B must be connected since they are both stakeholders.

[0304] This transaction satisfies the requirements for a multi-domain transaction; that is, asset registries R1 and R2 are not intermediaries because they each see only a single transfer in their exchange's domain, and therefore do not need to be connected to any other domains. In fact, asset registries R1 and R2 do not care whether the transaction is executed atomically across all domains. In contrast, A and B are intermediaries; both A and B are connected to all three domains. Atomicity is crucial for both. If A's transfer of X to B succeeds, but B's transfer of Y to A fails, A will end up with no assets.

[0305] The case of B is symmetric: therefore, both A and B have an interest in timely relay of messages between domains.

[0306] This transaction cannot be performed by the "domain change protocol" (as discussed above) because there is no domain to which all stakeholders are connected.

[0307] The remainder of this section explains the details of multi-domain transactions and how they differ from single-domain transactions.

[0308] Submitting a Transaction Submitting a multi-domain transaction differs from a single-domain transaction in the following ways:

[0309] The formation of the view takes into account where the contract resides. When the traversal of the transaction tree visits a subtransaction of a top-level transaction, a new box is created when: The contract (input or output) of the subtransaction is in a different domain than the contract of the parent node's input, or Every box with a different set of stakeholders (as in the single domain case) is annotated by the domain to which it is associated.

[0310] 8, the submitter prepares a confirmation request consisting of resource requests 831, 835 and payload messages 833, 837 for each domain involved in the transaction. Each resource request and payload message for domain D is prepared as in the single-domain case with the following modifications: · The resource and allowance fields in the resource request aggregate only the resource requirements and allowances to be transferred for the view sent over D. Furthermore, every relayer is allocated a resource limit in all domains for relaying acknowledgments. · Bandwidth refers to the size of the payload sent over D. The payload data contains only the description of the view's action to be sent via D. The list "allStakeholders" contains only the pseudonyms of stakeholders whose boxes are sent through D. If some intermediary P (including the submitter) is not among them but is nevertheless connected to D, the submitter artificially generates a pseudonym for P and adds that pseudonym to "allStakeholders". The list of expected confirmations includes confirmations required from all domains. For every confirmation, the domain ID is set, even if the confirmation is sent via the domain the payload message is sent from. The "multiDomain" field is set in the resource request as described below. This field defines, among other things, the offset and tolerance of the confirmation deadline, which is described below. data MultiDomainData = MultiDomainData { confirmationDeadlineOffset :: TimeDistance , confirmationTolerance :: TimeDistance } logTimeOffset is increased by the confirmation deadline offset. The "multiDomain" field in the metadata of the request payload is set with a list of resource IDs from other domains. data MultiDomainPayloadData = MultiDomainPayloadData { remoteRequestIds :: [(DomainID, RequestID)] }

[0311] The metadata for a multi-domain transaction in a resource request includes the following information: The submitter selects, for each domain, an offset for the confirmation deadline. Participants in a given domain submit their confirmations. logical time + crt instead of Logical time + crt = confirmationDeadLineOffset where crt is the acknowledgement timeout from the single-domain case. The acknowledgement deadline offset must satisfy the following constraints: confirmationDeadLineOffset < crt - 2 *Δ where Δ is the expected network delay for communicating with the domain's message broker. Furthermore, the confirmation deadline offset is 2 *Δmax + confirmationTolerance + skew≦confirmationDeadLineOffset must be satisfied, where Δmax is the maximum expected network delay from any included participant to any included domain to which it is connected, and skew is an upper bound on the clock skew between any two domains. The confirmation deadline offset gives submitters (and other participants) time to act as intermediaries to forward confirmations from one domain to another. The upper bound ensures that all participants have enough time to send confirmations after they observe the logical time. The lower bound gives intermediaries time to forward confirmations between domains. The verification tolerance specifies how far apart the verification deadlines of different domains can be. The more accurately a submitter can predict the physical timestamps of different domains, the closer the actual verification deadlines will be, and the tighter the tolerance the submitter can choose.

[0312] Instead of requesting a payload, the submitter 815 may abort the transaction. An abort is required if: The resource request is rejected in one of the domains, so the entire transaction must be rejected. The physical timestamp has drifted too far so that the verification tolerance is exceeded.

[0313] When a message broker receives a resource request or request payload, it processes them as if they were single-domain transactions. In particular, the submitter must pay the submission fee in every domain.

[0314] Processing confirmation requests Confirmation requests 831, 833, 835, and 837 are processed in the same way as single-domain transactions, except as follows: Participants verify that the "RemoteRequestIDs" field does not contain duplicate domain IDs and contains exactly one entry for every domain listed in the expected acknowledgment. Every participant derives a new request identifier from the request ID and the remote request ID given in the payload request. The derivation MUST NOT depend on the order of the remote request IDs. The new request identifier is used for the acknowledgment. The transaction confirmation deadline is phys_ts + logTimeOffset + crt - confirmationDeadlineOffset is determined by. · The capacity monitor uses the revised confirmation deadline to determine whether a transaction meets capacity agreements. Participants: 2 *Δmax + confirmationTolerance + skew≦confirmationDeadlineOffset < crt - 2 *Δ- skew Verify that:

[0315] Regarding the payload 833, 837 of the request, the participant further checks the following: The resource request 831, 835 and the request payload 833, 837 were sent via the same domain 803, 805. For fulfillment, the input contract exists in the domain where the confirmation request was sent. For creation, the domain of the request payload is acceptable to all stakeholders. For each action, a participant checks that by the time it sends an acknowledgment, it has received the boxes for all subtransactions in which it is a stakeholder. If the subactions of a view operate in different domains, the participant considers itself an intermediary. If a view's subactions operate in different domains, the participant checks all of the following before sending its confirmation: - The physical timestamps of all remote request IDs in "remoteRequestIDs" are at least confirmationTolerance + Δmax + skew before the view's confirmation deadline. - The participant has received resource requests for all domains listed in "remoteRequestIDs". - Every pair of confirmation deadlines for all those requests is at most 'confirmationTolerance' apart. The correct domain ID is set for the expected confirmation on the action box sent to the participant. When matching metadata and action boxes, a participant checks all sub-actions of the same domain. If the participant is an intermediary, it also performs this check for all sub-actions of other domains using the "allStakeholders" list sent via the corresponding domain. (The list of expected reviewers is checked for all sub-actions in any case.)

[0316] Participants send acknowledgments to pseudonyms from the list "allStakeholders", which verifies that they receive the expected acknowledgments from all domains. The multi-domain data md includes an acknowledgment tolerance when generating an acknowledgment. data MultiDomainConfirmationData = MultiDomainConfirmationData { confirmationTolerance :: TimeDistance }

[0317] In the case of competing transactions, multi-domain transactions are always processed according to the pessimistic rejection rule, even if conditional verdicts are used for single-domain transactions.

[0318] As a result, if the logical timestamp of a multi-domain transaction falls between the logical time and confirmation deadline for another (single or multi-domain) transaction, the multi-domain transaction is summarily rejected, making it a second-class citizen, especially since multi-domain transactions generally have a longer logical time offset.

[0319] Processing Acknowledgments A confirmer (such as a participant's node 811, 819 acting as a receiving node) processes an acknowledgment exactly the same as a single-domain transaction, except that every participant further verifies that the multi-domain data in the acknowledgment contains the same acknowledgment tolerances that the participant received in its resource request 831, 835. A participant considers a transaction to be finally approved in a given domain 803, 805 if all expected acknowledgments have arrived through this domain. In particular, if a participant appears under different pseudonyms in different domains, the participant must act with respect to final acknowledgment as if the participant were two separate entities. Thus, a participant may consider a transaction to be finally approved in one domain (e.g., 803) while the transaction is still pending in another domain (e.g., 805). In particular, a participant may base its decision regarding subsequent acknowledgments on final acknowledgment in one domain, while it must not do so in other domains. Nevertheless, the semantics of single-domain transactions guarantees that all stakeholders of a contract agree on its state, since the contract can only exist in one domain. Furthermore, the different states associated with a contract will converge by the time the most recent decision time has passed, barring timeouts, disputes, and crashes.

[0320] A participant node considers itself a relay if it considers itself a relay for any of the views it has received. When a relay receives an acknowledgment from a domain, it performs the same checks as in the single-domain case. In addition, it does the following: The intermediary collects acknowledgments from all domains. When a sufficiently large number of acknowledgments arrive from one domain (as determined by the list of expected acknowledgments), the relay transmits all acknowledgments to all participants in other domains. Because any participant connected to multiple domains acts as if it were a separate entity in each domain, the relay MUST NOT omit pseudonymous participants in other domains, even if they are contract stakeholders.

[0321] Because the submitter generated pseudonyms for all relays for all domains, all relays receive all acknowledgments and can therefore forward them. Relays can also forward acknowledgments immediately instead of first collecting them and then sending them in a single batch. To avoid unnecessary traffic, a relay only forwards acknowledgments to domains for which it has not yet received an acknowledgment. Because all forwarding races against each other, the same acknowledgment may be sent several times on a domain with different timestamps. Everyone may ignore forwarding acknowledgments with later timestamps.

[0322] Cross-domain atomicity In some cases, acknowledgements 851, 852 must be sent by the local acknowledgement deadline 845, 846. Responses from other domains only need to arrive by decision time 847, 848. These two timestamps represent the end of two phases of the two-phase commit protocol: all participants must send their readiness to commit to the submitter by the acknowledgement deadline, and they may expect to commit or abort by decision time 847, 848.

[0323] Classic two-phase commit protocols cannot combine hard timeouts with atomicity. As a result, a multi-domain transaction may execute nonatomically if some acknowledgments are not forwarded (851, 852) to all domains 803, 805 before the domain-specific decision times 847, 848. In an introductory example, assume that submitter 815 delays participant 1 811's confirmation of PL1 and forwards 854 the submitter's confirmation to domain 805 until after domain 805's decision time 847. Participant 1 811 and submitter 815 then consider the transaction in domain D1 approved. In contrast, participant 2 819 may consider domain D2's confirmation PL1 854 to have timed out and file a dispute against the submitter. Depending on the dispute rules of the second domain 805, the transaction may be rejected in domain 805. Thus, the transaction did not execute atomically. However, we argue that only the submitter 815 cared about atomicity in such instances, and that it was the submitter's fault that atomicity was broken. Therefore, no one can complain that the transaction was not executed atomically.

[0324] Generally, only certain parties care about the atomicity of (parts of) a transaction, not the system as a whole. More formally, tx = [a1, a2, ..., a n Let ] denote the transaction of interest. Any action a i itself generates a contract or contract c i Selection regarding i Carry out all the executions. i itself a further subtransaction tx i,j Further action with a i,j Subtransaction tx i Including etc. i The authorizers of the subtransaction txi One may care that a is executed atomically. i,j The licensee of tx i,j Pay attention to the atomicity of tx i,j tx i Since it is a subtransaction of i The licensee of tx i,j are executed atomically. For a top-level transaction tx, the submitter is responsible for its atomicity. In summary, for a (sub)transaction tx..., the submitter 815 and all authorizers 811, 819 on the path from the root to the subtransaction are responsible for the atomicity of that (sub)transaction tx. Other participants should not care whether tx... are executed atomically. In particular, if a participant is responsible for a subtransaction tx..., i1 is a stakeholder in the subtransaction tx i2 If a party is not a stakeholder in the transaction, that party may be unable to access the transaction due to the privacy model of DAML. i2 Since we can't even know about tx i2 executes atomically. The submitter only cares that all top-level actions execute atomically.

[0325] Furthermore, assuming that j ≠ k, the parties involved i,j and a i,k Although the authorizer of a i If a participant is not the authorizer of a transaction, then that participant must not care whether the two sub-actions are performed atomically or not. In particular, such a participant need not be an intermediary.

[0326] Given this notion of atomicity, any participant can itself guarantee the atomicity of the subtransactions to which it pays attention, as the following discussion shows. A participant considers the atomicity of a multi-domain (sub)transaction tx to be broken if one subtransaction tx1 of tx is approved in some domain (e.g., the first domain D1) and another subtransaction tx2 of tx is rejected in another domain (e.g., the second domain D2). Because the single-domain subprotocol guarantees completeness and atomicity within one domain, we do not need to consider D1 = D2 or tx1 = tx2, i.e., conflicts involving a single domain or a single subtransaction. In particular, we can ignore participants that are not intermediaries. Therefore, D1 ≠ D2, and consequently, tx1 ≠ tx2. An atomicity violation is possible only if all expected confirmations for the entire transaction tx arrive at domain D1 but not at D2. It is sufficient to show that participants avoid this situation by forwarding their confirmations in time. tx i Let D be any subtransaction whose acknowledgment arrived at D1 but not at D2. i But, tx i Let D represent the domain to which the intermediary is being sent. Since the intermediary is connected to all domains involved in the transaction, the intermediary, in particular, i The relay is connected to D i Since the intermediary receives the resource request and payload request via i Part of the "allStakeholders" list sent via tx i Confirmations regarding domain D1 have arrived at D1, and those confirmations will be sent to D1 before the confirmation deadline. i Assuming the message broker implements the messaging API correctly, the intermediary receives these acknowledgments in time. The intermediary forwards these replies to all domains, in particular D2. Thus, the replies arrive at domain D2. It remains to show that the intermediary can forward the acknowledgment in time (as measured by the message broker in D2). confirmationDeadlinei +Δmax + skew before the domain D i Therefore, if a participant forwards their acknowledgments immediately, they receive their acknowledgments from confirmationDeadline i + 2*Δmax + skew The message broker at D2 receives the message before the message broker at D2 receives the message. While processing the acknowledgment, the intermediary confirmationDeadline i ≦confirmationDeadline2+ confirmationTolerance 2 *Δmax + confirmationTolerance + skew≦confirmationDeadlineOffset2 We verified that decisionTime2 = confirmationDeadline2 + confirmationDeadlineOffset2, so we have the desired relationship confirmationDeadline i + 2 *Δmax + skew≦decisionTime2 It has.

[0327] Timeouts in multi-domain transactions It is the submitter 815 that selects the parameters that selects the timeouts in the various domains 803, 805. The submitter 815 is therefore responsible for transferring acknowledgments (853, 854) between domains, as it should select parameters that allow the submitter 815 to actually accomplish the transfer within the timeouts that the submitter node 815 sets for itself. All other participants 811, 819 in the transaction simply check whether the submitter 815 has selected timing parameters that are likely to allow them to perform their respective tasks in time and to follow through on their interests in the transaction.

[0328] Nevertheless, timeouts can occur. Participants 811, 819 only become aware of the multi-domain nature of the transaction when they receive the confirmation payloads 833, 837, since this is when the list of expected confirmations and the list of request IDs are sent. Therefore, this section focuses only on timeouts of the acknowledgements 851, 852 and ignores timeouts of the request payloads.

[0329] If a participant 811, 819 notices that a confirmation for the same domain is missing from a participant by the confirmation deadline 845, 846, the participant 811, 819 can file a dispute in the appropriate domain, just as with a single-domain transaction. If a participant notices that an acknowledgment is missing from another domain, the participant 811, 819 can file a dispute against the submitter 815 in the local domain 803, 805. This makes the submitter 815 the node primarily responsible for forwarding the acknowledgment (853, 854) across domains 803, 805. Conversely, all other intermediaries may do so for their own benefit, but are not obligated to do so. For example, a dispute may be directed at the submitter 815 if a participant in another domain failed to send its confirmation in time, even if it is not the submitter's fault.

[0330] The submitter 815 can then itself initiate a dispute in the other domain. Even if the submitter wins the latter dispute and loses the former, the submitter runs the risk that the effects of the two disputes will not cancel each other out.

[0331] If a timeout occurs, the transaction may not be executed atomically. As discussed in the previous section, every participant 811, 819 can guarantee the degree of atomicity that it cares about. However, a participant 811, 819 may be involved in several domains 803, 805 of a multi-domain transaction and still not care about that atomicity (e.g., because all of its views are executed in a single domain and therefore it is not an intermediary). In such a case, the participant 811, 819 may observe that the transaction is not atomic.

[0332] Depending on the rules of the dispute, participants 811, 819 may have to consider both successful and unsuccessful transactions. More precisely, any impact of a transaction (a contract being created or realized) is bound to the domain in which it resides. The impact occurs as soon as the transaction is approved in the domain in which it resides, regardless of the outcome of other domains.

[0333] However, timeouts do not create an opportunity for double spending; that is, when every contract is only in a single domain 803, 805, the two transactions involved in a double spend must be executed in the same domain. Since all stakeholders always agree on the state of the contract, all stakeholders must lie about the outstanding contract with respect to the second transaction.

[0334] Detecting fraud within multi-domain transactions As with single-domain transactions, participants can commit fraud within multi-domain transactions. This section identifies cases of fraud that are unique to multi-domain transactions. Countermeasures against possible fraud in single-domain transactions remain the same.

[0335] i. Inconsistent Information Because the resource request 831, 835 and request payload 833, 837 messages are split across domains 803, 805, the messaging API can no longer guarantee that all participants receive the same parts of the message. In particular, it is possible that the submitter 815 sends inconsistent information to different domains 803, 805. Participant nodes 811, 819 can detect the inconsistency and raise appropriate disputes in their domains. Dispute rules still need to be extended to apply to all these cases. LET: Every participant includes the LET from the payload request in its acknowledgment. When a participant processes the acknowledgment, it verifies that the LET is the same as the LET it saw. If the submitter sends a LET with a different view, at least all intermediaries notice the difference. (If none of the intermediaries check, non-cheating participants don't care about atomicity, i.e., LET consistency.) Remote Request IDs: All participants derive a transaction identifier from all Request IDs and use that transaction identifier in their acknowledgements. If participants receive a different list of Request IDs, the derived transaction identifiers will be different. Therefore, other participants will not recognize these acknowledgements and will file a dispute (either for malformedness or missing acknowledgement) against the participant (same domain) or the submitter (other domain). In the same domain case, this can only happen if the message broker does not implement the messaging API as specified. Expected confirmation: Every confirmation contains a hash of the expected confirmation. Different lists of expected confirmations will have different hashes, thus creating a dispute about a malformed confirmation. Acknowledgment tolerances: Acknowledgment tolerances are included in the acknowledgment, and participants verify that the values ​​in the acknowledgment are the same as the resource requests they received. Different acknowledgment tolerances therefore result in disputes about ill-formed acknowledgments.

[0336] ii. Malformed parameters In a multi-domain transaction, the submitter specifies the following parameters in addition to those for a single-domain transaction: Timing parameters "confirmationDeadlineOffset" (per view) and "confirmationTolerance" Domain ID in expected confirmation Remote Request ID

[0337] The "confirmationDeadlineOffset" is chosen per domain, while the other parameters are chosen for the entire transaction. These parameters are subject to constraints that every participant checks while processing a confirmation request. If the constraints are violated, the participant will raise a dispute against the submitter for a malformed message at the domain where the malformed message was sent.

[0338] Most checks involve only the participants' local knowledge and can therefore be performed reliably. The only exception is checks performed by relays for views with subviews from different domains. If the relay does not receive messages from other domains that it needs to check by the confirmation deadline, it sends a rejection. However, checking that the physical timestamps are at least skew + "confirmationTolerance" + Δmax before all confirmation deadlines ensures that, under normal network operation, the relay has received all required messages by the confirmation deadline. If this is not the case, the relay may dispute the absence of a request payload against the submitter. The check also ensures that all non-cheating relays reach the same verdict, regardless of network delays. (If a resource request takes longer than skew + "confirmationTolerance" + Δmax to travel from the message broker to the relay, the relay should dispute the SLA with the message broker or its ISP.)

[0339] Every stakeholder in a contract further checks that the view is sent through the correct domain. It is possible for an input contract to not be in its domain upon execution. This can happen under normal operation, i.e., without malicious intent. If this check fails, no dispute is raised. Instead, the stakeholder sends a denial containing the current residence of the contract, similar to the domain change protocol.

[0340] Interaction with domain changes Atomicity places a burden on intermediaries in multi-domain transactions because they must actively ensure that confirmations are forwarded in time. Therefore, participants 811, 819 may want to refrain from acting as intermediaries in any multi-domain transactions. However, participants cannot guarantee this unless they are connected to only a single domain.

[0341] Identity Manager and Multiple Domains One or more identity manager nodes 170, 270 may be provided, and in some examples, different domains have their own identity managers 170, 270. The identity manager nodes (and the identity manager system in general) may have the same trust and topology as a synchronization system. The system may be configured so that domains can be created by any node, and any participant node can connect to any domain as long as the participant has authorization from the domain's operator. That is, the system does not have or require a single global identity manager.

[0342] Each participant node 110, 120, 210, 220, 811, 815, 819, external node 130, 230, 813, 817, and / or intermediary 280 may have a local component called an identity provisioning service client (IPS client). The IPS client establishes a connection with an identity manager 170, 270 to read and verify domain (and / or participant) identity information. The IPS client exposes a read API that provides aggregated access to domain topology information and public keys provided by one or more domain's identity managers 170, 270.

[0343] The identity manager 170, 270 receives keys and certificates through some process and evaluates the justification before presenting the information to the IPS client of the participant node or other domain entity. The IPS client verifies the information. A local consumer of the IPS client's read API trusts the provided information without verifying the justification, leading to a separation of synchronization and identity management.

[0344] The identity managers 170, 270 and IPS clients may be designed with one or more of the following considerations. Mapping of participants to participants. Query the state at a particular time, associate a known identifier of a participant with a set of participants, and subscribe to a stream of updates that associates a local participant with a set of hosted participants. Mapping to a set of participants satisfies the high-level requirements for a party that uses multiple participants. Participant eligibility. I subscribe to a stream of updates that inform me about the trust level of participants, querying their status at a particular time and indicating whether they are untrusted (trust level 0) or trusted (trust level 1). Participant Relationship Qualification: The relationship between the participant and the stakeholder is qualified and limited to submission (including review), review, and observation (read-only). This also satisfies the high-level requirement for a read-only participant. Domain-aware mapping of participants to keys: query the state at a particular time and subscribe to a stream of updates that map participants to a set of keys, one per synchronization domain. Domain entity keys. Query the current state and subscribe to a stream of updates about domain entity keys. Key lifetime and purpose. For any key received, know what the key can be used for, what cryptographic protocol it relates to, and when it expires. Signature verification: Given a blob, a key obtained from the IPS, and a signature, verify that the signature is a valid signature for the given blob, signed by the respective key at a particular time. Immutability. The history of all keys is kept for the same time period as the audit log so that it can be used to audit the logs of participants or domain entities. Evidence. For any data received from the identity manager, obtain a set of relevant evidence to prove a claim in a legal dispute. The relevant evidence includes descriptors that can be used to read and examine material related to the definition of an otherwise opaque blob. No race conditions: Ensures certainty about the validity of the keys associated with a transaction so that there can be no disagreement about the validity of a transaction due to an in-flight key change. Querying about Parties. Use opaque query statements to query the identity manager about parties and receive results based on privacy policies unknown to the particular participant node / IPS client. Participant Metadata. Access metadata related to participants for display purposes. · Peer trust assumption. A federation protocol for reference identity management services must be based on an interoperability protocol and a peer trust assumption so that there is no mismatch between the capabilities of the two parties.

[0345] An identity manager system can be constructed with the following additional considerations: The synchronization protocol is separate from the identity protocol. However, to take advantage of the composability properties of the synchronization protocol, an equivalent approach is needed for identity. Thus, given that in some cases there is no single globally trusted entity that can be relied upon for synchronization, similarly, in some cases it is not possible to have a single globally trusted entity for establishing identity, which leads us to the first principle.

[0346] For global synchronization to actually work, there cannot be a single trust anchor.

[0347] A cryptographic key pair can be uniquely identified by the fingerprint of the public key. By possessing the associated private key, an entity can always unambiguously prove by signature that it is the owner of the public key. This principle is used in the system to verify and authorize the activities of participants. Therefore, we can introduce a second principle:

[0348] A participant is someone who can make an authorization and whose authorization can be verified (by someone using a known key).

[0349] That is, participants are entities / nodes that have a key or a set of keys that are known to constitute a group. However, this is not necessarily the same as knowledge of who owns the keys. Ownership is an abstract aspect of the real world and is not important to the synchronization itself. Real-world ownership is only important to interpreting the meaning of some shared data, not to interpreting the meaning of the data processing itself. This leads to the third principle:

[0350] Separate proof of system identity and legal identity (or separation of cryptographic identity and metadata)

[0351] Cryptographic keys can be used to build chains of trust by having the key sign certificates that attest to some ownership or fact associated with another key. However, at the root of such a chain there is always a root key. The root key itself is not certified and legal ownership cannot be verified; participants just need to trust it. As an example, when an entity looks at the local certificate store on its device, it needs to trust that a particular root is owned by a named certificate authority. Such trust is rooted in trust in the operating system provider that it has included only legitimate keys.

[0352] Any link between a legal identity to a cryptographic key by way of a certificate is therefore based on trusting that the entity controlling the root key is innocent, with the assurance that anyone tied to the root of trust has been appropriately vetted. Thus, while an entity may need to trust that a legal identity is properly associated, it is very difficult, and especially impossible, to be sure of this in an absolute sense, online.

[0353] Another related aspect is that the identity requirement is an asymmetric property. Large corporations want to be known by their name (BANK), while individuals tend to be more closed off and prefer their identity to be revealed only when absolutely necessary (GDPR, HIPAA, confidential information, bank secrecy). Also, by looking at, for example, a bearer bond, the owner has a much higher interest in the debtor's identity than the debtor has in the owner. If the debtor turns out to be a bad person or a fraudster, the owner may lose their money and investment funds. In contrast, the debtor could care less about who the debtor is repaying the bond to, except for some regulatory reasons. Hence, we get the fourth principle:

[0354] Identity on the ledger is an asymmetric issue where privacy and disclosure must be carefully weighed on a case-by-case basis.

[0355] To build a global, composable identity system, identity schemes need to generate globally unique identifiers. This allows global systems to avoid federations, which require cooperation among identity providers or agreement among all participants and are difficult to integrate with synchronization protocols.

[0356] We use `.key` to refer to a public / private key pair for some cryptography method.

[0357]

number

[0358] where the superscript x gives the context of the key's use and the subscript k is used to distinguish between keys.

[0359] From now on, we will call the key pair (p k , s k ) to point to the public key fingerprint I k = fingerprint(p k ) is used. Based on this, we k , respectively, (p k , s k ) will be used below as the identity's root key pair. There can be multiple of them, and we make no statements about who the owners of such keys are.

[0360] Here, we use a tuple (X, I) as a globally unique identifier. k ) and I k refers to the already introduced fingerprint of the root key of identity, and X is some abstract identifier that, in principle, we can verify equality. Thus, X = Y and I k = I l If (X, I k ) = (Y, I l ) Identifiers are globally unique by definition, meaning that there can be no collisions, since we defined that if two identifiers collide, they are equal by definition. Therefore, the identity key I k spans a namespace and ensures that there are no definitional conflicts within that namespace.

[0361] The unique identifier within a project in the example Scala code is defined as follows: / ** The namespace spanned by the public key fingerprint. * *This is based on the assumption that the fingerprint is unique for the public key* / final case class Namespace(fingerprint: Fingerprint) / **Unique identifier within a namespace* / final case class UniqueIdentifier(id: Identifier, namespace: Namespace) {

[0362] We use a globally unique identifier to identify participant nodes N=(N, I k ), stakeholder P=(P, I k ), and the domain entities D=(D, I k ) (i.e., X is (X, I k )). For the parties P and participant nodes N, we should use sufficiently long random numbers for privacy reasons. For the domains D, we use readable names.

[0363] Building alternative domains The above disclosure specifies that each domain may include a set of components for conducting transactions within or among that domain. For example, a domain may include a sequencer or external node (e.g., nodes 130, 230, 813, 817, 1018) for ordering transactions submitted by participant nodes within the domain (e.g., nodes 110, 120, 210, 220, 811, 815, 819), and an intermediary node 280 for aggregating confirmations within the domain and ensuring the fidelity of the confirmations. It should be understood that alternative constructions of domains are possible and are contemplated by this disclosure.

[0364] In some examples, the functionality of the intermediary node 280 may be implemented alternatively to that described above. In one example, the functionality of the intermediary node is replicated by a fault-tolerant service on a replication server (such as using Byzantine fault-tolerant state machine replication). In another example, the functionality of the intermediary node may be executed within a Software Guard Extensions (SGX) enclave of one or more nodes to provide stronger privacy and confidentiality. In some examples, such an enclave may be associated with an external node.

[0365] This disclosure contemplates that each domain or subset of domains may include a distributed system (e.g., a blockchain) running its own consensus protocol. In this case, instead of relying on a sequencer or external node (e.g., nodes 130, 230, 813, 817, 1018) to order transactions, participant nodes within a domain (e.g., nodes 110, 120, 210, 220, 811, 815, 819) may rely on the distributed system's (e.g., blockchain's) transaction ordering protocol to order and / or validate transactions submitted within that domain. Furthermore, as noted above, transactions may occur in or across different domains (e.g., multi-domain transactions). Accordingly, the synchronization protocols disclosed herein may be utilized to synchronize virtual ledgers across different distributed systems (e.g., blockchains). In that sense, the synchronization protocols disclosed herein can be constructed to synchronize different distributed systems, forming a web of different distributed systems, each running its own consensus and / or transaction ordering protocol.

[0366] Notably, such examples go beyond mere interoperability between different domains and systems: transaction protocols can remain the same to form a virtual ledger so that the domain infrastructure of a domain can be swapped or changed and different implementations of the domain can be connected.

[0367] In one example, the consensus protocol of the above-mentioned distributed systems may be a Byzantine Fault Tolerant protocol (e.g., BFT, PBFT, aBFT, etc.), the consensus protocol may be a consensus protocol used with Sybil-resistant features similar to Proof of Work (POW) or Proof of Stake (POS), or the consensus protocol may be another consensus protocol recognized in the art. Accordingly, it is envisioned that the synchronization protocols disclosed herein can synchronize transactions between different distributed systems and work in conjunction with other distributed systems (e.g., blocks) to form virtual ledgers for the different distributed systems. [Explanation of symbols]

[0368] 100 systems 102 Processes 104 Network 110 Submit Node 120 receiver nodes 122 Second receiver node 130 external nodes 140 Proposed Transactions 142 unencrypted sub-messages 144 Cryptographically protected sub-message, encrypted sub-message 150 Confirmation 152 Confirmation 160 Ledger 170 Identity Manager, Identity Manager Node 200 systems 210 Submit Node 220 receiver nodes 222 receiver nodes 224 receiver nodes 230 external nodes 240 Proposed Transactions 242 unencrypted submessages 244 Encrypted Sub-Messages 246 Encrypted Sub-Messages 250 Confirmed 252 Confirmation 260 Ledger 262 Ledger 264 Ledger 270 Identity Manager, Identity Manager Node 280 Intermediaries, Intermediary Nodes 300 examples 302 Proposed Transaction, PaintOffer Process 310 Subaction, Transfer of IOU 312 IOU 320 PaintAgree 330 Participant A 340 Participant P 342 Bank 502 processor 503 memory 504 instructions, program code 506 Data 508 Network Interface Device 509 Distributed Ledger Interface Device 510 Network Interface Device 512 User Interface 514 output 516 participants 610 Message broker of source domain, Message broker domain 1 612 Stakeholders 614 Initiator Node, Initiator 616 Message broker of destination domain 621 Transfer request 623 Transfer request confirmation 624 Transfer request 625 Transfer request TI, transfer message 630 Exclusivity Timeout 803 Domain 1 805 Domain 2 811 Participant 1 813 Message Broker 815 submission node, submitter 817 Message Broker 819 Participant 2 831 Resource Requests 833 Request Payload 835 Resource Requests 837 Request Payload 845 Confirmation Deadline 846 Confirmation Deadline 847 Decision Time 848 Decision Time 851 Acknowledgment 852 Acknowledgment 853 Transfer 854 forwarding 909 Ledger Effective Time (LET) 911 Logical Time Offset 913 Logical Time Offset 915 Confirmation Deadline Offset 917 Confirmation Deadline Offset 921 Logical Time 923 Logical Time 925 Tolerance 927 Tolerance 953 Confirmation Tolerance 1000 Single Domains 1001 Delivery vs. Payment (DvP) Example 1010 Alice 1012 Bob 1014 Bank 1016 Share Register SR 1018 Sequencer, External Node 1020 Intermediary 1031 IOU contract 1033 Stock Agreement 1035 DvP contract 1041 Transaction Confirmation Request 1051 Validity Check 1053 Validity Check 1055 Validity Check 1057 Validity Check 1061 Responses 1062 responses 1063 Responses 1064 Responses 1071 Confirmation Request 1072 Confirmation Request 1073 Confirmation Request 1074 Confirmation Request 1300 Confirmation Request State Transition Diagram 1410 First Box 1410' Box 1420 Second Box 1510 First action: Accept PaintOffer 1520 Generate PaintAgreement 1530 Action, Transfer of IOU 1540 Action, Transfer of IOU 1610 First View 1610' First view of the core 1620 Second View 1630 Third View 1700 candidate data structures 1701 Fence Painting Transactions 1710 PaintOffer Acceptance 1711 PaintOffer Acceptance 1720 IOU Transfer 1721 IOU Transfer 1730 Subviews 1800 candidate expressions 1900 candidate expressions 1913 Stakeholder Information 1923 Stakeholder Information 1933 Stakeholder Information 1950 Other Information

Claims

1. 1. A method for multi-domain transaction processing, comprising: dividing the transaction into sub-transactions, each sub-transaction including a first portion and a second portion, by an initiator node connected to the first domain and the second domain; the first portion of the transaction includes a first resource request and a first payload for a first participant; the second portion of the transaction including a second resource request and a second payload for a second participant; submitting, by the initiator node, the first resource request to a first external node of the first domain, the first resource request specifying a first resource amount needed by the first participant in a first time period; submitting, by the initiator node, the second resource request to a second external node in the second domain, the second resource request specifying a second amount of resources needed by the second participant in a second time period; determining, by the initiator node after a third period of time, whether the first resource request has been approved or denied by the first participant and whether the second resource request has been approved or denied by the second participant; based on determining whether the first resource request and the second resource request are approved or denied, (i) by the initiator node sending the first payload to the first external node and the second payload to the second external node, or (ii) aborting the multi-domain transaction process; A method comprising:

2. the first resource request is rejected by the first participant within the third period of time; or the second resource request is rejected by the second participant within the third time period; determining that the multi-domain transaction process is complete, and The method of claim 1 further comprising:

3. Aborting the multi-domain transaction process upon determining that a response to the first resource request and / or the second resource request is not received within the third time period; The method of claim 1 further comprising:

4. receiving a first response to the first resource request from the first external node prior to determining whether the first resource request is approved or denied; receiving a second response to the second resource request from the second external node prior to determining whether the second resource request is approved or denied; The method of claim 1 further comprising:

5. determining whether the first resource request is approved or denied includes determining whether the first response to the first resource request is received within the third period of time; determining whether the second resource request is approved or denied includes determining whether the second response to the second resource request is received within the third period of time; The method of claim 4.

6. determining whether the first response and / or the second response is received after the third period of time and then aborting the multi-domain transaction process; 6. The method of claim 5, further comprising:

7. determining whether the first response denies the first resource request and / or the second response denies the second resource request, and then aborting the multi-domain transaction process; The method of claim 4 further comprising:

8. the first response acknowledges the first resource request, and the second response acknowledging the second resource request; determining that 5. The method of claim 4, further comprising:

9. A method for transmitting a first payload to a first external node, comprising: transmitting the second payload to the second external node; 9. The method of claim 8, further comprising:

10. A system connected to a first domain and a second domain, comprising: one or more processors; one or more memory devices storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations involving multi-domain transactions; and the operation comprises: Dividing the transaction into sub-transactions including a first portion and a second portion, the first portion of the transaction includes a first resource request and a first payload for a first participant; the second portion of the transaction includes a second resource request and a second payload for a second participant; submitting, by an initiator node, the first resource request to a first external node of the first domain, the first resource request specifying a first resource amount needed by the first participant in a first time period; submitting, by the initiator node, the second resource request to a second external node in the second domain, the second resource request specifying a second amount of resources needed by the second participant in a second time period; determining, after a third period of time, whether the first resource request has been approved or denied by the first participant and whether the second resource request has been approved or denied by the second participant; based on determining whether the first resource request and the second resource request are approved or denied, transmitting the first payload to the first external node and the second payload to the second external node, or aborting the multi-domain transaction; Including, the system.

11. The operation is the first resource request is rejected by the first participant within the third period of time; or the second resource request is rejected by the second participant within the third time period; determining that the multi-domain transaction is to be terminated; and The system of claim 10 further comprising:

12. The operation is aborting the multi-domain transaction upon determining that a response to the first resource request and / or the second resource request is not received within the third period of time; and The system of claim 10 further comprising:

13. The operation is receiving a first response to the first resource request from the first external node before determining whether the first resource request is approved or denied; receiving a second response to the second resource request from the second external node before determining whether the second resource request is approved or denied; The system of claim 10 further comprising:

14. determining whether the first resource request is approved or denied includes determining whether the first response to the first resource request is received within the third period of time; determining whether the second resource request is approved or denied includes determining whether the second response to the second resource request is received within the third period of time.

14. The system of claim 13.

15. determining whether the first response and / or the second response is received after the third period of time and then aborting the multi-domain transaction; The system of claim 14 further comprising:

16. The operation is Aborting the multi-domain transaction upon determining whether the first response denies the first resource request and / or the second response denies the second resource request; The system of claim 13 further comprising:

17. The operation is the first response acknowledges the first resource request, and the second response acknowledging the second resource request; and 14. The system of claim 13, further comprising:

18. The operation is transmitting the first payload to the first external node; transmitting the second payload to the second external node; 20. The system of claim 17, further comprising:

19. A computer-readable storage medium storing instructions for performing a multi-domain transaction process, the instructions, when executed by one or more processors, causing the one or more processors to: Dividing the transaction into sub-transactions including a first portion and a second portion, the first portion of the transaction includes a first resource request and a first payload for a first participant; the second portion of the transaction includes a second resource request and a second payload for a second participant; submitting the first resource request to a first external node of a first domain, the first resource request specifying a first resource amount needed by the first participant in a first time period; submitting the second resource request to a second external node in a second domain, the second resource request specifying a second amount of resources needed by the second participant in a second time period; determining, after a third period of time, whether the first resource request has been approved or denied by the first participant and whether the second resource request has been approved or denied by the second participant; based on determining whether the first resource request and the second resource request are approved or denied, transmitting the first payload to the first external node and the second payload to the second external node, or aborting the multi-domain transaction process; A computer-readable storage medium storing instructions for causing a computer to perform the above.

20. When executed by the one or more processors, the instructions cause the one or more processors to: a first response to the first resource request is not received within the third period of time; or a second response to the second resource request is not received within the third period of time. and then suspending the multi-domain transaction process; or transmitting the first payload to the first external node and transmitting the second payload to the second external node; 20. The storage medium of claim 19, further comprising:

Images