Blockchain solutions for financial services and other transactions-based industries

Abstract

A system and a method for creating a holistic, flexible, scalable, confidential, low-latency, high-volume, immutable distributed ledger for the financial services and other industries. The system allows a scalable blockchain solution with respect to accessible memory requirements of distributed ledgers or distributed databases with confidentiality in the shared records as well as accommodating low-latency, high-capacity transaction capabilities. The method includes a fundamental, generic, logical representation of financial services life-cycles transactions in terms of variable sets of four simple, sequential components. The optimal process generates a self-validating, variable n-dimensional, multi-hash-linked, interdependent distributed ledger that allows the individual network participants to recreate the ledger without having to refer to or confirm with other network participants.

1 . A method for operating a transaction-driven, self-validating distributed ledger system comprising a network of multiple nodes, wherein each of first and second nodes, when transacting with each other or recording the transactions of a hosted transaction party transacting with another transacting party, can independently broadcast a complementary contra-transaction such that either of the first and second nodes, upon receipt of both contra-transactions, can independently validate the transactions and update the distributed ledger, the method comprising:
 (a) generating in the first node a first set of contra-transaction data, including the first node's contra-transaction block's unique ledger address and hash-link, which first set of contra-transaction data is complementary to a second set of contra-transaction data for a transaction, wherein the contra-transaction data of the first set comprises data overtly identifying the first node and covertly identifying the second node, data identifying an asset, data representing an amount of value and other data;   (b) generating in the second node the second set of contra-transaction data, including the second node's contra-transaction block's unique ledger address and hash-link, which second set of contra-transaction data is complementary to the first set of contra-transaction data for the transaction, wherein the contra-transaction data of the second set comprises data overtly identifying the second node and covertly identifying the first node, data identifying the asset and data representing the amount of value and other data;   (c) generating in the first node a first private key encrypted hash of a message comprising the first set of transaction data as a covert additional matching control;   (d) generating in the second node a second private key encrypted hash of a message comprising the second set of transaction data as a covert additional matching control;   (e) sharing the first private key encrypted hash with the second node;   (f) sharing the second private key encrypted hash with the first node;   (g) generating in the first node delivery contra-transaction data for the transaction, which delivery contra-transaction data comprises the first set of transaction data, including the first node's contra-transaction block's unique ledger address and hash-link in the first node's blockchain, and the second private key encrypted hash and does not identify the second node;   (h) generating in the second node receipt contra-transaction data for the transaction, which receipt contra-transaction data comprises the second set of transaction data, including the second node's contra-transaction block's unique ledger address and hash-link in the second node's blockchain, and the first private key encrypted hash and does not identify the first node;   (i) broadcasting the delivery contra-transaction data to the network;   (j) broadcasting the receipt contra-transaction data to the network;   (k) receiving the broadcast delivery and receipt contra-transaction data at the first and second nodes and a third node in the network;   (l) matching the broadcast delivery and receipt contra-transaction data in one or more of the first, second and third nodes;   (m) validating the delivery contra-transaction data in the second or third node by decrypting the second encrypted hash to generate a first hashed message, hashing the second set of transaction data to generate a second hashed message, and matching the first and second hashed messages;   (n) validating the receipt contra-transaction data in the first or third node by decrypting the first encrypted hash to generate a third hashed message, hashing the first set of transaction data to generate a fourth hashed message, and matching the third and fourth hashed messages; and   (o) posting the delivery and receipt contra-transaction data to delivery and receipt transaction logs respectively in one or more of the first, second and third nodes.   
     
     
         2 . The method as recited in  claim 1 , wherein step (o) comprises:
 posting the delivery contra-transaction data to a delivery transaction log in the second or third node referencing the first node's contra-transaction block's unique ledger address and hash-link in the first node's blockchain;   posting the receipt contra-transaction data to a receipt transaction log in the first or third node referencing the second node's contra-transaction block's unique ledger address and hash-link in the second node's blockchain; and   posting some of the delivery and receipt contra-transaction data to separate and distinct ownership logs in one or more of the first, second and third nodes.   
     
     
         3 . The method as recited in  claim 1 , wherein in order to meet a specified or unspecified obligation with a ledger-referenced value or non-ledger-referenced value to be transferred, loaned, borrowed or pledged, the transaction is one of the following types: a transfer, a pledge, a loan, a contingent transfer, a short transfer, a short transfer fill, a short contingent transfer and a short contingent transfer fill. 
     
     
         4 . The method as recited in  claim 1 , further comprising:
 the first node, referencing the first node's contra-transaction block's unique ledger address and hash-link in the first node's blockchain, posts the delivery contra-transaction data to a blockchain transaction log in the first node prior to step (i);   the first node, referencing the second node's contra-transaction block's unique ledger address and hash-link in the second node's blockchain, posts the receipt contra-transaction data to a replicated copy of a blockchain transaction log of the second node subsequent to step (i);   updating an ownership log in the first node to reflect changes in asset ownership resulting from the transaction subsequent to step (i);   the second node, referencing the second node's contra-transaction block's unique ledger address and hash-link in the second node's blockchain, posts the receipt contra-transaction data to the blockchain transaction log in the second node prior to step (j);   the second node, referencing the first node's contra-transaction block's unique ledger address and hash-link in the first node's blockchain, posts the delivery contra-transaction data to a replicated copy of the blockchain transaction log of the first node subsequent to step (j); and   updating an ownership log in the second node to reflect changes in asset ownership resulting from the transaction subsequent to step (j).   
     
     
         5 . The method as recited in  claim 1 , wherein each delivery transaction log has a first fractal lattice structure comprising fractal lattice addresses and each receipt transaction log has a second fractal lattice structure comprising fractal lattice addresses, the method further comprising:
 identifying a first next sequential fractal lattice address in the first fractal lattice structure;   hash linking the first next sequential fractal lattice address to a fractal lattice address in a prior layer of the first fractal lattice structure;   associating the delivery contra-transaction data with the first next sequential fractal lattice address;   identifying a second next sequential fractal lattice address in the second fractal lattice structure;   hash linking the second next sequential fractal lattice address to a fractal lattice address in a prior layer of the second fractal lattice structure; and   associating the receipt contra-transaction data with the second next sequential fractal lattice address.   
     
     
         6 . The method as recited in  claim 5 , wherein step (c) comprises hashing a message comprising the first next sequential fractal lattice address, a first node identifier, a second node identifier, an asset identifier and an amount of value and then encrypting the hashed message using a private encryption key of the first node, and step (d) comprises hashing a message comprising the second next sequential fractal lattice address, the first node identifier, the second node identifier, the asset identifier and the amount of value and then encrypting the hashed message using a private encryption key of the second node. 
     
     
         7 . The method as recited in  claim 1 , further comprising maintaining a unique blockchain transaction log for the controlled recording of transfers of value into and out of the network. 
     
     
         8 . The method as recited in  claim 1 , wherein the first and second nodes communicate via scripts, the method further comprising script building and running processes which are programmed in machine-readable code of four, parameter-driven sequential process components which are generically combined in various combinations to represent any financial services transaction or life-cycle without the need for infinite loops, wherein the four components are: (a) a single transfer of one asset; (b) an asset classification change; (c) a time-driven change in value; and (d) a contingent, dual asset, bi-directional transfer, and wherein the respective parameters for each sequential component are: (a) number, unit and value; (b) timings: single event, periodic events and multiple non-periodic events; (c) generated events: data, date, state, choice and gain/loss; and (d) primary, secondary and tertiary assets. 
     
     
         9 . A method for a multi-hash link, variable, n-dimensional self-validation of consistency and completeness on a distributed ledger or database for a network of multiple co-equal and participating nodes for single or multiple parties utilizing machine-readable code to record value, records or information and the transfer thereof between the multiple parties participating in the network on an immutable record, whereby updates to the ledger are independently generated by multiple parties utilizing multiple nodes for updating the ledger and the changes are broadcast via transaction data and the multiple nodes independently validate the integrity, completeness and consistency of the ledger with the transaction data alone without the need to confer with any other nodes or parties for consensus, competitive creation or third-party validation of the ledger, whether they instigated the transaction or not. 
     
     
         10 . The method as recited in  claim 9 , wherein the transaction data of any one node is sequenced utilizing a fractal lattice pattern created by its own defined equation allowing multiple algorithmically calculable, non-recurring, sequential, variable, n-dimensional branch locations to uniquely assign a data address for referencing unique transaction data in a distributed ledger or database for a network of multiple nodes for single or multiple parties utilizing machine-readable code such that the data's address is communicated and used by any other node in the network to recreate the data and unique address without the need to confer with the originating node or other nodes in the network. 
     
     
         11 . The method as recited in  claim 10 , wherein the fractal pattern chosen to create data addresses to be assigned is variable by a formula of a fractal pattern and is varied from data period to data period as long as the chosen pattern is communicated to the multiple nodes and parties in the network to allow them to recreate the structure without the need to confer with the originating nodes or parties or other nodes or parties in the network. 
     
     
         12 . The method as recited in  claim 10 , wherein a data set applied to the unique address is given a classification of “end” to mark the end of a fractal branch or “last” to mark a last transaction posted in a period so that the completeness of the data structure and addresses are communicated and used by any other node in the network to recreate and confirm the completeness of the data structure and unique address without the need to confer with the originating nodes or parties or other nodes or parties in the network. 
     
     
         13 . The method as recited in  claim 10 , further comprising hash-linking a data address to a hash of any prior utilized address in a structured or unstructured way which is referenced in the data address data such that when it is communicated to the network of multiple nodes for multiple parties, any node recreates and validates the hash link to verify the consistency of the originating nodes data structure without the need to confer with the originating node or parties or other nodes or parties within the network. 
     
     
         14 . The method as recited in  claim 9 , wherein every transaction in the network between two or more parties transacting utilizes coded script and securely shares data to agreed script parameters and shares transaction security and linking data at one or more nodes to create contra-transactions on a co-equal basis that reflect their distinct obligations for transfers or contingent transfers such that the contra-transactions are linked, validated and matched one contra-transaction per blockchain block to justify the update of ownership data based on the data of the two contra-transactions alone without the need to confer with the originating nodes or parties or other nodes or parties in the network. 
     
     
         15 . The method as recited in  claim 14 , wherein across the network two originating nodes generate distinct and unique private key encrypted hashes, whereby the hashes are created from a set of transaction data fields and transacting node identity is shared and recorded by the originating nodes on a reciprocal transaction as a means to link the contra-transactions and validate the identity of the originating nodes and prevent mismatches of identical transactions from different counterparties and interference unless the two private keys of the originating nodes are known. 
     
     
         16 . The method as recited in  claim 15 , whereby mathematical transformations of the transacting parties public encryption key in conjunction with transaction data and a random nonce create a unique, confidential identifier for every position in an ownership log of the distributed ledger or database when it is created, to be posted to the ownership log maintained by every participating node on the network, thereby only revealing the identity of the transacting parties whenever the transaction data and nonce are provided to a node which is independent of the nodes of the transacting parties. 
     
     
         17 . The method as recited in  claim 16 , whereby a further mathematical transformation of a unique identifier with transaction data and a random nonce are used to create an encumbrance for the value, records or information recorded on the distributed ledger or database ownership log such that the value can only be unlocked by the transacting party that knows the transaction data and random nonce combined with the mathematical transformation. 
     
     
         18 . The method as recited in  claim 14 , whereby two transacting parties via respective originating nodes process respective contra-transactions for a single asset transfer and then broadcast to the distributed ledger or database network of multiple parties or nodes, whereby the contra-transactions can be matched and validated by the multiple nodes in the network to update their distributed ledgers or databases in the network to confirm the related update to the ownership log is staged to occur immediately or at a time or event-driven time in the future whether the position transferred is a pledge or a loan, is ledger referenced or unreferenced, is specified or unspecified, and is future-dated or variable dependent. 
     
     
         19 . The method as recited in  claim 14 , whereby two transacting parties via respective originating nodes process respective pairs of contra-transactions for contingent, bi-directional dual asset transfers which are broadcast to the distributed ledger or database network of multiple parties or nodes, whereby the pairs of contra-transactions are matched and validated by the multiple nodes in the network to update their distributed ledgers or databases of contingent transfers in the network to confirm the related creation and processing of the two pairs of contra-transactions is staged to occur immediately or at a time or event-driven time in the future whether the positions for either of the dual assets transferred are a pledge or a loan, are ledger referenced or unreferenced, are specified or unspecified, and future-dated or variable dependent position. 
     
     
         20 . A transaction-driven, self-validating distributed ledger system comprising a network of multiple nodes, comprising first, second and third nodes configured to perform the following operations:
 (a) generating in the first node a first set of contra-transaction data, including the first node's contra-transaction block's unique ledger address and hash-link, which first set of contra-transaction data is complementary to a second set of contra-transaction data for a transaction, wherein the contra-transaction data of the first set comprises data overtly identifying the first node and covertly identifying the second node, data identifying an asset, data representing an amount of value and other data;   (b) generating in the second node the second set of contra-transaction data, including the second node's contra-transaction block's unique ledger address and hash-link, which second set of contra-transaction data is complementary to the first set of contra-transaction data for the transaction, wherein the contra-transaction data of the second set comprises data overtly identifying the second node and covertly identifying the first node, data identifying the asset and data representing the amount of value and other data;   (c) generating in the first node a first private key encrypted hash of a message comprising the first set of transaction data as a covert additional matching control;   (d) generating in the second node a second private key encrypted hash of a message comprising the second set of transaction data as a covert additional matching control;   (e) sharing the first private key encrypted hash with the second node;   (f) sharing the second private key encrypted hash with the first node;   (g) generating in the first node delivery contra-transaction data for the transaction, which delivery contra-transaction data comprises the first set of transaction data, including the first node's contra-transaction block's unique ledger address and hash-link in the first node's blockchain, and the second private key encrypted hash and does not identify the second node;   (h) generating in the second node receipt contra-transaction data for the transaction, which receipt contra-transaction data comprises the second set of transaction data, including the second node's contra-transaction block's unique ledger address and hash-link in the second node's blockchain, and the first private key encrypted hash and does not identify the first node;   (i) broadcasting the delivery contra-transaction data to the network;   (j) broadcasting the receipt contra-transaction data to the network;   (k) receiving the broadcast delivery and receipt contra-transaction data at the first, second and third nodes in the network;   (l) matching the broadcast delivery and receipt contra-transaction data in one or more of the first, second and third nodes;   (m) validating the delivery contra-transaction data in the second or third node by decrypting the second encrypted hash to generate a first hashed message, hashing the second set of transaction data to generate a second hashed message, and matching the first and second hashed messages;   (n) validating the receipt contra-transaction data in the first or third node by decrypting the first encrypted hash to generate a third hashed message, hashing the first set of transaction data to generate a fourth hashed message, and matching the third and fourth hashed messages; and   (o) posting the delivery and receipt contra-transaction data to logs in one or more of the first, second and third nodes.   
     
     
         21 . The system as recited in  claim 20 , wherein in order to meet a specified or unspecified obligation with a ledger-referenced value or non-ledger-referenced value to be transferred, loaned, borrowed or pledged, the transaction is one of the following types: a transfer, a pledge, a loan, a contingent transfer, a short transfer, a short transfer fill, a short contingent transfer and a short contingent transfer fill. 
     
     
         22 . The system as recited in  claim 21 , wherein:
 each of the first, second and third nodes is further configured to maintain delivery transaction logs having a first fractal lattice structure comprising fractal lattice addresses and receipt transaction logs having a second fractal lattice structure comprising fractal lattice addresses;   the first node is further configured to identify a first next sequential fractal lattice address in the first fractal lattice structure, hash link the first next sequential fractal lattice address to a fractal lattice address in a prior layer of the first fractal lattice structure, and associate the delivery contra-transaction data with the first next sequential fractal lattice address; and   the second node is further configured to identify a second next sequential fractal lattice address in the second fractal lattice structure, hash link the second next sequential fractal lattice address to a fractal lattice address in a prior layer of the second fractal lattice structure, and associate the receipt contra-transaction data with the second next sequential fractal lattice address.   
     
     
         23 . The method as recited in  claim 22 , wherein operation (c) comprises hashing a message comprising the first next sequential fractal lattice address, a first node identifier, a second node identifier, an asset identifier and an amount of value and then encrypting the hashed message using a private encryption key of the first node, and operation (d) comprises hashing a message comprising the second next sequential fractal lattice address, the first node identifier, the second node identifier, the asset identifier and the amount of value and then encrypting the hashed message using a private encryption key of the second node. 
     
     
         24 . A method for operating a distributed ledger system comprising a network of multiple nodes, comprising:
 (a) generating a first set of transaction data for a transaction in a first node in the network, wherein the transaction data of the first set comprises data identifying the first node, data identifying a second node in the network, data identifying an asset, data representing an amount of value and other data;   (b) generating a second set of transaction data for the transaction in the second node in the network, wherein the transaction data of the second set comprises data identifying the first and second nodes, data identifying the asset and data representing the amount of value and other data;   (c) generating a first encrypted hash of a message comprising the first set of transaction data in the first node;   (d) generating a second encrypted hash of a message comprising the second set of transaction data in the second node;   (e) sharing the first encrypted hash with the second node;   (f) sharing the second encrypted hash with the first node;   (g) generating delivery contra-transaction data for the transaction in the first node, which delivery contra-transaction data comprises the first set of transaction data and the second encrypted hash and does not identify the second node;   (h) generating receipt contra-transaction data for the transaction in the second node, which receipt contra-transaction data comprises the second set of transaction data and the first encrypted hash and does not identify the first node;   (i) broadcasting the delivery contra-transaction data to the network;   (j) broadcasting the receipt contra-transaction data to the network;   (k) receiving the broadcast delivery and receipt contra-transaction data at a third node in the network;   (l) matching the broadcast delivery and receipt contra-transaction data in the third node;   (m) validating the delivery contra-transaction data in the third node by decrypting the second encrypted hash to generate a first hashed message, hashing the second set of transaction data to generate a second hashed message, and matching the first and second hashed messages;   (n) validating the receipt contra-transaction data in the third node by decrypting the first encrypted hash to generate a third hashed message, hashing the first set of transaction data to generate a fourth hashed message, and matching the third and fourth hashed messages; (o) posting the delivery and receipt contra-transaction data to delivery and receipt transaction logs in one or more of the first, second and third nodes, wherein each delivery transaction log has a first fractal lattice structure comprising fractal lattice addresses and each receipt transaction log has a second fractal lattice structure comprising fractal lattice addresses;   (p) identifying a first next sequential fractal lattice address in the first fractal lattice structure;   (q) hash linking the first next sequential fractal lattice address to a fractal lattice address in a prior layer of the first fractal lattice structure;   (r) associating the delivery contra-transaction data with the first next sequential fractal lattice address;   (s) identifying a second next sequential fractal lattice address in the second fractal lattice structure;   (t) hash linking the second next sequential fractal lattice address to a fractal lattice address in a prior layer of the second fractal lattice structure; and   (u) associating the receipt contra-transaction data with the second next sequential fractal lattice address.   
     
     
         25 . The method as recited in  claim 24 , wherein step (c) comprises hashing a message comprising the first next sequential fractal lattice address, a first node identifier, a second node identifier, an asset identifier and an amount of value and then encrypting the hashed message using a private encryption key of the first node, and step (d) comprises hashing a message comprising the second next sequential fractal lattice address, the first node identifier, the second node identifier, the asset identifier and the amount of value and then encrypting the hashed message using a private encryption key of the second node. 
     
     
         26 . A method for a multi-hash link, variable, n-dimensional self-validation of consistency and completeness in a database for a network of multiple nodes for single or multiple parties utilizing machine-readable code to record information and the transfer thereof between the multiple parties participating in the network on an immutable record, whereby updates to the database by multiple parties utilizing multiple nodes update the database and broadcast the changes via transaction data and the multiple nodes validate the integrity, completeness and consistency of the database with the transaction data alone without the need to confer with any other nodes or parties, whether they instigated the transaction or not, the method comprising sequencing the transaction data of any one node utilizing a fractal lattice pattern created by its own defined equation allowing multiple algorithmically calculable, non-recurring, sequential, variable, n-dimensional branch locations to uniquely assign a data address for referencing unique transaction data in the database for the network of multiple nodes for single or multiple parties utilizing machine-readable code such that the data's address is communicated and used by any other node in the network to recreate the data and unique address without the need to confer with the originating node or other nodes in the network. 
     
     
         27 . The method as recited in  claim 26 , wherein the fractal pattern chosen to create data addresses to be assigned is variable by a formula of a fractal pattern and is varied from data period to data period as long as the chosen pattern is communicated to the multiple nodes and parties in the network to allow them to recreate the structure without the need to confer with the originating nodes or parties or other nodes or parties in the network. 
     
     
         28 . The method as recited in  claim 26 , wherein a data set applied to the unique address is given a classification of “end” to mark the end of a fractal branch or “last” to mark a last transaction posted in a period so that the completeness of the data structure and addresses are communicated and used by any other node in the network to recreate and confirm the completeness of the data structure and unique address without the need to confer with the originating nodes or parties or other nodes or parties in the network. 
     
     
         29 . The method as recited in  claim 26 , further comprising hash-linking a data address to a hash of any prior utilized address in a structured or unstructured way which is referenced in the data address data such that when it is communicated to the network of multiple nodes for multiple parties, any node recreates and validates the hash link to verify the consistency of the originating nodes data structure without the need to confer with the originating node or parties or other nodes or parties within the network. 
     
     
         30 . The method as recited in  claim 26 , wherein every transaction in the network between two or more parties transacting utilizes coded script and securely shares data to agreed script parameters and shares transaction security and linking data at one or more nodes to create contra-transactions that reflect their distinct obligations for transfers or contingent transfers such that the contra-transactions are linked, validated and matched to justify the update of ownership data without the need to confer with the originating nodes or parties or other nodes or parties in the network. 
     
     
         31 . The method as recited in  claim 30 , wherein across the network two originating nodes generate distinct and unique private key encrypted hashes, whereby the hashes are created from a set of transaction data fields and transacting node identity is shared and recorded by the originating nodes on a reciprocal transaction as a means to link the contra-transactions and validate the identity of the originating nodes and prevent interference unless the two private keys of the originating nodes are known. 
     
     
         32 . The method as recited in  claim 31 , whereby mathematical transformations of the transacting parties public encryption key in conjunction with transaction data and a random nonce create a unique, confidential identifier for every position on the database ownership log when it is created, to be posted to the ownership log maintained by every participating node on the network, thereby revealing the identity of the transacting parties whenever the transaction data and nonce are provided to a node which is independent of the nodes of the transacting parties. 
     
     
         33 . The method as recited in  claim 32 , whereby a further mathematical transformation of a unique identifier with transaction data and a random nonce are used to create an encumbrance for the value, records or information recorded on the database ownership log such that the value can only be unlocked by the transacting party that knows the transaction data and random nonce combined with the mathematical transformation. 
     
     
         34 . The method as recited in  claim 26 , whereby two transacting parties via respective originating nodes process respective contra-transactions for a single transfer and then broadcast to the database network of multiple parties or nodes, whereby the contra-transactions can be matched and validated by the multiple nodes in the network to update their databases in the network to confirm the related update to the ownership log is staged to occur immediately or at a time or event-driven time in the future whether the position transferred is a pledge or a loan, is ledger referenced or unreferenced, is specified or unspecified, and is future-dated or variable dependent. 
     
     
         35 . The method as recited in  claim 26 , whereby two transacting parties via respective originating nodes process respective pairs of contra-transactions for contingent, bi-directional dual asset transfers which are broadcast to the distributed database network of multiple parties or nodes, whereby the pairs of contra-transactions are matched and validated by the multiple nodes in the network to update their distributed databases of contingent transfers in the network to confirm the related creation and processing of the two pairs of contra-transactions is staged to occur immediately or at a time or event-driven time in the future whether the positions for either of the dual assets transferred are a pledge or a loan, are ledger referenced or unreferenced, are specified or unspecified, and future-dated or variable dependent position. 
     
     
         36 . A method for electronically recording transfers of assets between first and second parties using a network comprising first and second nodes that communicate via scripts, comprising script building and running processes which are programmed in machine-readable code residing in the first and second nodes, the script building and running processes comprising four parameter-driven sequential process components which are generically combined in various combinations to represent any financial services transaction or life-cycle without the need for infinite loops, wherein the four components are: (a) a single transfer of one asset; (b) an asset classification change; (c) a time-driven change in value; and (d) a contingent, dual asset, bi-directional transfer, and wherein the respective parameters for each sequential component are: (a) number, unit and value; (b) timings: single event, periodic events and multiple non-periodic events; (c) generated events: data, date, state, choice and gain/loss; and (d) primary, secondary and tertiary assets.