US20200356991A1 - Method And Apparatus For Execution Of Atomic Transactions - Google Patents

Abstract

The present disclosure relates to methods and systems to settle a transaction involving a plurality of digital assets, comprising receiving a notification of a proposed transaction comprising a plurality of proposed component atomic transactions that atomically transfer at least a portion of the plurality of digital assets from one or more transferring nodes to one or more receiving nodes. The method further comprises at least in part determining or verifying that each transferring and receiving computer node is cryptographically authorized to receive and/or transfer at least some of the plurality of digital assets, and that each transferring and receiving computer node has a sufficient amount of the plurality of digital assets. The method further comprises sending an authorization notification to at least one execution node to transfer the plurality of digital assets from the transferring computer nodes to the receiving computer nodes to settle the proposed transaction.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• The present application is a national phase entry under 35 U.S.C. § 371 of International Application No. PCT/US2018/060132 filed Nov. 9, 2018, published in English, which claims priority from U.S. Provisional Patent Application No. 62/584,227, filed on Nov. 10, 2017, all of which are incorporated herein by reference.
TECHNICAL FIELD
• The present disclosure relates to the field of distributed ledgers. In some examples, the disclosure relates to a system and method to perform an atomic transaction of a plurality of digital assets using a distributed ledger.
BACKGROUND
• In some current distributed ledger implementations, a node due to receive a token or digital asset may have an associated technical problem in that the node may bear a risk of non-performance of a node transferring the token or digital asset. In other words, the risk may be a risk that the node obligated to deliver such token or digital asset may, for whatever reason, fail to deliver such token or digital asset to a receiving node. Such failure may be due to a host of factors, ranging from unintentional (such as system or computer failures, electrical outages, communications disruptions, or human/operator error) to intentional (bankruptcy stays or a decision to renege on the delivery).
• The associated technical problem may be exacerbated when the transfer of a token or digital asset occurs along a chain of nodes from a first node (the originator of the token or digital asset) to a last node (ultimate designated receiver of the token or digital asset). Each node, and the communication systems between each node, may become a potential point of failure. Moreover, each node in that chain bears the risk of non-performance by every other node in the chain. Any failure, whether a technical computer outage or an intentional halt to the transfer, at any node in the chain, may prevent the last node from receiving the token or digital asset.
• The associated technical problem is exacerbated when there is an exchange of two tokens or digital assets over a chain of intermediary nodes, with two or more ultimate originators of the tokens or digital assets and two or more ultimate receiver of the tokens or digital assets, with the transaction of the exchange spread over one or more intermediary nodes, where the intermediary node would only be part of the exchange by passing tokens or digital assets onwards.
• Unfortunately, should intermediary nodes be required to facilitate the transaction between/among the nodes ultimately providing and/or receiving the tokens, these intermediary nodes create additional points of failure to the system.
• Throughout the present 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.
• Any discussion of documents, acts, materials, devices, articles or the like, which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each of the appended claims.
SUMMARY
• There is provided a computer system to settle a transaction that transfers a plurality of digital assets comprising: a computational node including a processor and memory, the computational node configured to: receive a notification of a proposed transaction, wherein the proposed transaction transfers the plurality of digital assets from one or more transferring computer nodes to one or more receiving computer nodes, each of the transferring computer nodes and receiving computer nodes belonging to a network of nodes that maintain a distributed ledger, the proposed transaction comprising a plurality of proposed component atomic transactions that atomically transfer at least a portion of the plurality of digital assets from the one or more transferring nodes to the one or more receiving nodes; determine at least one digital lock associated with the proposed transaction, wherein when activated the digital lock prevents transfer of any of the plurality of digital assets to any transferring or receiving computer node that is not a participant designated to receive or transfer at least some of the plurality of digital assets for purposes of the proposed transaction; at least in part determine or verify that: each transferring and receiving computer node is cryptographically authorized to receive and/or transfer at least some of the plurality of digital assets, and that the digital lock is activated; and each transferring and receiving computer node involved in the proposed transaction has a sufficient amount of the plurality of digital assets to fulfill all of the transferring or receiving computer node's obligations under each proposed component atomic transaction involving such node; and based on the verification, send an authorization notification to at least one execution node to cryptographically unlock the activated digital lock and transfer the plurality of digital assets from the transferring computer nodes to the receiving computer nodes to settle the proposed transaction.
• In the computer system, the computational node may be further configured to determine the plurality of proposed component atomic transactions.
• In the computer system, each of the plurality of proposed component atomic transactions may be associated with one or more digital locks. In the computer system, at least a first of the digital locks may be associated with the plurality of proposed component atomic transactions that, when activated, may be operable to prevent transfer of a first subset of the plurality of digital assets in multiple proposed component atomic transactions.
• In the computer system, each of the proposed component atomic transactions, when executed, may be configured for recordation in the distributed ledger at the same time.
• In the computer system, each of the proposed component atomic transactions, when recorded to the distributed ledger, may have a common time stamp.
• In the computer system the computational node or the execution node may be further configured to: schedule the cryptographic unlocking of the activated digital lock to prevent the transfer of any of the plurality of digital assets for purposes other the proposed transaction.
• In the computer system, the distributed ledger may be blockchain and the proposed component atomic transactions may be recorded on a same block of the blockchain.
• The computer system may further comprise at least one execution node to: cryptographically unlock the activated digital lock; and transfer the plurality of digital assets from the transferring computer nodes to the receiving computer nodes to settle the proposed transaction, wherein the transfer comprises atomically executing all of the proposed component atomic transactions.
• In the computer system, the computational node and the execution node may share at least one common processor.
• There is also provided a computer-implemented method to facilitate settlement of a transaction involving a plurality of digital assets, the method comprising: receiving a notification of a proposed transaction, wherein the proposed transaction transfers the plurality of digital assets from one or more transferring computer nodes to one or more receiving computer nodes, each of the transferring computer nodes and receiving computer nodes belonging to a network of nodes that maintain a distributed ledger, the proposed transaction comprising a plurality of proposed component atomic transactions that atomically transfer at least a portion of the plurality of digital assets from the one or more transferring nodes to the one or more receiving nodes; at least in part determining or verifying that: each transferring and receiving computer node is cryptographically authorized to receive and/or transfer at least some of the plurality of digital assets; and each transferring and receiving computer node involved in the proposed transaction has a sufficient amount of the plurality of digital assets to fulfill all of the transferring or receiving computer node's obligations under each proposed component atomic transaction involving such node; and based on the verification, sending an authorization notification to at least one execution node to transfer the plurality of digital assets from the transferring computer nodes to the receiving computer nodes to settle the proposed transaction.
• The method may further comprise the steps of: determining at least one digital lock associated with the proposed transaction, wherein when activated the digital lock prevents transfer of any of the plurality of digital assets to any transferring or receiving computer node that is not a participant designated to receive or transfer at least some of the plurality of digital assets for purposes of the proposed transaction.
• In the method, the computational node may be further configured to: determine the plurality of proposed component atomic transactions.
• In the method, the computational node may determine the plurality of proposed component atomic transactions by: mapping a route for the transfer of the plurality of digital assets from the one or more transferring computer nodes to the one or more receiving computer nodes, wherein each transfer of each of the plurality of digital assets from any transferring computer node to any receiving computer node in the network comprises a proposed component atomic transaction.
• In the method, the computational node may determine the route by: testing connections between transferring computer nodes and receiving computer nodes in the network to determine which nodes support the transfer of the plurality of digital assets.
• In the method, to at least in part determine or verify that each transferring and receiving computer node has a sufficient amount of the plurality of digital assets may comprise: for a given transferring or receiving computer node that is participant to the proposed transaction: determining a sum of inbound digital assets that the given node is a participant designated to receive or transfer; determining a sum of outbound digital assets that the given node is a participant designated to receive or transfer; and determining a result by subtracting the sum of outbound digital assets from the sum of inbound digital assets.
• In the method, the result may be determined by subtracting the sum of outbound digital assets from the sum of inbound digital assets for digital assets of a same type.
• In the method, when the result is positive or neutral, the computational node may determine that the given node has a sufficient amount of the plurality of digital assets.
• In the method, determining or verifying that each transferring and receiving computer node has a sufficient amount of the plurality of digital assets may further comprise the steps of: determining an initial transferring node of the inbound digital assets to the given node; and determining whether the initial transferring node has a sufficient amount of the inbound digital assets available for transfer to the given node.
• In the method, determining or verifying that each transferring and receiving computer node has a sufficient amount of the plurality of digital assets further comprises the steps of: determining one or more initial transferring nodes that have the plurality of digital assets for the proposed transaction; and determining whether the one or more initial transferring node(s) have the respective plurality of digital assets available for transfer to the given node.
• There is also provided a computer-implemented method to facilitate settlement of a transaction involving a plurality of digital assets, wherein the transaction is based on a proposed transaction comprising a plurality of proposed component atomic transactions that each atomically transfer at least some of the plurality of digital assets from one or more transferring computer nodes to one or more receiving computer nodes, wherein each of the transferring computer nodes and receiving computer nodes belong to a network of nodes that maintain a distributed ledger, the method comprising: receiving an authorization notification to transfer the plurality of digital assets from the transferring computer nodes to the receiving computer nodes to settle a proposed transaction, wherein the authorization notification is based on a verification that: each transferring and receiving computer node is cryptographically authorized to receive and/or transfer at least some of the plurality of digital assets; and each transferring and receiving computer node involved in the proposed transaction has a sufficient amount of the plurality of digital assets to fulfil all of the transferring or receiving computer node's obligations under each proposed component atomic transaction involving such node; determining an authorization to transfer the plurality of digital assets from the transferring computer nodes to the receiving computer nodes; and based on the authorization, atomically transferring the plurality of digital assets from the transferring computer nodes to the receiving computer nodes to settle the proposed transaction.
• There is also provided a non-transitory computer-readable medium comprising program instructions that, when executed, cause a computer to perform the method as described above.
BRIEF DESCRIPTION OF DRAWINGS
• Examples of the present disclosure will be described with reference to the figures below:
• FIG. 1 illustrates an example system to settle a transaction that transfers a plurality of digital assets consistent with embodiments of the present disclosure;
• FIG. 2 illustrates an example transaction and proposed component transactions consistent with embodiments of the present disclosure;
• FIG. 3 illustrates an example of a lock contract composed in DAML;
• FIG. 4 illustrates an example method to facilitate settlement of a transaction consistent with embodiments of the present disclosure;
• FIG. 5 illustrates an example flow and transfer of a digital asset between multiple nodes;
• FIG. 6 illustrates the example flow and transfer ofFIG. 5, in accordance with the present disclosure;
• FIG. 7 illustrates an example transaction of a digital asset between multiple nodes;
• FIG. 8 illustrates a further example transaction of a digital asset between multiple nodes;
• FIG. 9 illustrates the example transaction ofFIG. 7, in accordance with the present disclosure;
• FIG. 10 illustrates an example flow and transfer in accordance with the present disclosure;
• FIG. 11 illustrates a further example transaction ofFIG. 9, in accordance with the present disclosure;
• FIG. 12 illustrates a further example transaction using a settlement facility in accordance with the present disclosure;
• FIG. 13 illustrates a further schematic of the example transaction ofFIG. 12;
• FIG. 14 illustrates a further example transaction using a settlement facility in accordance with the present disclosure;
• FIG. 15 illustrates a further example transaction using a settlement facility in accordance with the present disclosure;
• FIG. 16 illustrates an example securities lending transaction;
• FIG. 17 illustrates a further example transaction ofFIG. 16;
• FIG. 18 illustrates a further example securities lending transaction;
• FIG. 19 illustrates a further example securities lending transaction;
• FIG. 20 illustrates the example securities lending transaction ofFIGS. 18 and 19 in accordance with the present disclosure;
• FIG. 21 illustrates a further example transaction with multiple originator nodes and multiple receiver nodes;
• FIG. 22 illustrates the example transaction ofFIG. 21, in accordance with the present disclosure;
• FIG. 23 illustrates an exemplary computer node that may be used in examples of the disclosure;
• FIG. 24 illustrates a schematic of several nodes in a distributed computer network;
• FIG. 25 illustrates a further schematic of the nodes in the distributed computer network ofFIG. 23, with messaging, APIs, and additional internal node architecture illustrated in more detail;
• FIG. 26 illustrates an exemplary process for deploying or updating program instructions (e.g., a DAML contract) to a distributed ledger;
• FIG. 27 illustrates an exemplary distributed ledger network with a plurality of nodes;
• FIG. 28 illustrates a structure of a blockchain;
• FIG. 29 illustrates an exemplary Merkle Tree data structure; and
• FIG. 30 illustrates an exemplary efficient lookup of data in a Merkle Tree.
DESCRIPTION OF EMBODIMENTS
• The present disclosure relates to a distributed ledger implementation for performing an atomic transaction of a digital asset. Below, the disclosure first provides exemplary distributed ledger implementations that may be utilized with the aforementioned atomic transaction, and subsequently a system and method for performing such an atomic transaction along with the distributed ledger implementations.
• A distributed ledger is a record of transactions or other data, which exists across multiple distinct entities in a network. The ledger may be wholly replicated across participants, or segments may be partially replicated across a subset of participants. In either case, the integrity of the data is ensured in order to allow each entity to rely on its veracity and to know that data they are entitled to view is consistent with that viewed by others entitled to view the same data. This makes the distributed ledger a common, authoritative prime record—a single source of truth—to which multiple entities may refer and with which they may securely interact.
• Distributed ledger technologies (“DLT”) have expanded beyond mere transaction registries to include other forms of data and encoded business logic, sometimes referred to as “smart contracts”. This means that not only does the technology synchronize the record of who owns what, but also provides an automated common workflow for processing that data, ensuring that the results of agreements are processed in the same, mutually agreed manner.
• Several examples of DLT, which may be utilized with the presently-disclosed embodiments, are described below. The first example is an implementation that has a platform architecture, which includes a distributed ledger having a global synchronization log (GSL) and private contract store (PCS). The ledger may operate in conjunction with encoded business logic (e.g., smart contracts), e.g., with a modelling language referred to as the Digital Asset Modelling Language (“DAML”). Certain aspects of DAML are described in more detail in WO 2017/189027 and WO 2017/187394, while certain aspects of a distributed ledger as described above may be found in WO 2018/013124 and WO 2018/013934, the disclosures of which are hereby incorporated herein in their entireties. The second example is an alternative implementation of DLT that may be used with the presently-disclosed embodiments. The leger may additionally have features that enable the locking of tokens and other digital assets to a specified purpose (“Locking”). Certain aspects of Locking are described in more detail in PCT/US2018/044682, the disclosure of which are incorporated herein in their entirety.
Distributed Ledger Architecture
• A first example of a distributed ledger that may be used along with the presently-disclosed embodiments maintains confidentiality while allowing for the same data integrity assurances of typical blockchain solutions. This may be achieved by the parties involved physically segregating and storing locally confidential contractual information, and sharing a globally replicated log of only fingerprints, or “hashes”, of sensitive data and execution commitments. These hashes are one-way cryptographic functions which may be proven to accurately match a party's data, but do not contain any information about the confidential data itself nor the parties involved.
• The distributed ledger may be implemented by way of asystem2001 as shown, for example, inFIGS. 24 and 25. Thesystem2001 may include multiple layers, such as anApplication layer2003, aBusiness Logic Layer2005, and a distributedledger2007 layer as illustrated inFIG. 24. Each layer may have its own communication channels2009. The distributedledger2007 may be a permissioned ledger, meaning it is a ledger accessible (for reading or for writing) only by known and pre-approved parties. This differs from a permissionless ledger, where anyone is permitted to read or write to the blockchain. The distributedledger2007 may include multiple subcomponents, including a Global Synchronization Log (“GSL”)2013 and a Private Contract Store (“PCS”)2015. ThePCS2015 can, for example, be a private data store that is segregated from theGSL2013. As used herein, “segregated” means that data included in thePCS2015 is not recorded in theGSL2013, but rather is kept in a separate, private data store. As explained in more detail below, the use of aPCS2015 may serve to enhance privacy of the distributed ledger for participants in the network.
The DistributedLedger2007,GSL2013 andPCS2015
• Thesystem2001 may maintain privacy for participants by concealing private data from other participants in thePCS2015 while providing aGSL2013 with public data which may be used to verify information and the integrity of information. Accordingly, the distributed ledger technology ofFIG. 24 may provide technical improvements over extant distributed ledgers with regards to accuracy of the information stored thereon. Moreover, the distributed ledger technology ofFIG. 24 may provide improved user experience over extant distributed ledgers with regards to privacy.
• Unlike a network of segregated ledgers that lacks a global arbiter of truth where the system cannot guarantee network participants integrity of the complete set of relevant data, the present disclosure may utilize aGSL2013, which may maintain confidentiality of the physically segregated ledgers (such as each party's individual PCS2015) while also serving as a global arbiter of eachPCS2015.
• For example, theGSL2013 may be a shared and globally replicated log that allows for private data stored in one ormore PCSs2015 to be synchronized. Accordingly, theGSL2013 may provide a mechanism by whichPCSs2015 may maintain accurate and up to date data. In some embodiments, theGSL2013 does not cause an update of data stored in thePCS2015 to occur (although it may in some examples). Instead,G S L2013 may allow aPCS2015 to be made to be consistent with the public data on theGSL2013, as well as the private data of other participants (e.g., stored in another PCS2015). For example, if a node (or participant in communication with a node) determines there is private data that needs to be updated, then the node may request such data. In some embodiments, synchronization does not mean that aPCS2015 must store the same data as another PCS2015 (such as that of another node), although such synchronization may occur. As used herein, “synchronization” includes any arrangement in which private data stored in thePCS2015 is provably consistent with the public data in theGSL2013 and that inconsistencies with the public data may serve as notice to the nodes and/or participants that private data should be updated.
• Althoughsystem2001 may be used for synchronization of any kinds of private data, in the context of the present disclosure it is generally used as a synchronized system for locking digital assets for settling transactions involving those digital assets. The details concerning locking of digital assets for purposes of committed settlement of transactions is discussed in more detail below.
Nodes and Participants in theSystem2001
• In the present disclosure, reference is made to a node in a number of contexts. As used herein, a “node” may refer to a computer or system that interacts with a computer and interfaces with the distributed ledger. Nodes may be operable in different modes including but not limited to: Reader Mode, Writer Mode and Auditor Mode. Each of these modes may give a different level of access to theGSL2013 and associatedPCS2015 of the distributedledger2007.
• As illustrated inFIG. 25, a node, e.g.,nodes2018,2020, and2024, may comprise, or be connected to, one or more participants, e.g.,participants2017,2019,2021, and2023. There may be several types of participants in thesystem2001.
• A network participant, e.g.,participant2017,2021, or2023, may be a participant in the system that operates a node, e.g.,node2018,2022, or2024. A participant may be considered a direct participant when it has direct access to read or write to theGSL2013. In the example of a financial market,market operators2019,2023 may operatenodes2020,2024 and may also be responsible for maintaining the rules of the market.Market operators2019,2023 may further govern access to theGSL2013. This globally replicated log may be a permissioned ledger, meaning it is a ledger accessible (for reading or for writing) only by known and pre-approved nodes with associated participants.
• Another type of participant may be an indirect participant. The indirect participants may not operate a node and therefore may connect to the network through interfaces operated by others. Indirect participants may delegate actions on theGSL2013 to a third party who interacts with theGSL2013 on their behalf.
• Private data may be data that is private and confidential to a participant and, where the node associated with the participant, maintains privacy for the participant. Private data of a participant may be stored in confidence, with the authority of the participant, by other nodes. The private data may be stored in arespective PCS2015 of a node to maintain confidentiality of the data.
• Each network participant, e.g.,participant2017,2021, or2023, may have its own PCS, which contains all validated contracts to which the participant is a party. In this context, the term “contracts” refers to business logic, including transaction parameters, rights and obligations, reflecting the encoded terms of legal agreements by which participants are bound. Business logic may be composed using DAML, and thus may include program instructions that are representative of legal or other agreements between participants to the network. Accordingly, program instructions that may be executed by the node may be stored in the node'sPCS2015. ThePCS2015 may be stored locally and only contain those contractual agreements that the participant is entitled to store and view. ThePCS2015 may be a durable store of the codified contractual relations between parties. It may not process the executable business logic itself, which instead may be performed at theBusiness Logic Layer2005. Therefore, theBusiness Logic Layer2005 may execute the program instructions constituting the contractual relations between the parties rather than such execution happening in a node'sPCS2015. ThePCS2015 may contain a historical record of all executable contracts (both active and inactive) pertaining to a participant, but this segment of the distributed ledger, in some examples, cannot be constructed from the contents of thePCS2015 alone. To construct the historical record, in certain examples, contracts stored within thePCS2015 may be paired with corresponding active evidences stored in theGSL2013.
• When a node, e.g.,node2018,2020,2022, or2024, is operable in a reader mode, referred to herein as a reader node, the reader node may become a network node that acts on behalf of participants that might be involved in some contracts or for supervising authorities. The reader node may monitor for notifications on behalf of its served participants on theGSL2013, and may aggregate a partial database of private data. In some embodiments, some network participants only have reader mode permissions—forexample participant2017 andcorresponding node2018 may only read theGSL2013 to verify private data.
• When a node, e.g.,node2020 or2024, is operable in a writer mode, referred to herein as a writer node, the writer node may record evidence intoGSL2013. The writer node may also guarantee the contradiction-less recording of evidence and, as a consequence, may have full access into private data that it records as public data. The role of the writer node may be shared by several nodes, such that a write to theGSL2013 requires joint authorization, at least in certain scenarios. In some examples, this joint authorization may be arrived at using a consensus protocol, as detailed below. In other examples, a participant who is an operator (e.g.,participant2019 or2023) may run a node (e.g.,node2020 or2024) that is both a writer node and a reader node in order to be able to submit data on its own. Alternatively, a participant who is an operator may operate multiple separate nodes: one of which may be a writer node, the other of which may be a reader node.
• A third mode is that of an “auditor” node. An auditor node may be a node authorized to run in auditor mode, which may have access to private data for the purposes of determining the integrity of at least part of the data in thesystem2001. An auditor may have partial access to private data to ensure the integrity of theGSL2013 is maintained. An auditor node may be associated with an auditor participant (such as an official auditor) who utilizes the auditor node to perform integrity checks on the data in the system. The “auditor” node may be associated with participants that have an interest in ensuring the integrity of the data such as a regulatory authority, market operator, or other authorized person.
DAML Contract and Data Propagation
• The process of a node committing a DAML contract to the distributedledger2007, or updating data stored in a DAML contract or updating the DAML contract itself, is described below with reference toFIGS. 26 and 27. The process described below may be utilized to deploy initial DAML lock contracts, as described herein, and/or update data in DAML lock contracts or the DAML lock contract itself. Updating a DAML contract itself refers to deploying a new, updated version of the DAML contract to the network in place of a prior DAML contract that has been archived, as described herein.
• When data is available, a node(s) of therespective participants2017,2019,2021,2023,2025 may send a DAML Command via the Platform API ofFIG. 25 to its DAML Execution Engine (“DAMLe”)2031, which is interpreted byDAMLe2031 and translated into a transaction(s), as depicted in Steps01-04 ofFIG. 26. A DAML Command may constitute an API request (e.g., to the Platform API ofFIG. 25) to execute certain DAML program instructions or code. In that sense, a DAML Command may constitute an API request that contains a data payload instructing a node(s) to execute certain DAML code and cause an update to theGSL2013 and/orPCSs2015 of affected parties. In some cases, this may take the form of updating data in a DAML contract, archiving and replacing a DAML contract with a new version of such contract, or more generally executing code in a DAML contract or series of related DAML contracts that causes state updates to occur to theledger2007. TheDAMLe2031 may constitute a runtime environment for execution of DAML code.
• The DAML Command and the transaction(s) may be sent to a writer node(s)2020,2024, for instance using thecommitter API2033 ofFIG. 25, as depicted inStep05 ofFIG. 26. The transaction(s) may be a message to the writer node(s)2020 to exercise a choice (e.g., execute a certain code segment) on a contract that has been previously deployed, which defines the rights and obligations of parties in the network. For instance, the message may be to execute a certain code segment in a DAML contract that modifies some data set forth in the DAML contract, executes a transaction (e.g., trade), deploys another DAML contract, or another function capable of being modelled in DAML. The message sent to the committer node(s)2020 may contain an event that archives an original instance of the DAML contract, and creates a new instance of the DAML contract with new data, or creates an entirely different DAML contract or series of contracts representing the parties' agreement.
• The writer node(s)2020,2024 may interpret the DAML command (as depicted in Step06) to confirm that the transaction it received inStep05 is valid. For instance, the writer node(s)2024 may validate, by running the DAML Command received by the node(s)2018,2022 in its own DAMLe, among other things, that the message sender has the right to see the original DAML contract, the sender has a right to execute the relevant code segment that forms part of the DAML contract, any new transaction(s) signatories may be bound/placed into an obligable position, the DAML was correctly interpreted, and the most-recent version of DAML was used. The writer node(s)2020 may also ensure the original DAML contract has not already been archived by a prior transaction, and determine who should be notified of the transaction, once it has been recorded to the distributed ledger2007 (e.g.,GSL2013 and/orPCSs2015 of relevant parties).
• Once validation is complete, the writer node(s)2020 may store the new DAML contract in its PCS2015 (as depicted in Step07 ofFIG. 26) and add the aforementioned transaction to its transaction buffer (e.g., Transaction Mempool ofFIG. 25) for eventual commitment to theGSL2013. The transaction may be added to the Transaction Mempool along with other transactions, which ultimately may be combined in a block of theGSL2013. As detailed above, the transaction may include a cryptographic representation (e.g., a hash) of events caused by execution of a code segment of a DAML contract. These events may include the creation of new DAML contracts or the archival of outdated contracts. The hash of the transaction may be combined with other transaction hashes, which may be hashed once more in a repeating cycle to form a Merkle tree (e.g., similar to the example shown inFIG. 29). Either the passage of a set amount of time or exceeding a maximum transaction limit in the Mempool may trigger the writer node(s)2020 to produce a new block on the GSL and notify relevant participants. The new GSL block may contain a Merkle root (i.e., root of a Merkle hash tree, for instance as shown inFIG. 29) of all the transactions in the current Transaction Mempool, including the transaction created above. The block may also contain a sorted Merkle root of all notifications that must be sent to all relevant parties and/or all notifications that may be sent to one or more relevant parties.
• An event may be broadcast on the GSL2013 (as depicted inStep08 ofFIG. 26) and a private notification, cryptographic proof and transaction details sent by the writer node(s)2020 to appropriate Network Participant node(s)2018,2022 (as depicted inStep09 ofFIG. 26). Whether or not a participant/node in the network receives the aforementioned private notification (as depicted inStep09 ofFIG. 26) may depend on whether the participant/node is a stakeholder on the new DAML contract. A stakeholder may include (1) obligable parties (e.g., signatories/owners of the contract or parties being bound by the execution of a code segment of the DAML contract), (2) parties having rights (e.g., parties having an ability to execute a code segment of the DAML contract), and/or (3) parties having observer (e.g., read-only) privileges to the contract. If the participant/node is a stakeholder, it may receive the private notification described above. If not, the participant/node may simply receive the GSL block. The private notification may be a message sent, via a private, optionally encrypted secure channel (e.g., through the Replicator and Block Fetcher ofFIG. 25), to stakeholders of a contract that provides:
• 1. The new GSL block,
• 2. An archival event of the original DAML contract,
• 3. The data of the newly created DAML contract,
• 4. Merkle proofs of the create and archive events, and/or
• 5. Merkle proofs of the notification of the create and archive events.
• As shown in Steps10-12 ofFIG. 26, each stakeholder'sDAMLe2013 may validate the results (e.g., using a validation process described above in ¶ [83]), store the new DAML contract in itsPCS2015, and send a DAML event to any connected applications and/or send a notification message to the stakeholder. The DAML event may be sent to any connected applications through an API so that the stakeholder or any of its applications listening for contract changes are notified of a change to the relevant DAML contract.
• Using the above mechanism, only actual stakeholders to a DAML contract may be notified of a modification to the contract (e.g., any of the data therein, execution of a code segment in the DAML contract, etc.), and any resulting smart contract may be stored in thePCS2015 of only stakeholders to the DAML contract. As such, using the private notification mechanism provided above, data pertaining to DAML contracts may be kept confidential inledger2007.
• As detailed more fully below, thesystem2001 andledger2007 may be utilized with DAML lock contracts (disclosed below) to affect transactions that provide for committed settlement of digital assets. The various DAML lock contracts may also be updated and kept confidential using the mechanisms described above.
Alternative Distributed Ledger Technology Platform
• Although the example of a distributed ledger that may be used with DAML contracts (including DAML lock contracts) described above may be used in embodiments of the present disclosure, a different distributed ledger may be utilized with the present embodiments to affect committed settlement of digital assets utilizing a distributed ledger. An example of such an alternative distributed ledger is disclosed below.
• ADLT network2101 that may be employed with the present embodiments may typically include a plurality of nodes, as shown inFIG. 27. The nodes may include “full” or “committer” nodes2120, which are nodes capable of reading and writing transactions to the distributed ledger or blockchain2107 (FIG. 28). The nodes may also include “participant” or read-only nodes2118 that may read, but not write, to the distributedledger2107 or blockchain. In one example, the network of nodes may be permissioned to control which nodes have the ability to enter the network, in addition to which nodes are read-only or are read/write nodes. A permissioned network may include a network where the ability to run a node, whether read-only or read/write, is subject to approval/permission. A permissioned network may help to provide scalability (e.g., more transactions/sec), achieve privacy, and/or improve security of a distributed ledger, such asledger2107. In another example, the network of nodes may be permissionless or a hybrid permissioned/permissionless network. In a permissionless network, anyone has the ability to run a node, whether read-only or read/write, without requiring permission by some entity in partial or full control of the network.
• For both permissioned, permissionless or hybrid networks, thenetwork2101 may utilize a consensus protocol. Examples of consensus protocols that may be used include byzantine-fault tolerant (BFT) consensus algorithms such as, for example, Paxos, Tendermint, Raft, or others, a Proof-of-Work (POW) consensus algorithm (e.g., as used in Bitcoin), a Proof-of-Stake (POS) algorithm, Practical Byzantine Fault Tolerant (PBFT) algorithms, and even other consensus algorithms. A consensus protocol may operate to keep all nodes on thenetwork2101 synchronized with each other, in terms of the state of the ledger orblockchain2107. In other words, the consensus protocol may be a protocol where nodes come to an agreement on data that may be written to the ledger orblockchain2107, so that all nodes in thenetwork2101 agree on the data—or state—comprising the ledger orblockchain2107. In certain examples, a consensus protocol may use a peer-to-peer messaging protocol (e.g., over HTTP, RPC, or another messaging protocol) to transmit messages and data between nodes and arrive at consensus. As explained further below, where a consensus protocol is used, it may assist with determining what data should be written to the ledger by all nodes in the network.
• A consensus protocol may also be utilized with thesystem2001 andledger2007 detailed previously for the same purpose—e.g., to arrive at consensus as to updates to the state of theledger2007.
• Thenetwork2101 may also include a runtime environment/execution-engine (e.g., such as DAMLe described above, a virtual machine, etc.) that permits execution of program instructions or (e.g., a smart contract written in DAML) on thenetwork2101.
• In one example, the data structure of the ledger may be ablockchain2107, as shown inFIG. 28. Ablockchain2107 may comprise a series of blocks that reference each other to form a “chain”. As shown inFIG. 28, each block that is part of the chain references its prior block by a hash of the prior block (Prev_Hash), and the block may include a Timestamp, a Nonce, and a Tx_Root, which may be the root of aMerkle tree2133 as shown inFIG. 29. In cryptography and computer science, a hash tree orMerkle tree2133 is a tree in which every leaf node is labelled with the hash of a data block and every non-leaf node is labelled with the cryptographic hash of the labels of its child nodes. Hash trees generally allow for efficient and secure verification of the contents of large data structures. Merely as an example, a detailed Merkle tree is shown inFIG. 29, and an efficient lookup2135 of data in a Merkle tree is shown inFIG. 30. Hash trees are a generalization of hash lists and hash chains.
• Alternatively, the data structure of theledger2107 may constitute a distributed ledger with a different data structure.
• An exemplary process of writing data to the ledger is now disclosed. It should be understood that the data-writing process may be used with, or interfaced with, DAML applications to update data in DAML contracts, submit transactions, or the like.
• If a particular node has data to write to the ledger, in the form of an update to a DAML contract, executing a code segment of a DAML contract, deploying a new DAML contract, conducting a transaction in DAML, or the like, the node (e.g.,node2018 or2022) may transmit the data to a read/write node for recording on theledger2007. Alternatively, if the node (e.g.,node2020 or2024) is a read/write node, it may bypass the transmission to another node. In one example, the data may be cryptographically signed using a digital signature before it is transmitted to provide data integrity. Once received by the read/write node, the data (e.g., a “transaction”) may be, in certain instances, hashed and combined with other hashed transactions in an efficient data structure, such as the Merkle tree ofFIGS. 29 and 30. Incoming transactions/data may be assembled in a “transaction memory pool” of the read/write node and, in certain examples, logically ordered according to timestamp. In other cases, the transactions might not be ordered according to time. The transaction memory pool may be a buffer or another data-storage mechanism for pooling transaction data prior to recording such data to theledger2107.
• If a blockchain data structure is used for the ledger, as shown inFIG. 28, the Merkle root (Tx_Root) may be supplied in a block along with a hash of the prior block (Prev_Hash), a block timestamp, and a nonce. A consensus algorithm may then be used by the read/write node to communicate peer-to-peer with other nodes participating in consensus to propose the block for entry into the ledger orblockchain2107. For instance, the consensus algorithm might rely on a voting process amongst a set of nodes referred to as “validators”. A block may be said to be committed by the network when a two-thirds (⅔) majority of validator nodes have cryptographically signed and broadcast commits for a particular block. When enough votes for a block are received, it may be committed to theledger2107 along with all the block's transactions. As one of ordinary skill will recognize, other consensus mechanisms (described above) may be used to determine whether to commit a block to theledger2107.
• In a permissioned distributed ledger, particular nodes may be granted permission to commit blocks to the distributedledger2107.
• In certain examples, privacy-preserving features may also be used with the distributed ledger orblockchain2107. For instance, as in thesystem2101 andledger2007 detailed above, data stores that are accessible only to a specific node (e.g., PCSs2015) may be segregated/kept private from the public-facing portion of the distributed ledger or blockchain2007 (e.g., GSL2013) and/or other nodes. The public-facing portion of the distributed ledger or blockchain2007 (e.g., GSL2013) may then be used to ensure that the private data stores (e.g., PCSs2015) of logically-related nodes (e.g., those who have engaged in a DAML contract) are consistent, with respect to DAML contracts that relate specifically to the parties.
• Other privacy-preserving techniques may include encrypting data on-chain or in the ledger, such that the encrypted data is only readable by those with the required keys. Additionally or alternatively, advanced cryptographic techniques such as Zero-Knowledge Proofs (e.g., zkSNARKs, zkSTARKs, Buletproofs, etc.), ring signatures, or other mechanisms may be used to provide confidentiality to transactions as a whole or certain portions of transactions (e.g., a transaction amount).
Overview ofSystem1
• An example of asystem1 to settle a transaction to transfer a plurality ofdigital assets7 is illustrated inFIG. 1. Thesystem1 may comprise aComputational Node3, one or more transferring computer nodes and one or more receiving computer nodes such as afirst computer node9,second computer node11 and at least oneintermediate node17. Thesystem1 may also comprise at least oneExecution Node19. Although not shown inFIG. 1,system1 may include all the components, nodes, etc. ofsystem2001 and/or2101 detailed previously.
• TheComputational Node3 may include a processor and memory. TheComputational Node3 may be configured to receive a notification of a proposedtransaction5. The proposed transaction may relate to the plurality ofdigital assets7 to be transferred from afirst computer node9 to the one or more receiving computer nodes in anetwork13. In one example, thenetwork13 may be anetwork2101 as described above. The proposedtransaction5 may comprise a plurality of proposed component atomic transactions that atomically transfers at least a portion of the plurality ofdigital assets7 from the one or more transferring computer nodes to the one or more receiving computer nodes.
• TheComputational Node3 may further be configured to determine at least one digital lock associated with the proposed transaction. The digital lock, when activated, will prevent transfer of any one of the plurality ofdigital assets7 to any transferring or receiving computer node that is not a participant designated to receive or transfer at least some of the plurality of digital assets for purposes of the proposedtransaction5.
• TheComputational Node3 may further be configured to at least in part determine or verify that each transferring computer node and each receiving computer node is cryptographically authorized to receive and/or transfer at least some of the plurality of digital assets defined in the proposed transaction. TheComputational Node3 may further be configured to at least in part determine or verify that the digital lock is in an activated state to prevent transfer of any one of the plurality of thedigital assets7. Based on the verification, theComputational Node3 may send an authorization notification to at least oneExecution Node19 to digitally unlock the activated digital lock and transfer the plurality ofdigital assets7 from the transferring computer nodes to the receiving computer nodes, which may include one or moreintermediate nodes17 to settle the proposedtransaction5.
• TheComputational Node3 andExecution Node19 may reside on a distributed ledger system as described above. The transferring computer nodes, receiving computer nodes, and any intermediary computer nodes may also reside on a distributed ledger system as described above.
• In some examples afirst computer node9 is a node of the transferring computer nodes and asecond computer node11 is a node of the receiving computer nodes. Anintermediary node17 may be an example of either a transferring computer node or a receiving computer node.
Computational Node3 Receives aProposed Transaction5
• As described above, theComputational Node3 may receive a proposedtransaction5. TheComputational Node3 may be associated with the Business Logic Engine of a node in thenetwork13, such as a transferring computer node like thefirst computer node9. In other examples theComputational Node3 may be associated with another node in thenetwork13, such as a central node orcentral committer node2020 as described above.
• In one example theComputational Node3 may receive the proposedtransaction5 from thefirst computer node9. In this example, along with or prior to sending, thefirst computer node9 may store the proposedtransaction5 in a private data store of thefirst computer node3. The private data store may be the PCS of thefirst computer node9 as described above. Similarly, theComputational Node3, upon receipt of the proposedtransaction5, may be configured to store the proposedtransaction5 in a private data store of theComputational Node3. The private data store of theComputational Node3 may be the PCS of theComputational Node3. In another example,nodes3,9 may not store the proposedtransaction5 in a private data store and may instead use other privacy-preserving mechanisms detailed herein to keep the details of the proposedtransaction5 private to the nodes.
• In other examples theComputational Node3 receives the proposedtransaction5 from another node in thenetwork13, such as a receiving computer node like thesecond computer node11. In other examples theComputational Node3 receives the proposed transaction from a central node orcentral committer node2020.
• The proposedtransaction5 may relate to a transaction between one or more transferring computer nodes to one or more receiving computer nodes, such as, e.g.,first computer node9 andsecond computer node11. This may involve transferring the plurality ofdigital assets7 from thefirst computer node9 to thesecond computer node11. In one example the proposed transaction involves transferring the plurality ofdigital assets7 indirectly between thefirst computer node9 and thesecond computer node11 via the one or moreintermediate nodes17. In this way, theintermediate node17 may act as a transferring computer node and receiving computer node.
Plurality of Proposed Component Atomic Transactions
• As described above the proposedtransaction5 may comprise a plurality of proposed component atomic transactions that atomically transfers at least a portion of the plurality ofdigital assets7 from the one or more transferring computer nodes to the one or more receiving computer nodes. This may comprise atomically transferring at least a portion of the plurality ofdigital assets7 from thefirst computer node9 to thesecond computer node11 via the one or moreintermediate nodes17.
• TheComputational Node3 may determine the proposed component atomic transactions by dividing the proposedtransaction5 into one or more proposed component atomic transactions. In one example, theComputational Node3 may determine the proposed component transactions based on the transferring and receiving computer nodes, such as thefirst computer node9,second computer node11 and the one or moreintermediate nodes17. This may involve theComputational Node3 determining or “mapping” the transfer of the plurality ofdigital assets7 from thefirst computer node9 to thesecond computer node11 via theintermediate nodes17. In this way, each individual movement of the plurality ofdigital assets7 between thenodes3,9,17 may be associated with a proposed component atomic transaction.
• In one example theComputational Node3 may map the transfer of the plurality of digital assets from thefirst computer node9 to thesecond computer node11 via thesystem1 by tracing the potential routes that connect thefirst computer node9 to thesecond computer node11 via the intermediate nodes (17 and others not pictured inFIG. 1) that are capable of supporting the transfer of tokens necessary to affect the proposedtransaction5.
• In some examples, theComputational Node3 can determine the proposed component atomic transactions based on data included in the proposedtransaction5. In other examples, theComputational Node3 can determine the proposed component atomic transactions based on additional data available to theComputational Node3 not otherwise included in the proposedtransaction5.
• In some examples, the route for transfer of the plurality ofdigital assets7 may be predetermined at the time that the Computational Node receives the notification of the proposedtransaction5. For example, systems with a central token “registry” node and a hierarchy of supporting intermediary nodes that feed into the central token registry node may have a predetermined route. In this way, the node ultimately providing the token can connect with nodes above it in the hierarchy, up each tier of the hierarchy until it connects with the central token registry node, and then down each tier of the hierarchy until it connects with the ultimate receiver node.
• For example, a system with one level of hierarchy may have thefirst computer node9 representing the ultimate provider node (such as an initial transferring node that provides an initial digital asset to be transferred), thesecond computer node11 representing the ultimate receiver node, and theintermediate computer node17 representing the central token registry node. For examples without such predetermined routes, theComputational Node3 may test the connections between nodes in thenetwork13 that would support the transfer of the tokens/plurality of digital assets involved in the proposed exchange, such that the token is able to transfer between thefirst computer node9, as the ultimate provider node, and thesecond computer node11, as the ultimate receiver node. For example, theComputational Node3 may determine theintermediate computer node17 as a suitable route from thefirst node9 to thesecond node11. Alternatively in such a system without a predetermined path, theComputational Node3 can also run a simulation of the transaction from the ultimate provider node to the ultimate receiver node to ensure that the correct path has been chosen. Such a simulation may utilize the connections between the ultimate receiver node to the ultimate provider node previously tested by the Computational node, a test of the communication route between to ultimate receiver node to the ultimate provider node to confirm whether such route can also support the transfer of tokens and/or digital assets necessary for the transaction, or to test some other connection determined by theComputational Node3.
• Once the mapping is complete, theComputational Node3 may determine the proposed component atomic transactions that comprise the overall proposedtransaction5. Utilizing the map/route, theComputational Node3 can consider each binary pair of computer nodes, i.e. transferring or receiving computer nodes, that comprise the route linking the ultimate provider node to the ultimate receiver node. Each transfer of one or more tokens or digital assets of the same type from one node to another node can comprise a component atomic transaction. In a further example, theComputational Node3 may consider the transfer of the plurality of tokens or digital assets from one node to the next node as a component atomic transaction. For the avoidance of doubt, each component atomic transaction, in an example, can comprise tokens or digital assets moving in the same direction from one computer node to another. If the pair of computer nodes are exchanging tokens with each other, and even if the tokens are the same tokens, such exchange can be treated as separate proposed component atomic transactions.
• TheComputational Node3 can continue determining each of the proposed component atomic transactions until the entire transaction, as mapped out over each intermediary node connecting the ultimate provider nodes and the ultimate receiver nodes has been broken into discrete component atomic transactions, that when added together, comprise the entire transaction. Alternatively, theComputational Node3 may simulate all of the component atomic transactions to confirm that effectuating the sum of all component atomic transactions will achieve the same results of the overall transaction.
• In determining the component atomic transactions, theComputational Node3 may examine the program instructions (e.g., the smart contract written in DAML or other language) for the overall transaction, and write program instructions/smart contracts for each of component atomic transactions that it will execute in lieu of the program instructions for the overall transaction. In an alternative scenario, theComputational Node3 may additionally run a simulation utilizing the program instructions/smart contracts for each component atomic transaction to ensure that executing the totality of program instructions/smart contracts for all of the component atomic transactions will produce the same result as executing the program instructions/smart contracts for the overall transaction.
• As described below, theComputational Node3 may utilize such program instructions/smart contracts in analyzing the node and/or running the described simulations. Alternatively, theComputational Node3 may use other calculations in its analysis.
• Alternatively, theComputational Node3 may perform the step of writing program instructions/smart contracts for each of the component atomic transactions after successfully determining that each node involved in the transaction as sufficient tokens or other digital assets to perform all of its obligations under all of the component atomic applicable to it, as described below. Delaying the this step until after the analysis of each node may save system processing time by eliminating the need for theComputational Node3 to write such program instructions/smart contracts for transactions that fail the test. If such step is delayed until after the analysis, theComputational Node3 may conduct the analysis based upon its calculations in lieu of the rewritten program instructions/smart contracts.
• TheComputational Node3 can then determine whether each node involved in the overall transaction has sufficient tokens or other digital assets to perform all of its obligations under all of the component atomic transactions. This may be performed by first identifying all component atomic transactions involving the node in question. TheComputational Node3 can then examine all of the component atomic transactions where the node in question is due to receive tokens and digital assets, and then aggregating all of the inbound tokens and digital assets. TheComputational Node3 can also examine all of the component atomic transactions where the node in question is due to transfer/send tokens and digital assets, aggregating all of the outbound tokens and digital assets. TheComputational Node3 can then subtract the aggregated outbound tokens and digital assets from the aggregated inbound token and digital assets. In performing this calculation, theComputational Node3 can, in one example, only subtract tokens and digital assets of the same type. If the result is positive or neutral for each token and digital asset subtracted, theComputational Node3 can consider the node in question to have sufficient tokens and digital assets to complete the transaction and mark the node a success. Alternatively, theComputational Node3 may query all nodes as described in the following paragraph, regardless of a positive, neutral, or negative calculation. If the result is negative for any token or digital asset subtracted, theComputational Node3 may examine whether the node has such token or digital asset available in the amount to cover the negative calculation.
• In an alternative scenario, to prevent nodes from entering into fully netted transactions without having the necessary tokens, theComputational Node3 may query the ultimate provider node to ascertain that such node has the tokens that originate from it. In this query of the ultimate provider node, the Computational Node will not take into account tokens that such ultimate provider node may receive during or upon the completion of the transaction.
• To check whether the node has the required token or digital assets in the amount necessary to cover the negative calculation, theComputational Node3 may query the PCS of the node. Alternatively, theComputational Node3 may query the PCS of the central Execution Node or another node such as a central Committer Node. Alternatively, theComputational Node3 may query its PCS.
• If theComputational Node3 determines that the node has sufficient tokens or digital assets to cover the negative calculation, theComputational Node3 can consider the node in question to have sufficient tokens and digital assets to complete the transaction and mark the node a success. TheComputational Node3 can include tokens and digital assets previously Locked to the transaction in question as available to cover the negative calculation. TheComputational Node3 can exclude any tokens and digital assets previously locked to any other transaction as unavailable. In this example, theComputational Node3 can mark the tokens or digital assets necessary to complete the transaction, and either Lock them to the transaction or otherwise reserve them to prevent them from being used for any other transaction. If theComputational Node3 determines that such node does not have sufficient tokens or digital assets to cover the negative calculation, theComputational Node3 can consider the node in question to have insufficient tokens and digital assets to complete the transaction and mark the node a failure.
• In one example the overall proposed transaction can only be performed if all nodes involved can successfully perform all component atomic transactions. If any one node cannot perform any one component atomic transaction, the entire transaction may fail. In a further example, the Computational Node may fail the transaction by sending a notification to all nodes in the transaction, i.e. all transferring computer nodes and all receiving computer nodes, that a component atomic transaction(s) was determined not to succeed.
• Examples with Central Nodes
• In examples with a centralComputational Node3 and either a central Committer Node or a central Execution Node19 (where the central Committer Node may be an Execution Node19), the centralComputational Node3 can notify thecentral Execution Node19 of the potential transaction and the tokens and digital assets being queried in each node involved in the transaction. The central Execution Node can prevent the transfer of any tokens and digital assets necessary for any node that was marked successful. Such tokens or digital assets at a particular node might either be Locked or reserved for the overall transaction during the time theComputational Node3 queries such node for success or failure of its ability to meet the obligations of the component atomic transactions applicable to such node. Should theComputational Node3 pass the entire transaction for settlement, the Lock can remain on such tokens or digital assets until the time of settlement. Thus, in the event all component atomic transactions and all applicable nodes are marked successful by theComputational Node3, then the tokens or digital assets Locked or reserved can be used to complete thetransaction5. In the event any component atomic transaction or any applicable node is marked a failure, the entire transaction can be marked a failure, and the digital lock or the reservation of the tokens or digital assets can be released by theComputational Node3.
• The mapping of the transaction, the determination of the nodes involved in the transaction, the determination of the component atomic transactions that comprise the overall transaction, and the queries of each node for sufficient available assets to cover such node's obligations in each of the component atomic transactions involving such node is hereby referred to collectively as the “Settlement Logic.”
• In this way, once theComputational Node3 has determined that each component atomic transaction and each applicable node has passed the tests described above, then theComputational Node3 can submit the entire transaction, comprised of each component atomic transaction, for processing to theExecution Node19. The central Execution Node can ensure that all component atomic transactions are executed as a whole together. Alternatively, the central Execution Node can ensure that all component atomic transactions are written to the same block on the distributedledger15 and/or that such component atomic transactions share a common time stamp. That is, theExecution Node19 may ensure that all component atomic transactions are recorded to the distributedledger15 with the same timestamp applicable to all transactions and other data ledgered on that block. In an alternate scenario, theExecution Node19 can do this by either querying the remaining data capacity of any block prior to writing all of the necessary data of all component atomic transactions to the block. Alternatively, the Execution Node may also wait until the beginning of the next block to ensure that all component atomic transactions of the relevant transaction are recorded together, bearing the same timestamp of the block.
Decentralized Distributed Ledger Systems
• In examples without a centralizedComputational Node3 and without acentralized Execution Node19, each computer node in the network may contain its own components bearing the same functionalities that would have been performed by a Computational Node and an Execution Node. As these components are limited to the computer node containing it, however, the functionalities may only be applicable to the node containing the component. Thus, the Computational Component may only query the node containing that Computational Component, and the committer and the Execution component may only commit and transfer tokens and digital assets held by the node containing the respective components.
• In this example, mapping of the proposedtransaction5 from the ultimate provider nodes and the ultimate receiver nodes may be accomplished in several different ways. The map/route may be predetermined as described in paragraph [116] above. Alternatively, there may be a node with a map of all nodes which may be queried to determine such a map in a similar manner to a system with a centralized node.
• Alternatively, in a truly decentralized system, once the ultimate receiver nodes and the ultimate provider nodes agree upon a proposedtransaction5, each node may utilize the node network which transmitted the messaging of the agreement. Alternatively, if the messaging network does not also support the transfers of the plurality of the tokens or digital assets, each ultimate receiver node and ultimate provider node can submit test queries to adjacent intermediary nodes who then pass on these queries until these queries reach the desired ultimate receiver nodes and/or ultimate provider nodes, as applicable, that are parties to the transaction. In such an event, the path of the successful query can constitute the map/route of the proposedtransaction5.
• Once the map/route of thetransaction5 in a decentralized system is complete, each node can transmit the entire map/route and the transaction to all nodes involved in the transaction, including any intermediate nodes. The Computational Component of a node may then utilize the map to determine the proposed component atomic transactions comprising the entire transaction and broadcast its determination to all nodes involved in such component atomic transactions. Such calculations can be in the same manner as described above, with each unidirectional movement of tokens or digital assets between a binary pair of nodes constituting a single component atomic transaction.
• Alternatively, the Computational Component of each node can then utilize that route to calculate the component atomic transactions comprising the entire transaction. Such calculation maybe in the same manner as described above. Each node may optionally transmit such calculation of the component atomic transactions to ensure that all Computational Components of the different nodes involved in thetransaction5 agree with each other's calculations. The Computational Components of the different nodes can then work to reconcile any differences, if any, by utilizing a set algorithm of determining consensus, first ensuring that each node had the same map, then by ensuring that each node utilized the same calculation method, and finally, if there is still is no unanimous calculation of the component atomic transactions, by some other method, such as majority rule. Alternatively, as the calculation of component atomic transactions is unlikely to result in differences, especially in systems with predetermined routes, the nodes may not necessarily confirm that the Computational Components of the other nodes reached the same calculations.
• Once the component atomic transactions are determined, the Computational Component of each node can query the node to determine whether that node has sufficient tokens or digital assets necessary to fulfil all component atomic transactions involving it. As described in paragraph [123] above, the Computational Component can subtract the aggregated outbound tokens and digital assets from the aggregated inbound token and digital assets, only subtracting tokens and digital assets of the same type. If the result is positive or neutral for each token and digital asset subtracted, the Computational Component can consider its node to have sufficient tokens and digital assets to complete the transaction and mark its node a success. If the result is negative for any token or digital asset subtracted, the Computational Component can look to examine whether its node has such token or digital asset available in the amount to cover the negative calculation. If the Computational Component determines that its node has sufficient tokens or digital assets to cover the negative calculation, the Computational Component can consider its node to have sufficient tokens and digital assets to complete the transaction and mark the node a success. In such event, the Computational Component can mark the tokens or digital assets necessary to complete the transaction, and either Lock them to the transaction or otherwise reserve them to prevent them from being used for any other transaction. If the Computational Component determines that its node does not have sufficient tokens or digital assets to cover the negative calculation, the Computational Component can consider its node to have insufficient tokens and digital assets to complete the transaction and mark its node a failure.
• When the Computational Component marks its node as a success, it can also Lock or otherwise reserve the tokens or digital assets necessary to cover any negative calculation and thus necessary to process the component atomic transactions due to be processed from its node. These tokens or digital assets can be Locked or reserved until either the node receives a message from another node that such other node failed the query and did not have sufficient tokens or digital assets to meet its obligations or until the settlement of the entire transaction.
• After completing the queries of their own nodes, the Computational Components of each of the nodes involved in the transaction may then message each of the other nodes to inform them of their success or failure. If any one node messages failure or fails to message, then the entire transaction is deemed a failure and cancelled. If all nodes message success, then, and only then, will the transaction be cleared for settlement.
• In a decentralized system as described in this example, once the transaction has been cleared for settlement, each of the nodes involved in the settlement of that transaction can coordinate with the others to effect the settlement of the overall transaction by acting upon each of the component atomic transactions simultaneously. The transaction itself may contain a time for its execution, as agreed upon by the participants to the transaction. In this way, the nodes can execute their component atomic transactions at the agreed time, each writing its portions of the component atomic transactions to the block at the agreed/pre-designated time. Alternatively, a “lead” node may be designated to select the block upon which all component atomic transactions will be written. Such a lead node can ensure that it will wait until the beginning of a block or it may generate a separate block, in either case, to ensure that all component atomic transactions are written on the same block, such that all component atomic transactions, and thus the entire transaction, bears the same time stamp. Alternatively, each node may message the other as to the moment that the component atomic transactions should be written to a block, again ensuring that all component atomic transactions are written on the same block, bearing the same timestamp.
• In yet another scenario, an Execution Node can be designated to aggregate all component atomic transactions from all nodes involved in the proposed transaction, and submit all component transactions aggregated into a single transaction. The Execution Node can then broadcast the proposed transaction to the network of nodes maintaining the distributed ledger, which can record the proposed transaction to the distributed ledger if it satisfies network parameters. If not, the proposed transaction, and all its component atomic transactions, can be failed and nothing recorded to the distributed ledger. In this way, the Execution Node can serve as a coordinator and proxy for submitting all component atomic transactions at the same time, as part of a single proposed transaction.
• FIG. 2 illustrates an example proposedtransaction5 between afirst computer node9 and asecond computer node11. In this example, the proposedtransaction5 involves a transfer of thedigital asset7 from thefirst computer node9 to thesecond computer node11, as well as a transfer of adigital asset207 from thesecond computer node11 to thefirst computer node9. In some examples thefirst computer node9 andsecond computer node11 may comprise sports teams trading players, or a seller and buyer or a lender and borrower respectively. In this example the Computational Node3 (not illustrated inFIG. 2) may determine the proposed component transactions by dividing the proposedtransaction5 into multiple proposedcomponent transactions240 and250. As illustrated inFIG. 2, thefirst component transaction240 comprises a transfer of thedigital asset7 from thefirst computer node9 to theintermediary node17, and a transfer of thedigital asset207 from theintermediary node17 to thefirst computer node9. Thesecond component transaction250 involves a transfer of thedigital asset7 from theintermediary node17 to thesecond computer node11, and a transfer of the asset digital207 from thesecond computer node11 to theintermediary node17. In this way, theComputational Node3 may determine the proposedtransactions240,250 by considering the movement of thedigital assets7,207 between thefirst computer node9,second computer node11 andintermediary note17.
Digital Lock
• As described above, theComputational Node3 may be configured to determine at least one digital lock associated with the proposed transaction. In one example, the proposedtransaction5 may comprise at least one digital lock. In this way, theComputational Node3 may determine the proposed digital lock from the proposedtransaction5. In other examples theComputational Node3 may determine the digital lock by receiving the digital lock from a node, such as a transferring computer node or receiving computer node like thefirst computer node9 or another node in thenetwork13.
• In some examples theComputational Node3 may determine the digital lock using the methods described in International PCT application PCT/US2018/044682, the disclosure of which is incorporated herein by reference in its entirety.
• In one example, theComputational Node3 determines the digital lock from the proposedtransaction5 from thefirst computer node9. In this example, thefirst computer node9 may cryptographically sign (e.g., using a private key, digital signature, etc.) the digital lock that is sent to theComputational Node3 so that theComputational Node3 may confirm the authenticity of the digital lock. Cryptographically signing a digital lock may comprise creating and applying a digital signature to a message containing the digital lock by way of a private key associated with thefirst computer node9. Cryptographically signing the digital lock may permit the Computational Node3 (or another node in the network13) to verify that the digital lock came from thefirst computer node9 of the proposedtransaction5.
• The digital lock can, in one example, comprise instructions or code (e.g., in DAML as shown inFIG. 3) that, when executed, “commits” or digital locks thefirst computer node9 andsecond computer node11 to a transaction involving adigital asset7 recorded to a distributedledger15. The distributedledger15 may be either of distributedledgers2007 or2107 detailed above in the context ofsystems2001 and2101, respectively. In one example, the digital lock may comprise an inactive digital lock related to thedigital asset5, wherein when activated the digital lock may prevent transfer of any one of the plurality ofdigital assets7 from thefirst computer node9 to another node that is not thesecond computer node11 or anintermediate node17.
• TheComputational Node3 may also be configured to receive acceptance of the digital lock from a transferring or receiving computer node such as thesecond computer node11. This acceptance may indicate that the second computer node11 (or other node in thenetwork13 that is party to the digital lock) agrees to the terms in the digital lock of the proposedtransaction5. In one example, after theComputational Node3 receives theacceptance7, theComputational Node3 may activate the inactive digital lock to prevent transfer of thedigital asset7 except to settle the proposedtransaction5. The acceptance may comprise a notification or token that is sent from thesecond computer node11 to thefirst computer node9 orComputational Node3. In some examples, thefirst computer node9 may receive the acceptance from thesecond computer node11 and send it to theComputational Node3. In some examples the acceptance may provide an indication that parameters of the digital lock are accepted for the transaction by thesecond computer node11. Thesecond computer node11 may cryptographically sign the acceptance in some embodiments.
• Additionally or alternatively, the acceptance may take the form of thesecond computer node11 simply activating the digital lock and messaging thefirst computer node9 as to its acceptance of the digital lock, either privately and/or by recording its acceptance to the distributedledger15. Activating the digital lock may constitute thefirst computer node9 orsecond computer node11 executing program instructions (e.g., a code segment) that acts to: (i) submit a transaction that is recorded to the distributed ledger (e.g.,ledger15,2007, or2107) to update the state of the ledger and reflect that the digital asset is locked except for purposes of settling the digital asset transfer from thefirst node9 to thesecond node11, and/or (ii) deploy additional program instructions or code that specifies the details of the digital asset transfer (e.g., the particular digital asset, quantity, price, parties to the transfer, etc.) and includes a code segment(s) executable by thefirst computer node9 or thesecond computer node11 that transfers the digital asset from thefirst computer node9 to thesecond computer node11 according to the details of the agreed-upon transfer. The instructions of (ii), or a cryptographic representation (e.g., a hash) thereof, may be recorded to the distributed ledger (e.g.,ledger15,2007, or2107) as a transaction or series of transactions, in certain cases.
• In other examples thefirst computer node9 may activate the digital lock. In this way the code segment(s) of (ii) that transfers thedigital asset7 may, in one example, require a cryptographic signature (e.g., private key, digital signature, etc.) by thefirst computer node9 to be executed. Likewise, in embodiments where thesecond computer node11 activates the digital lock, the code segment(s) of (ii) that transfers the digital asset may, in one example, require a cryptographic signature (e.g., private key, digital signature, etc.) by thesecond computer node11 to be executed. For example, thefirst computer node9 may send a digital lock that includes a code segment that is executable by thesecond computer node11 upon providing its cryptographic signature and, when executed, acts to lock thedigital asset7 that is the subject of the transaction for purposes of settling the transaction. By sending the digital lock with the code segment executable by thesecond computer node11, thefirst computer node9 may be considered to have implicitly agreed to activation of the digital lock according to the terms set forth in the proposedtransaction5 and associated digital lock. Thus, thesecond computer node11 may be free to activate the digital lock that is associated with the proposedtransaction5 by executing the activation code segment provided by thefirst computer node9 in the digital lock.
• In some examples, the digital lock may also comprise instructions or code that, when executed, commits thefirst computer node9 and thesecond computer node11 to the same transaction also involving thedigital asset207. In this way, when the digital lock is activated the digital lock may also prevent transfer of thedigital asset207 from thesecond computer node11 to another node that is not thefirst computer node9 or anintermediate node17.
• In other examples the proposedtransaction5 may comprise a further digital lock to lock and/or commit thedigital asset207 for transfer from thesecond computer node11 to thefirst computer node9 or anintermediary node17. The further digital lock may be in accordance with the embodiments of the digital lock described above.
• In some examples, the distributed ledger may resolve and commit one or more digital locks that are locked and all unlocked within the a same atomic transaction by consolidating all locks and unlock into the lock and unlock of the two step commit of the distributed ledger transaction (e.g. GSL2013).
• For distributed ledger systems without a centralized Computational, Execution, or Write Nodes, the above processes can be performed by the Computational, Execution, or Write Components, as applicable, of each of the nodes involved in the transaction.
Digital Locks for the Plurality of Proposed Transactions
• In some examples each of the plurality of proposed component atomic transactions may be associated with one or more digital locks. In this way, theComputational Node3 may determine the one or more digital locks in accordance with the method described above.
• The one or more digital locks may be activated to prevent transfer of any one of the plurality of digital assets in multiple proposed component transactions.
• Verify that the Computer Nodes are Cryptographically Authorized
• As described above, theComputational Node3 may also be configured to verify that each of thefirst computer node9 andsecond computer node11 is cryptographically authorized to receive and/or transfer the digital asset(s) defined in the proposed transaction.
• In one example, verifying that thenodes9,11 are cryptographically authorized may comprise determining whether eachnode9,11 has the digital asset(s) required for the proposedtransaction5 to occur. For example, referring toFIG. 2 theComputational Node3 may verify thatfirst computer node9 hasdigital asset7, and thatsecond computer node11 hasdigital asset207. In addition, verifying that thenodes9,11 are cryptographically authorized to receive and/or transfer the digital asset(s) defined in the proposed transaction can involve determining whether thenodes9,11 have appropriate cryptographic authorization to execute one or more code segments (e.g., DAML contracts) recorded to the distributed ledger, which are required to effectuate the proposed transaction. This can involve determining whether thenodes9,11 have an appropriate cryptographic key to execute such one or more code segments (e.g., DAML contracts) recorded to the distributed ledger, as detailed below.
• To perform verification, theComputational Node3 may read a private data store associated with thefirst computer node9 to confirm adigital asset7 is unlocked and can be transferred from thefirst computer node9 to another computer node in thenetwork13. The private data store associated with thefirst computer node9 may be the PCS of thefirst computer node9. In another example, theComputational Node3 may read the distributedledger15 to confirm thedigital asset7 is unlocked.
• Similarly, theComputational Node3 may read a private data store associated with thesecond computer node11 to confirmdigital asset207 is unlocked and can be transferred from thesecond computer node11 to another computer node in thenetwork13. The private data store associated with thesecond computer node11 may be the PCS of thesecond computer node11. In another example, theComputational Node3 may read the distributedledger15 to confirm the digital asset orasset207 is unlocked.
• In a further example, verifying that thenodes9,11 are cryptographically authorized may comprise determining whether eachnode9,11 has the digital asset(s) committed to the proposedtransaction5.
• Verifying may also comprise validating that a node is properly permitted to execute a particular code segment. In one example, validating that a node is properly permitted to execute a particular code segment may be enforced using digital signatures and/or public/private key pairs associated with a node. For instance, in the above example, execution of the code segment by thesecond computer node11 that activates the digital lock may be enforced using a public/private keypair associated with thesecond computer node11. To demonstrate that thesecond computer node11 is permitted to execute the code segment activating the digital lock that is associated with the proposedtransaction5, thesecond computer node11 may cryptographically sign (e.g., using its private key, a digital signature, etc.) to confirm it is a node permitted to execute the code segment. Likewise, determining whether any node is properly permitted to execute a code segment described herein may use the same mechanism (i.e., require a cryptographic signature by such node for execution of the code segment). Accordingly, embodiments of the present disclosure may use a technical solution including cryptographic signatures to avoid trust problems that arise with conventional intermediaries.
Digital Lock in an Activated State to Prevent Transfer of theDigital Asset7
• As described above, when activated the digital lock may prevent transfer of thedigital asset7 to another computer node. In this way, thedigital asset7 may be “committed” to the proposedtransaction5. In one example, after activation of the digital lock associated with the proposedtransaction5, theComputational Node3 may broadcast the activated digital lock for recordation in the distributedledger15,2007,2107. In other examples, thefirst computer node9 orsecond computer node11 or another node in the network may broadcast the activated digital lock for recordation. As described previously, the distributedledger15 may comprise aGSL2013 shared between nodes of thesystem2001, andseparate PCSs2015 of thefirst computer node9 andsecond computer node11 that are participants to the proposedtransaction5 including thedigital asset7. Thefirst computer node9 and/orsecond computer node11 may also read the distributed ledger (e.g. ledger15,2007, or2107) to confirm the distributed ledger contains the digital lock in an activated state. In some examples, the Computational Node3 (orother nodes9,11) may transmit data to a central node (e.g. a central writer or a “committer” node) for recordation in the distributed ledger (e.g. ledger15,2007, or2107). Accordingly, the central node may act as a writer node as described above to record evidence of the activated digital lock to theGSL2013. Thenodes3,9,11 may also act in writer mode to record evidence of the activated digital lock on theGSL2013 of the distributed ledger. In some examples, evidence of the activated digital lock may comprise a cryptographic representation of the activated digital lock, such as a hash, recorded in theGSL2013.
• With the activated digital lock recorded to the distributed ledger (e.g.,ledger15,2007, or2107), all participants to the transaction, such as thefirst computer node9 andsecond computer node11, may confirm that thedigital asset7 that is subject to the proposedtransaction5 is locked for purposes of thespecific transaction5 and that transaction only. Further, the distributedledger15 may serve as the prime source of truth between the parties that thedigital asset7 is locked for purposes of theirtransaction5 and that transaction only.
Send an Authorization Notification to at Least OneExecution Node19
• As described above, theComputational Node3 may further be configured to send an authorization notification to at least oneExecution Node19 to cryptographically unlock the activated digital lock and transfer thedigital asset7 from thefirst computer node9 to thesecond computer node11 via the at least oneintermediate node17 to settle the proposedtransaction5. TheExecution Node19 may be associated with the Business Logic Engine (“BLE”) of a node in thenetwork13. In some examples, there may be more than oneExecution Node19 so that the function of the Execution Node is shared between nodes.
• As also described above, the sending of the authorization notification may be based on the verification that thefirst computer node9 andsecond computer node11 are cryptographically authorized to receive and/or transfer the digital asset7 (and/or digital asset207) defined in the proposedtransaction5. In this way, the authorization notification may indicate to the Execution Node that the proposedtransaction5 is ready for execution. In other words, this may mean that thedigital asset7 is ready for transfer from thefirst computer node9 to thesecond computer node11 via the at least oneintermediate node17.
• Sending the authorization notification may comprise theComputational Node3 sending a notification or token to theExecution Node19. In other examples, theComputational Node3 may send the authorization notification or token to theExecution Node19 via another node such as thecomputer nodes9,11,17. In further examples, another node may send the authorization notification or token to theExecution Node19. The authorization notification may provide confirmation to theExecution Node19 that the transaction is ready for settlement. In other examples, theComputational Node3 may send the authorization notification to theExecution Node19 via another node in thenetwork13.
• The authorization notification may comprise details of the proposedtransaction5 and the proposed component atomic transactions, including details of thenodes9,11,17.
• The authorization notification may cryptographically unlock the activated digital lock. Cryptographically unlocking the activated digital lock may comprise deactivating the digital lock. In this way, theExecution Node19 may be configured to deactivate the digital lock related to thedigital asset7. In some examples, deactivating the digital lock related to the digital asset may comprise executing program instructions (e.g., a DAML code segment) that updates the distributed ledger (e.g.,ledger15,2007, or2107) as part of a transaction or series of transactions to reflect that the digital asset may be transferred by thefirst computer node9 to another node (such assecond node11 via one or more intermediate nodes17) in the network (e.g.,network13,2001 or2101) without restriction. For example, this may include recording a code segment (e.g., a DAML code segment) and/or a cryptographic representation (e.g., a hash) thereof, to the distributed ledger (e.g.,ledger15,2007, or2107) that is executable byfirst computer node9 or Execution Node (e.g., upon providing its cryptographic signature) and, when executed, transfers thedigital asset7 from thefirst computer node9 to another node in thenetwork13 without restriction. A process for execution of shared code segments (e.g., DAML shared code segments) is described in detail in PCT/IB2018/058375, the disclosure of which is hereby incorporated by reference herein. The process described in the aforementioned application can be utilized to lock or unlock any digital lock of the present system, as detailed above and in subsequent sections of the disclosure.
• As described, deactivating the digital lock may comprise sending a token of deactivation to another node in thenetwork13. Examples of other nodes include thesecond computer node11 or a central node. The other node may then update the ledger (e.g. ledger15,2007,2107) to deactivate the digital lock. Additionally or alternatively, the other node may deactivate the digital lock.
• After theExecution Node19 receives the authorization notification, theExecution Node19 may pass the proposedtransaction5 to a Write Node. The Write Node may then record the proposedtransaction5, including the proposed component transactions, to a block on theledger15. In some examples, the Write Node records the proposedtransaction5 to a single GSL block of the GSL.
• The Write Node can record each of the movements by the Execution Node. The Write Node can allow for the simultaneous transfer of the digital assets involved in the proposed component atomic transactions by recording each proposed component transaction in the same block, thus allowing each component transaction to occur with the same timestamp. In practice, this means that each proposed component atomic transaction can have the same timestamp for execution. This is an advantage of the present disclosure since the proposed component transactions will be executed with the same timestamp. This eliminates risk of non-performance and delay in exchange of the digital assets. In other examples, each proposed component atomic transaction can be submitted for inclusion in the distributed ledger as part of the same overall transaction, where the transaction is provided with a timestamp when recorded to the distributed ledger. In this way, if a proposed component atomic transaction fails, the overall transaction can fail and not be recorded to the distributed ledger. Additionally, since the overall transaction is provided a timestamp when recorded to the distributed ledger, each proposed component atomic transaction, for purposes of settling the exchange of digital assets, can be considered to be submitted and/or settled all at the same time, thereby reducing risk of non-performance or delay in the exchange of the digital assets.
• In some examples, the transfer of thedigital asset7 may be executed by theExecution Node19 at some set time. In practice, this may comprise thefirst computer node9 transferring thedigital asset7 in accordance with the transaction and being permitted to execute program instructions (e.g., a DAML code segment) that transfers thedigital asset7 from thefirst computer node9 to thesecond computer node11 via the at least oneintermediate node17 for the purposes of settling the transaction. As previously mentioned, such DAML code segment, or a cryptographic representation (e.g., a hash) thereof, can be recorded to the ledger (e.g.,ledger13,2007, or2107) in advance of execution of the segment to ensure that proper evidence is in the ledger as to the content of the code segment and which node(s) is authorized to execute the segment. Subsequently, the computer node (e.g. node9,11 or17) that executes the program instructions (e.g., code segment) transferring thedigital asset7 may record an update to the distributed ledger (e.g.,ledger15,2007, or2107) that lists the intermediary node(s)17 orcomputer node11 as the transient owner of the digital asset. Alternatively, the node (e.g.,node9,11 or17) that executes the transfer code segment may delegate recording to the distributed ledger to another node (e.g., a write node).
• In this way, by unlocking the digital asset(s) of the proposedtransaction5, this can cause the proposed component transactions to be settled. That is, the Execution Node can execute thetransaction5, moving thedigital asset7 in accordance with each proposed component transaction.
• For example, referring toFIG. 2, at the time of settlement theExecution Node19 may move thedigital asset7 in accordance with the proposedcomponent transactions240,250. In this way, thedigital asset207 can also move in accordance with the proposedcomponent transactions240,250. That is, thedigital asset7 may transfer from thefirst computer node9 to theintermediary node17 and thedigital asset207 may transfer from theintermediary node17 to thefirst computer node9. Thedigital asset7 may then transfer from theintermediary node17 to thesecond computer node11, and thedigital asset207 may transfer from thesecond computer node11 to theintermediary node17.
Method400
• FIG. 4 illustrates a method400 to facilitate settlement of a transaction involving a plurality ofdigital assets7. In the method400, the transaction may be based on a proposedtransaction5 as described above. That is, the proposedtransaction5 may comprise a plurality of proposed component atomic transactions that each atomically transfer at least some of the plurality of digital assets from one or more transferring computer nodes to one or more receiving computer nodes, wherein each of the transferring computer nodes and receiving computer nodes belong to anetwork13 of nodes that maintain a distributedledger15.
• In some examples, a transferring computer node may be afirst computer node9 and a receiving computer node may be asecond computer node11 as described above. In further examples anintermediate node17 may act as a transferring and receiving computer node.
• In some examples, a node such as theComputational Node3 may determine the proposed component atomic transactions by dividing the proposedtransaction5 into one or more proposed component atomic transactions. For example theComputational Node3 may determine the proposed component transactions based on the transferring and receiving computer nodes, such as thefirst computer node9,second computer node11 and the one or moreintermediate nodes17. This may performed as described above with respect tosystem1.
• The method400 may comprise receiving4010 an authorization notification to transfer the plurality of digital assets from the transferring computer nodes to the receiving computer nodes to settle a proposed transaction. As described above, a node such as theComputational Node3 may be configured to send the authorization notification. As also described above the authorization notification may indicate to the receiving node, such as theExecution Node19, that the proposedtransaction5 is ready for execution. The authorization notification may comprise a notification or token as described above.
• The authorization notification may be based on a verification that each transferring and receiving computer node is cryptographically authorized to receive and/or transfer at least some of the plurality of digital assets. The authorization notification may further be based on a verification that each transferring and receiving computer node involved in the proposed transaction has a sufficient amount of the plurality of digital assets to fulfil all of the transferring or receiving computer node's obligations under each proposed component atomic transaction involving such node.
• The method400 may further comprise determining4020 an authorization to transfer the plurality ofdigital assets7 from the transferring computer nodes to the receiving computer nodes.
• The method400 may further comprise atomically transferring4030, based on the authorization, the plurality ofdigital assets7 from the transferring computer nodes to the receiving computer nodes to settle the proposedtransaction5.
• Examples of the present disclosure further include a non-transitory computer-readable medium comprising program instructions that, when executed, cause a computer to perform the method400 as illustrated inFIG. 4 and described above. The non-transitory computer-readable medium may also comprise program instructions that, when executed, cause a computer to perform the steps described above with respect to the examples ofsystem1.
Further Examples of Proposed Component Transactions
• As a foreword to the following examples, it is important to note that the inefficiencies, risks, and potential failures of current operational systems as described below may be solved using embodiments of the present disclosure without the need to eliminate nodes or participants or their roles in current operational systems or otherwise change the structure of current operational systems.
Simple Exchange
• FIG. 5 shows the inefficiencies of current operational systems via a simple and typical transaction whereNode A110 exchanges token ABC toNode C130 for token XYZ, where that transaction is settled through intermediary Node B120. In this simplest scenario,Node A110 andNode C130 share a mutual intermediary, Node B120, and the transfer of the token ABC from Node A to Node B is actually an exchange transaction whereNode A110 transfers token ABC to intermediary Node B120 in exchange for token XYZ (First Movement140) and a second exchange transaction whereNode B130 transfers token ABC to Node C120 in exchange for token XYZ (Second Movement150).
• Note that prior to the execution of the transaction, Node B120 lacks both token ABC for theSecond Move150 and token XYZ for theFirst Move140. Thus, under a transfer regime where each party is must receive a token before delivering a token in exchange, intermediary Node B120 is unable to begin the sequence of settlement unless Node B120 itself obtains one of the tokens involved. Node B120 is unable to obtain the needed token ABC fromNode A110 until it is able to transfer token XYZ, which it does not yet have. Node B120 is similarly unable to obtain the needed token XYZ fromNode C130 until it is able to transfer token ABC, which it does not have.
• In order to execute theFirst Move140, Node B120 must transfer token XYZ to Node A (leg160). Node B120 must, therefore, find a source for token XYZ in order to complete theother leg170 of theFirst Move140. Node B120 must either utilize its own token XYZ140A, in effect loaning its token XYZ to the transaction toNode C130 before taking Node C'stoken XYZ180, or, if Node B120 does not have token XYZ, Node B120 must utilize its own assets to buy token XYZ140A in order to loan that token XYZ to the transaction.
• After Intermediary Node B120 transfers token XYZ to Node A,160, theFirst Move140 is completed by the delivery of token ABC toNode B170. Node B120 can now complete the overall transaction by affecting theSecond Move150 when it receives token XYZ fromNode B180 and delivers token ABC toNode C190. Upon the receipt of token XYZ fromNode C180, Node B120 can erase the token XYZ loan140A it created to initiate the transaction. Depending on the timing differences between the initiation of thetransaction160 and the close of thetransaction190, Node B's loan of token XYZ140A to the transaction could have been intra-day or overnight, and each of the nodes suffers settlement, counterparty, performance, and delivery risks during that time.
• In the ordinary course where token ABC and token XYZ both represent fungible tokens, the First Move and the Second Move are interchangeable. However, if one token is an unit of exchange or is otherwise more easily obtainable, current convention processes the transfer of the more difficult-to-obtain token to the intermediary node first in exchange for the more easily-obtainable token second, because the intermediary node may more easily obtain that token to lend into the transaction.
• A real world example of the inefficiencies of current operational systems is the DVP settlement of dematerialized securities for cash, where a seller, Node A120, is selling a share of ABC (token ABC) to a buyer,Node C130 in exchange for an amount of money (token XYZ). As dematerialized securities are recorded on the books and records of custodians, brokers, central securities depository participants (to the extent the custodian and/or broker are not themselves central securities depository participants), and the central securities depository (each a “settlement entity”), the single sell transaction between a seller and buyer actually comprises of a series of transactions forming a chain from the seller, each individual settlement entity that connects that seller and buyer, and the buyer. Node B represents an intermediary settlement entity. In order to facilitate theFirst Move140, Node B120 must payNode A110 an amount of money (token XYZ160 in exchange for the share ofABC170. However, as Node B has yet to complete the Second Move withNode C150, Node B must advance that amount of money (XYZ Credit140A) in order to initiate theFirst Move140. The settlement entity, therefore, must extend clearing credit in the amount of XYZ in order to settle the overall purchase and sale. Therefore, the settlement entity may bear the risk of loss of the amount of the extension. For example the risk may be a risk that the node obligated to deliver the token may fail to deliver such token due to a host of factors. Example factors include unintentional (such as system or computer failures, electrical outages, communications disruptions, or human/operator error) to intentional (bankruptcy stays or a decision to renege on the delivery). Moreover, each node in the path may become a potential point of failure. Each node in the chain bears the risk of non-performance by every other node in the chain. Any failure, whether a technical computer outage or an intentional half to the transfer, at any node in the chain, may prevent another node from receiving the tokens.
• In one example, in the event the buyer becomes bankrupt before the completion of the Second Move, the settlement entity risks the amount of the extension. Even if the settlement entity has a claim on the shares of ABC for which it bought in the First Move, it still suffers market risk, if the shares of ABC decline in value. Similarly, each of the seller (Node A), intermediary (Node B), and buyer (Node C) suffers counterparty, settlement, market, and performance risk due to the potential failure, bankruptcy, or renege of the other nodes. Therefore, it is common for the parties, especially the settlement entity, to impose economic inefficiencies on the other parties, ranging from margin requirements and collateral postings, to transaction and membership fees.
• FIG. 6 shows exemplary efficiencies of embodiments of the present disclosure in processing the same exchange transaction of token ABC for token XYZ betweenNode A210 andNode C230 via their mutualintermediary Node C220. Unlike current infrastructure, there is no separate first move transaction betweenNode A210 andBode C220, nor a separate second move transaction betweenNode B220 andNode B230. Instead, there are four (4) atomic components to the overall transaction: (a) a transfer of token XYZ from Node B toNode A240, (b) a transfer of token ABC from Node A toNode B250, (c) a transfer of token XYZ from Node C toNode B260, and (d) a transfer of token ABC from Node B toNode C270. Once the Computational Node queries each of the nodes to determine that all necessary tokens or digital assets have been Locked, reserved, or are otherwise available to complete each of the component atomic transactions, it can pass notice of the acceptable transaction to the Execution Node. Upon receipt of the acceptable transaction, the Execution Node can process all component atomic transactions simultaneously, by recording each movement of each component atomic transaction to the ledger within the same block or overall transaction so that each component atomic transaction bears the same timestamp as all of the others.
• The need to credit token XYZ (see140A inFIG. 1) that is necessitated by the current infrastructure is no longer necessary, asintermediary Node B220 effectively nets, or passes through, its obligation to deliver token XYZ toNode A240 against the receipt of token XYZ fromNode C270 when those two (2) atomic transactions occur simultaneously. The technical result of simultaneous recording of the multiple component atomic transactions may include reducing (or eliminating) the time to complete multiple component transactions, which in turn improves security. Also eliminated are any settlement, counterparty, and delivery risk, as the digital asset management system either settles all atomic component transaction if all of the assets necessary for settlement have been locked and are available, or the digital asset management system declines to settle any atomic component transaction if any of the assets of any atomic component transaction is unavailable.
• Unlike current infrastructure, there is no separate transaction betweenNode A210 andIntermediary Node C220 nor a separate transaction betweenIntermediary Node C220 andNode B230, and Node C is not required to source or borrow token XYZ in order to facilitate the first transaction with Node A. In this way methods of the present disclosure may mitigate the risks of non-performance as described above.
Chain Exchange
• FIG. 7 shows a more typical transaction under existing operating systems, whereNode A310, the ultimate originator of token ABC that wishes to exchange it for token XYZ, andNode G320, the ultimate originator of token XYZ, do not share an intermediary node.Node A310 has agreed to exchange token ABC toNode G320 in exchange for token XYZ.
• Current operating systems for transfers are often centralized via a central intermediary node, here represented byNode D370, with the ultimate counterparties likeNode A310 andNode G320 interacting with each other and the central intermediary node via one or more layers of other nodes. InFIG. 3, Node A interacts withNode D370 viaNode B330 andNode C350, while Node G interacts withNode D370 via Node F340 andNode E360.
• Thus, under existing operating structures, the transfer of token ABC fromNode A310 toNode G320 is again broken up into stages, with sequential exchanges between Node A andNode B380, Node B andNode C381, Node C andNode D382, Node D andNode E383, Node E andNode F384, and Node F and Node G385. Each of thetransactions380,381,382,383,384, and385 consists of a movement of token ABC along the chain in the direction from Node A towards Node G (in order,380A,381A,382A,383A,384A, and385A), against the movement of token XYZ in the opposite direction (in order,380B,381B,382B,383B,384B, and385B). BecauseNode G320 originates token XYZ and because the transaction withNode G320 occurs last in the sequence385, each ofNode B330,Node C350,Node D370,Node E360, andNode F320 must source, borrow, or use their own token XYZ to order to initiate each of their respective purchase transactions. For instance,Node B330 must sourcetoken XYZ380C in order to transfer it toNode A380B in exchange for token ABC as required for theFirst Move380;Node C350 must sourcetoken XYZ381C in order to transfer it toNode B381B in exchange for token ABC as required for theSecond Move381; although central intermediaries like Node D may have other means of settlement like end of day net settlement, in order for a central intermediary not to delay settlement,Node D370 must also sourcetoken XYZ382C in order to transfer it toNode C382B in exchange for token ABC as required for theThird Move382;Node E360 must sourcetoken XYZ383C in order to transfer it toNode D383B in exchange for token ABC as required for theFourth Move383, and Node F340 must sourcetoken XYZ384C in order to transfer it toNode E384B in exchange for token ABC as required for theFifth Move384. Each source of XYZ, whether borrowed from elsewhere, purchased on credit, or load from itself by each node described above cannot be extinguished until the completion of the next transaction in the chain.
• FIG. 8 shows the same structure asFIG. 7, but applied to the sale of a share of ABC, a dematerialized security traded on a central securities depository (CSD). Seller, Node A,310 has agreed to sell a share of ABC to Buyer, Node G,320 for $100, token XYZ. Seller trades through its introducing broker (SIB)330, while Buyer trades through a different introducing broker (BIB)340. SIB settles its trades through Clearing Member1 (CM1)350, while BIB settles its trades through Clearing Member2 (CM2)360. CM1 and CM2 are members of the Central Securities Depository (CSD)370.
• Using current financial infrastructure, the sale of token ABC fromSeller310 toBuyer320 is again broken up into stages, with sequential transactions between Seller andSIB380, SIB andCM1381, CM1 andCSD382, CSD andCM2383, CM2 andBIB384, and BIB and Buyer385. Each of thetransactions380,381,382,383,384, and385 consists of a movement of ABC along the chain in the direction from Seller towards Buyer (in order,380A,381A,382A,383A,384A, and385A), against the movement of the $100 cash purchase price in the opposite direction (in order,380B,381B,382B,383B,384B, and385B). Because theBuyer320 originates the cash and because the transaction with theBuyer320 occurs last in the sequence385, each ofSIB330,CM1350,CSD370,CM2360, andBIB320 extends clearing credit to initiate each of their respective purchase transactions. For instance,SIB330 must extend $100clearing credit380C in order to pay toSeller310 the $100380B and settle theSeller SIB Trade380;CM1350 must extend $100clearing credit381C in order pay toSIB330 the $100381B in order to settle theSIB CM1 Trade381; although CSDs may have other means of settlement like end of day net settlement, in order for a CSD not to delay settlement theCSD370 must extend $100clearing credit382C in order to payCM1350 the $100382B in order to settle theCM1 CSD Trade382;CM2360 must extend $100clearing credit383C in order to pay theCSD370 the $100383B in order to settle theCSD CM2 Trade383, andBIB320 must extend $100clearing credit384C in order to payCM2360 the $100384B in order to settle theCM2 BIB Trade384. Each extension of clearing credit cannot be extinguished until the completion of the next transaction in the chain.
• It is important to note the significant inefficiencies created by the current market infrastructure that are magnified, simply due to the sequencing of each DVP transaction and the inability for the current market infrastructure to operate as a whole. The number of sequential transactions can also lead to delay in completion of the process and pose a security risk. This may be compounded if sequential transactions follow a predictable pattern whereby the predictable pattern may be exploited by unscrupulous nodes. Furthermore, as demonstrated in this example, extensions of credit in the marketplace is multiples (totaling $500 to settle a $100 trade) of the actual trade, tying up liquidity that could be used for other purposes. As each of the entities extending credit faces settlement, counterparty, and delivery risks, each entity, in turn, charges margin to mitigate these risks, creating additional liquidity drains in the form of margin postings. These risks are magnified forSIB330, BIB340,CM1350,CM2360, andCSD370, the settlement entities, as they become committed to the trade upon the date the transaction is agreed (T) even though the settlement doesn't occur for another two days (T+2). The result is that the settlement entities require margin from their customers and participants not just for the credit extensions during the settlement cycle, but for the added counterparty and delivery risks. The margin requirements further magnify the multiples of inefficiencies in the system. AlthoughSIB330, BIB340,CM1350,CM2360, andCSD370 typically would net their obligations to deliver shares of ABC across their trading book (FIG. 8 shows the transaction as if only one share of ABC was available for trade), the risks borne by and the credit extensions made by each entity remains, and each entity imposes margin on its customer and/or posts margin for these reasons.
• FIG. 9 shows the same transaction asFIG. 7, only performed on the embodiment where all nodes operate as part of the platform. Just as inFIG. 7,Node A410 is exchanging token ABC withNode G420 for token XYZ, but the transaction takes place via a chain of intermediary nodes comprising ofNode B430,Node C450,Node D470,Node E460, andNode F440. UnlikeFIG. 7, however, the transfers of token ABC and token XYZ between the nodes are not sequential. There are no first, second, third, fourth, fifth, and sixth moves. Instead, token ABC moves through the chain fromNode A410 toNode G420 via the component atomic movements of480A,481A,482A,483A,484A, and485A while token XYZ moves through the chain of nodes fromNode G420 toNode A410 via the component atomic movements of480B,481B,482B,483B,484B, and485B.
• Unlike current system infrastructure, however, the atomic movements are not sequential. Rather, once the Computational Node determines that token ABC and token XYZ are available for the transaction or have been Locked or reserved to the transaction, or are otherwise available. Once the Computational Node determines that each of the nodes has or will have the assets necessary to complete its atomic transaction assuming the completion of allatomic transactions480A,480B,481A,481B,482A,482B,483A,483B,484A484B,485A, and485B, effectively allowing each participant to net its obligations, the Computational Node can alert that Execution Node that the transaction is ready for settlement. The Execution Node can complete all component atomic transactions simultaneously recording all movements to the distributed ledger in the same block or overall transaction with the same time stamp. This simultaneous recording of the component atomic transactions may reduce security risks compared with a series of sequentially related exchanges executed over a period of time.
• FIG. 10 shows the benefits of the present system applied to the current market infrastructure of dematerialized securities settled through a central securities depository. Again,Seller410 has agreed to sell a share of ABC toBuyer420 for $100 (token XYZ). Seller trades through its introducing broker (SIB)430, while Buyer trades through a different introducing broker (BIB)440. SIB settles its trades through Clearing Member1 (CM1)450, while BIB settles its trades through Clearing Member2 (CM2)460. CM1 and CM2 are members of the Central Securities Depository (CSD)470. Again, the share of ABC moves through the chain fromSeller410 toBuyer420 via the component atomic movements of480A,481A,482A,483A,484A, and485A while the $100 moves through the chain fromBuyer420 toSeller410 via the component atomic movements of480B,481B,482B,483B,484B, and485B.
• Unlike current market inefficiencies show inFIG. 8, the present system eliminates the sequential settlement necessitated by DVP, allowing each intermediary participant to net their obligations. The lack of sequential settlement of six (6) component transactions and netting allows each intermediary participant to not extend credit, as none of them need to source the payment of cash from their own liquidity. Further, as the entire transaction is settled all at once, there is no longer any bankruptcy, delivery, counterparty, or performance risk, as there is no longer any chance that one or more of the participants may declare bankruptcy or otherwise fail to perform during the processing of the six (6) sequential transactions. As the assets are committed to the transaction, and as the timing of each movement component atomic transaction coincides with each other component atomic transaction, there are no extensions of clearing credit, no counterparty risks, no delivery risks, no buy-in risks, and no settlement risks during the settlement cycle.
• Therefore, the present system may mitigate the risk of non-performance of nodes in the transaction. Example risks may include risks that the node obligated to deliver a token may fail to deliver such token due to factors such as system/computer failures, electrical outages, communications disruptions or human/operator error.
Settlement Facility
• The efficiencies of some embodiments of the present disclosure may only extend to the entities that are part of the same distributed ledger system or have their transactions monitored and calculated by the Computational Node. In practicality, there can be many entities who may not have such access to the system. Thus, the present disclosure contemplates a settlement facility to allow participation without having to adopt the distributed ledger system or subject an entity's transaction processes to monitoring and calculation by the Computational Node.
• FIG. 11 shows a hybrid settlement of the same transaction described inFIG. 9 where only the entities operatingNode C550,Node E560, andNode D570 participate in the system.Participant A510,Participant B530,Participant F540, andParticipant G520 either use existing technology or another system without the benefit of atomic settlement.
• This hybrid settlement shows the benefits of atomic transactions and the inefficiencies of current market infrastructure all in a single scenario. The start of the settlement arc, fromParticipant A510 toParticipant B530 and fromParticipant B530 toNode C550 still consists of two (2) separate transactions,First Move580 andSecond Move581. BothParticipant B530 andNode C550 may extend or lend their own token XYZ, source, or otherwise extend their own liquidity to purchase token XYZ in order to fulfil their obligations to settle the First and Second Moves580C and581C, respectively, in order to settle their obligations in these two (2) trades. As all parties bear counterparty risk, performance risk, and system failure risk forParticipant B530 andNode C550,Participant B530 can impose margin or collateral requirements onParticipant A510 for the transaction, just asNode C550 can impose margin or collateral requirements onParticipant B530. Just as before, neitherParticipant B530 orNode C550 can extinguish their loan of token XYZ until the completion of the subsequent transaction. Similarly, at the end of the settlement arc, theFourth Move584 betweenNode E560 andParticipant F540 might require the extension ofcredit584C byParticipant F540, creating counterparty risk for all parties and buy-in risks forNode E560 andParticipant F540, resulting in margin requirements forParticipant G520 andParticipant F540.
• In contrast, the middle of the settlement arc,Third Move583 betweenNode C550 andNode D570 and betweenNode D570 andNode E560, when broken up into atomic transactions performed via the present system, requires no extensions of credit byNode D570, althoughNode E560 may extend lend their own token XYZ, source, or otherwise extend their own liquidity to purchasetoken XYZ583C in order to fulfil their obligations to settle the Third Move. This loan of token XYZ can only be extinguished upon the completion ofFourth Move584. However, for the exchange of token ABC fromNode C550 through toNode E560 against the exchange of token XYZ fromNode E560 through toNode C550, none ofNode C550,Node D560, andNode E570 have counterparty risk, settlement risk, delivery risk, performance risk, or risk of system failure. In order to initiate theThird Move583,Node C550 may have token ABC andNode E560 may have token XYZ. If either token is not available or is not Locked and committed to the move, the Computational Node can see insufficient assets to settle the move and refuse to perform the move. However, once the Computational Node determines that token ABC and token XYZ are available or have been Locked and committed to the move, and once the Computation Node determines that each of theNode C550,Node D560, andNode E570 has or will have the assets necessary to complete its atomic transaction assuming the completion of all atomic transactions, effectively allowing each participant to net its obligations, the Computational Node can alert that Execution Node that the transaction is ready for settlement. The Execution Node can complete all component atomic transactions simultaneously, recording all movements to the distributed ledger in the same block or overall transaction with the same time stamp.
• In order to eliminate the inefficiencies present in a hybrid settlement scenario where only a portion of the trading entities are participants to the distributed ledger system, the present system can contain a settlement facility that allows the participants the benefits of the system without having to fully adopt the system or become members of the of the distributed ledger network directly.
• FIG. 12 shows the same exchange arc of token ABC fromParticipant A610 toParticipant G620 for token XYZ fromParticipant G620 toParticipant A610. Each of the participants,Participant A610,Participant B630,Participant C650,Participant D670,Participant E660,Participant F640, andParticipant G620 are represented on theSettlement Facility680 by their respective Nodes:Participant A610 hasNode A610A,Participant B630 hasNode B630A,Participant C650 hasNode C650A,Participant D670 hasNode D670A,Participant E660 hasNode E660A,Participant F640 hasNode F640A, andParticipant G620 hasNode G620A.
• In this scenario, there is no need for each of the participants to fully utilize or adopt the system for all transfers and settlements of their tokens. Instead,FIG. 12 shows that each participant can remain separate from their nodes, only utilizing theSettlement Facility680 for certain transfers, like the exchange of token ABC for token XYZ in this example.
• The exchange arc is initiated by the transfer oftoken ABC690A byParticipant A610 toNode610A within theSettlement Facility680 and by the transfer oftoken XYZ690B by theParticipant G620 toNode G620A within theSettlement Facility680. Upon the receipt of either matching instructions to initiate the exchange fromParticipant A610 andParticipant G620, or matching instructions from all participants involved (Participant A610,Participant B630,Participant C650,Participant D670,Participant E660, Participant F640), depending on the configuration of the Settlement Facility, the Execution Node can Lock token ABC inNode A610A and commit it towards the ultimate delivery to theNode G620A and Lock token XYZ inNode G620A and commit it towards the ultimate delivery toNode A610A. At the time of settlement, the Execution Node can process the exchange in a manner similar to the scenario described inFIG. 9. Once the Computational Node determines that sufficient assets have been Locked to complete the transaction, the Execution Node can move token ABC through the chain fromNode A610A toNode G620A via the component atomic movements of691A,692A,693A,694A,695A, and696A and token XYZ through the chain fromNode G620A toNode A610A via the component atomic movements of691B,692B,693B,484B,696B and696B.
• Again, the atomic movements need not be sequential. Rather, once the Computational Node, using the Settlement Logic, determines that token ABC and token XYZ have been Locked and committed to the trade and once the Computational Node, using the Settlement Logic determines that each of the parties has or will have the assets necessary to complete its atomic transaction assuming the completion of all atomic transactions, the Computational Node can alert that Execution Node that the transaction is ready for settlement. The Execution Node can complete all component atomic transactions simultaneously, effectively allowing each participant to net its obligations. As the tokens necessary for the exchange are either present or are committed to the transaction, and as the timing of each movement component atomic transaction coincides with each other component atomic transaction, there are no extensions of clearing credit, no counterparty risks, no delivery risks, no buy-in risks, and no settlement risks during the settlement cycle. This holds true as none of the intermediary participants,Participant B630,Participant C650,Participant D670,Participant E660, or their corresponding nodes (Node B630A,Node C650A,Node D670A,Node E660A,Node F640A) need to source or locate any token or lend any token in order to fulfil their obligations in the overall exchange.
• Upon completion of the exchange arc on theSettlement Facility680, theParticipant A610 can withdraw token XYZ697A fromNode A610A at theSettlement Facility680, andParticipant G620 can withdrawtoken ABC697B fromNode G620A at theSettlement Facility680. Note that unlike theFirst Move580 betweenParticipant A510 andParticipant B530 inFIG. 5, there is no extension of credit and no settlement risk betweenParticipant A610 and itsown Node A610A, as token ABC is transferred byParticipant A610 to itsown Node A610A, and as token ABC is removed fromNode A610A only upon the simultaneous exchange for token XYZ. Thus,Participant A610 via its control overNode A610A has either token ABC or token XYZ during the entire time of this exchange arc. The same holds true on the other side of the exchange arc forParticipant G620 and itsNode G620A.
• The key difference provided by theSettlement Facility680, however, is that none of the entities participating in the transaction must change their operating systems to the embodiment system. Instead, each participant entity can be represented in the Settlement Facility by nodes or accounts opened on theSettlement Facility680, thus allowing the system (the Locking, the Computational Node, the Settlement Logic, the Execution Node) to work via theSettlement Facility680. This is more clearly illustrated the Settlement Facility as a route to adoption of the present system by the financial industry as shown inFIG. 13.
• Just as described above,Seller610 is selling a share of ABC, a dematerialized security cleared on aCentral Securities Depository670 toBuyer620 for the purchase price of $100. Each of the participants,Seller610,Buyer620, Seller Introducing Broker (SIB)630, Buyer Introducing Broker (BIB)640, Clearing Member1 (CM1)650, Clearing Member2 (CM2)660, andCSD670 are represented on theSettlement Facility680 by their respective accounts opened and maintained on the books and records of the Settlement Facility680A:Seller Account610A,Buyer Account620A,SIB Account630A,BIB Account640A,CM1 Account650A,CM2 Account660A, andCSD Account670A.
• In this scenario, none of the participants have adopted the present system to replace their current books and records or their method of transaction, but each wish to utilize the present system to settle the sale of ABC share in order to avoid the current market inefficiencies relating to settlement. Thus, the settlement arc is initiated by the transfer of the share ofABC690A bySeller610 to theSeller Account610A at theSettlement Facility680 and by the transfer of $100690B by theBuyer620 to theBuyer Account620A at theSettlement Facility680. Upon the receipt of either matching instructions to initiate the transaction fromSeller610 andBuyer620 or matching instructions from all participants,Seller610,SIB630,CM1650,CSD670,CM2660,BIB640, andBuyer620, depending upon the configuration and permissioning of theSettlement Facility680, the Execution Node can Lock token ABC in theSeller Account610A and commit it towards the ultimate delivery to theBuyer Account620A and Lock the $100 in theBuyer Account620A and commit it towards the ultimate delivery to theSeller Account610A. At the time of settlement, the Execution Node can process the transaction in a manner similar to the scenario described in Diagram4. Once the Computational Node determines that sufficient assets are present or have been Locked to complete the transaction, the Execution Node can move the share of ABC through the chain fromSeller Account610A toBuyer Account620A via the component atomic movements of691A,692A,693A,694A,695A, and696A and the $100 through the chain fromBuyer Account620A toSeller Account610A via the component atomic movements of691B,692B,693B,484B,696B and696B.
• Upon completion of the settlement arc on the Settlement Facility, theSeller610 can withdraw the $100697A from theSeller Account610A at theSettlement Facility670 and theBuyer620 can withdraw the share ofABC697B from the Buyer Account680A at theSettlement Facility680. Note that unlike theSeller SIB Trade580 betweenSeller510 andSIB530 inFIG. 11, there is no extension of credit and no settlement risk betweenSeller610 andSeller Account610A, as the share of ABC is deposited by the Seller in its own account, and as the share of ABC is removed only upon the simultaneous exchange for the purchase price of $100. The same holds true on the other side of the settlement arc forBuyer620 and theBuyer Account620A.
• Again, the atomic movements need not be sequential. Rather, once the Computational Node, using the Settlement Logic, determines that the share of ABC and the $100 have been Locked and committed to the trade and once the Computational Node, using the Settlement Logic determines that each of the parties has or will have the assets necessary to complete its atomic transaction assuming the completion of all atomic transactions, the Computational Node can alert the Execution Node that the transaction is ready for settlement. The Execution Node can complete all component atomic transactions simultaneously, effectively allowing each participant to net its obligations. The Writing Node can record all movements to the distributed ledger in the same block or overall transaction with the same time stamp. As the assets are committed to the transaction, and as the timing of each movement component atomic transaction coincides with each other component atomic transaction, there are no extensions of clearing credit, no counterparty risks, no delivery risks, no buy-in risks, and no settlement risks during the settlement cycle.
• The key difference provided by theSettlement Facility680, however, is that none of the entities participating in the transaction must change their operating systems to become part of the distributed ledger network. Instead, each participant entity can be represented in the Settlement Facility by accounts opened on theSettlement Facility680, thus allowing the present system (the Locking, the Computational Node, the Settlement Logic, the Execution Node, and the Write Node) all to work via theSettlement Facility680.
• FIG. 14 shows that the efficiencies of the Settlement Facility may also hold true in scenarios whereParticipant A710 orParticipant B720 are not part of the same distributed ledger as theSettlement Facility780. Instead, asParticipant B730 either operates a node for Participant A on a different distributed ledger, maintains accounts for Participant A, or otherwise holds tokens on behalf ofParticipant A710A. Similarly,Participant F740 maintains the same720A forParticipant G720.
• To initiate the settlement arc,Participant A710 depositstoken ABC790A in OffChain Node A710A atParticipant B730, andParticipant G720 depositstoken XYZ790B in OffChain Node B720A atParticipant F740.Participant B730 then depositstoken ABC791A intoNode B730A maintained at theSettlement Facility780 where the share is Locked for settlement, whileParticipant F740 depositstoken XYZ791B into Node F740B maintained at theSettlement Facility780 where token XYZ is Locked for settlement. It is important to note that none of the movements thus far,790A,790B,791A, and791B, involve the need to borrow tokens, extend or loan tokens, and thus, none of the movements create any delivery, settlement, counterparty, or system failure risks.Participant A710 has deposited token ABC into itsOff Chain Node710A maintained byParticipant B730 forParticipant A710, whileParticipant B730 has recorded that token ABC belongs to Participant A710 while depositing token ABC toNode B730A at theSettlement Facility780. The same has happened on the other side of the settlement arc withParticipant B720, the OffChain Node G720A,BIB740 andNode F740A.
• Once token ABC has been Locked and/or is available inNode B730A and token XYZ has been Locked and/or is available inNode G740A, the Computational Node, using the Settlement Logic, can recognize that all of the parties to the transaction,Node B730A,Node G740A, theNode C750A, theNode E760A, andNode D770A have, or will have upon the completion of each component transaction, sufficient assets necessary to complete the transaction. Effectively, the Settlement Logic can allowNode C750A,Node E760A, andNode E770A to net their obligations in the settlement arc, withoutParticipant C750,Participant E760 orParticipant D770 having to contribute anything to their respective nodes or borrow or loan any tokens in order to facilitate settlement. The Computational Node can then signal the Execution Node that the transaction is ready for settlement. The Execution Node can move token ABC fromNode B730A toNode C750A, from theNode C750A toNode D770A, fromNode D770A toNode E760A, from theNode E760A toNode F740A, fulfilling componentatomic transactions792A,793A,794A, and795A, respectively. Concurrently, the Execution Node can move token XYZ fromNode F740A toNode E760A, from Node E toNode D770A, fromNode D770A toNode C750A, and fromNode C750A toNode B730A, fulfilling componentatomic transactions795B,794B,793B, and792B, respectively. The Execution Node can record all of these atomic transactions as having occurred simultaneously onto the same block or overall transaction onto the system of record, and the atomic transactions can finish.
• Upon completion of the atomic transactions,Participant B730 may withdrawtoken XYZ796B fromNode B730A on theSettlement Facility780 and place token XYZ on the OffChain Node A710 maintained byParticipant B730 for the benefit ofParticipant A710, whereuponParticipant A710 may withdrawtoken XYZ797B fromNode A710A. The same happens at the other end of the chain with token ABC moving from Node F to OffChain Node G791B and finally to ParticipantG797A. Unlike the current processes, the present system allows all of these movements to be made without the need for any of the parties to borrow or loan tokens in order to facilitate these movements, and allows each of the parties to make these transactions free from settlement, counterparty, system, market, or other risks, including risk of failures to perform.
• The benefits of such hybrid embodiments may more clearly be seen when applied to a same purchase and sale from aSeller710 to aBuyer720 of a dematerialized share of ABC that is registered with a central securities depository (CSD)770 for the purchase price of $100.FIG. 15 shows thesame Settlement Facility780 where theBuyer720 and theSeller710 are not part of the distributed ledger or the Settlement Facility. Instead, theSeller710 maintains anaccount710A at the Seller Introducing Broker (SIB)730, while theBuyer720 maintains anaccount720A at the Buyer Introducing Broker (BIB)740.
• To initiate the settlement arc,Seller710 deposits shareABC790A in theSeller Account710A atSIB730, andBuyer720 deposits $100790B in theBuyer Account720A atBIB740.SIB730 then depositstoken ABC791A into theSIB Account730A maintained at theSettlement Facility780 where the share is Locked for settlement, whileBIB740 deposits the $100791B into the BIB Account740B maintained at theSettlement Facility780 where the $100 is Locked for settlement. It is important to note there that none of the transactions thus far,790A,790B,791A, and791B, involve the extension of credit, or create any delivery or settlement risk: all are free deliveries. Further, it is important to note that ownership of the share of ABC and of the $100 has not changed. Thus, none of the parties thus far have extended any credit or are subject to any counterparty risk.Seller710 has deposited token ABC into itsown account710A atSIB730, whileSIB730 has recorded that ABC share toSeller710 on its books and records and deposited that share into itsfbo customer account730A at theSettlement Facility780. The same has happened on the other side of the settlement arc withBuyer720, theBuyer Account720A,BIB740, and theBIB Account740A.
• Once token ABC has been Locked and/or is available in theSIB Account730A and the $100 has been Locked and/or is available in theBIB Account740A, the Computational Node, using the Settlement Logic, can recognize that all of the parties to the transaction, theSIB Account730A, theBIB Account740A, theCM1 Account750A, theCM2 Account760A, and theCSD Account770A have, or will have upon the completion of each component transaction, sufficient assets necessary to complete the transaction. Effectively, the Settlement Logic can allow theCM1 Account750A, theCM2 Account760A, and theCSD Account770A to net their obligations in the settlement arc, withoutCM1750,CM2760 orCSD770 having to contribute anything to their respective accounts or to extend any credit towards settlement. The Computational Node can then signal the Execution Node that the transaction is ready for settlement. The Execution Node can move the share of ABC from theSIB Account730A to theCM1 Account750A, from theCM1 Account750A to theCSD Account770A, from theCSD Account770A to theCM2 Account760A, from theCM2 Account760A to theBIB Account740A, fulfilling componentatomic transactions792A,793A,794A, and795A, respectively. Concurrently, the Execution Node can move $100 from theBIB Account740A to theCM2 Account760A, from the CM2 Account to theCSD Account770A, from theCSD Account770A to theCM1 Account750A, and from theCM1 Account750A to theSIB Account730A, fulfilling componentatomic transactions795B,794B,793B, and792B, respectively. The Write Node can record all of these atomic transactions as having occurred simultaneously onto the same block or overall transaction onto the system of record, and the atomic transactions can finish.
• As with the beginning of the settlement arc, the end of the settlement arc also does not involve any extensions of credit or counterparty risk. Upon the completion of the atomic transactions, $100 resides in the SIB'sfbo customer account730A at theSettlement Facility780, where that $100 is reflected in the Seller'sAccount710A maintained at theSIB730 for theSeller710. The Seller may withdraw that $100797B, which will result in a withdrawal of $100 from the SIB'sfbo customer account796B. As the $100 belongs to the Seller at the end of the atomic transactions, these withdrawals are made without any extension of credit, counterparty, market, or other risks, including risk of failures to perform. The same is true at the other end of the settlement arc, where the atomic transactions have concluded with Buyer having ownership of the share of ABC. The share of ABC resides in the BIBfbo customer account740A at theSettlement Facility780, and is reflected on the books and records of theBIB740 as belonging to theBuyer720 with a credit to the Buyer's Account maintained for the Buyer by theBIB720A. Should theBuyer720 wish to transfer that share of ABC elsewhere, theBuyer720 may withdraw that share ofABC797A, which necessitates a withdrawal of that share of ABC from the BIBfbo customer account740A. Again, as the share of ABC belongs to the Buyer at the end of the atomic transactions, these withdraws are made without any extension of credit, counterparty, market, or other risks, including risk of failures to perform.
Securities Lending
• Further advantages of the present disclosure can be appreciated in an example of a securities transaction where cash is not part of the proposedtransaction5.FIG. 16 illustrates an example securities lending transaction where aborrower820 wishes to borrow a digital asset/token, such as a share of ABC, from alender810. In this example, theborrower820 may collateralize its borrowing with a digital asset/token, such as a share of XYZ. Theborrower820 may wish to use the digital asset (token ABC) for some purpose and for some limited time, but does not wish to purchase that digital asset, while thelender810, who owns token ABC, is willing to “lend” the share in order to receive a return on the loan.
• Conceptually, this is the exact same transaction as shown inFIG. 6 (thelender810 operatesNode A210, thebroker830 operatesNode B220, and theborrower820 operates Node C230), but the difficulty in processing this transaction in the real world illustrates the need for the present system.
• While the purpose of the delivery of token XYZ (870 and860) from theborrower820 to thelender810 is to offset the delivery risk that the digital asset (token ABC,840 and850) will not be returned and to offset the bankruptcy risk that the borrower cannot fulfil its obligations to return token ABC, the delivery of token XYZ (860 and870) does not necessarily coincide with the delivery of token ABC (840 and850). These deliveries are each made free of payment, are not contingent upon each other, not simultaneous, not sequential and, from a purely operational perspective, unrelated. One may happen without the other, leaving one party or node with both the borrowed security and the collateral, and until both legs of the transactions are settled, there is no mitigation of any system failure or of the delivery, settlement, bankruptcy, and other risks the delivery of token XYZ as collateral was supposed to provide. In the event theborrower820 becomes bankrupt after it receives token ABC but before delivering token XYZ, thelender810 does not have any collateral to offset its risk and losses.
• The reason for this risk is the lack of a widespread mechanism for the simultaneous exchange of securities for securities. The main mechanism for simultaneous exchange only applies to binary transactions between two (2) parties and only as an exchange of securities for cash payment, commonly called “delivery versus payment” or “DVP” or “receive versus payment” or “RVP.” The current systems do not support securities versus securities or cash versus cash. As the present system can transfer tokens and other digital assets that may represent securities, cash, and other items, the present system may be utilized to address this lack in the current systems.
• Without the present system, to address such risks described above, the prior art has attempted to use DVP/RVP functionality as a mitigant. As shown inFIG. 17, thelender910 and theborrower920 have turned the delivery oftoken ABC940A and941A and the delivery oftoken XYZ942A and943A into two (2) DVP/RVP transactions by adding offsetting cash legs, represented by token DEF,940B and941B to offset940A and941A, and942B and943B to offset942A and943A. When thelender910 deliverstoken ABC940A and941A to theborrower920, theborrower920 transfers market value of token ABC, $100940B and9041B to thelender910, and when the borrower deliverstoken XYZ942A and943A to thelender910, the lender deliverstoken DEF942B and943B to the borrower. These interveningcash legs940B,941B,942B, and943B offset the bankruptcy, delivery, and settlement risks in the original securities lending scenario. In the event theborrower920 becomes bankrupt before it can delivertoken XYZ942B and943B, at the very least thelender910 will have the cash (token DEF) that was the market approximation of the value of the ABC share it delivered.
• While these cash legs mitigate the risk that one party or the other is bankrupt, the end result is essentially two (2) sale transactions, with all of the attendant risks and market inefficiencies, but doubled for a single securities lending transaction. In order to initiate the first DVP transaction fortoken ABC940A, thebroker930 must extend $100 credit to purchase token ABC from thelender940B. This extension of credit is only extinguished by the settlement of the sale of token ABC to theborrower941A, where the borrower has to inject $100 of its liquidity9041C in order to pay thebroker930 for token ABC9041A. The borrower's liquidity drain is only extinguished when thebroker930 pays theborrower942B in exchange fortoken XYZ942A, and the broker must yet again extend itscredit942C to finance this transaction. This extension of credit by thebroker942C is only extinguished by the settlement oftoken XYZ943A with thelender910, when thelender910 pays $100 fortoken XYZ943B.
• Note that the same cash essentially makes a round trip among theparties941B,940B,943B, and942B, but because the sequential nature of the DVP/RVP settlement followed the order necessary to move the securities instead of the flow of the cash, there were three (3) extensions of credit/injections of liquidity for cash movements that would otherwise net to zero. Additionally, in comparison to a purchase/sale transaction, the borrower must have twice the resources to settle this securities lending transaction, even though cash was not contemplated in the original securities lending transaction and even though the cash will eventually be returned. Each such extension of credit/injection of liquidity brings with it, capital and liquidity charges, counterparty risks, settlement risks, and market risks.
• The efficiencies of embodiments of the present disclosure in processing the same securities lending transaction as compared with existing systems may be evident to one of ordinary skill. First, the Computational Node can recognize that the securities lending transaction shown inFIG. 16 comprises four (4) proposed component transactions:840,850,860, and870. Once theComputational Node3 has determined that the necessary assets have been locked and/or committed and are available to complete each of proposed component atomic transactions, it can pass notice of the acceptable transaction to the Execution Node. Upon receipt of the acceptable transaction, the Execution Node can process all proposed component transactions simultaneously, by recording each movement of each proposed component transactions to the distributed ledger within the same block or overall transaction so that each proposed component transaction bears the same timestamp. Because all proposed component transactions are executed within the same block or overall transaction, there is never a time where any entity lender (operating Node A810), borrower (operating Node C)820, or broker (operatingNode B)830 have both token ABC or token XYZ, eliminating the settlement, bankruptcy, counterparty and other risks in the present settlement of securities lending transactions. As these risks have been eliminated, there is no need to add the cash legs to convert the securities lending transaction into DVP/RVP segments, and some (or even all) of the market inefficiencies associated with such cash conversion shown inFIG. 19 can be avoided.
• The benefits of the present system are more clearly demonstrated in a more typical securities lending transaction in the far more realistic and far more likely event that thelender1010 and theborrower2020 do not share the same broker. In a more realistic scenario shown inFIG. 18, lender,node A1010 is lending token ABC to borrower, Node G,2020 who will pledge token XYZ tolender1010 as collateral.Lender1030 trades through its introducing broker (LIB)1030, while borrower trades through a different introducing broker (BIB)1040. SIB settles its trades through Clearing Member1 (CM1)1050, while BIB settles its trades through Clearing Member2 (CM2)1060. CM1 and CM2 are members of the Central Securities Depository (CSD)1070.
• As shown inFIG. 17, because the movement of token ABC fromlender1010 along the settlement arc toborrower2020 is independent of the movement of token XYZ fromborrower2020 tolender1010, thelender1010 and theborrower2020 are subject to the risk of failure by the system, each other, and all other entities involved in the settlement arc. To mitigate such risk, thelender1010 and theborrower2020 may require the exchange for cash (shown onFIG. 18 as DEF) for tokens ABC and XYZ. The net result is two (2) settlement arcs that resemble the sale transaction depicted inFIG. 8, for the sale of token ABC fromlender1010 tobuyer2020 and the sale token XYZ frombuyer2020 tolender1010.
• As shown previously inFIG. 7, the transfer of token ABC fromlender1010 toborrower2020 is again broken up into stages, with sequential transactions between lender andLIB1080, LIB andCM11081, CM1 andCSD1082, CSD andCM21083, CM2 andBIB1084, and BIB andborrower1085. Each of thetransactions1080,1081,1082,1083,1084, and1085 includes movement of token ABC along the chain in the direction from lender towards borrower (in order,1080A,1081A,1082A,1083A,1084A, and1085A) against the movement of the cash price, depicted as DEF in the opposite direction (in order,380B,381B,382B,383B,384B, and385B). Because theborrower2020 originates the cash and because the transaction with theborrower2020 occurs last in thesequence1085, each ofLIB1030,CM11050,CSD1070,CM21060, andBIB2020 extends clearing credit to initiate each of their respective transactions:LIB1030 must extend $100clearing credit1080C in order to pay tolender1010 the $1001080B and settle thelender LIB trade1080;CM11050 must extend $100clearing credit1081C in order pay toLIB1030 the $1001081B in order to settle theLIB CM1 trade1081; although CSDs may have other means of settlement like end of day net settlement, in order for a CSD not to delay settlement theCSD1070 must extend $100clearing credit1082C in order to payCM11050 the $1001082B in order to settle theCM1 CSD trade1082; CM21060 must extend $100clearing credit1083C in order to pay theCSD1070 the $1001083B in order to settle theCSD CM2 trade1083, andBIB2020 must extend $100clearing credit1084C in order to payCM21060 the $1001084B in order to settle theCM2 BIB trade1084. Each extension of clearing credit cannot be extinguished until the completion of the next transaction in the chain.
• UnlikeFIG. 7, however, the securities lending transaction doubles the inefficiencies by turning the transfer of token XYZ fromborrower2020 tolender1010 into DVP transfer of token XYZ fromborrower2020 tolender1010. The same inefficiencies described above for token ABC are enacted in reverse, with each of thetransactions1090,1091,1092,1093,1094,1095 moving token XYZ in stages between each bilateral pair ofborrower2020 and BIB1040 (trade1090), with the BIB extending clearing credit,BIB1040 and CM21060 (trade1091), withCM21060 extending clearing credit, withCM21060 and CSD1070 (trade1092) with theCSD1070 extending clearing credit to avoid end of day net processing, withCSD1070 and CM21050 (trade1093) with CM2 extending clearing credit, withCM21050 and LIB1030 (trade1094) with LIB extending clearing credit, and finally withlender1010 and LIB1030 (trade1095).
• As stated previously, it is important to note the significant inefficiencies created by current market infrastructure that are magnified, simply due to the sequencing of each DVP transaction and the inability for current market infrastructure to operate as a whole. These inefficiencies are doubled simply because current infrastructure has no mechanism for securities for securities transactions as DVP supports only cash for securities. The number of sequential transactions can also lead to delay in completion of the process and pose a security risk. This may be compounded if the sequential transactions follow a predictable pattern whereby the predictable pattern may be exploited by unscrupulous nodes. Furthermore, as demonstrated in this example, extensions of credit in the marketplace is multiples (totaling $1000 to settle a $100 trade) of the actual trade, tying up liquidity that could be used for other purposes. As each of the entities extending credit faces settlement, counterparty, and delivery risks, each entity, in turn, charges margin to mitigate these risks, creating additional liquidity drains in the form of margin postings. These risks are magnified forLIB1030,BIB1040,CM11050,CM21060, andCSD1070, the settlement entities, as they become committed to the trade upon the date the transaction is agreed (T) even though the settlement doesn't occur for another two (2) days (T+2). The result is that the settlement entities require margin from their customers and participants not just for the credit extensions during the settlement cycle, but for the added counterparty and delivery risks. The margin requirements further magnify the multiples of inefficiencies in the system. AlthoughLIB1030,BIB1040,CM11050,CM21060, andCSD1070 typically would net their obligations to deliver token ABC and token XYZ across their trading book (FIG. 8 shows the transaction as if only one token ABC and XYZ was available for trade), the risks borne by and the credit extensions made by each entity remains, and each entity imposes margin on its customer and/or posts margin for these reasons.
• Given the magnified inefficiencies in securities lending, some market participants have attempted to streamline the process by utilizing a triparty securities loan custodian1180 to facilitate the transfer of collateral.FIG. 19 illustrates this attempt at a solution where token ABC is transferred via the open market settlement chain fromlender1110 toborrower1120 via the LIB1130,CM11150,CSD1170,CM21160,BIB1140 with all of the attendant issues and inefficiencies described previously. The collateral for token ABC, token XYZ, however, is transferred via the triparty securities loan custodian1180. This structure results in the combination of the inefficiencies shown inFIG. 5 andFIG. 7, but such combination is still an improvement over the inefficiencies inFIG. 18. Note that token ABC cannot be transferred via the triparty securities loan custodian as theborrower1120 needs to utilize token ABC and needs to receive it in a true open market transaction: token XYZ remains on the books and records of the triparty securities loan custodian1180 even if it is ledgered tolender1110.
• The issues illustrated inFIG. 18 and in the current industry's attempt to solve such problems inFIG. 19 reveal the need for the present system.FIG. 20 shows how embodiments of the present disclosure may reduce, or even eliminate, these inefficiencies. Afterlender1010 andborrower2020 agree upon the securities lending transaction of token ABC for token XYZ, the Computational Node can calculate the individual component atomic transactions that comprise the movement of token ABC fromlender1010 to borrower2020 (1080,1081,1082,1083,1084, and1085) and of token XYZ fromborrower2020 to lender1010 (1090,1091,1092,1093,1094, and1095). Applying the Settlement Logic, the Computational Node can examine each node (lender1010,LIB1030,CM11050,CDS1070,CM21060,BIB1040, and borrower2020) to see if each node has sufficient tokens or digital assets to fulfil its obligations to all component atomic transactions involving it. Each ofLIB1030,CM11050,CDS1070,CM21060, andBIB1040 can receive and transfer the exact same tokens and digital assets, leaving a net obligation of zero, and unlike current infrastructure, none of them will have to extend any credit or bear any risk to settle this transaction. Once the Computational Node has determined thatlender1010 has token ABC and thatborrower2020 has token XYZ, the Computational Node can mark the transaction as passing its individual components. At the time of execution, the Execution Node can execute the trade, and can write, or cause the Write Node, as applicable, to write all component atomic transactions onto a single block or the same overall transaction, all with the same timestamp.
• Embodiments of the present disclosure may thus solve the securities loan transactions with fewer (even zero) risks of default, fewer (even zero) credit extensions, and fewer (even none) of the resulting inefficiencies associated with those risks.
Multi Originator and Multi Receiver Transactions
• Existing infrastructure has no solution to protect against systemic failures in non-binary transactions where the node providing a token to a second node receives a token in return from a third node. All current infrastructure has provided for the simultaneous exchange of a single step transaction where a pair of nodes exchange tokens as a means ensuring that neither node has possession of none or both tokens, meaning that both nodes are protected in the event of a system or other failure to complete the exchange of tokens. This current protection, however, does not cover events involving more than one ultimate provider of tokens, more than one ultimate receiver of tokens, more than two tokens being exchanged, or combinations of any of the foregoing.
• FIG. 21 illustrates an example where Node A1301 deliverstoken ABC1350 toNode B1320. In exchange for token ABC, Node A1301 can receivetoken JKL1380 fromNode D1340. This is a shift from current infrastructure, asNode A1310 bears the risk of performance ofNode D1340, even though Node A's1310 obligation is to perform forNode B1320. Similarly,Node B1320 is obligated to deliver token DEF toNode C1330 in exchange for receivingtoken ABC1350 fromNode A1310.Node C1330 is obligated to delivertoken GHI1370 toNode E1340 in exchange for the receivingtoken DEF1360 fromNode B1320. Finally,Node D1340 is obligated to delivertoken JKL1380 toNode A1310 in exchange for receivingGHI1370 from Node C.
• In this transaction, any node that transfers its token first bears the risk of nonperformance or system failure until the node in the circle behind it performs. Current market infrastructure may attempt to solve this issue by creating an artificial exchange of a common and otherwise unnecessary token in the opposite direction of the transaction, e.g. token ABC for token XYZ betweenNode A1310 andNode B1320, token DEF for token XYZ betweenNode B1320 andNode C1330, token GHI for token XYZ between Node C1330 andNode D1340, and token JKL for token XYZ betweenNode D1340 andNode A1310. Introducing token XYZ effectively converts the transaction into four (4) separate binary transactions that may be protected under current infrastructure. However, in doing so, the conversion also creates the inefficiencies attendant to current infrastructure, forcing each ofNode A1310,Node B1320,Node C1330, andNode D1340 to source and lend token XYZ, a token unnecessary to the original transaction but for the need to protect each participating node from the failure of the other nodes or of the system.
• The present system may solve this transaction without the need for an extraneous token and without any of the risks, potential failures, or inefficiencies required by current infrastructure. Once the transaction has been agreed upon, the Computational Node can break the transaction into its component atomic transactions,1350,1360,1370, and1380. The Computational Node can then query each of the nodes to ascertain that they have sufficient tokens or digital assets to meet the requirements of each component atomic transaction affecting such node. In this example,Node A1310 may have token ABC,Node B1320 may have token DEF,Node C1330 may have token GHI, andNode D1340 may have token JKL. Once verified, the Computational Node can mark each node as successful. At the time of execution, the Execution Node can make each movement of the tokens, and write, or have the Write Node write, as applicable, each of the component atomic transactions to the same block or overall transaction, all with the same timestamp. None of the nodes bear risk of failure or must source and/or lend any additional tokens to the transaction.
• FIG. 22 shows the same transaction asFIG. 21 with the same four (4) nodes,Node A1401,Node B1402,Node C1403, andNode D1404 transferring tokens ABC, DEF, GHI, JKL in the same exact pattern, with the difference thatNode A1401 may transfer token ABC toNode B1402 viaIntermediary Node F1411, Node B may transfer token DEF to Node C via Intermediary Node G1412, Node C may transfer token GHI to Node D viaIntermediary Node H1413, andNode D1404 may transfer token JLK toNode A1401 viaIntermediary Node I1414. As before, each of the ultimate token providers,Node A1401,Node B1402,Node C1403, andNode D1404, can take risks of non-performance of the prior node that is delivering tokens to it. The additional complexity ofFIG. 22 stems from the intermediary nodes, representing a system where the ultimate provider nodes are unable to directly transfer their tokens to the ultimate receiver nodes, and instead utilize one or more intermediary nodes in order to do so.
• Under current infrastructure, entities can either accept the risk of non-performance, system failure, or loss or they would again attempt to solve this issue by creating an artificial exchange of a common and otherwise unnecessary token in the opposite direction of the transaction. Thus, the movement oftoken ABC1421A fromNode A1401 toIntermediary Node F1411 would be made in exchange for token XYZ fromIntermediary Node F1411 toNode A1401, forcingIntermediary Node F1411 to source, loan, and extend token XYZ as credit. The subsequent movement oftoken ABC1421B fromIntermediary Node F1411 toNode B1402 would also be made in exchange for token XYZ fromNode B1402 toIntermediary Node F1411, forcingNode B1402 to source, loan, and extend token XYZ as credit. Intermediary Node F's1141 extension of token XYZ credit is only extinguished upon the completion of the delivery oftoken ABC1421B toNode B1402 in exchange for token XYZ. The same sequential transactions occurs for token DEF, GHI, and JKL, breaking the one transaction exchanging four (4) securities between four (4) parties into eight (8) exchanges, forcing each of the eight (8) nodes to source, loan, and extend XYZ as credit in order to ensure that any one node is not left with nothing should there be a failure of one or more of the other seven (7) nodes or of the system itself. The attenuating inefficiencies of the system is made clear that except for its role as collateral against system or node failure, token XYZ is not part of the original transaction and completely nets out upon the completion of the transaction.
• As demonstrated previously, the present system may solve this transaction without the need for an extraneous token and without any of the risks, potential failures, or inefficiencies required by the current infrastructure. For example, the present system may mitigate the risk of non-performance of nodes due to factors such as system or computer failures, electrical outages, communication disruptions or human/operator error.
• Once the transaction has been agreed upon, the Computational Node can break the transaction into its component atomic transactions:1421A,1421B,1422A,1422B,1423A,1423B,1424A, and1424B. The Computational Node can then query each of the nodes to ascertain that they have sufficient tokens or digital assets to meet the requirements of each component atomic transaction affecting such node. In this example,Node A1310 may have token ABC,Node B1320 may have token DEF,Node C1330 may have token GHI, andNode D1340 may have token JKL.Intermediary Node F1411, Intermediary Node G1412,Intermediary Node H1413, andintermediary Node I1414 all have the matching inflows and outflows of tokens and digital assets, resulting in a net requirement of zero, passing the query made by the Computational Node. Once verified, the Computational Node can mark each node as successful. At the time of execution, the Execution Node can make each movement of the tokens, and write, or have the Write Node write, as applicable, each of the component atomic transactions to the same block or overall transaction, all with the same timestamp. None of the nodes bear risk of failure or must source and/or lend any additional tokens to the transaction.
Exemplary Node
• FIG. 23 illustrates an example computer node102. The node102 may be any node in any of the systems disclosed herein, including any ofnodes3,9,11,17,19. As shown inFIG. 23, the node102 can include aprocessor2402, amemory2403, anetwork interface device2408, a distributedledger interface device2409 that interfaces with the distributed ledger and auser interface2410. The memory can storeinstructions2404 anddata2406, and theprocessor2402 can perform the instructions from the memory to implement any of the processes described herein.
• The embodiments can include computer-executable instructions, such as routines executed by a general or special-purpose data processing device (e.g., a server or client computer). The instructions can be stored in a non-transient manner or distributed on tangible computer-readable media, including magnetically or optically readable computer discs, hard-wired or pre-programmed chips (e.g., EEPROM semiconductor chips), nanotechnology memory, biological memory, or other data storage media.
• The data may be provided on any analog or digital network (e.g., packet-switched, circuit switched, or the like). The embodiments can be practiced in distributed computing environment where tasks or modules are performed by remote processing devices, which are linked through a communications network, such as a Local Area Network (“LAN”), Wide Area Network (“WAN”), or the Internet. In a distributed computing environment, program modules or subroutines may be located in both local and remote memory storage devices. The embodiments can be implemented as software as a service (SaaS) in a cloud computing environment. Those skilled in the relevant art will recognize that portions of the described technology may reside on a server computer, while corresponding portions reside on a client computer (e.g., PC, mobile computer, tablet, or smartphone).
• The information described herein can be transmitted and stored as data structures. Various messaging protocols can be used and each transaction can include a transaction message that includes the sender's digital signature, a recipient address (e.g., a hash value based on the receiver's public key). Transaction messages can be digitally signed by the sender's private key to create a digital signature for verifying the sender. The messages can be decrypted using the digital signature via the sender's public key to verify authenticity in a known manner.
• The computing devices can include a personal computer, workstation, phone, or tablet, having one or more processors coupled to one or more memories storing computer-readable instructions. The various devices can be communicatively coupled in a known manner as via a network. For example, network hubs, switches, routers, or other hardware network components within the network connection can be used.
• In general, the description of embodiments of the software and/or hardware facilities is not intended to be exhaustive or to limit the technology to the precise form disclosed above. While specific embodiments of, and examples for, the technology are described above for illustrative purposes, various equivalent modifications are possible within the scope of the software and/or hardware facilities, as those skilled in the relevant art will recognize. The teachings of the software and/or hardware facilities provided herein can be applied to other systems, not necessarily the system described herein. The elements and acts of the various embodiments described herein can be combined to provide further embodiments.
Examples not Exclusive
• It will be appreciated by persons skilled in the art that numerous variations, combinations, and/or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive. In addition, it is to be appreciated that features from any of the embodiments or examples can be shared or combined with features from any other embodiment or example in ways that would be appreciated by a person of skill in the art.
• Specifically, although the examples showed the application of the present system to settlement chains of two (2), three (3), and seven (7) nodes, the present system may settle transactions atomically for chains containing any positive numbers of nodes with any positive number of intermediary nodes in the same manner as described. Additionally, although the examples show the application of the present system to transactions with two (2) and four (4) nodes as ultimate token providers and with two (2) and four (4) nodes ultimate token receivers over zero (0) and four (4) intermediary nodes, the present system may settle transactions atomically for any positive number of nodes as ultimate token providers, ultimate token receivers, and intermediaries in the manner as described. Finally, although the examples showed the nodes serving as ultimate token providers also receiving tokens as ultimate token receivers, the present system applies equally to scenarios where nodes that are ultimate token providers are not also ultimate token receivers, nodes that are ultimate token receivers do not provide nodes, and intermediary nodes for some tokens in the transactions may also be ultimate token providers and/or ultimate token receivers for other nodes in the transaction.

Claims (22)

1. A computer system to settle a transaction that transfers a plurality of digital assets comprising:

a computational node including a processor and memory, the computational node configured to:

receive a notification of a proposed transaction, wherein the proposed transaction transfers the plurality of digital assets from one or more transferring computer nodes to one or more receiving computer nodes, each of the transferring computer nodes and receiving computer nodes belonging to a network of nodes that maintain a distributed ledger, the proposed transaction comprising a plurality of proposed component atomic transactions that atomically transfer at least a portion of the plurality of digital assets from the one or more transferring nodes to the one or more receiving nodes;

determine at least one digital lock associated with the proposed transaction, wherein when activated the digital lock prevents transfer of any of the plurality of digital assets to any transferring or receiving computer node that is not a participant designated to receive or transfer at least some of the plurality of digital assets for purposes of the proposed transaction;

at least in part determine or verify that:

each transferring and receiving computer node is cryptographically authorized to receive and/or transfer at least some of the plurality of digital assets, and that the digital lock is activated; and

each transferring and receiving computer node involved in the proposed transaction has a sufficient amount of the plurality of digital assets to fulfill all of the transferring or receiving computer node's obligations under each proposed component atomic transaction involving such node; and

based on the verification, send an authorization notification to at least one execution node to cryptographically unlock the activated digital lock and transfer the plurality of digital assets from the transferring computer nodes to the receiving computer nodes to settle the proposed transaction.

2. A computer system according toclaim 1, wherein the computational node is further configured to determine the plurality of proposed component atomic transactions.

3. A computer system according toclaim 1, wherein each of the plurality of proposed component atomic transactions is associated with one or more digital locks.

4. A computer system according toclaim 2 or3, wherein at least a first of the digital locks associated with the plurality of proposed component atomic transactions, when activated, is operable to prevent transfer of a first subset of the plurality of digital assets in other proposed component atomic transactions.

5. The computer system according toclaim 1, wherein each of the proposed component atomic transactions, when executed, are configured for recordation in the distributed ledger at the same time.

6. The computer system according toclaim 5, wherein each of the proposed component atomic transactions, when recorded to the distributed ledger, has a common time stamp.

7. The computer system according toclaim 1, wherein the computational node or the execution node is further configured to:

schedule the cryptographic unlocking of the activated digital lock to prevent the transfer of any of the plurality of digital assets for purposes other the proposed transaction.

8. The computer system according toclaim 1, wherein the distributed ledger is a blockchain and the proposed component atomic transactions are recorded on a same block of the blockchain.

9. The computer system according toclaim 1 further comprising:

at least one execution node to:

cryptographically unlock the activated digital lock; and

transfer the plurality of digital assets from the transferring computer nodes to the receiving computer nodes to settle the proposed transaction, wherein the transfer comprises atomically executing all of the proposed component atomic transactions.

10. The computer system according toclaim 1, wherein the computational node and the execution node share at least one common processor.

11. A computer-implemented method to facilitate settlement of a transaction involving a plurality of digital assets, the method comprising:

receiving a notification of a proposed transaction, wherein the proposed transaction transfers the plurality of digital assets from one or more transferring computer nodes to one or more receiving computer nodes, each of the transferring computer nodes and receiving computer nodes belonging to a network of nodes that maintain a distributed ledger, the proposed transaction comprising a plurality of proposed component atomic transactions that atomically transfer at least a portion of the plurality of digital assets from the one or more transferring nodes to the one or more receiving nodes;

at least in part determining or verifying that:

each transferring and receiving computer node is cryptographically authorized to receive and/or transfer at least some of the plurality of digital assets; and

each transferring and receiving computer node involved in the proposed transaction has a sufficient amount of the plurality of digital assets to fulfill all of the transferring or receiving computer node's obligations under each proposed component atomic transaction involving such node; and

based on the verification, sending an authorization notification to at least one execution node to transfer the plurality of digital assets from the transferring computer nodes to the receiving computer nodes to settle the proposed transaction.

12. The method ofclaim 11, further comprising the steps of:

determining at least one digital lock associated with the proposed transaction, wherein when activated the digital lock prevents transfer of any of the plurality of digital assets to any transferring or receiving computer node that is not a participant designated to receive or transfer at least some of the plurality of digital assets for purposes of the proposed transaction.

13. The method ofclaim 11, wherein the computational node is further configured to:

determine the plurality of proposed component atomic transactions.

14. The method ofclaim 13, wherein the computational node determines the plurality of proposed component atomic transactions by:

mapping a route for the transfer of the plurality of digital assets from the one or more transferring computer nodes to the one or more receiving computer nodes, wherein each transfer of each of the plurality of digital assets from any transferring computer node to any receiving computer node in the network comprises a proposed component atomic transaction.

15. The method ofclaim 14, wherein the computational node determines the route by:

testing connections between transferring computer nodes and receiving computer nodes in the network to determine which nodes support the transfer of the plurality of digital assets.

16. The method ofclaim 11, wherein to at least in part determine or verify that each transferring and receiving computer node has a sufficient amount of the plurality of digital assets comprises:

for a given transferring or receiving computer node that is participant to the proposed transaction:

determining a sum of inbound digital assets that the given node is a participant designated to receive or transfer;

determining a sum of outbound digital assets that the given node is a participant designated to receive or transfer; and

determining a result by subtracting the sum of outbound digital assets from the sum of inbound digital assets.

17. The method ofclaim 16, wherein the result is determined by subtracting the sum of outbound digital assets from the sum of inbound digital assets for digital assets of a same type.

18. The method ofclaim 16, wherein:

when the result is positive or neutral, the computational node determines that the given node has a sufficient amount of the plurality of digital assets.

19. The method ofclaim 16, wherein determining or verifying that each transferring and receiving computer node has a sufficient amount of the plurality of digital assets further comprises the steps of:

determining an initial transferring node of the inbound digital assets to the given node; and

determining whether the initial transferring node has a sufficient amount of the inbound digital assets available for transfer to the given node.

20. The method ofclaim 16, wherein determining or verifying that each transferring and receiving computer node has a sufficient amount of the plurality of digital assets further comprises the steps of:

determining one or more initial transferring nodes that have the plurality of digital assets for the proposed transaction; and

determining whether the one or more initial transferring node(s) have the respective plurality of digital assets available for transfer to the given node.

21. A computer-implemented method to facilitate settlement of a transaction involving a plurality of digital assets, wherein the transaction is based on a proposed transaction comprising a plurality of proposed component atomic transactions that each atomically transfer at least some of the plurality of digital assets from one or more transferring computer nodes to one or more receiving computer nodes, wherein each of the transferring computer nodes and receiving computer nodes belong to a network of nodes that maintain a distributed ledger, the method comprising:

receiving an authorization notification to transfer the plurality of digital assets from the transferring computer nodes to the receiving computer nodes to settle a proposed transaction, wherein the authorization notification is based on a verification that:

each transferring and receiving computer node is cryptographically authorized to receive and/or transfer at least some of the plurality of digital assets; and

each transferring and receiving computer node involved in the proposed transaction has a sufficient amount of the plurality of digital assets to fulfil all of the transferring or receiving computer node's obligations under each proposed component atomic transaction involving such node;

determining an authorization to transfer the plurality of digital assets from the transferring computer nodes to the receiving computer nodes; and

based on the authorization, atomically transferring the plurality of digital assets from the transferring computer nodes to the receiving computer nodes to settle the proposed transaction.

22. A non-transitory computer-readable medium comprising program instructions that, when executed, cause a computer to perform the method ofclaim 11.

Images