Blockchain Communication and Ordering

Abstract

To provide a method, a system, a computer program, and a software development kit for maintaining a record of the order of transactions appearing on one or more block-chains.SOLUTION: A method includes: identifying a plurality of transactions appearing on one or more block-chains, each transaction included in any of the one or more block-chains; and storing, in a data store, a record indicating the relative order of the plurality of transactions.SELECTED DRAWING: None

Description

[Technical field]

[0001] The present disclosure relates to methods, systems, computer programs, and SDKs for maintaining a record of the order of transactions appearing on one or more blockchains, as well as methods, systems, computer programs, and SDKs related to blockchain communications. [Background technology]

[0002] Blockchain technology has a wide range of potential applications, providing a way in which data may be stored safely and securely without the need for a central data authentication authority. As a result, blockchain technology may enable many technical benefits across a wide range of sectors, such as increased data transparency, more robust data storage independent of reliance on specific storage entities, improved data security, and improved resistance to fraud, and has already found applications in areas as diverse as electrical energy distribution and peer-to-peer cloud storage.

[0003] Blockchain was first conceptualized in 2009 in a white paper titled "Bitcoin: A Peer-to-Peer Electronic Cash System" published under the name of Satoshi Nakamoto. A copy of the white paper can be found at https: / / bitcoin.org / bitcoin.pdf. The white paper proposed a peer-to-peer version of electronic cash called "Bitcoin" that utilized what has since been called the blockchain to record peer-to-peer transfers of Bitcoin.

[0004] Blockchains are decentralized, distributed digital ledgers that can be used to store effectively immutable records of data. They are decentralized in that no central authority is necessarily required to add data to the blockchain or to maintain the integrity of the blockchain. Data can be added to a blockchain by an entity broadcasting a "transaction" to a network of nodes participating in the blockchain, where the transaction includes the data to be added to the blockchain and a cryptographic element that conforms to the blockchain protocol. Each node participating in the blockchain then verifies the validity of the transaction and, if approved, adds the transaction to a new block in the works.

[0005] Each node may also add to its new block other new transactions that it is working on that are broadcast to the network of nodes. After some time, the node publishes its new block to other nodes in the network, with the new block containing the various new transactions and cryptographic data that ties the new block to the previous block in the blockchain. By cryptographically linking successive blocks in this way, it may be easily detectable if one block in the blockchain is later altered (e.g., if someone wants to tamper with the data stored in the blockchain).

[0006] After a node publishes a new block, other nodes in the network verify the contents of the new block and, if approved, begin work on the next new block, which is also cryptographically linked to its previous block. Thus, as new blocks are published and approved, the blockchain grows, and we see that each new approved block is cryptographically linked to its previous block. This process by which nodes verify the published new block and accept it into the blockchain is often referred to as the "consensus" mechanism.

[0007] In the white paper "Bitcoin: A Peer-to-Peer Electronic Cash System", a specific protocol is proposed for Bitcoin. The protocol covers such things as the format and type of information that should be included in transactions, the format and type of information included in new blocks, the encryption techniques and recipes that should be used for transactions and new blocks, as well as the specific type of consensus mechanism to be used (for example, in Bitcoin, the consensus mechanism utilizes a hash-based proof-of-work on each block of the blockchain, which is also a cryptographic tie between each successive block). Broadcast transactions will not be included in any new block if they do not properly comply with the protocol. Similarly, new blocks will not be accepted into the blockchain by the network of nodes if they do not properly comply with the protocol.

[0008] Blockchain, also known as distributed ledger technology (DLT), was initially proposed to enable the cryptocurrency Bitcoin, but has since found many other uses. First, new cryptocurrencies such as Ethereum, Ripple, and Namecoin were launched, each running on its own specific blockchain and utilizing its own specific protocol. Since then, it has been recognized that blockchain technology can be used much broader than cryptocurrencies and in any scenario where an effectively immutable record of data is useful. This has led to a rapid expansion in the number of different blockchains in existence, each tailored to a specific use case, and it is expected that the number of different blockchains will continue to grow as the technology gains more momentum and awareness. Summary of the Invention

[0009] In a first aspect of the present disclosure, a computer-implemented method is provided for maintaining a record of an order of transactions appearing on one or more blockchains (DLTs), the method including identifying a plurality of transactions, each transaction of the plurality of transactions being included in one of the one or more blockchains, and storing a record of the plurality of transactions in a data store, the record indicating a relative order of the plurality of transactions.

[0010] Maintaining a record of transaction ordering may reduce security and stability vulnerabilities associated with out-of-order messages, thereby improving the security and stability of systems that utilize one or more blockchains. This technical advantage is particularly evident when the order of transactions that appear across two or more (multiple) blockchains is recorded, as ordering of transactions across multiple blockchains is particularly problematic and subject to security and fraud issues.

[0011] Identifying the multiple transactions may include reading the contents of each new block added to each of the one or more blockchains.

[0012] Identifying the plurality of transactions may further include comparing the transactions in each new block to a relevance criterion, where the identified plurality of transactions includes transactions that meet the relevance criterion. By comparing to the relevance criterion, only relevant transactions need to be identified in the data store, which may increase the speed at which the data store is reviewed in the future and reduce the size of the data store required.

[0013] Preferably, storing a record of the plurality of transactions in the data store comprises storing a record of the identified transaction in the data store each time a transaction is identified in a new block, and the relative order of the plurality of transactions is determined by storing a record of the identified transaction in the data store each time a transaction is identified in a new block, Each of the transactions is identified in relative order.

[0014] Preferably, the record of the plurality of transactions includes a plurality of consecutive validation sets, at least some of the plurality of consecutive validation sets including one or more transaction identifiers corresponding to respective one or more of the plurality of transactions.

[0015] The method may further include storing a record of a most recent validation set of the plurality of successive validation sets in at least one of the one or more blockchains, in this manner enhancing the integrity and non-repudiation of the record, thereby improving the security and stability of the method.

[0016] The method may further include verifying that a prior validation set record in the plurality of validation sets exists in at least one of the one or more blockchains, and if the prior validation set record does not exist in the at least one of the one or more blockchains, redoing the prior validation set record in the at least one of the one or more blockchains. In this manner, early forks of a blockchain may be quickly identified while maintaining reliability of the recorded order of transactions.

[0017] The preceding validation set record may be re-stored in at least one of the one or more blockchains before storing the most recent validation set record in at least one of the one or more blockchains.

[0018] The method may further include, if a record of the preceding validation set does not exist in at least one of the one or more blockchains, verifying that each of the transactions identified in the preceding validation set is present in its corresponding blockchain of the one or more blockchains, and, if one or more transactions identified in the preceding validation set are not present in their corresponding blockchains of the one or more blockchains, redoing the one or more transactions to their corresponding blockchains.

[0019] The method may further include verifying that each of the transactions identified in the most recent validation set exists in at least one of the one or more blockchains, and, if one or more transactions identified in a prior validation set do not exist in their corresponding blockchains of the one or more blockchains, redoing the one or more transactions to their corresponding blockchains.

[0020] The one or more transactions may be redeployed to their corresponding blockchains prior to storing a record of the most recent validation set in at least one of the one or more blockchains.

[0021] The record of the most recent validation set may include a validation set identifier determined at least in part based on the contents of the most recent validation set.

[0022] The validation set identifier of the most recent validation set may include a hash of the contents of the most recent validation set.

[0023] Storing a record of the most recent validation set may include broadcasting a transaction to at least one of the one or more blockchains for inclusion in the at least one blockchain, where the broadcasted transaction includes a unique identifier of the most recent validation set.

[0024] The multiple transaction records may include multiple transaction identifiers, each determined at least in part based on the content of the respective transaction.

[0025] The transaction identifiers may include hashes of the contents of the transactions.

[0026] A record of the multiple transactions may include content of at least some of the multiple transactions.

[0027] In a second aspect of the present disclosure, there is provided a system comprising one or more processors and a memory storing a software program which, when executed by the one or more processors, causes the one or more processors to perform a method according to any of the preceding claims.

[0028] In a third aspect of the present disclosure there is provided one or more computer programs which, when executed by one or more processors, cause the one or more processors to perform a method according to the first aspect.

[0029] In a fourth aspect of the present disclosure, there is provided a software development kit SDK comprising a set of software development tools for developing one or more computer programs of the third aspect.

[0030] In a fifth aspect of the present disclosure, a method is provided for providing interoperability between an application functionality layer and a plurality of different blockchains, where the application functionality layer includes functional operations utilizing one or more of the plurality of different blockchains, the method including a blockchain communications layer receiving a blockchain request from the application functionality layer, the blockchain request relating to a blockchain operation to be performed on one or more of the plurality of different blockchains, and interfacing with the one or more blockchains according to a protocol of the one or more blockchains to perform the blockchain operation. Thus, the application functionality layer may be decoupled from the blockchain protocol, allowing applications to more easily operate across and switch between blockchains, thereby allowing any security or stability threats in a particular blockchain to be more quickly mitigated.

[0031] A blockchain request may include a request to read data on one or more blockchains. A request to read data from one or more blockchains may include a data identifier that indicates the data to be read from one or more blockchains.

[0032] Interfacing with the one or more blockchains includes reading the requested data in the one or more blockchains, and the method further includes the blockchain communications layer communicating the data read from the one or more blockchains to the application functionality layer.

[0033] A blockchain request may include a request to write data to one or more blockchains.

[0034] A data write request may include data to write to one or more blockchains.

[0035] The blockchain request may include a request to execute a cross-ledger transaction XLT between a first blockchain of the multiple blockchains and a second blockchain of the multiple blockchains, where the request to execute the XLT includes an XLT identifier indicating data on the first blockchain to be transferred by the XLT to the second blockchain.

[0036] Communication between the blockchain communication layer and the application function layer may be performed according to the methods defined by the blockchain programming interface BPI.

[0037] In a sixth aspect of the present disclosure, there is provided a system comprising one or more processors and a memory storing a software program which, when executed by the one or more processors, causes the one or more processors to perform a method according to any of the preceding claims.

[0038] In a seventh aspect of the present disclosure there is provided one or more computer programs which, when executed by one or more processors, cause the one or more processors to perform a method according to the fifth aspect.

[0039] In an eighth aspect of the present disclosure, there is provided a software development kit SDK comprising a set of software development tools for developing one or more computer programs of the seventh aspect.

[0040] In a ninth aspect of the present disclosure, a method is provided for executing a cross-ledger transaction XLT between a first blockchain and a second blockchain, the method including: identifying a propose XLT transaction associated with the XLT on the first blockchain; storing a record of the propose XLT transaction in a transaction record of a data store; identifying a ready XLT transaction on the second blockchain; and storing the record of the ready XLT transaction in the transaction record in the data store, the record indicating a relative order of the propose XLT transaction and the ready XLT transaction; determining whether the LT transaction and the ready XLT transaction satisfy the XLT criteria, and if the propose XLT transaction and the ready XLT transaction satisfy the XLT criteria, broadcasting a commit XLT transaction to the first blockchain and the second blockchain to execute the XLT between the first blockchain and the second blockchain, the XLT criteria including a first criterion that the ready XLT transaction corresponds to the propose XLT transaction and a second criterion that the transaction record indicates that the propose XLT transaction precedes the ready XLT transaction. Thus, the security and reliability of cross-ledger transactions are improved and the risk of fraud is reduced because the order of transactions across two or more blockchains can be reliably maintained and understood even if one or more blockchains experience a fork.

[0041] The method further includes broadcasting one or more transactions to the first blockchain and / or the second blockchain, wherein the one or more transactions may each include one or more record identifiers, each record identifier determined at least in part based on at least a portion of content of the transaction record, and wherein the one or more record identifiers together indicate records of the propose XLT transaction and the ready XLT transaction.

[0042] The one or more record identifiers may include one or more hashes of at least a portion of the contents of the transaction record.

[0043] The XLT criterion may include a third criterion that one or more transactions are included in the first blockchain and / or the second blockchain, resulting in one or more record identifiers being stored in the first blockchain and / or the second blockchain.

[0044] The propose XLT transaction record may include a hash of the contents of the propose XLT transaction, and the ready XLT transaction record includes a hash of the contents of the ready XLT transaction.

[0045] In a tenth aspect of the present disclosure, there is provided a system including one or more processors and a memory storing a software program that, when executed by the one or more processors, causes the one or more processors to perform a method according to the ninth aspect.

[0046] In an eleventh aspect of the present disclosure there is provided one or more computer programs which, when executed by one or more processors, cause the one or more processors to perform a method according to the ninth aspect.

[0047] In a twelfth aspect of the present disclosure, there is provided a software development kit SDK comprising a set of software development tools for developing one or more computer programs of the eleventh aspect.

[0048] In a thirteenth aspect of the present disclosure, a method is provided for maintaining a record of the relative order of transactions performed on two or more blockchains, thereby enabling increased security and reliability, particularly in the case of blockchain forks and / or XLTs, since the order of transactions on different blockchains can be reliably ordered.

[0049] In a fourteenth aspect of the present disclosure, there is provided a system comprising one or more processors and a memory storing a software program, the software program, when executed by the one or more processors, causing the one or more processors to perform a method according to the ninth aspect.

[0050] In a fifteenth aspect of the present disclosure there is provided one or more computer programs which, when executed by one or more processors, cause the one or more processors to perform a method according to the ninth aspect.

[0051] In a sixteenth aspect of the present disclosure, there is provided a software development kit SDK comprising a set of software development tools for developing one or more computer programs of the eleventh aspect. [Brief description of the drawings]

[0052] Aspects of the present disclosure will now be described, by way of example only, with reference to the following drawings.

[0053] [Figure 1] FIG. 1 illustrates an example representation of an overledger communication layer according to one aspect of the disclosure.

[0054] [Diagram 2] FIG. 2 illustrates an exemplary representation of a system utilizing the overledger communication layer of FIG.

[0055] [Diagram 3]FIG. 3 illustrates an exemplary representation of a further system utilizing the overledger communication layer of FIG.

[0056] [Figure 4] FIG. 4 is a diagram illustrating a representation of exemplary method steps performed using the system of FIG.

[0057] [Diagram 5] FIG. 5 illustrates an exemplary representation of a further system utilizing the overledger communication layer of FIG.

[0058] [Figure 6] FIG. 6 is a diagram illustrating an example representation of a fork in a blockchain.

[0059] [Figure 7] FIG. 7 illustrates an example representation of a method for maintaining a record of the order of transactions appearing on one or more blockchains, according to one aspect of the disclosure.

[0060] [Figure 8] FIG. 8 illustrates an example representation of two blockchains on which the method of FIG. 7 is performed.

[0061] [Figure 9] FIG. 9 illustrates a further exemplary representation of two blockchains on which the method of FIG. 7 is performed.

[0062] [Figure 10] FIG. 10 illustrates an example representation of two blockchains in which cross-ledger transactions are performed according to aspects of the disclosure.

[0063] [Figure 11] FIG. 11 illustrates an example representation of a further system according to one embodiment of the present disclosure.

[0064] [Figure 12] FIG. 12 illustrates an exemplary representation of a method performed by the system of FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0065] The inventors have recognized that as blockchain technology grows and develops, it may become increasingly difficult for various entities to utilize it safely, securely, and reliably. For example, currently, if an entity wants to develop a new software application that uses blockchain technology, it must either start its own new blockchain (which is extremely time consuming and complex and requires the establishment of an entirely new blockchain protocol) or utilize an existing blockchain technology such as Bitcoin or Ethereum.

[0066] The inventors have realized that to take advantage of an existing blockchain technology, an entity must develop a software application that fully complies with that blockchain's protocol, e.g., using the encryption techniques, transaction formats, and communication channels defined by the protocol. Thus, the selection of which blockchain technology to use is a decision that must be made very early in the software development process, potentially before the requirements and usage of the software application are fully understood.

[0067] Each blockchain has its own set of requirements that are designed to meet the specific needs of the blockchain. There is a specific protocol. Blockchain protocols cannot be changed without causing a hard fork in the blockchain, which means that blockchains are less adaptable to necessary changes. As a result, if an entity later determines that the selected blockchain technology no longer meets its needs (e.g., because the selected blockchain technology has become unstable or insecure, or because the requirements of the software application have changed such that a different blockchain technology is advantageous, or because a new blockchain is superior to the originally selected but now outdated blockchain technology), in order to start using the alternative blockchain technology, the software must be modified to comply with the protocol of the alternative blockchain technology. In practice, this can be very difficult, if not impossible, because the software is built on the foundation set by the protocol of the originally selected blockchain technology. Therefore, choosing the right blockchain technology from the beginning is very important, but because blockchain technology is developing so rapidly, this can be very difficult in practice to achieve.

[0068] Additionally, any data previously stored on a blockchain may not be directly transferred to an alternative blockchain due to differences between blockchain protocols.

[0069] In view of these long-term difficulties identified by the inventors, a technical solution has been devised by the inventors and is provided in this disclosure that introduces a new communication layer to separate application functions from the blockchains they utilize. By decoupling application functions from the various requirements of the blockchains on which they operate, interoperability between applications and blockchains can be improved. As will be understood from aspects of the disclosure described in more detail below, this may mean that future changes in blockchain technology can be addressed more efficiently and flexibly. This may help address security threats (e.g., if one blockchain technology is identified as having a security flaw, the application can easily switch to a more secure blockchain technology), improve security and reliability (as applications can more easily operate across multiple blockchains, store duplicate data across blockchains, and / or transfer data across blockchains), and / or improve efficiency and speed (e.g., if a newer blockchain technology increases the speed of transaction processing, the application can easily switch to the newer blockchain technology).

[0070] Throughout the following disclosure, the terms "blockchain," "blockchain technology," and "distributed ledger technology (DLT)" are used interchangeably. Additionally, throughout the following disclosure, the term "transaction" is used in connection with the blockchain. Those skilled in the art will understand that a "transaction" in this context is not limited to any transfer of ownership, such as, for example, currency. Rather, a "transaction" is a means by which some form of information can be placed on the blockchain. For example, an entity may broadcast a "transaction" to be placed on the blockchain, which includes the information to be placed on the blockchain and other data items (such as public keys, signatures, hashes, etc.) required for the transaction to be approved by the blockchain. The information placed on the blockchain may relate to a financial transfer of currency, but may instead be any other type of information (such as data that an entity wants to store on the blockchain for its own reference at a later time).

[0071] FIG. 1 shows an example visualization of the introduction of an “overledger communications layer” 20 that sits between the application capabilities layer 30 and the DLT layer 10. The term “overledger communications layer” is used throughout this disclosure to describe the protocol requirements of DLT to applications that utilize DLT. A communications layer that separates the functional operation of an application (sometimes called the "business logic") from the communication layer.

[0072] In FIG. 1, two DLTs (first DLT 12 and second DLT 14) are shown as part of the DLT layer 10, but it will be understood that the overledger communications layer 20 may be capable of interfacing with any number of different DLTs, e.g., Bitcoin, Ethereum, Corda, OpenChain, Hyperledger, etc. Each DLT has its own specific protocol for blockchain operations, such as reading data from a blockchain, writing data to a blockchain, and / or transferring ownership of data from one entity to another entity on the same blockchain or to another blockchain (cross-ledger transactions) (various blockchains may allow any one or more of read, write and transfer operations on a blockchain depending on the purpose the blockchain is configured to perform).

[0073] The overledger communication layer 20 includes different ways in which blockchain operations may be performed on the first DLT 12 and the second DLT 14. For example, the first DLT 12 may be Bitcoin, with a specific protocol for writing new transactions to its blockchain. Bitcoin's specific protocol is well understood by those skilled in the art, but in brief, may include information such as the recipient's public key (the recipient's "wallet"), the amount being transferred to the recipient, a hash of a previous transaction in which the payer obtained the Bitcoin currently being transferred, and the payer's signature (signed using the payer's private key). The protocol defines the acceptable format of each of these items (such as length and object type), the cryptographic techniques (such as SHA-256) that must be used to generate the hash and signature, and the order in which each item appears in the transaction. The protocol may also define how information may be read from Bitcoin's blockchain (e.g., identifying what information to keep in each transaction and in each block of the blockchain), the format and order of the information, and the cryptographic techniques used to generate the hash, signature, and proof-of-work (so that each may be verified when the blockchain is read). In contrast, the second DLT 14 may have an entirely different protocol that allows different blockchain operations to be performed, such as read operations only (e.g., it is a closed blockchain that anyone can read, but only authorized entities can write), each block may contain different information in a different order, and / or may use different cryptographic techniques relative to the first DLT 12. The overledger communication layer 20 includes methods that allow for various permissible operations to be performed on each of the first DLT 12 and the second DLT 14.

[0074] The application functionality layer 30 shown in FIG. 1 includes the functional operations (sometimes referred to as "business logic") of an application that is utilizing one or more DLTs. When the application functionality layer 30 of an application wishes to perform a blockchain operation, it passes relevant information (a blockchain request) to the overledger communication layer 20 (e.g., including the nature of the data it wishes to write to the DLT or the information it wishes to read from the DLT), which then interfaces with the relevant DLT according to the protocol of the relevant DLT to perform the blockchain operation. The overledger communication layer 20 may then return any relevant results to the application functionality layer 30. This operation may be more fully understood from a more specific example described later in this disclosure.

[0075] To allow the methods maintained in the overledger communication layer 20 to be utilized by a variety of different entities, the methods may be encapsulated, for example, in a software development kit (SDK), hereafter referred to as the overledger SDK. It will be appreciated that the methods maintained in the overledger communication layer 20 may be encapsulated in any other suitable equivalent manner. By acquiring the Overledger SDK, developers may more easily select the DLT they wish to utilize for the particular software application they are developing, and let the Overledger SDK provide the methods and tools necessary to interact with their selected DLT.

[0076] 2 shows an example representation of a system 200 including an SDK provider 210, an application developer 220, a developed application 230, a first DLT network 240, and a second DLT network 250. The SDK provider 210 may be responsible for building and maintaining the Overledger SDK, which in this example includes methods of interfacing (interacting) with at least the first DLT 12 and the second DLT 14, but may include methods of interaction for any number of DLTs (i.e., for multiple DLTs). When an application developer 220 wants to develop an application that utilizes the first DLT 12 and / or the second DLT 14, they may obtain the Overledger SDK from the SDK provider 210 (e.g., by downloading it from the SDK provider 210 or from any other Overledger SDK hosting entity). The Overledger SDK may then be utilized to develop an application 230, which may then interact with the first DLT 12 and / or the second DLT 14 according to methods defined in the Overledger SDK. In FIG. 2, a first DLT network 240 represents a network of participating nodes of the first DLT 12, and a second DLT network 250 represents a network of participating nodes of the second DLT 14. In the particular example shown in FIG. 2, the application 230 is shown to be able to interact with both the first DLT network 240 and the second DLT network 250, but it will be appreciated that an application developer may instead utilize the Overledger SDK to configure the application 230 to interact only with the first DLT network 240, or only with the second DLT network 250.

[0077] In one particular aspect, as part of the development of the application 230, the application developer 230 may develop a programming interface to handle communication between the overledger communication layer 20 and the application functionality layer 30 of the application 230. Hereinafter, this interface is referred to as the blockchain programming interface (BPI), and the BPI is configured to help simplify the interaction between the application functionality layer 30 and the overledger communication layer 20. For example, the overledger communication layer 20 of the application 230 may operate according to a method defined in the Overledger SDK to handle communication between the first DLT network 240 and / or the second DLT network 250. The application developer 220 may develop the BPI to define certain types of information that the application functionality layer 30 of the application 230 may pass to and / or receive from the overledger communication layer 20 in a blockchain request associated with a blockchain operation performed on one or more blocks. For example, a "write to first DLT 12" command may be provided, which may specify any relevant parameters (maximum length, object type, etc.) of the data to write to the first DLT 12, and / or a "read from second DLT 14" command may be provided, which may specify any relevant data required to read information from the second DLT 14 (e.g., if one wishes to read data from the second DLT 14 that was written to the second DLT 14 by a particular entity, the "read from second DLT 14" command may specify that a blockchain identifier for the particular entity, such as a public key, is required, which the Overledger communications layer 20 may use to search the contents of the second DLT 14 for transactions that include that blockchain identifier). As a result, the Overledger communications layer 20 may be able to read data from any of the DLTs supported by the Overledger SDK. It will be appreciated that in order to interface with such, application functionality layer 30 of application 230 may utilize various commands provided by the BPI.

[0078] Thus, the application functionality layer 30 of the application 230 is decoupled from the specific DLT layer 10 protocol requirements of the first DLT 12 and the second DLT 14 by the overledger communication layer 20 operating according to the overledger SDK. The application functionality layer 30 only needs to send and receive data to the overledger communication layer 20 in the manner defined by the BPI in order to interact with the first DLT 12 and / or the second DLT 14. As a result, if either the first DLT 12 or the second DLT 14 changes its protocol in the future, this can be handled by the overledger communication layer 20 with changes to the overledger SDK. Because the application functionality layer 30 of the application 230 sends and receives data to the overledger communication layer 20 as defined in the BPI, it may remain unchanged, or at most be minimally modified if a DLT protocol change requires the BPI to be modified in some way (e.g., if the object types that can be written to the DLT change, the BPI may also change, thereby requiring the application functionality layer 30 to provide data for different object types). Nonetheless, it will be apparent that, if any changes are necessary to the application functionality layer 30, they will be minimal and the fundamental aspects of the application functionality layer 30 may remain unchanged.

[0079] Similarly, the same would be seen if the application developer 220 made the decision to start using a different DLT (e.g., because the originally selected DLT is now unstable or has security flaws, or because a new DLT with improved speed and / or efficiency has been launched). If that different DLT is supported by the Overledger SDK, the application developer 220 may simply update the BPI to provide commands to interact with that different DLT, and the application functionality layer 30 of the application 230 can then utilize that different DLT. Again, it can be seen that only minimal to no changes may be required to the application functionality layer 30 of the application 230, since the application functionality layer 30 has not been developed to interact with one particular DLT and the particular protocols that that DLT requires, but instead has been developed to perform the application's functional requirements and utilize the BPI whenever some form of blockchain interaction is required.

[0080] The advantage of using an over-ledger communications layer 20 to separate the application functionality layer 30 from the DLT layer 10 can be further understood by considering a scenario in which an application developer 220 develops a service offering for other "client" application developers to consume. The service offering may relate to any kind of blockchain service that other application developers may want to consume, such as, for example, a service that allows for writing certain types of information to the blockchain (as described in more detail in the "Messaging Aspects" section) and / or a service that allows for cross-ledger transactions (as described in more detail in the "Cross-ledger Transaction Aspects" section) and / or a service that allows for reading certain types of information from the DLT.

[0081] 3 illustrates an exemplary system 300 for demonstrating a service offering that may be utilized by a "client" application developer. System 300 includes SDK provider 210 (described above), service offering developer 310, client application developer 320, client application 330, first DLT network 240 (described above), and second DLT network 250 (described above).

[0082] FIG. 4 shows example method steps illustrating how a service offering developer may utilize the Overledger SDK.

[0083] In step S410, the service offering developer 310 may obtain the Overledger SDK from the SDK provider 210 (eg, by downloading it from the SDK provider 210 or from any other Overledger SDK hosting entity).

[0084] In step S420, the service offering developer 310 may develop a BPI for the service they are offering and suitably encapsulate it (e.g., encapsulated in a BPI configuration file, although any other suitable alternative may be used instead). The BPI specifies functions, commands, etc. that may be used by the application functionality layer 30 of the client application 330 to interact with one or more DLTs, as described above.

[0085] In step S430, the client application developer 320 may obtain the Overledger SDK and BPI configuration files (eg, by downloading from the service offering developer 310 or from any other suitable hosting entity).

[0086] In step S440, the client application developer 320 develops the application functionality layer 30 of the client application 330. If the application functionality layer 30 needs to interact with the DLT in any way, the application functionality layer 30 simply needs to appropriately utilize commands or functions of the BPI to communicate blockchain requests to the overledger communication layer 20, where the blockchain requests relate to blockchain operations to be performed on one or more blockchains. It can thus be seen that the overledger SDK and the BPI provided by the service offering developer 310 decouple the application functionality layer 30 from the DLT layer 10. Thus, the overledger SDK may be considered to perform the functions of the overledger communication layer 20, and the BPI may be considered to define how the application functionality layer 30 may interface with the overledger communication layer 20 to perform a particular service provided by the service offering developer.

[0087] As a result, if the client application developer 320 later decides that he or she wants to change the DLT used for the client application 320 (e.g., the functional application layer 30 of the client application 330 may initially be configured to use BPI functions and commands to interact with the first DLT 22, but it is later determined that the second DLT 24 should be used instead), then he or she only needs to change the particular BPI functions and commands that the functional application layer 20 uses (assuming that the Overledger SDK and the BPI support both the first DLT 22 and the second DLT 24). Similarly, if something changes about the protocol of any DLT supported by the Overledger SDK, the Overledger SDK may be changed, and the service offering developer 310 may change the BPI as a result, as necessary. As a result, in many cases, the client application developer only needs to change the particular BPI functions and commands that the functional application layer 30 of the client application 330 uses, without any fundamental aspects of the functional application layer 30 of the client application having to be changed.

[0088] Optionally, the service offering developer 310 may provide a BPI configuration file so that the client application developer 320 can verify that the BPI configuration file obtained is valid. After you create a PI configuration file, you may sign it using standard public-private key cryptography techniques.

[0089] The Overledger SDK may include a number of different features that enable specific types of DLT interactions to take place. Two of these specific features, "Messaging Aspects" and "Cross-Ledger Transactions" aspects, are described in more detail below.

[0090] Although both application functionality layer 30 and overledger communication layer 20 are described above as "layers," it will be appreciated that they may alternatively be considered as software modules or packages. For example, they may be two modules within application 230 or client application 330. Alternatively, they may each be located within a different application and run on a different electronic device. For example, application functionality layer 30 may be a software module or package running on a client electronic device, and overledger communication layer 20 may be a different software module or package running on a service offering electronic device, with the two layers communicating according to the BPI via any suitable communication interface. Furthermore, overledger communication layer 20 may be considered as a software module or package configured to perform a particular blockchain operation on any one or more different DLTs, and service offering developer 310 allows client application developers to download overledger communication layer 20 and use it via the BPI or to use it remotely via the BPI.

[0091] Messaging aspects It has been recognized by the inventors that it can often be useful to maintain an immutable record on a blockchain of information that the blockchain is not necessarily designed to store. Throughout the following, the term "message" is used, but it should be understood that "message" encompasses any type of information for which one wishes to keep a record using a blockchain.

[0092] By using a blockchain to keep a record of messages, a virtually immutable record of the messages can be kept so that the contents of the messages can be verified in the future. Blockchains are equipped to approve some types of information in the transactions contained in each block, but are typically very prescriptive about what that information is. For example, many popular blockchains (such as Bitcoin) were originally designed for cryptocurrency and simple financial transfers. Other blockchains have been developed for other specific purposes, and even more blockchains may be developed in the future for still further specific purposes. In the course of developing the Overledger Communication Layer 20, the inventors realized that being able to store some types of information on a blockchain that was not designed for that purpose could be very useful. One specific use case is as part of maintaining a record of the order of transactions appearing on one or more blockchains, as described below, but there are many other potential uses and benefits.

[0093] Having realized the potential benefits of storing messages on a blockchain that was not designed for that purpose, the inventors investigated the details of transactions within existing blockchain architectures. They noticed that many blockchain architectures contain fields within transactions in which non-essential data can be added. For example, Bitcoin has an OP-RETURN field, Ethereum has a field used for script bytecode, and Ripple has a "memo" field. These fields are sometimes commonly referred to as "non-essential data fields". However, the size, and therefore the usefulness, of each of these fields is relatively limited. It is set forth.

[0094] The solution identified by the inventors is to use such a field to store a value that is based at least in part on and uniquely represents a message (e.g., a hash or encryption of the message) and then store the message elsewhere (off-chain). The value that uniquely represents the message can act as a pointer (e.g., a hash pointer) to the complete message stored off-chain. By storing a value that uniquely represents the message on the blockchain, the integrity of the message can be checked at any time by simply generating a test value based on the message stored off-chain and checking it against the value stored on the blockchain. Since the test value was generated in the same way as the value stored on the blockchain (e.g., using the same hash recipe), if the test value matches the value stored on the blockchain, then the message stored off-chain is consistent (i.e., unaltered). If they do not match, then the message stored off-chain has been tampered with in some way. This is because the values ​​stored on the blockchain cannot be altered in any way, since the contents of the blockchain are effectively immutable.

[0095] Those skilled in the art will appreciate that the value that uniquely represents the message may be generated in any suitable manner. For example, the value may be generated by hashing the contents of the message using a hashing algorithm such as SHA-2 (e.g., SHA-256, SHA-512, etc.) or SHA-3, and the value that uniquely represents the message is the hash and serves as a hash pointer within the blockchain. Alternatively, the value may be generated by encrypting the contents of the message using any suitable encryption algorithm. The particular manner in which the value that uniquely represents the message may be generated may be selected based on the requirements of the particular blockchain in which the message is stored, and / or the particular cryptographic requirements that need to be met (e.g., the level of integrity provided by the algorithm, etc.). For example, the transaction field in which the value is stored may have a particular maximum length, and certain hash algorithms are excluded because the hash that is generated may be too long. The Overledger SDK may include particular hashing and / or encryption algorithms appropriate for the DLT it supports, such that the application functionality layer need only pass the message to the Overledger communication layer 20, which may then process the message appropriately to store a record of the message in the DLT. The application may then store a copy of the message elsewhere off-chain (e.g., in the local memory of the device on which the application is running, or in remote memory such as a remote database or cloud storage).

[0096] As previously mentioned, there are many potential uses for the messaging aspects described above. One particular, non-limiting use case is described below with reference to FIG.

[0097] FIG. 5 illustrates a system 500 including a service offering developer 310, a client application developer 320, a client application backend 510, a first client application 520, a second client application 530, and a first DLT network 240. The service offering developer 310 can create a BPI for a messaging service that provides BPI functionality for logging messages to one or more DLTs using the messaging aspects described above. The client application developer 320 can then use the Overledger SDK and the service offering developer's 310 BPI configuration file to develop a messaging application that allows users of the messaging application to securely send messages to each other. The first client application 520 and the second client application 530 communicate with the electronic devices of the first and second users. The first and second client applications 520 and 530 may run on the first and second users' electronic devices, such as a mobile electronic device (such as a smartphone, or tablet computer, or laptop computer) or a desktop computer, respectively. The first and second client applications 520 and 530 may run on the first and second users' electronic devices, as software installations on the devices, as web browser-based applications, or the like.

[0098] When a first user wishes to convey a message to a second user, the first user may input the message and the second user's ID (the ID may take any suitable form, e.g., the username of the second user of the client application) into the first client application 520. The client application's functionality application layer 30 may be configured to pass the message to the overledger communication layer 20 of the first client application 520 for addition to the first DLT 12 using an appropriate function / command of the BPI created by the service offering developer 310. The overledger communication layer 20 may then hash the message according to the method of the SDK for interacting with the first DLT 12, construct an appropriate transaction for the first DLT 12 that includes the hash of the message, and communicate the transaction to the first DLT network 240. The hash of the message is thus included in the first DLT 12. The overledger communication layer 20 of the first client application 520 may also be configured to optionally return a notification to the application functionality layer 30 when it determines that the transaction has been successfully added to the first DLT 12. A copy of the entire message and the hash of the message may also be communicated to the client application backend 510 (which may be, for example, a server, database, or cloud-based storage system provided by the client application developer 320 for receiving, storing, and retrieving messages), for example by the application functionality layer 30 receiving the hash of the message from the overledger communication layer 20 and communicating it along with the message to the client application backend 510. Communications between the first client application 520 and the client application backend 510 may optionally be secured using any suitable encryption technique.

[0099] The second user may then notice that a message is waiting. There are many different ways this can occur, for example the second user identifier may be the second user's DLT public key or DLT wallet, or may have been used by the first client application 520 to obtain the second user's DLT public key or DLT wallet, and a transaction on the DLT 12 may identify the second user's public key or DLT wallet as the recipient of the transaction. In this case, the second client application 530 may notice that the second user is identified in a new transaction in the first DLT 12 (if the second client application 530 is configured to monitor the contents of each new block added to the first DLT 12 looking for any new transactions that identify the second user's DLT public key or DLT wallet). Alternatively, a third party service may perform this monitoring process and notify the second client application 530. The application functionality layer 30 of the second client application 530 can then use the appropriate BPI “read” function to obtain the hash of the message from the first DLT 12 .

[0100] Once the second client application 530 has a copy of the message hash, the application functionality layer 30 may communicate it to the client application backend 510 along with some form of authentication to authenticate the second user to the client application backend 510 (e.g., this may be done by the second client application 530 itself). The second client application 530 may then verify the integrity of the returned message by passing it through the same hash algorithm used by the first client application 520 (e.g., using a suitable "check message" BPI function, or in any other manner the service offering provider 310 and / or client application developer 320 deem suitable), creating a test hash, and then comparing the test hash to the message hash obtained from the first DLT 12.

[0101] Many advantages of this particular example process will be immediately apparent. First, the contents of the message may be securely passed from a first user to a second user without the need for techniques that are complex and often difficult to perform reliably, such as encrypted email or password-protected documents that require the agreement of a password between the two users. Furthermore, the second user 530 can be confident that the client application backend 510 has not tampered with the message in any way, since the test hash would not otherwise match the message hash stored in the first DLT 12. Furthermore, if at any time in the future there is any form of dispute between the first and second users regarding the contents of the message, the message hash stored in the first DLT 12 can be used to settle the dispute once and for all.

[0102] The second user may likewise reply to the message in a similar manner.

[0103] It will be appreciated that this is just one particular use case of the messaging aspects of the present disclosure, and that many others may be possible. Additionally, many alternative implementations of the above particular use case are possible. For example, the application backend may alternatively be provided by the service offering developer 310, the BPI may simply be configured to receive messages, and the overledger commutation layer 20 may handle placing the message hash in the first DLT 12, as well as communicating the message and the message hash to the application backend 510. In this case, the application functionality layer 30 of the client application may only be concerned with other functionality, such as the GUI and other functionality provided by the client application. Additionally, the application functionality layer 30 may utilize functionality or commands provided by the BPI to place the message hash in many DLTs, not just one, thereby providing further redundancy and backup of the message hash.

[0104] Transaction ordering aspects A key requirement for reliable blockchain operation is transaction ordering. For example, to prevent double-spending cryptocurrency fraud, it is traditionally recognized that when a new transaction is broadcast to the blockchain network, it must be possible to determine whether the cryptocurrency identified in the new transaction has been previously spent, and to include the new transaction in a new block only if the new transaction has not been previously spent (i.e., preventing double-spending). Many existing blockchains achieve this by virtue of the chronological nature of the blocks on the blockchain, where each block contains a timestamp that verifies that the cryptocurrency identified in the new transaction has not yet been spent in any existing block.

[0105] However, the inventors have recognized that reliable ordering of transactions may be important not only for cryptocurrency blockchains, but more generally for all types of blockchains. For example, it will be appreciated that in various Internet and telecommunications fields and protocols, misordered messaging may be exploited as a security and stability weakness. For example, there are many ways in which the ordering and synchronization of TCP / IP packets may affect the security of a system, e.g., messages being out of order or a message set being incomplete may reduce the security of the system, either in terms of integrity or availability. Thus, the inventors have recognized that maintaining the correct ordering of transactions within a blockchain may be critical to obtaining a safe, secure and fraud-resistant system utilizing one or more DLTs, e.g., when used to carry messages according to the messaging aspects described above, but also for any other purpose.

[0106] Two particular challenges in maintaining correct transaction ordering in DLT are identified by the inventors.

[0107] 1. When a blockchain forks, one or more transactions that appeared in the shorter prong of the fork may be lost from the blockchain. Those skilled in the art will readily recognize the possibility of a DLT forking and the characteristics of how the DLT behaves in that case. However, it should be noted that traditionally, if a transaction is lost due to a fork, that transaction may be later added to the longer prong of the fork by the network of participating nodes if the transaction is recognized as lost.

[0108] FIG. 6 illustrates an exemplary representation of a fork in a blockchain. Transaction 1 is part of block B1, which appears in “prong 1” of the blockchain. However, as a result of the fork, transaction 1 is effectively lost from the blockchain because the blockchain continues in a longer prong, “prong 2”. Transaction 2 is part of block B3, which appears in “prong 2”. Sometime later, transaction 1 is added to the blockchain as part of block B8 in “prong 2”. Thus, transaction 1 appears later in the blockchain than transaction 2. However, if it is important that transaction 1 precedes transaction 2 (e.g., if they are related in successive messages), this could cause security or stability flaws or enable fraud to occur in applications utilizing the blockchain.

[0109] 2. As previously described, in some scenarios it may be desirable for an application to utilize two or more different DLTs. As part of this, it may sometimes be necessary to perform a cross-ledger transaction (XLT) to move data (e.g., a message (discussed above), or a portion of a cryptocurrency, or other type of separate information stored in a DLT) from one DLT to another. However, each blockchain may be developed to maintain ordering among different blocks on that blockchain (e.g., using timestamps), and because each DLT may utilize different timestamp procedures and / or the clocks used for timestamps may not be synchronized, it may be very difficult to reliably identify ordering among transactions that appear on different blockchains. Thus, when utilizing two or more (multiple) DLTs, determining and maintaining the order of transactions that appear on the DLTs may be critical to the security and stability of the application using the DLTs.

[0110] Figure 7 shows exemplary method steps of a process developed by the inventors to maintain transaction order using a "validation set." Figure 8 shows an example visualization of two DLTs and a validation set that is useful for understanding the method steps of Figure 7.

[0111] In step 710, the first DLT 12 and the second DLT 14 are monitored to identify when a new transaction of interest is included in a block added to the first DLT 12 or the second DLT 14. The first DLT 12 and the second DLT 14 may be monitored by reading the contents of each new block as it is added to the DLT. The relevance criteria for what constitutes a transaction of interest is a matter of the particular implementation of the method. For example, the BPI disclosed above may be configured such that any transaction placed in the DLT using the BPI includes a specific identifier that distinguishes it from transactions placed in the DLT by any other means (e.g., by other entities not using the BPI). The specific identifier may be, for example, a public key used in the transaction, or some other type of information in the transaction. As a result, the relevance criteria may be an identifier included by the BPI such that any transaction included in the first DLT 12 or the second DLT 14 using the service provided by the service offering developer 310 (e.g., a transaction added by the first client application 520 or the second client application 530, or for that matter any service application operated by the service offering developer to place the transaction in the DLT as required) meets the relevance criteria and may be identified as relevant. This may be particularly useful when the first DLT 12 and / or the second DLT 14 are generic DLTs that may be utilized by many different entities, but the service offering developer 310 needs to identify transactions that are relevant to its service to ensure proper ordering of transactions to protect the security and stability of the service offering.

[0112] In Figure 8, transactions A, C, E, and O are all target transactions. The transaction labeled "Transaction X" is not a target transaction.

[0113] When a new block is added to either the first DLT 12 or the second DLT 14 and identified in step S710 as containing related transactions, a transaction identifier (e.g., a hash) may be determined for each identified based at least in part on the contents of the transaction in step S720. This identifier is then added to a current or "ongoing" validation set. The validation set is part of an off-chain record of related transactions stored in any suitable memory, database, data array, cloud storage, or other data store. The transaction identifier may act as a pointer (e.g., a hash pointer) to the related transactions in the DLT. Each new transaction ID is added to the "ongoing" validation set in the order in which it was found. Thus, the record of the identified transactions indicates the relative order of the transactions regardless of whether the transaction appeared in the first DLT 12 or the second DLT 14. As a result, it can be seen that by monitoring both DLTs and adding a transaction identifier for each related transaction as soon as it is added to the first DLT 12 or the second DLT 14, the relative order of transactions may be recorded across one or more different DLTs. Those skilled in the art will recognize that the "in progress" validation set may be stored using any suitable data storage technique that maintains the order of related transactions. Once a new related transaction has been added to the "in progress" validation set, the process may return to step S710 to continue monitoring the first DLT 12 and the second DLT 14.

[0114] At a particular time, the process may proceed to step S730 to begin the process of saving a record (e.g., a validation set identifier) ​​of the “in progress” validation set (e.g., a hash or encryption based at least in part on the contents of the “in progress” validation set) in the first DLT 12 and the second DLT 14. The particular time at which the process proceeds to step S730 is a matter of implementation and may, for example, be after a particular amount of time has been spent monitoring the DLT since the most recent previous validation set record was added to the DLT, or after a particular number of associated transactions have been added to the “in progress” validation set, or after a particular number of blocks have been added to the first DLT 12 or the second DLT 14 since the most recent previous validation set record was added to the DLT, etc.

[0115] In step S730, it is determined whether a record (e.g., a hash or encryption) of the contents of the immediately preceding validation set exists in both the first DLT 12 and the second DLT 14 (e.g., to ensure that there are no forks in either DLT that would cause the record to be lost). If the record appears in both DLTs ("Yes" in FIG. 7), the process proceeds to step S750. If the record does not appear in both DLTs ("No" in FIG. 7), the process proceeds to step S740. This check may be performed by searching for a record of the immediately preceding validation set in both DLTs.

[0116] In step S740, the missing record may be replayed on the DLT in which it is missing (essentially, the transaction whose record was originally placed on the DLT is rebroadcast and added to the DLT, e.g., using the "messaging aspects" described above). However, before replaying the missing record, it may first be determined whether any of the transactions identified in the immediately preceding validation set are missing from the corresponding DLT in which they should have appeared. This may be quickly determined by using the pointer nature (e.g., a hash pointer) of the transaction identifier in the immediately preceding validation set that is stored in the transaction record. Any missing transactions may then be replayed on the associated DLT before replaying the missing record of the immediately preceding validation set. Any replayed transactions may now appear in a later DLT than the transactions that the missing transactions would have preceded (if they had not been missing), but the validation set will still have maintained a proper record of the correct order of transactions. As a result, the missing validation set records, and any missing transactions associated with them, may be re-added to the DLT without losing the proper order in which the transactions occurred. The details of this step can be more fully understood from the discussion of Figures 8 and 9 below.

[0117] In step S750, it is determined whether all transactions identified in the "in progress" validation set are still present in the associated DLT (e.g., to ensure that none have been lost due to one or both forks of the DLT). If they are all still present in the associated DLT ("Yes" in FIG. 7), the process proceeds to step S770. If they are not all present in the associated DLT ("No" in FIG. 7), the process proceeds to step S760. This check may be performed by the nature of the transition identifier pointer in the "in progress" validation set.

[0118] In step S760, the transaction identified as now missing may be redone (essentially rebroadcast and added to the DLT) on the corresponding DLT where it should have appeared. Any redone transactions may now appear in a DLT later than the transactions that the missing transaction would have preceded (if it had not been missing), but the "in progress" validation set will still maintain a proper record of the correct ordering of transactions. As a result, the missing transaction may be Transactions can be added back to the DLT without losing the proper order in which they occurred.

[0119] In step S770, a record of the "in progress" validation set is determined based at least in part on the contents of the "in progress" validation set (e.g., determining a validation set identifier, such as a hash or encryption, based at least in part on the contents of the validation set) and added to both the first DLT 12 and the second DLT 14. The record may be added to both DLTs by utilizing the techniques described in the "Messaging Aspects" above. As a result, it can be seen that by using the "Messaging Aspects" above, a record of the contents of the "in progress" validation set can be added to both DLTs, thereby providing an effectively immutable record of the contents of that validation set, which can be used to provide improved data integrity, and therefore security and reliability, of the records of the associated transactions. The process then returns to step S710 to continue monitoring the DLTs and may begin work on the next "in progress" validation set.

[0120] Returning to Figure 8, the validation set n-1 810, Validation Set n 820, and the validation set n+1 830, one can see records 840 of the associated transactions stored in an off-chain data store (any suitable type of data store, database, cloud storage, or any other type of memory). n-1810 includes a hash of transaction Y and a hash of transaction Z, which are previous transactions on the first DLT 12 or the second DLT 14, and are not shown separately in FIG. 8 for simplicity. n 820 includes a hash 822' of transaction A, a hash 824' of transaction O, and a hash 826' of transaction C. Transactions A 822 and C 826 appear in the first DLT 12, and transaction O 824 appears in the second DLT 14. They form a validation set n The order of appearance in 820 indicates that transaction O 824 was found after transaction A 822, but before transaction C 826. n+1 830 contains a hash 832' of transaction E, which in this example can be considered the "in progress" validation set.

[0121] As can be seen, the validation set n-1 810' hash and validation set n Both hashes of 820' have been previously added to both DLTs according to step S770 above. n If 820 was an "in progress" validation set, when it gets to step S730 above, the validation set n-1 It will be appreciated that since the hash of 810' is present in both DLTs, the process can proceed directly to step S750. Similarly, once it gets to step S750, since transaction A 822, transaction O 824 and transaction C 826 all still appear in their associated DLTs, the process proceeds directly to step S770, where both DLTs contain the validation set n A hash of 820' may be added.

[0122] It will be seen that as a result of this process, an off-chain record of the order of transactions appearing on the two blockchains is kept by the validation sets in the transaction record 840. The off-chain record indicates the relative order of the transactions they relate to. By also using the "messaging aspect" above to store a hash pointer for each validation set in both DLTs, a record of each validation set may be kept in the DLT, which may be particularly useful in maintaining the data integrity and security of the off-chain record of the validation sets, and in the event of a fork occurring in the first DLT 12 and / or the second DLT 14 as described below.

[0123] FIG. 9 is a block diagram of the method of FIG. 7 to aid in understanding the method steps, particularly steps S730 to S760. FIG. 9 shows a further exemplary visualization of the two DLTs and the validation set. FIG. 9 is similar to FIG. 8, but includes a representation of a fork of the first DLT 12, which has resulted in two transactions and one record of the validation set being lost from the first DLT 12.

[0124] In FIG. 9, the first DLT 12 forks before including transaction C 826. Transaction C 826, validation set n The hash of 820', and transaction E 832 all appear in "prong 1" of the fork. However, in this example, it is "prong 2" of the fork that moves forward as DLT 12, and the contents of "prong 1" are effectively lost (at least temporarily). n If we add the hash 820' to the DLT, the validation set n+1 At 930, operation begins, which as can be seen includes, in order, a hash of transaction E 832' and a hash of transaction G 934'. At point P identified in FIG. 9, the process of FIG. 7 proceeds to step S730, at which point the validation set nIt is identified that the hashes of transaction C 820' and transaction C 826 no longer appear in the first DLT 12 (because they both appear in "prong 1", which is the prong of the missing fork). As a result, in step S740, transaction C is replayed (identified in FIG. 9 by reference numeral 926, although it will be understood that the content of original transaction C 826 and replayed transaction C 926 are the same), and then a validation set n (identified in FIG. 9 by reference number 920′, it will be understood that the original hash of validation set 820′ is the same as the hash of the redone validation set 920′). Then, in step S750, transaction E832 (the “in progress” validation set n+1 It is determined that transaction E (identified as 930 in FIG. 9 ) no longer appears in the first DLT 12 because it was included in “prong 1”. Thus, in step S760, transaction E is replayed (identified as 932 in FIG. 9 , although it will be understood that the content of original transaction E 832 and replayed transaction E 932 are the same). Thereafter, in step S770, the validation set n+1 The hash of 930' is added to both DLTs. Therefore, transaction C826, the validation set nIt can be seen that even if the hashes of A, B, C, E, and E, and E, were all lost from the first DLT 12, they could still be added back to the first DLT 12 after transaction G (which first occurred after transaction C and E) without losing any reliable record of the true order of transactions, thereby ensuring the security and stability of the system. As a result, it will be appreciated that while including the hashes of the validation sets in the DLT is optional (alternatively, the off-chain records of the transactions could simply be retained without storing any hashes of the validation sets in the DLT), storing a record of each validation set in the DLT not only allows for improved security and reliability by enabling data alignment of the off-chain validation sets, but also allows for forks to be quickly identified and missing records and / or transactions to be re-added to the relevant DLT.

[0125] It will be appreciated that while each block shown in Figure 9 contains only a single transaction, in practice each block is likely to contain many transactions. Additionally, while the above describes a process using two DLTs, it will be appreciated that the process may be applied to a single DLT, or to three or more different DLTs. Additionally, while the above describes a validation set and a "hash" of the transaction, any suitable validation set identifier determined at least in part based on the contents of the validation set, and any suitable transaction identifier based at least in part on the contents of the transaction may instead be used.

[0126] Furthermore, while in the above process the hash of the validation set is added to both DLTs, in an alternative approach the hash may be added to only one of the DLTs. It may be desirable to include the hash of the validation set in two or more DLTs in operation, since even in the event of a fork, there should always be at least one record of the immediately preceding validation set (it is extremely unlikely that two DLTs would fork independently at the same time, causing both to lose the hash of their immediately preceding validation set). This can be useful for data integrity, i.e. security, reasons.

[0127] Further, in addition to or instead of storing hashes of related transactions in the validation set, complete copies of related transactions may be stored. However, for data storage efficiency, storing hashes of related transactions may be preferable. In one implementation, a hash of each related transaction may be stored, and complete copies of recent related transactions may be stored (e.g., transactions in the last 1, 2, 3, 4 validation sets), which may be useful for redoing missing transactions. By storing only recent related transactions, data storage requirements may still be minimized.

[0128] Additionally, while identifying and replaying missing transactions is optional, it may be desirable to perform these procedures to ensure that the DLT is as up-to-date as possible and that the order of transactions on the DLT corresponds as closely as possible to the order of the actual transactions as identified in the transaction records 840.

[0129] Cross-ledger transaction behavior To help further understand the importance of the transaction ordering aspects described above, we now describe an exemplary Cross-Ledger Transaction (XLT) process that utilizes the transaction ordering aspects.

[0130] In this example, it is desired to transfer information appearing in a transaction in a first DLT 12 to a second DLT 14. The information could be anything, for example an amount of cryptocurrency, a hashed message (as described above in "Messaging Aspects"), or any other data. The transaction may transfer information from a first owner to a second owner, or ownership may not be transferred at all (e.g., an entity may simply want to store the information in another DLT, effectively deleting it from the previous DLT).

[0131] FIG. 10 shows an example of the visualization of two DLTs and the corresponding validation set that constitutes a record 1040 of a transaction stored off-chain, on which the XLT is executed. Transaction S1012 contains information that is transferred from the first DLT 12 to the second DLT 14. n-1 1010 includes a hash 1012' of transaction S. The XLT may be executed using a two-phase commit process, which will be well understood by those skilled in the art, but is nevertheless briefly described below for completeness. A proposal to transfer transaction S's information from DLT 12 to DLT 14 is first added to DLT 12 (identified as "proposed XLT(S) 1022" in FIG. 10). This effectively locks transaction S 1012 so that it cannot be used by any other transaction. The intended recipient (which in some circumstances may be the same entity as the current owner of the information to be transferred, as explained above) may then indicate in DLT 14 that it is ready to accept the transfer (identified as "ready XLT(S) 1026"). Alternatively, in some DLT protocols it may indicate readiness by repeating "proposed XLT(S) 1022" in a second DLT 14. Once the second DLT 14 indicates that it is ready, both DLTs (identified in FIG. 10 as “commit XLT(S) 1032” and “commit XLT(S) 1034”) A cross-ledger transaction may be executed by a commit transaction that is added to the first DLT 12. As will be well understood by those skilled in the art, this commitment effectively removes the traded item from the first DLT 12 and places it in the second DLT 14.

[0132] In order to execute the XLT safely and securely without risk of fraud or system failure, it may be necessary to ensure that a readiness indication appears on the second DLT 14 before the commit transaction is placed on the two DLTs before the XLT can be executed. Furthermore, it may be desirable for the readiness indication to always follow the proposal so that the two can be properly matched and authenticated. In this way, it can be ensured that the readiness indication does not actually relate to some other similar but different transaction (e.g. relating to an XLT proposal between the same parties but for the contents of a different previous transaction on the DLT 12). It can also be ensured that the readiness indication does not fraudulently change any of the details of the XLT.

[0133] Conventionally, as previously described, it has been very difficult to determine the correct order of transactions on different DLTs, especially when one or more DLTs have undergone a fork. As a result, it has been difficult to execute XLTs in a safe, simple and secure manner. However, by utilizing the above transaction ordering aspects, the correct order of related transactions can be recorded even when one or more DLTs have undergone a fork.

[0134] For example, aspects of transaction ordering may be used to ensure that XLT criteria are met, such as both that the proposed XLT(S) 1022 corresponds to the ready XLT(S) 1026 (and optionally both still appear on the first DLT 12 and the second DLT 14, respectively), and that the proposed XLT(S) 1022 precedes the ready XLT(S) (even if a fork has occurred). In this regard, the commit XLT(S) 1032 transaction may be added to the DLT only after the XLT criteria are met. Optionally, the XLT criteria may include a criterion that a hash of a validation set identifying the proposed XLT(S) 1022 and ready XLT(S) 1026 transactions is present in one or both DLTs, thereby ensuring that both the proposed XLT(S) 1022 and ready XLT(S) 1026 transactions are present in the respective DLTs. In this example, the hash 1022' of the proposed XLT(S) and the hash 1026' of the ready XLT(S) appear in the same validation set, but it is understood that in some cases they may appear in different validation sets. If the hash 1022' of the proposed XLT(S) appears in a validation set preceding the validation set in which the hash 1026' of the ready XLT(S) appears, then the correct order can be confirmed. If the hash 1022' of the proposed XLT(S) appears in a validation set following the validation set in which the hash 1026' of the ready XLT(S) appears, then it can be confirmed that the transactions are in the wrong order, and therefore no XLT will occur.

[0135] As can be seen in FIG. 10, the validation set n 1020 includes the hash 1022′ of the proposed XLT(S), followed by the hash 1026′ of the ready XLT(S) (validation set n1020 also includes hashes of other transactions that are considered related, but that are not related to the XLT described here. In practice, an entity constructing a validation set may identify many related transactions in the DLT and identify them in the validation set. Some of those related transactions may be related to each other, such as transactions related to a particular XLT, and others may not be related to each other in any way, for example, related to different XLTs or to any other kind of DLT transaction that the entity considers to be related. Validation Set n The hash 1020' appears in both DLTs, and then the commit XLT of the first DLT 12 ( This is followed by a commit of the second DLT, XLT(S) 1032, and a commit of the second DLT, XLT(S) 1034 (which are then used to n+1 (Identified by 1030).

[0136] This type of XLT can be implemented in a variety of other ways. Figure 11 shows one particular implementation example involving a service offering developer 310, who in this particular example develops a service application (or software package / module) 1110 for implementing the XLT, and also provides the BPI to a client application developer 320, allowing the client application developer to develop a particular XLT client application (alternatively, the service offering developer 310 may create the client application itself, in which case the BPI is not provided to any external developer). The first client application 1120 and the second client application 1130 are copies of the XLT client application that the first entity 1140 and the second entity 1150 obtained from the client application developer 320, respectively. The client application in this example can effectively implement the application functionality layer 30, and the software package or module 1110 can effectively implement the overledger communication layer 20.

[0137] FIG. 12 illustrates exemplary steps that may be performed by the example system shown in FIG.

[0138] In step S1210, the service application 1110 receives a request from a first client application 1120 to execute an XLT and transfer an item of information appearing in the first DLT 12 to the second DLT 14 and transfer ownership to a second entity 1150. As will be appreciated, the request may include any information necessary to execute the XLT, as defined in the BPI.

[0139] In step S1220, the Service Application 1110 may broadcast the Proposed XLT transaction to the first DLT network 240 for addition to the first DLT 12.

[0140] Next, in step S1230, the service application 1110 can broadcast the ready XLT transaction to the second DLT network 250 for addition to the second DLT 14. Optionally, the service application 1110 can communicate its intention to execute the XLT to the second client application 1130, and then perform steps S1220 or S1230 only after receiving confirmation from the second application 1130 that the transaction should occur.

[0141] Meanwhile, the service application 1110 performs the transaction ordering aspects described above and stores records of related transactions in the data store 1115 that indicate the ordering of the related transactions.

[0142] In step S1240, the service application 1110 can also verify that the proposed XLT transaction is identified in the stored record of transactions as having occurred before the corresponding ready XLT transaction, and, optionally, that the hash of the associated validation set has appeared in one or both DLTs.

[0143] If this check is successful, then in step S1250, the service application 11 10 broadcasts the commit XLT transaction to the first DLT network 240 and the second DLT network 250 for addition to the first and second DLTs. Optionally, the service application 1110 may notify the first client application 1120 and / or the second client application 1130 of a successful XLT (this may be performed after the commit XLT transaction appears in both DLTs, or after a hash of the validation set in which the commit XLT transaction was identified is included in one or both of the DLTs). If the validation is not passed, the XLT process may time out after a period of time, and the first client application 1120 and / or the second client application 1130 may be notified of the failure.

[0144] Thus, by implementing the ordering aspects described above, and then only posting a commit transaction to the DLT after the validation set has verified that the proposed XLT transaction and the corresponding ready XLT transaction have been performed in the correct order, the service application 1110 can ensure that the XLT is executed safely and stably.

[0145] It will be understood that this is merely one particular, non-limiting example. Alternatively, depending on the implementation of the particular BPI provided by the service offering developer 310 and / or the client application provided by the client application developer 320, the first client application 1120 may itself broadcast the proposed XLT transaction to the first DLT network 240 and / or the second client application 1130 may itself broadcast the ready XLT transaction to the second DLT network 250. In this case, the service application 1110 may simply perform the transaction ordering aspect described above and then perform steps S1140 and S1150 upon identifying the proposed XLT transaction and the corresponding ready XLT transaction in the relevant DLT. Furthermore, an XLT may only contain one entity, since an entity may simply move information from one DLT to another, with any change of ownership.

[0146] It will be appreciated that the Overledger SDK may include rules and methods for implementing transaction ordering aspects and optionally XLT aspects as well. Thus, the Overledger SDK provides tools that allow a service offering developer 310 to implement any service application / module that utilizes transaction ordering aspects (and optionally XLT aspects) with any selected DLT supported by the Overledger SDK. The corresponding BPI of the selection is then created to make any appropriate functionality of the service offering available to the client application developer 320 such that interactions with the DLT in implementing the ordering aspects can be performed by the Overledger communication layer 20 and decoupled from the operation of any application functionality layer 30 on the client application. As a result, the client application can take advantage of the security and stability benefits provided by the transaction ordering aspects while remaining decoupled from direct interactions with the DLT.

[0147] As a result, it can be seen that by providing an Overledger SDK that contains the rules and methods for implementing the transaction ordering aspects, it can be seen that there is great flexibility and opportunity for the technical advantages of the transaction ordering aspects to be utilized in a variety of ways by a wide range of different entities, while still decoupling blockchain interactions from the application functionality layer 30.

[0148] Those skilled in the art will readily appreciate that various changes or modifications can be made to the above-described aspects of the present disclosure without departing from the scope of the present disclosure.

[0149] While all interfaces indicated with arrows in Figures 2, 3, 5, and 11 indicate direct connections between each of the different entities and modules, it will be appreciated that there may be any number of intermediate entities or modules as part of these interfaces, such as, for example, communication routers. Furthermore, each interface may convey data / communications between each of the entities and modules according to any suitable communication architecture and protocol.

[0150] All of the above described aspects of the disclosure may be implemented by software, hardware, or a combination of software and hardware. For example, the transaction ordering aspects and / or the XLT aspects and / or the overledger messaging layer may be implemented by software including computer readable code, which performs the above functions when executed on one or more processors (such as one or more microprocessors, or programmable logic) of any electronic device (such as any standard computing device, such as a server, desktop computer, or laptop computer). The software may be stored on any suitable computer readable medium, such as a non-transitory computer readable medium, such as a read-only memory, a random access memory, a CD-ROM, a DVD, a Blu-ray, a magnetic tape, a hard disk drive, a solid state drive, and an optical drive. The computer readable medium may be distributed across network-coupled computer systems such that the computer readable instructions are stored and executed in a distributed manner.

Claims

1. 1. A method for a blockchain communication layer providing interoperability between an application function layer and a plurality of different blockchains, the application function layer including functional operations utilizing one or more of the plurality of different blockchains, the method comprising: receiving a blockchain request from the application functionality layer, the blockchain request relating to a blockchain operation to be performed on one or more of the plurality of different blockchains; interfacing with the one or more blockchains according to a protocol of the one or more blockchains to perform the blockchain operations; Including, the blockchain request includes a request to execute a cross-ledger transaction (XLT) between a first blockchain of the plurality of blockchains and a second blockchain of the plurality of blockchains, the cross-ledger transaction (XLT) moving data from the first blockchain to the second blockchain.

2. The method of claim 1 , wherein the blockchain request comprises a request to read data on the one or more blockchains.

3. 3. The method of claim 2, wherein the request to read data from one or more blockchains includes a data identifier indicating data to be read from the one or more blockchains.

4. interfacing with the one or more blockchains includes reading the requested data on the one or more blockchains; 4. The method of claim 2 or claim 3, further comprising the blockchain communications layer communicating the data read from the one or more blockchains to the application functions layer.

5. The method of any one of claims 1 to 4, wherein the blockchain request comprises a request to write data to the one or more blockchains.

6. 6. The method of claim 5, wherein the data write request comprises data to write to the one or more blockchains.

7. Returning a result of writing the data to the one or more blockchains to a sender of the request to write the data. The method of claim 5 or claim 6, further comprising:

8. 8. The method of claim 1, wherein the request to execute the XLT includes an XLT data identifier indicating the data on the first blockchain to be transferred to the second blockchain by the XLT.

9. 9. The method of claim 1, wherein interfacing with the first blockchain comprises writing data to the first blockchain for executing the XLT, and wherein interfacing with the second blockchain comprises writing data to the second blockchain for executing the XLT.

10. 10. The method of claim 9, wherein data written to the first and second blockchains is based on but differs from data forming part of a request to execute the XLT.

11. Interfacing with the one or more blockchains includes: writing a proposed XLT transaction to the first blockchain; writing a ready XLT transaction to the second blockchain; writing a commit XLT transaction to the first blockchain; writing a commit XLT transaction to the second blockchain; The method according to any one of claims 1 to 10, comprising any one or more of the following:

12. 12. The method of any one of claims 1 to 11, wherein interfacing with one or more blockchains comprises writing data to two or more of the plurality of different blockchains.

13. 13. The method of claim 12, wherein the data written to each of the two or more blockchains is based on but differs from data forming part of the blockchain request.

14. 14. The method of claim 12 or 13, wherein data written to a first one of the two or more blockchains is different from data written to a second one of the two or more blockchains.

15. The method of claim 14, wherein the data written to the first blockchain, which is a proposed XLT transaction, is logically linked to the data written to the second blockchain, which is a ready XLT transaction.

16. The method according to any one of claims 1 to 15, wherein communication between the blockchain communication layer and the application function layer can be performed according to a method defined by a blockchain programming interface (BPI).

17. one or more processors; A memory for storing a software program, said software program being configured to cause said one or more processors to perform the method of any one of claims 1 to 16 when executed by said one or more processors; A system including:

18. One or more computer programs, when executed by one or more processors, causing said one or more processors to perform the method of any one of claims 1 to 16.

Images