Secure multi-distributed ledger system

Abstract

The present disclosure relates to methods, systems, electronic devices, and computer programs that enable execution of instructions using any of two or more different distributed ledgers. The disclosure includes a computer-implemented method for executing instructions issued via any of two or more different distributed ledgers, the method including: monitoring multiple distributed ledgers for distributed ledger transactions including instructions to be executed; identifying a first plurality of distributed ledger transactions, each including instructions to be executed, appearing in any of the multiple distributed ledgers; verifying some of the first plurality of instructions in the identified first plurality of distributed ledger transactions; executing instructions for each of the first plurality of instructions that are positively verified; and storing results of the executed instructions in an electronic data record. This allows, for example, a user to issue instructions on two or more different distributed ledgers, and those instructions are executed securely and consistently, and any user data associated with the executed instructions is reliably updated consistently regardless of the distributed ledger on which each instruction is issued.

Description

[Technical Field]

[0001] The present disclosure relates to methods, systems, electronic devices, and computer programs for enabling the execution of instructions using any of two or more different distributed ledgers, such that user-related data may be securely controlled using any of the two or more different distributed ledgers. [Background technology]

[0002] Distributed ledger technology (DLT) has a vast range of potential uses, providing a way in which data can be stored securely and reliably without the need for a central data authentication authority. DLT can therefore enable many technical benefits across a wide range of areas, such as increased data transparency, more robust data storage that is not dependent on one particular storage entity, improved data security, and increased resistance to fraud, and is already finding use in areas as diverse as electrical energy distribution and peer-to-peer cloud storage.

[0003] Blockchain is an example of DLT and was first conceptualized in a 2009 white paper titled "Bitcoin: A Peer-to-Peer Electronic Cash System" published under the name of Satoshi Nakamoto. A copy of this white paper can be found at https: / / bitcoin.org / bitcoin.pdf. The white paper proposes a peer-to-peer version of electronic cash called "Bitcoin," which utilizes what has come to be called the blockchain to record peer-to-peer transfers of Bitcoin.

[0004] Distributed ledgers, such as blockchains or block-directed acyclic graphs (block-DAGs) (such as those described in the paper "Inclusive Block Chain Protocols" by Yoad Lewenberg et al., https: / / fc15.ifca.ai / preproceedings / paper_101.pdf), are digital ledgers or electronic data records that can be used to store virtually immutable records of data. They can be decentralized in that they do not necessarily require a central authority to add data to the distributed ledger or to maintain the integrity of the distributed ledger. In some cases, they are permissioned, meaning that any entity / node can write data to and read data from the distributed ledger. In other cases, they are permissioned, meaning that read and / or write privileges are granted only to authorized entities / nodes participating in the distributed ledger. Data may be added to a distributed ledger by an entity broadcasting a "transaction" to a network of nodes participating in the distributed ledger network, where the transaction includes the data to be added to the distributed ledger and cryptographic elements that conform to the distributed ledger protocol. Each of the nodes participating in the distributed ledger network can then verify the validity of the transaction and, if approved, can immediately add the transaction to their local copy of the distributed ledger, add the transaction to a block of transactions they are working on, or add the transaction to a list of unconfirmed transactions to await inclusion in a block broadcast by another node.

[0005] When a block of transactions is in place, each of the nodes will then broadcast the new block to the network of other nodes. After a period of time, the node publishes a new block to other nodes in the network, the new block containing various new transactions as well as cryptographic data that ties the new block to the preceding block in the blockchain or to the preceding block in the block DAG. By cryptographically linking successive blocks together in this manner, if a block in the blockchain or block DAG is altered at any later point in time (e.g., by someone wishing to tamper with the data stored in the blockchain or block DAG), it may be easily detectable.

[0006] After a new block is published by a node, other nodes in the network can verify the contents of the new block, and if accepted, the entire contents of the block are added to their local copies of the distributed ledger. Additionally, and optionally, each node can begin work on the next new block, which is again cryptographically bound to its preceding block or blocks. Thus, it can be seen that both the blockchain and the block DAG grow each time a new block is published and accepted, and each accepted new block is cryptographically bound to its preceding block or blocks. This process by which nodes verify published new transactions and published new blocks and accept this node into their copies of the distributed ledger is often referred to as the "consensus" mechanism.

[0007] The white paper, "Bitcoin: A Peer-to-Peer Electronic Cash System," proposes a specific protocol for the Bitcoin blockchain. The protocol includes the format and type of information that should be included in transactions, the format and type of information that should be included in new blocks, the cryptographic techniques and recipes that should be used for transactions and new blocks, and the specific type of consensus mechanism that should be used (e.g., in Bitcoin, the consensus mechanism utilizes hash-based proof-of-work in each block of the blockchain, which is also the cryptographic bond between each successive block). If a broadcast transaction does not properly conform to the protocol, the transaction will not be included in any new block. Similarly, if a new block does not properly conform to the protocol, the block will not be accepted into the blockchain by the network of nodes.

[0008] DLTs, including blockchains and block DAGs, were first proposed to enable the cryptocurrency Bitcoin but have since found many other uses. Initially, new cryptocurrencies such as Litecoin, Ripple, and Namecoin were launched, each utilizing its own specific DLT protocol and operating on its own specific distributed ledger network. Since then, it has been recognized that DLTs can be used much more broadly than cryptocurrencies and in any scenario where a virtually immutable record of data is useful. For example, Ethereum and Corda are DLTs created for the use of more expressive smart contracts—computer programs or instructions that run on the DLT and can be configured to execute specific processes when specific data appears on the distributed ledger. Another exemplary DLT is Hashgraph, which uses block DAGs. This has led to a rapid expansion of the number of different DLTs that currently exist, each tailored to its own specific use case, and it is expected that the number of different DLTs will continue to increase as the technology gains further momentum and recognition. [Prior art documents] [Non-patent literature]

[0009] [Non-Patent Document 1] “Bitcoin: A Peer-to-Peer Electronic Cash System”,Satoshi Nakamoto [Non-patent document 2] “Inclusive Block Chain Protocols”, Yoad Lewenberg et al-https: / / fc15.ifca.ai / preproceedings / paper_101.pdf Summary of the Invention

[0010] In a first aspect of the present disclosure, a computer-implemented method for executing instructions issued via any of two or more different distributed ledgers is provided, the method including: monitoring a plurality of distributed ledgers for distributed ledger transactions including instructions to be executed; identifying a first plurality of distributed ledger transactions, each appearing in any of the plurality of distributed ledgers, each including instructions to be executed; verifying at least some of the first plurality of instructions in the identified first plurality of distributed ledger transactions; for each of the first plurality of instructions that are positively verified, executing the instructions; and storing results of the executed instructions in an electronic data record.

[0011] The method may further include, after executing the positively verified instructions of the first plurality of instructions, storing in at least one of the plurality of distributed ledgers a first verification record indicating each stored result in the electronic data record.

[0012] The first verification record may indicate the order in which the positively verified instructions of the first plurality of instructions were executed. Additionally or alternatively, the first verification record may indicate the order in which the results of the executed first plurality of instructions were stored in the electronic data record.

[0013] The electronic data record may include a Merkle tree, and the method further includes updating the Merkle tree of the electronic data record based at least in part on each of the stored results of the executed instructions of the first plurality of instructions, and the first verification record includes a first Merkle root of the updated Merkle tree of the electronic data record.

[0014] The method may further include, after executing the positively verified instructions of the first plurality of instructions, generating a first instruction record based on the executed instructions of the first plurality of instructions, wherein the first verification record further includes the first instruction record.

[0015] The first instruction record may indicate an order in which the positively verified instructions of the first plurality of instructions were executed.

[0016] The first instruction record may include a second Merkle root generated using at least a portion of each executed instruction of the first plurality of instructions. Additionally or alternatively, the first instruction record may include a value (e.g., a hash) that uniquely indicates at least a portion of each executed instruction of the first plurality of instructions.

[0017] The first validation record may include a sequence identifier that indicates a relative order of the validation records stored in at least one of the multiple distributed ledgers.

[0018] The method includes storing the first validation record in at least one of the plurality of distributed ledgers, then verifying that the first validation record exists in at least one of the one or more distributed ledgers, and if the first validation record does not exist in at least one of the plurality of distributed ledgers, storing the first validation record in at least one of the one or more distributed ledgers. and reproducing the same together.

[0019] The method may further include storing a copy of each executed instruction of the first plurality of instructions; verifying that each executed instruction of the first plurality of instructions exists in at least one of the multiple distributed ledgers; and for each executed instruction of the first plurality of instructions that does not exist in at least one of the multiple distributed ledgers, broadcasting a new distributed ledger transaction to at least one of the multiple distributed ledgers, the new distributed ledger transaction including the executed instruction.

[0020] The method may further include determining an order for executing the positively verified first plurality of instructions, and executing the positively verified first plurality of instructions according to the determined order.

[0021] The method may further include identifying a second plurality of distributed ledger transactions, each appearing in one of the plurality of distributed ledgers, each including an instruction to be executed; verifying at least some of the second plurality of instructions; for each of the second plurality of instructions that are positively verified, executing the instruction; and storing a result of the executed instruction in an electronic data record.

[0022] The method may further include, after executing the positively verified instructions of the second plurality of instructions, storing in at least one of the plurality of distributed ledgers a second verification record indicating each result stored in the electronic data record as a result of the executed instructions of the second plurality of instructions.

[0023] The second verification record may indicate the order in which the positively verified instructions of the second plurality of instructions were executed.

[0024] The electronic data may include a Merkle tree, and the method further includes further updating the Merkle tree of the electronic data record based at least in part on each of the stored results of the executed instructions of the second plurality of instructions, and the second verification record includes a third Merkle root of the further updated Merkle tree of the electronic data record.

[0025] The method may include, after executing the positively verified instructions of the second plurality of instructions, generating a second instruction record based on the executed instructions of the second plurality of instructions, wherein the second verification record includes the second instruction record.

[0026] The second instruction record may indicate the order in which the positively verified instructions of the second plurality of instructions were executed.

[0027] The second instruction record may include a fourth Merkle root generated using at least a portion of each executed instruction of the second plurality of instructions. Additionally or alternatively, the second instruction record may include a value (e.g., a hash) that uniquely indicates at least a portion of each executed instruction of the second plurality of instructions.

[0028] The second verification record may include a sequence identifier that indicates that the second verification record follows the first verification record.

[0029] The method further includes determining an order for executing the positively verified second plurality of instructions; and executing the positively verified second plurality of instructions according to the determined order. It can be done.

[0030] At least one of the plurality of first distributed ledger transactions may appear on a first distributed ledger of the plurality of distributed ledgers and includes instructions for performing a process associated with the first user, and at least one other of the plurality of first distributed ledger transactions may appear on a second distributed ledger of the plurality of distributed ledgers and includes instructions for performing a further process associated with the first user.

[0031] The instructions for performing a process associated with the first user may include instructions for modifying data associated with the first user, and the instructions for performing a further process associated with the first user may include instructions for further modifying data associated with the first user.

[0032] At least one of the plurality of first distributed ledger transactions may appear on a first distributed ledger of the plurality of distributed ledgers and may include instructions for performing a process associated with the first user, and at least one of the plurality of second distributed ledger transactions may appear on a second distributed ledger of the plurality of distributed ledgers and may include instructions for performing a further process associated with the first user.

[0033] The instructions for performing a process associated with the first user may include instructions for modifying data associated with the first user, and the instructions for performing a further process associated with the first user may include instructions for further modifying data associated with the first user.

[0034] Each of the first plurality of instructions may include an identifier of a user associated with the instruction, and each result of the executed instruction is stored in the electronic data store along with an association to the user associated with the executed instruction.

[0035] The method may further include receiving a first status inquiry regarding a state of electronic data stored in an electronic data store associated with the first user, and in response to the first status inquiry, communicating a status notification including an indication of the state of the electronic data associated with the first user and proof of the state for use in verifying the indicated state of the electronic data associated with the first user.

[0036] The first status inquiry may be regarding a current state of electronic data associated with the first user, and the status notification may further indicate verification records stored in one or more of the plurality of distributed ledgers corresponding to stored results of executed instruction records that caused the current state of the data associated with the first user.

[0037] The first status inquiry may further include an identifier of a validation record stored in one or more of the plurality of distributed ledgers, and the representation of the state of the electronic data may be an representation of the state of the electronic data associated with the first user as of the identified validation record.

[0038] The electronic data record may include a Merkle tree, the proof of state may include a Merkle proof, and the verification record corresponding to the indicated state of the electronic data associated with the first user may include a Merkle root generated based at least in part on stored results of executed instructions that caused the indicated state of the electronic data associated with the first user.

[0039] In a second aspect of the present disclosure, there is provided a computer program (such as a non-transitory computer program) configured to perform the method of the first aspect when executed on at least one processor of an electronic device.

[0040] In a third aspect of the present disclosure, an electronic device (e.g., an operator as disclosed herein) configured to perform the method of the first aspect is provided. For example, the electronic device may include one or more processors and a memory containing a computer program configured to perform the method of the first aspect when executed on any of the one or more processors.

[0041] In a fourth aspect of the present disclosure, there is provided a computer-implemented method for monitoring execution of instructions issued via any of two or more different distributed ledgers, the method including: monitoring a plurality of distributed ledgers for distributed ledger transactions including instructions to be executed; identifying a first plurality of distributed ledger transactions, each appearing in any of the plurality of distributed ledgers, each including instructions to be executed; identifying a first verification record stored in at least one of the plurality of distributed ledgers, the first verification information being for verifying execution of instructions in the first plurality of instructions; and verifying the execution of the instructions using the first verification information.

[0042] The result of each executed instruction may be stored in an electronic data record, and the first verification record may include a first statement of data modification indicating the electronic data record after the result of execution of the verified instructions has been stored in the electronic data record, and verifying the execution of the instructions uses at least the first statement of data modification.

[0043] Validating the execution of the instruction may further use a preceding validation record that is stored in at least one of a plurality of the plurality of distributed ledgers and that precedes the first validation record.

[0044] The preceding verification record may include a preceding statement of data modification that indicates the electronic data record before the instruction being verified was executed, and verifying the execution of the instruction uses at least the preceding statement of data modification.

[0045] The electronic data record may include a Merkle tree, where a first statement of data modification includes a first Merkle root and a preceding statement of data modification includes a preceding Merkle root.

[0046] Verifying the execution of the instructions may include verifying the order in which at least some of the first plurality of instructions were executed. Optionally, verifying the order in which at least some of the first plurality of instructions were executed may further use one or more additional verification records.

[0047] The method may further include receiving a first status inquiry regarding a current state of data associated with the first user in an electronic data record that stores results of each executed instruction, and in response to the first status inquiry, communicating a status notification that includes an indication of the current state of the data associated with the first user, an identifier of a verification record stored in one or more of a plurality of distributed ledgers that includes the verification record for use in verifying the indicated current state of the data associated with the first user, and a proof of state for use in verifying the indicated current state of the data associated with the first user.

[0048] The method may further include receiving a second status query regarding a state of data associated with the first user in an electronic data record storing results of each executed instruction, the second status query including an identifier of a verification record stored in one or more of the plurality of distributed ledgers; and, in response to the second status query, communicating a status notification including an indication of the state of the data associated with the first user as of the identified verification record and a proof of the state for use in verifying the indicated state of the data associated with the first user as of the identified verification record.

[0049] In a fifth aspect of the present disclosure, there is provided a computer program (such as a non-transitory computer program) configured to perform the method of the fourth aspect when executed on at least one processor of an electronic device.

[0050] In a sixth aspect of the present disclosure, there is provided an electronic device (e.g., a monitor entity as disclosed herein) configured to perform the method of the fourth aspect. For example, the electronic device may include one or more processors and a memory containing a computer program configured to perform the method of the fourth aspect when executed on any of the one or more processors.

[0051] In a seventh aspect of the present disclosure, there is provided a computer-implemented method for a first user to verify a state of data associated with the first user and stored in an electronic data record, the method including: outputting a status query regarding the state of data associated with the first user in the electronic data record, the status query including an identifier of the first user; receiving a status notification including an indication of the state of the data associated with the first user and a proof of state for use in verifying the indicated state of the data associated with the first user; identifying verification records on one or more of a plurality of distributed ledgers for use in verifying the indication of the state of the data associated with the first user; and verifying the indication of the state of the data associated with the first user using the proof of state and the identified verification record. The status notification may include an indication of the verification record.

[0052] In an eighth aspect of the present disclosure, there is provided a computer program (such as a non-transitory computer program) configured to perform the method of the seventh aspect when executed on at least one processor of an electronic device.

[0053] In a ninth aspect of the present disclosure, an electronic device (e.g., a first user or a second user as disclosed herein) configured to perform the method of the seventh aspect is provided. For example, the electronic device may include one or more processors and a memory containing a computer program configured to perform the method of the seventh aspect when executed on any of the one or more processors.

[0054] In a tenth aspect of the present disclosure, there is provided a computer-implemented method for issuing instructions to be executed using one of a plurality of different distributed ledgers, the method including: issuing a first instruction to be executed to a first distributed ledger of the plurality of different distributed ledgers, the first instruction including an identifier of a first user, and execution of the first instruction resulting in modification of data associated with the first user and stored in an electronic data record; and issuing a second instruction to be executed to a second distributed ledger of the plurality of different distributed ledgers, the second instruction including an identifier of the first user, and execution of the second instruction resulting in modification of data associated with the first user and stored in an electronic data record. Includes toto.

[0055] In an eleventh aspect of the present disclosure, there is provided a computer program (such as a non-transitory computer program) configured to perform the method of the tenth aspect when executed on at least one processor of an electronic device.

[0056] In a twelfth aspect of the present disclosure, there is provided an electronic device (e.g., an operator as disclosed herein) configured to perform the method of the tenth aspect. For example, the electronic device may include one or more processors and a memory containing a computer program configured to perform the method of the first aspect when executed on any of the one or more processors. Aspects of the present disclosure will now be described, by way of example only, with reference to the following drawings, in which: [Brief explanation of the drawings]

[0057] [Figure 1] 1 illustrates an exemplary representation of a system 100 according to one aspect of the present disclosure. [Figure 2] 2 shows a conceptual visualization of the layering of data records, a first DLT, and a second DLT in the system of FIG. 1. [Figure 3]2 shows a sequence diagram depicting an exemplary process by which a first user of the system of FIG. 1 can modify data associated with the first user. [Figure 4] 4 illustrates an exemplary visualization of the data involved in a blockchain transaction as part of the process of FIG. 3. [Figure 5] 5 illustrates an exemplary visualization of the data included in the instructions in the blockchain transaction of FIG. [Figure 6] 4 illustrates an exemplary visualization of the data included in a validation record as part of the process of FIG. 3. [Figure 7] 2 illustrates an example Merkle tree for Layer 2 data records of the system of FIG. 1. [Figure 8] 7 shows an example Merkle tree for instructions to the verification record of FIG. 6. [Figure 9] 1 illustrates an exemplary representation of a fork in a blockchain. [Figure 10] 4 shows an example of an instruction and validation record on the first DLT and second DLT as part of the process of FIG. 3. [Figure 11] 2 shows a sequence diagram illustrating an exemplary process by which a first user in the system of FIG. 1 can verify the current state of that first user's data on a Layer 2 data record. DETAILED DESCRIPTION OF THE INVENTION

[0058] The inventors have recognized that as distributed ledger technology (DLT) grows and develops, it may become increasingly difficult for different entities to utilize the technology securely, safely, and reliably. For example, if one particular DLT is selected to manage data or assets / data assets (such as financial assets / tokens, e.g., digital or cryptocurrencies, or any other form of data / information / instructions securely stored or executed via DLT), it may be very difficult to migrate the data or assets / data assets to a different DLT if the originally selected DLT proves to be insecure, unreliable, or outdated. Therefore, the inventors have recognized that there may be benefits to using two or more different DLTs to control the same data. This may improve data security and reliability of DLTs because stored data is no longer tied to a single specific DLT platform, which may suffer from any number of known or unknown security vulnerabilities, attacks, and / or other flaws / imperfections in the future. However, this presents many different technical challenges. For example, if the same data is managed using two or more different DLTs, If the data being controlled is a digital currency, that data may be independently modified via two different, independent mechanisms. This can lead to security and stability vulnerabilities as a result of transactions / instructions related to the data being processed inconsistently and / or out of order. Furthermore, if the data is not consistently updated across two or more DLTs, there may be inaccuracies / inconsistencies across different DLTs, which may present additional security / stability risks. This may be important when the data being controlled is digital currency, for example, leading to double-spending or other types of accidental / intentional fraud, but is also important more generally for all types of DLTs and data records. Further details of the technical problem this presents, as well as the technical solution developed by the inventors, are described below, particularly with respect to handling blockchain rollbacks.

[0059] Throughout the following disclosure, the terms “blockchain,” “distributed ledger,” “blockchain technology,” and “distributed ledger technology (DLT)” are used interchangeably. While blockchain is one particular type of DLT, it will be understood that the present invention is equally applicable to other types of DLT, such as block DAGs. Thus, whenever the term “blockchain” is used, it will be understood that the present disclosure applies equally to any other type of DLT. Furthermore, throughout the following disclosure, the term “transaction” is used in reference to DLT. Those skilled in the art will understand that a “transaction” in this context is not limited to the transfer of ownership of something, such as currency. Instead, a “transaction” is a means by which some form of information can be placed on a DLT. For example, an entity can broadcast a “transaction” to be placed on a DLT, where the transaction includes the information to be placed on the DLT as well as any other data items (such as a public key, signature, hash, etc.) required for the transaction to be accepted into the DLT. The information carried on the DLT may relate to financial transfers of currency, but may alternatively be any other kind of data or information (e.g., a piece of data that an entity wants to store on the DLT for its own reference later, or instructions to perform some further processing, e.g., via a computer program (such as a smart contract) that can be triggered by the instruction). Therefore, alternative terms to "transaction" may be used, such as DLT / blockchain "instruction" or DLT / blockchain "message".

[0060] 1 shows an exemplary representation of a system 100 according to one aspect of the present disclosure. The system 100 includes an operator 110, an electronic data record 115 controlled / maintained at least in part by the operator 110, a first DLT network 120, a second DLT network 130, a first user 140, a second user 150, and a monitor entity 160. Each of the operator 110, the first user 140, the second user 150, and the monitor entity 160 may each be implemented as part of any suitable electronic computing device / entity, such as a server, computer, or mobile computing device, such as a smartphone, tablet, laptop, etc. For example, the functionality (described below) of each of the operator 110, the first user 140, the second user 150, and the monitor entity 160 may be encoded in software / computer programs that may be stored in memory on the computing device and executed using one or more processors of the computing device. Although two different users are depicted, system 100 may alternatively include only one user, or three or more users, each configured to perform the user operations described below.

[0061] Although two DLTs are depicted in Figure 1, the operator 110, the first user 140, the second user 150, and the monitor entity 160 may interface with any number of DLTs. Each DLT may have the ability to read data from the blockchain, Each DLT may have its own specific protocol for DLT operations, such as writing data to a blockchain and / or transferring ownership of data from one entity to another on the same blockchain. Each DLT may be permissioned or permissionless. As non-limiting examples, each DLT may operate according to any of the protocols of Bitcoin, Ethereum, Corda, Quorum, Hyperledger, etc.

[0062] The electronic data record 115 may be implemented as any suitable form of data store, for example, as a DLT in which the operator 110 participates (e.g., a permissioned blockchain that the operator has permission to edit), or may be a non-blockchain data record, such as any form of database, that is at least partially managed by the operator 110.

[0063] Although not depicted in FIG. 1 , the operator 110 and the monitor entity 160 may optionally communicate with each other. The operator 110 and the first user 140 may optionally communicate with each other. The operator 110 and the second user 150 may optionally communicate with each other. The monitor entity 160 and the first user 140 may optionally communicate with each other. The monitor entity 160 and the second user 150 may optionally communicate with each other. Each of the communication interfaces may be implemented using any suitable electronic communication protocol / standard. While each communication interface depicted in FIG. 1 is a direct connection, it will be understood that, optionally, there may be any number of intermediate devices / entities in the communication path.

[0064] FIG. 2 shows a conceptual visualization of the layering of data record 115 and first and second DLTs 120 and 130. DLTs 120 and 130 may be considered to be at “Layer 1” of the system structure. Layer 1 may contain any number of different DLTs, each of which is editable and readable by different participants in system 100, such as operator 110, first user 140, second user 150, and monitor entity 160. Data record 115 may be considered to be at “Layer 2” of the system structure. Layer 2 data record 115 is maintained / controlled by operator 110. In the system 100 of the present disclosure, a particular data item or asset may be controlled using two or more of the Layer 1 DLTs. For example, first user 140 may have a data asset, such as an amount of digital currency or any other form of information / data, that he or she desires to control using two or more Layer 1 DLTs. This data may be controlled by instructions that the user posts to either the first DLT 120 or the second DLT 130. The operator 110 uses Layer 2 data records to maintain consistency of data simultaneously controlled by two or more of the Layer 1 DLTs. In this way, data associated with a user may be modified in a secure and consistent manner across all of the Layer 1 DLTs by transactions / instructions posted to any one of multiple Layer 1 DLTs. Layer 1 may be conceptually thought of as residing at Layer 0 of the system, which would be the public / private network in which the Layer 1 DLTs execute.

[0065] FIG. 3 shows a sequence diagram illustrating an exemplary process by which a first user 140 can issue instructions to be executed.

[0066] In step S310, the first user 140 broadcasts a first DLT transaction 400 (hereinafter referred to as the first blockchain transaction) to either the first DLT 120 or the second DLT 130.

[0067] FIG. 4 shows an example visualization of data included in a first blockchain transaction 400. The first blockchain transaction 400 may be formatted according to a protocol used for any DLT to which this blockchain transaction will be broadcast, including DLT transaction request parameters 410 (which may include, for example, any one or more of a sender address, a recipient address, a transaction fee, etc.) and a DLT transaction signature 420. The DLT transaction signature 420 may be generated by a first user 140 by signing the contents of the first blockchain transaction 400 using the user's DLT private key according to the cryptographic protocol used for any DLT to which the first blockchain transaction 400 will be broadcast. According to the present disclosure, the first user 140 includes a first instruction 500 in the first blockchain transaction. As will be appreciated by those skilled in the art, blockchain transactions typically have a user-defined data field 430 available, and the first instruction 500 may be included in the user-defined data field 430.

[0068] 5 shows an example visualization of the data included in first instructions 500. First instructions 500 may be configured to include data that allows operator 110 to identify first user 140, as well as data indicating the nature of the instructions. For example, the instructions may be to perform some modification to the first user's data in electronic data record 115, or may be instructions to trigger some computer program / process (e.g., a smart contract) maintained in electronic data record 115 or maintained elsewhere and linked to operator 110 or electronic data record 115, such that execution of the instructions triggers the computer program / process and any other data required in accordance with any security / cryptographic procedures established by operator 110. In this example, first instructions 500 include first user ID 512, which operator 110 can use to uniquely identify the first user and, therefore, any data in layer-2 data record 115 associated with first user 140. First user ID 512 may uniquely identify first user 140, or first user 140 may have multiple different first user IDs, each associated with several different pieces of data for that user in layer 2 data record 115. In that case, first user ID 110 may be considered an account ID that identifies the layer 2 account of first user 140.

[0069] In the example depicted in FIG. 5 , the nature of the instruction is indicated using function 514 and variable 518. Depending on the particular type of instruction system 100 is configured to allow, for example, a variety of different functions may be available for first user 140 to set, such as, for example, “trigger,” “send,” “delete,” “replace,” “transfer,” “add,” etc. Variable 518 may contain any data necessary to execute the indicated instruction (e.g., data to be added to data record 115, an identifier of a computer program / routine to be triggered, another user account whose data will also be modified in some way, or the content and recipient of a message to be communicated, etc.). As an example, if the first user holds multi-DLT digital currencies in a layer 2 account, function 514 may indicate that a funds transfer of some amount of the first user's currency is desired. In this case, modifying function 514 may be set to indicate “transfer,” and the variable may indicate the amount to be transferred and the layer 2 account to which the amount will be transferred. In a further example, function 514 may indicate that a particular process or operation is to be executed / triggered, and variable 518 includes any data required for that to occur, such as an identification of the address of the routine to be executed and / or a payload to be passed to the routine.

[0070] In the example depicted in Figure 5, the security / cryptographic requirements of the multi-DLT system 100 are The first instruction 500 is configured to require that the instruction details 510 include a first user sequence number 516 and that the first instruction 500 include a first user signature 520 (although both the user sequence number 516 and the first user signature 520 are optional, and in some implementations, the operator 110 may not require one or both to be present in a transaction to positively validate the transaction). The first user sequence number 516 may be a value that the first user 140 increments / decrements with each new instruction generated by the first user 140. This may enable the operator 110 to enhance the security of the multi-DLT system 100 when performing the process of step S330 described below, for example, to prevent replay attacks and / or to verify the relative execution ordering that may be required for instructions from the first user 140. The first user signature 520 may be a digital signature of the instruction details 510 generated using a private key associated with the first user 140 according to any cryptographic protocol defined by the system security standard for instruction execution. The cryptographic standard used for the first user signature 520 to secure the first instruction 500 may be different from the cryptographic standard used for the DLT transaction signature 420. As a result, operations performed on the layer 2 data records may be secured to a higher cryptographic standard than that used for the first DLT 120 and / or the second DLT 130. As a result, the present disclosure can enhance data security for the first DLT 120 and / or the second DLT 130 in which the system operates.

[0071] It will be appreciated that while different layer 1 DLTs may require different types of DLT transaction request parameters 410 and / or DLT transaction signatures 420, the content of the instruction 500 may always be the same regardless of the DLT it is sent to. As a result, each different instruction broadcast to any of the layer 1 DLTs may be uniquely identified from its content, and optionally, a unique cross-DLT ID may be generated for each instruction, for example, by generating a hash of the instruction 500 or instruction details 510 (e.g., see instruction record 616, described below).

[0072] The operator 110 is configured to monitor the first DLT 120 and the second DLT 130 for distributed ledger transactions including instructions. For example, the operator 110 may be running a participating node in the first and second DLTs and receive each broadcast transaction. Additionally or alternatively, the operator may read the contents of each block (each of which includes multiple distributed ledger transactions) added to the first and second DLTs. Additionally or alternatively, the operator 110 may not be running a node in the first and second DLTs, but instead monitor one or more of the first and second DLTs by querying entities running nodes in the first and second DLT networks.

[0073] In step S320, operator 110 identifies a first distributed ledger transaction as a transaction that includes instructions to be executed. It will be understood that each of the first and second DLTs may include many distributed ledger transactions not relevant to this disclosure (e.g., if these transactions are a general-purpose DLT such as Ethereum), in which case operator 110 is configured to identify distributed ledger transactions that include instructions so that other transactions on the DLT may be ignored. There are various different ways in which operator 110 may identify transactions that include instructions to be executed, and these different possibilities are not the subject of this disclosure. Therefore, although a detailed explanation is not given in this disclosure, by way of simple example only, operator 110 may evaluate the content of all transactions to look for data in the form of instructions as described with reference to FIG. 5, or may include instructions in the DLT transaction request parameters 410 and / or user-defined data fields registered with operator 110. Note that the operator 110 may be configured to look for data identifying the account (e.g., using the first user ID 512, or the layer 2 account ID to which the transfer is being directed and comparing them with the user ID / account ID registered with the operator 110), or any other item of data in the transaction that marks it as being relevant to the operator 110 (e.g., a flag indicating that the transaction includes instructions to be executed).

[0074] In step S330, after identifying the first distributed ledger transaction 400 as relevant, the operator 110 validates the first instruction 500. The validation may include any one or more of checking for correct formatting of the instruction, verifying the first user signature 520 using a cryptographic key registered to the first user and standard symmetric / asymmetric cryptography techniques, and verifying that the first user sequence number 516 meets an expected value (e.g., the operator 110 has not previously seen that value included in a previously identified instruction from the first user 140 and / or that the included value correctly increments / decrements from a prior instruction from the first user 140).

[0075] It will be appreciated that many different instructions may appear in the first DLT 120 and / or the second DLT 130 from various different users (e.g., first user 140, second user 150, etc.). The operator 110 may continuously monitor the first and second DLTs for these instructions and verify their contents as they are identified. For example, the operator 110 may store a copy of each identified instruction (e.g., as part of the layer 2 data records 115 or in any other memory accessible to the operator 110) and then periodically or intermittently verify one or more of the identified instructions (e.g., in the order in which the instructions were identified, with the oldest instructions verified first, or in any ordering identified within the instructions, or in any other order, etc.). Optionally, a copy of each instruction that is positively verified (i.e., passes all of the verification checks) may be recorded by operator 110 (e.g., as part of layer 2 data records 115 or in any other memory accessible to operator 110) and marked as "pending." Periodically, operator 110 may then select one or more pending instructions for execution (e.g., prioritize based on time spent pending, or according to any other requirement, such as any ordering identified in the instructions, or execute according to any other ordering scheme or process). Alternatively, operator 110 may immediately execute each instruction after positive verification.

[0076] Prior to executing the identified instructions, operator 110 may be configured to determine the order in which to execute the instructions. This may occur before verification of the identified instructions, for example, if the instructions are executed immediately after positive verification, or it may occur after verification, for example, if the operator validates the instructions and adds the positively verified instructions to a “pending” pool from which to select the instructions for execution. It will be understood that operator 110 may be configured to determine the order of execution in any suitable manner, depending on the particular implementation of system 100. For example, this may be based on any execution sequence rules operator 110 is configured to follow, the content of the instructions (e.g., following any sequence numbering included in user sequence number 516 / variables 518 or determining the correct order based on the nature of the instructions, such as functions 514 and / or variables 518), and / or the time operator 110 identified the instructions (e.g., executing the instructions in the identified order). In this way, the correct ordering of instruction execution may be maintained by the operator 110 regardless of the layer 1 DLT in which each instruction is posted, which maintains the security, reliability, and robustness of the system 100.

[0077] In step S340, the positively verified first instruction 500 is executed. For example, if the instruction details 510 indicate that the first user 512 wishes to transfer an amount of currency from their layer 2 account to a different user's layer 2 account, the operator 110 will modify the electronic data record 115 to reflect that change by storing the results of the executed instruction (in this case, the results would include decreasing the balance in the first user's account and increasing the balance in the different user's account). In a further example, if the instruction details 510 include additional data that the first user 140 wants to store, the operator 110 will store the additional data in the electronic data record 115 as a result of the executed instruction, along with an association to the first user ID 512. In a further example, if the modification details 510 are instructions that trigger some other process (e.g., invoke a layer 2 smart contract or some other form of computer code / program to perform a particular process), the operator 110 executes those instructions and stores the results of the executed instructions in the electronic data record 115 (optionally along with an association to a user ID 512, allowing the user to later query the current state of the data in the electronic data record 115, which state depends on the stored result). In this example, the stored result may be, for example, a value returned by the triggered process, such as a process receipt, result, or response, and / or may be computer code contained within the instruction details 510, the storage of which may optionally trigger further processes, the result also being stored as part of the result.

[0078] Optionally, for all types of stored results, the stored result may include a sequence number (e.g., a sequence number 516 that may create a further link between the executed instruction and the result, or a sequence number that changes with each further update to the data associated with the first user, e.g., incrementing or decrementing with each stored result associated with the user, or a sequence number that changes with each result stored by the operator 110, e.g., incrementing or decrementing with each new stored result regardless of the associated user). For example, each stored result may include a sequence number, new data resulting from the execution of the instruction, such as a new account balance, or a returned response / receipt / result of executing the instruction, etc. Optionally, the user ID of the user associated with the result may also be included, or the user may be associated with the stored result in any other way within the electronic data record 115. Thus, a historical record of each stored result may be constructed.

[0079] The number of stored results does not necessarily match the executed instructions in a 1:1 ratio. For example, an executed instruction may result in two different stored results, such as a decrease in one user's balance (which is one stored result) and an increase in another user's balance (which is another stored result). Furthermore, if a set of instructions is executed (discussed below in the context of a "validation set") and two instructions cause changes to data stored associated with a particular user, operator 110 may be configured to store separate results for each instruction, or may be configured to store a single result for the particular user that is the result of executing both of the two instructions.

[0080] The operator 110 may store / record the entire contents of the first instruction 500, for example, in a "validation set" (e.g., as part of the layer 2 data records 115 or in any other memory accessible to the operator 110). As will be explained in more detail below in the "Instruction Execution Ordering" section, the operator 110 may keep a record of each executed instruction in a series of consecutive validation sets, each validation set containing one or more executed instructions. This record may be used to It can be useful for verifiability of the ordering of executed transactions and / or for handling blockchain rollbacks.

[0081] In step S350, the operator 110 stores in the first DLT 120 and / or the second DLT 130 a first verification record 600 indicating the stored results (in the electronic data record 115) of the executed first instruction 500.

[0082] FIG. 6 shows an exemplary visualization of the data contained in a first verification record 600. The purpose of the first verification record 600 is to allow the first user 140 and / or the monitoring entity 160 to verify that the command was correctly executed by the operator entity 110. The verification details 610 may contain information that allows the first user 140 and / or the monitoring entity 160 to perform this verification. The operator signature 620 is optional and is a digital signature of the verification details 610 that the operator 110 generates using a private key associated with the verification details to attest that the first verification record 600 originated from the operator 110. This may be used to verify the integrity of the first verification record 600 and ensure that the first verification record 600 originated from an entity authorized to execute commands and modify layer 2 data records 115 and therefore can be trusted. However, trust in the origin and content of the first verification record 600 may be achieved in any other suitable manner.

[0083] The verification details 610 include a data record modification statement 614 indicating the layer-2 data record 115 after the results of the executed instructions have been stored (e.g., it may indicate the stored results of the executed instructions). This may be used by the first user 140 and / or the monitor entity 160 to verify the executed instructions. In one particular example where the layer-2 data record 115 includes a Merkle tree, when the operator 110 records the results of the executed instructions, the operator 110 may update the Merkle tree using the stored results, and the data record modification statement 164 may include the Merkle root of the updated Merkle tree. If the verification record is for use in verifying two or more stored results, such as when two or more instructions have been executed (e.g., when its corresponding verification set includes two or more instructions), the data record modification statement 614 may indicate the order in which the results were stored. In some configurations, the order in which the results were stored may also indicate the order in which the corresponding instructions were executed (e.g., when the operator 110 is configured to store a result for each instruction it executes, the operator may store these results in the Merkle tree in the same order that the instructions were executed). However, in other implementations, the order in which results are stored may not be indicative of the instruction execution order, for example, if two or more potentially non-sequentially executed instructions cause only one result to be stored. Making the data record modification statements 614 indicative of the order in which results are stored can be accomplished in many different ways, for example, by using Merkle trees, as described below, to generate the data record modification statements in a manner that depends on the order in which results are stored.

[0084] In a further example, layer 2 data records 115 may not include Merkle trees, but may be structured in any other manner, in which case the way the data is stored in layer 2 data records 115 may indicate the order in which the results were stored, and data record modification statements 164 may include a database hash of that data, such that the database hash may also indicate the order in which the results were stored.

[0085] Optionally, the validation details 610 may also include an operator ID 612 that uniquely identifies the operator 110. This may be used, for example, if there are multiple operators 110 authorized to execute instructions and modify layer 2 data records 115. .

[0086] Further optionally, the verification details 610 may include a verification record ID 618 that uniquely identifies the first verification record 600. Using the verification record ID 618, the first verification record 600 may be uniquely identified. The verification record ID may function as a sequence identifier indicating the relative order of the verification records stored in the DLT in layer 1, for example, if it is an incrementing / decrementing number that increments / decrements the verification record ID 618 that appears in a preceding verification record. However, it will be appreciated that the first verification record 600 may be uniquely identified in any other manner (e.g., by a data record modification statement 614, which is likely unique for each verification record stored in the first and / or second DLT).

[0087] Further optionally, the first validation record 600 may include an instruction record 616 indicating the instruction to which the first validation record 600 is associated (i.e., the instructions included in the corresponding validation set). As mentioned above and described in more detail below under "Instruction Execution Ordering," each validation set recorded by the operator 110 may include one or more executed instructions, and each validation record stored by the operator 110 in the first and / or second DLT may correspond to a validation set (e.g., each validation set may optionally be uniquely numbered to indicate the relative order / sequence of the validation sets, and the numbering may be related to or the same as the validation record ID 618). The data record modification statement 614 indicates the state of the layer 2 data record 115 after storing the results of the execution of one or more instructions in the validation set. The instruction record 616 indicates one or more executed instructions in the validation set and may indicate the relative order in which the instructions were executed.

[0088] The instruction records 616 may include one or more of the following: a Merkle root generated based on at least a portion of one or more executed instructions; a hash (or some other unique record / identifier / value) of at least a portion of each executed instruction; and / or a hash (or some other unique record / identifier / value) of at least a portion of two or more executed instructions. If hashes / identifiers of at least a portion of each executed instruction are included, they may optionally be ordered within the instruction records 616 in a manner that indicates the order in which they were executed. If hashes / identifiers of at least a portion of two or more executed instructions are included, the instructions may be arranged in an order that corresponds to the order in which they were ordered and then hashed, such that hashes / identifiers generated based on the instructions indicate the sequence of execution.

[0089] FIG. 7 illustrates an example of a Merkle tree for layer 2 data record 115. Those skilled in the art will readily understand the operation of a Merkle tree. In this particular example, four different results of instruction execution are stored in layer 2 data record 115 (e.g., this could be the result of the execution of four different instructions, or fewer than four executed instructions, or more than four executed instructions, as previously described), resulting in four leaves in the Merkle tree, each representing a stored result. However, it will be understood that a Merkle tree can include any number of leaves. In this example, the hash H1 of leaf 1 is associated with the stored result of the first instruction executed 500. The contents of leaf 1 (i.e., the stored result of the first instruction executed, or the hash of the stored result of the first instruction executed) will depend on the implementation of system 100 and the nature of the instructions being executed. For example, the content may include a copy of layer 2 data for the first user 140 after the requested data modifications have been made, or may be the returned results / receipt of a program / process triggered by the instruction (and optionally instruction sequence number 516), etc. In one example where the first instruction 500 relates to a currency transaction, Leaf 1 may include the first user ID 510 and the balance of the first user account after the transaction is executed. As discussed above, the ordering of each leaf can indicate the order in which each result is stored, and in some implementations also indicates the sequence in which the operator 110 executed the instructions (e.g., when the operator is configured to store one or more results for each executed instruction and to store those results in an order corresponding to the order of instruction execution). For example, in FIG. 7, the instruction that caused the stored result included in leaf 1 may have executed before the instruction that caused the stored result included in leaf 2, and so on. The relative ordering of the leaves affects the Merkle root of the tree, such that the Merkle root indicates the relative ordering of the stored results.

[0090] FIG. 8 illustrates an example Merkle tree for instructions with a first verification record 600 associated therewith. In this particular example, the first verification record 600 is associated with four instructions executed by the operator 110, resulting in four leaves in the Merkle tree, each indicating a result of the execution. However, it will be understood that a Merkle tree can include any number of leaves. In this example, leaf 1 includes at least a portion of the executed first instruction, e.g., the entire first instruction 500, a hash of the first instruction 500, instruction details 510, or a hash of the instruction details 510 (i.e., the unique cross-DLT ID discussed above). Optionally, each leaf can also include some data indicative of the execution of the instruction, e.g., the receipt or result of a process / program triggered by the instruction. If the relative execution ordering of the instructions with which the verification record 500 is associated is important, the ordering of each leaf can indicate the sequence of execution of the instructions. For example, in FIG. 8, the instruction in leaf 1 may have executed before the instruction in leaf 2, and so on. The relative ordering of the leaves influences the Merkle root of the tree, such that the Merkle root indicates the relative ordering of the executed instructions. However, if the relative ordering of the executed instructions to which the first verification record 600 is associated is not important, then the ordering of the leaves that make up the Merkle root may be arbitrary. By generating a Merkle tree in this manner, operator 110 can include the Merkle root as part of the instruction records 616, thereby containing relatively small / short provable records of all of the executed instructions to which the first verification record 600 is associated, and optionally the order in which they were executed.

[0091] The operator 110 can store the first verification record 600 by broadcasting a further blockchain transaction to the first DLT 120 and / or the second DLT 130, where the first verification record 600 is contained within a user-defined data field (as described above with reference to FIG. 4). As a result, the first verification record 600 can be stored in a virtually immutable manner readable by the first user 140, the second user 150, and the monitoring entity 160. The first user 140 and / or the monitoring entity 160 can then use the first verification record 600 to verify that the operator 110 executed the instruction correctly, as described below in “Proof of Instruction Execution.”

[0092] (instruction execution ordering) The ordering of instruction execution can be very important to the secure and reliable operation of system 100. For example, it has long been recognized that to prevent double-spend cryptocurrency fraud, it must be possible to determine whether a cryptocurrency has been previously spent. Some existing standalone blockchains achieve this through the chronological nature of blocks on the blockchain, with each block containing a timestamp within it, confirming in an existing block that the cryptocurrency identified in a new transaction has not yet been spent.

[0093] However, the inventors believe that reliable ordering is not only useful for currency-related applications. It has been recognized that this may be important not only for applications in general, but for all applications more generally. For example, it will be appreciated that in various Internet and telecommunications domains and protocols, misordered instructions / messaging can be exploited as a security and stability vulnerability. For example, each of the instructions described above may include communication data, such as TCP / IP packets, and there are numerous ways in which ordering and synchronization communication data can affect the security of a system, such that if messages / instructions are out of order or if an incomplete message / instruction set compromises the security of the system, either in terms of integrity or availability. As explained above, instructions in the present disclosure may relate to any form of data instruction / messaging. Thus, the inventors have recognized that maintaining and / or verifying instruction execution order, for example, not only when used to convey instructions / messages but also when used for any other purpose, may be crucial in achieving a secure, reliable, and tamper-resistant system.

[0094] However, this is particularly challenging in a multi-DLT system where the system operates across multiple Layer 1 DLTs (e.g., a first DLT 120 and a second DLT 130). For example, instructions posted across two or more different Layer 1 DLTs may need to be executed in a specific order to maintain the system's secure, reliable, and fraud-resistant nature. One particular additional challenge in maintaining and verifying instruction execution ordering and system consistency across multiple Layer 1 DLTs is a "blockchain rollback," in which blocks in the blockchain may be lost. For example, a rollback may be caused by a blockchain fork, and one or more blockchain transactions that appeared on the shorter prong of the fork may be lost (or rolled back) from the blockchain. Those skilled in the art will readily understand the potential for a DLT to fork and the characteristics of how a DLT behaves when there is a fork. The result of this may be that a rebroadcast distributed ledger transaction containing the first instruction (which was previously lost in the ledger rollback) may appear on the distributed ledger after some other distributed ledger transaction containing the second instruction, when in fact the first instruction was executed before the second instruction.

[0095] Figure 9 shows an example 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, it is effectively lost from the blockchain because the blockchain continues on the longer prong, "prong 2." Transaction 2 is part of block B3, which appears in "prong 2." At some later point, transaction 1 may be added to the blockchain as part of block B8 on "prong 2," for example, by a node participating in the blockchain. Thus, transaction 1 appears later in the blockchain than transaction 2. However, if it is important that transaction 1 precedes transaction 2 (e.g., they are related in consecutive messages), this could cause security or stability failures or allow fraud to occur in applications utilizing the blockchain. Another cause of a rollback could be when participants in a blockchain agree, for some reason, to roll the blockchain back to a specific previous block (e.g., Ethereum and Ethereum Classic forks).

[0096] Losing blockchain transactions can be particularly problematic in the present disclosure because the relative ordering of instruction execution across different Layer 1 DLTs can be important for the security and stability of the system and the verifiability of the actions of the operator 110. In this case, the loss of a blockchain transaction on a Layer 1 DLT due to a rollback can be a significant problem. Simply replaying the run transactions may not be safe, as the replayed transactions may be out of sequence with the actual execution of the instructions that took place.

[0097] To address these technical challenges, the inventors have implemented the use of validation records as described above.

[0098] FIG. 10 shows an example of instructions and verification records on the first DLT 120 and the second DLT 130. Each instruction is represented by a letter, such as A, Q, or M, and is included within a blockchain transaction in a block of either the first DLT 120 or the second DLT 130. Each instruction may take the form of the first instruction 500 described above. It will be understood that the first user 140 can issue an instruction to one of the layer 1 DLTs and then issue subsequent instructions to the same or different layer 1 DLTs (i.e., instructions can be issued to any layer 1 DLT such that data stored in the electronic data store with an association to the first user 140 (e.g., layer 2 data) is equally controllable across all of the layer 1 DLTs).

[0099] Each blockchain transaction including instructions A, Q, M, etc. is identified by operator 110 in step S320 above, verified in step S330, and executed in step S340. (In this example, verification is performed on all of the identified instructions, and they all pass verification; alternatively, only some of the identified instructions A, Q, M may pass verification at this point, while others may pass verification later, e.g., they would appear in a later validation set / record.) Operator 110 is configured to determine the correct execution order of instructions A, Q, M, as described above, thereby maintaining system security and reliability. As part of the process of step S340, operator 110 may also record a copy of the executed instructions, for example, in a “validation set” (e.g., as part of layer 2 data record 115 or in any other memory accessible to operator 110), as briefly discussed above. For example, operator 110 may identify instruction A and add it to the pending group. Operator 110 does the same for each additional instruction identified (in this example, instructions Q and M) until a predetermined period of time has elapsed or until the pending group is full. As each instruction is executed, it may be stored in a validation set. If the relative ordering of instruction execution within the validation set is important for security / verifiability purposes, the relative order in which they were executed may be recorded, for example, by a Merkle tree of electronic data record 115 (FIG. 7) and / or a Merkle tree of executed instructions (e.g., leaf 1 contains at least a portion of instruction A, leaf 2 contains at least a portion of instruction Q, etc., FIG. 8). Thus, regardless of the DLT in layer 1 in which the instructions were found, operator 110 can maintain and record the relative ordering of transaction execution. If the relative ordering of instruction execution within the validation set is not important, a record of the sequence of execution may not be recorded.

[0100] The operator 110 can generate a validation record corresponding to the validation set. The validation record can take the form of the first validation record 600 described above. For example, the validation record n is generated based on the stored results of the executed instructions, which in this example are instructions A, Q, and M (i.e., data record modification statement 614 is generated based on the stored results of the executed instructions A, Q, and M). n may also be generated based at least in part on the executed instructions A, Q, and M (e.g., instruction record 616 may be generated based at least in part on each of instructions A, Q, and M). Once generated, operator 110 may also optionally generate a verification record n copy to a different location than the Layer 1 DLT (e.g., Layer 2 data records) 115, or any other memory accessible to the operator 110. This is called a verification record. n This may be useful if the verification record is lost in the future from one of the Layer 1 DLTs. n and the validation set n (or the validation set n It is possible to store / record the association between the instruction and the executable (only copies of the executed instructions that are part of the executable).

[0101] Optionally, before storing the latest verification record in at least one of the layer 1 DLTs, the operator 110 may n-1 , and / or the preceding validation record n-1 the executed instructions that are relevant (e.g., the preceding validation set n-1 Executed instructions that are part of the current verification record) and / or n The executed instructions (e.g., verification records) n The current validation set that is about to be stored nIt may be verified that the executed instructions (which are part of the DLT) are still present in the DLTs of Layer 1. If not, they may be added back to at least one of the DLTs of Layer 1.

[0102] For example, in Figure 10, it can be seen that the second DLT 130 has a fork. The lower prong of the fork advances and the contents of the upper prong are lost. Instructions M and Z, and a verification record n All of the verification records initially appear on the upper prong of the second DLT 130 and are lost as a result of the rollback caused by this fork. n+1 After preparing the validation set n and the validation set n+1 , as well as the verification record n appears in the DLT at Layer 1. At this time, the operator 110 can verify that the executed instructions contained in n can identify that instruction M was lost as a result of the rollback. The operator can broadcast a new blockchain transaction to the second DLT 130 in which instruction M was lost. (This is possible because the operator 110 held a copy of instruction M which it could include as part of the new blockchain transaction. It is not important that the new blockchain transaction originates from and is signed by the operator. The provenance of the layer 1 distributed ledger transaction is irrelevant to the present system. The user-defined data field of the new transaction contains an entire copy of the previously lost instruction, which is important information for the operation and verification process of the present disclosure.) This appears in Figure 10 as the bottom prong of the fork. This is also known as the verification record. n Another new blockchain transaction containing instruction Z can be broadcast, both of which also appear in Figure 10 on the bottom prong of the fork. Then, the latest validation record n+1may be stored in at least one of the layer 1 DLTs. Each of these new transactions is represented in a separate block, although some or all of them may appear in the second DLT 130 within the same block. Furthermore, as will be understood from the description below, the order in which the new transactions appear in the second DLT 130 is not important.

[0103] The relative order in which the executed instructions and verification records appear in the Layer 1 DLT is not important because the order in which they were actually executed (which may be important to the secure, safe, and reliable operation of system 100) is noted in the contents of the verification records, regardless of where those verification records appear in the Layer 1 DLT. In particular, each verification record may include a sequence identifier that indicates the relative sequence / order of the verification record. In this case, the verification record n-1 The relevant instructions are the verification records n are all executed before the relevant instruction, which means that the verification record n+1 It is possible to determine that all have been executed before the associated instruction.

[0104] In some system implementations, it is necessary to know the relative order of instruction execution within each validation record. For example, in systems where only a coarser level of execution order verifiability is required to maintain the security and stability of the system, or where the order of execution of two or more instructions is important, if operator 110 is configured to execute the instructions such that they each appear in a different validation set so that the execution ordering can be verified in that way, or if operator 110 is configured to include only one executed instruction in each validation set.

[0105] However, in other systems, it may be important to know the relative order of instruction execution within each validation record, i.e., validation execution ordering is required down to the finder level. This may be accomplished using the data record modification statements 614 and / or instruction records 616 described above.

[0106] In this way, despite rollbacks, a record of each executed instruction can be maintained, as well as verification data that allows the execution order to be verified and validated (at either a coarse-grained or fine-grained level). Thus, a user can be confident that, once the verification record is included in the Layer 1 DLT, the associated instructions have been executed by the operator 110, and their ordering relative to previously executed instructions can be verified, regardless of a rollback in any of the Layer 1 DLTs. A further benefit of this relates to the period over which a user can be confident that an instruction was reliably executed. For example, in many blockchain technologies, such as Bitcoin, relying on blockchain transactions, it is recommended that it is best to wait for a certain number of blocks (e.g., six blocks) to be added to the blockchain after the block in which the transaction appears. This is to ensure that the transaction is not lost due to a fork. Because each block takes a period of time (e.g., approximately 10 minutes) to be added, this wait can be significant. However, in the present disclosure, as soon as the operator stores a verification record based on the user's instructions in the Layer 1 DLT, the user can be confident that the instruction was executed, regardless of a potential future rollback (assuming the user has verified its contents, as described below). This can significantly increase the speed and efficiency with which users can be sure that the commands they issue through the Layer 1 DLT are executed.

[0107] While each block depicted in FIG. 10 contains only a single transaction, it will be understood that in practice, each block is likely to contain many transactions. The blocks that appear empty in FIG. 10 are not actually empty, but in this example, they do not contain any blockchain transactions with instructions according to the present disclosure. In this example, the validation record is stored in both the first and second DLTs. This may be preferable to improve robustness and data integrity, and thus security, so that at least one copy of the validation record must always exist in the Layer 1 DLT, even in the event of a fork (it is highly unlikely that two DLTs would fork independently at the same time, causing both of them to lose the same validation record). However, this is not required; alternatively, the validation record may be stored in only one of the Layer 1 DLTs.

[0108] In the above example, operator 110 verifies that the instructions of the immediately preceding validation record and / or the immediately preceding validation set and / or the current validation set are present in the DLT at layer 1, but operator 110 can alternatively always verify that the instructions of any preceding validation set and any preceding validation record still appear in the DLT at layer 1.

[0109] (Proof of command execution) To be sure that the operator 110 is executing the instructions correctly, the user The correction records stored in the DLT of Layer 1 may be used to attempt to verify the state of the data records 115 in Layer 2.

[0110] FIG. 11 shows a sequence diagram illustrating an exemplary process by which a first user 140 can verify the current state of that first user's data on the layer 2 data record 115.

[0111] In step S1110, the first user 140 communicates a first status inquiry to the operator 110 and / or the monitoring entity 160. The monitoring entity 160 may be an entity configured to monitor the Layer 1 DLT to identify blockchain transactions containing instructions and to identify validation records stored in the Layer 1 DLT. It may also be configured to determine which validation records are associated with which executed instructions. This may be done, for example, by using the instruction hash contained within the instruction record 616 of the validation record to generate a hash of the relevant portion of each instruction it identifies in the Layer 1 DLT and compare it with the hash contained in the identifying instruction record 616. Alternatively, if the instruction hash does not form part of the instruction record 616, the operator 110 may inform the monitoring entity 160, for example, via a communication channel between the monitoring entity 160 and the operator 110, which instructions are associated with each validation record. Optionally, the monitoring entity 160 may use the instruction record 616 to verify this information communicated from the operator 110. For example, if the instruction record 616 of the verification record 600 indicated by the operator 110 contains a Merkle root, the monitoring entity 160 can generate a Merkle root based on the instructions the operator 110 described as part of the indicated verification record 600 and the order in which the operator 110 described them as included in the Merkle tree, and compare it to the Merkle root in the instruction record 616 of the indicated verification record 600. Alternatively, in addition to communicating which instructions are relevant to the verification record, the operator 110 can also provide a proof to attest to the instruction record in the verification record, such as a Merkle proof if the instruction record contains a Merkle root, or a zero-knowledge proof (ZK proof) if the instruction record contains hashes of two or more executed instructions. As a result, the monitoring entity 160 can verify the information provided by the operator 110 (and, if relevant, the order of instruction execution in the verification record).Additionally, monitoring entity 160 may optionally monitor the state of the data maintained in electronic data records 115, for example, by updating the shadow copy records it maintains with each executed instruction and / or by operator 110 communicating to monitoring entity 160 each stored result of instruction execution (which is verifiable by statements of data record modification 614 in each verification record). Thus, monitoring entity 160 may have very similar operations and knowledge level as operator 110, but unlike operator 110, is not authorized to execute instructions, make changes to data records 115 in layer 2, or store verification records in the DLT in layer 1.

[0112] The monitor entity 160 in the system 100 is optional, as the operator 110 can perform the same functions as the monitor entity 160. However, there may be some advantages to having a monitor entity 160 that is independent of the operator 110, for example, to prevent / detect censorship of orders by the operator 110, to detect fraud / inaccuracy from the operator 110, and / or to provide a communication interface to the user so that the operator 110 does not have to communicate with the user.

[0113] The first status inquiry may be, for example, a request for the current state of data associated with the first user in the electronic data record 115, or a request for a particular verification in the Layer 1 DLT. The first status inquiry may be a request for the state of data associated with a first user in electronic data record 115 at the time of the record. The first status inquiry may include an identifier for the first user (e.g., first user ID 512) and information about the nature of the inquiry (e.g., if it is a request for the state at the time of a particular verification record, it may include an identifier for the verification record, such as verification record ID 618).

[0114] In step S1120, the operator 110 and / or the monitor entity 160 can communicate a status notification to the first user. The status notification can include an indication of the state of the first user data (e.g., the current / latest state or the state as of the verification record identified in the first status query). The current / latest state can be the most recently stored result of instruction execution associated with the first user (e.g., if in step S340 each record stored by the operator includes, for example, a sequence number, a user ID, and new data resulting from the execution of an instruction, the indication of the current state can be the stored result with the most recent sequence number). The state as of the verification record identified in the first status query can be the stored result associated with the first user based on which the verification record was generated or the most recently stored result associated with the first user that preceded the generation of the verification record (e.g., when the verification record was generated based on stored results not associated with the first user). The status notification can further include proof of the state for use by the first user 140 in verifying the indicated state of the first user data. If the first status inquiry is regarding the most recent state of the data, the status notification may further include a display of a verification record corresponding to the most recent change to the state of the first user's data (i.e., a verification record including a statement of data record modification 614 generated based at least in part on the most recent change to the first user's data caused by the record of executed instructions stored by the operator 110). The proof of state may take any suitable form that enables the first user 140 to verify the indicated state of the first user's data using the proof of state and statement of data record modification 614 in the associated verification record.For example, if the verification record is configured such that the statement of data record modification 614 is a Merkle root, the proof of state may be a Merkle proof that the first user 140 can use to verify that the Merkle root (in the statement of data record modification 614) was generated by the operator 110 using, at least in part, the indicated state of the first user's data. If the statement of data record modification 614 is a database hash, the proof of state may include a ZK Proof.

[0115] Optionally, the operator 110 / monitoring entity 160 can also communicate to the first user a proof that the identified verification record is associated with one or more specific executed instructions (e.g., if the user is checking the status of their data after execution of specific instructions, either the specific instructions identified by the user in the first status inquiry, or the specific instructions that resulted in the current state of the user data). This proof can take any suitable form. For example, if the verification record is configured such that the instruction record includes a Merkle root, the proof may be a Merkle proof, or if the instruction record includes hashes of two or more executed instructions, the proof may be a ZK proof. However, if the verification record is configured to include hashes of at least some of the executed instructions to which they are associated, the first user can simply prove that any specific instructions associated with them form part of the identified verification record.

[0116] In step S1130, the first user 140 searches for the relevant verification record in the first DLT 120 or the second DLT 130 and then retrieves any relevant information (e.g., At least a portion of the data record modification statements 614 and / or instruction records 616 may be retrieved.

[0117] In step S1140, the first user 140 can verify the state of their data using the proof of state and the retrieved portion of the associated verification record. Thus, statements from the operator 110 and / or monitoring entity 160 to the first user 140 regarding the state of their data can be proven or disproven using cryptographically secure information accessible at the first DLT 120 and / or second DLT 130.

[0118] The indication of status received by the user may take any suitable form depending on the nature of the user data stored in electronic data record 115. For example, if the user data relates to a financial currency, the status may indicate the current balance of the user account, which is modified each time the results of an executed instruction related to the first user are stored in electronic data store 115. In a further example, if the user data includes records / results of processes / communications / actions triggered by instructions posted on the Layer 1 DLT, the status may include the records / results received and stored.

[0119] Optionally, a user can read the layer-1 DLT and / or query the operator 110 / monitoring entity 160 to identify instructions that appear in the layer-1 DLT associated with them (e.g., instructions that originate from them or that identify them in some way, e.g., as recipients of financial transactions). The user can also query the operator 110 / monitoring entity 160 to determine which instructions were executed and the validation records that were generated based on the results of each instruction execution (e.g., the user can ask the operator 110 / monitoring entity 160 whether any of instructions A, B, C, etc. were executed, and in return the user can receive an indication that instruction A was executed and is included in validation record Y, optionally along with a proof of inclusion such as a Merkle proof or ZK proof, as described above). The user can then see which instructions are said to have been executed and when they were executed (and verify their inclusion in the indicated verification records), and can then verifiably ascertain the state of those data as a result of the instruction execution (e.g., by querying the state of those data at the time of verification record Y, as described above, and then verifying the returned indicated state).

[0120] As a result, a user can issue commands to any of multiple Layer 1 DLTs in a manner that results in secure, consistent, and verifiable execution of those commands. Thus, a user can control data using any two or more different Layer 1 DLTs in a secure, safe, consistent, and reliable manner.

[0121] 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.

[0122] In the above description, operator 110 stores ordered validation sets, each containing a copy of one or more executed instructions. However, alternatively, operator 110 can simply store each executed instruction along with an association to a validation record that was partially generated as a result of the executed instruction. The relative ordering of each validation record may be maintained, for example, by a validation record ID, and thus the relative ordering of instruction execution among validation records can be noted in this manner (and the relative ordering of instruction execution within a validation record may be noted by data record modification statements 614 and / or instruction records 616).

[0123] The instruction record 616 in the verification record 600 is optional. For example, some verification records may relate to a starting state for one or more portions of the electronic data record 115, such as a beginning balance for a user account in a layer 2 record. In this case, the instruction record 616 may be omitted, and the data record amendment statement 614 may indicate the starting state of one or more portions of the electronic data record 115.

[0124] The first user 140 and / or the second user 150 may optionally include a smart contract or some other form of triggerable computer program / process. The user processes described above may be performed, for example, by a smart contract, and further processes may optionally be performed depending on the results. For example, a smart contract may be triggered by the presence of a specific instruction on the first DLT 120. This may verify execution of the instruction using the process described with reference to FIG. 11 and, optionally, perform further actions if verified. In one specific, non-limiting example, data such as tokens may be migrated in this manner from a Layer 2 account to a Layer 1 account on a specific Layer 1 DLT. For example, an instruction to transfer tokens from the Layer 2 account to the migration Layer 2 account may be posted to one of the Layer 1 DLTs. The smart contract may be triggered by a reference in the instruction to the migration Layer 2 account. Executing this instruction stores the result in the Layer 2 electronic data record 115, resulting in tokens being added to the balance of the migration account. The smart contract may verify execution of the instructions (e.g., using the user verification process described above with reference to FIG. 11) and, if verified, add tokens to the Layer 1 DLT (e.g., in a predetermined Layer 1 token:Layer 2 token ratio). Optionally, the smart contract may then issue further instructions to one of the Layer 1 DLTs to delete the Layer 2 tokens held in the migration account, or the Layer 2 tokens in the migration account may be locked or deleted in any other suitable manner. A similar process may be done in reverse to migrate Layer 1 tokens to a Layer 2 account.

[0125] The term "hash" is used frequently throughout this disclosure. Where a hash is generated based on data, any other suitable type of value that uniquely represents the data may alternatively be generated using any suitable process. For example, where a hash of at least a portion of executed instructions is generated, a value that uniquely represents at least a portion of the executed instructions may alternatively be generated based on the executed instructions using any suitable process.

[0126] In some aspects of the present disclosure, the use of Merkle trees and Merkle roots is disclosed, for example, in connection with layer 2 data records 115 and data modification statements 164, and / or executed commands and instruction records 616. This is just one non-limiting example structure / approach that may be used, and as previously indicated, others are possible. As further examples of types of data structures that preserve or indicate relative ordering of information within the data structure, birkle trees and birkle roots may be used for layer 2 data records 115 and data modification statements 164, and / or executed commands and instruction records 616. Birkle trees are similar to Merkle trees, but can combine more than two items at each level. Any other type of data structure that preserves or indicates relative ordering may alternatively be used for layer 2 data records 115 and data modification statements 164, and / or executed commands and instruction records 616. In the example described above, system 100 includes a single operator 110 and a single monitor entity 160. However, Alternatively, the system 100 may include two or more operator entities 110 and / or two or more monitor entities 160, each functioning as described above. For example, if there are two or more operator entities 110, they may be configured to share processing loads, such as generating alternating verification records. In a further example, if there are two or more monitor entities 160, they may each independently perform the monitoring functions described above.

[0127] All of the above-described aspects of the present disclosure may be implemented by software, hardware, or a combination of software and hardware. For example, the functions of the operator 110, the user, and / or the monitor entity 160 may each be implemented by software including computer-readable code that, when executed on one or more processors (such as one or more microprocessors or programmable logic) of any electronic device, performs the functions described above. The software may be stored on any suitable computer-readable medium, e.g., a non-transitory computer-readable medium such as read-only memory, random-access memory, CD-ROM, DVD, Blu-ray, magnetic tape, hard disk drive, solid-state drive, and 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 computer-implemented method for executing instructions issued via any of two or more different distributed ledgers, the method comprising: monitoring a plurality of distributed ledgers for distributed ledger transactions including instructions to be executed; identifying a first plurality of distributed ledger transactions, each of which appears on one of the plurality of distributed ledgers, the first plurality of distributed ledger transactions including instructions to be executed; verifying at least some of a first plurality of instructions in the identified first plurality of distributed ledger transactions; for each of the first plurality of instructions that are positively verified, executing the instructions; storing the results of the executed instructions in an electronic data record; A method comprising:

2. storing, after executing the positively verified instructions of the first plurality of instructions, a first verification record indicative of each stored result in the electronic data record in at least one of the plurality of distributed ledgers. The method of claim 1 further comprising:

3. The method of claim 2 , wherein the first verification record indicates an order in which the positively verified instructions of the first plurality of instructions were executed.

4. After executing the positively verified instructions of the first plurality of instructions, generating a first instruction record based on the executed instructions of the first plurality of instructions. further comprising the first verification record further includes the first instruction record; The method according to claim 2 or claim 3.

5. The method of claim 4 , wherein the first instruction record indicates an order in which the positively verified instructions of the first plurality of instructions were executed.

6. 6. The method of claim 2, wherein the first validation record includes a sequence identifier that indicates a relative ordering of validation records stored in the at least one of the plurality of distributed ledgers.

7. determining an order of execution of the positively verified first plurality of instructions; executing the positively verified first plurality of instructions according to the determined order; The method of any one of claims 1 to 6, further comprising:

8. At least one of the plurality of first distributed ledger transactions appears on a first distributed ledger of the plurality of distributed ledgers and includes instructions for executing a process associated with a first user; 8. The method of claim 1, wherein at least one other transaction of the first plurality of distributed ledger transactions appears on a second distributed ledger of the plurality of distributed ledgers and includes instructions for executing a further process associated with the first user.

9. identifying a second plurality of distributed ledger transactions, each of which appears on one of the plurality of distributed ledgers, the second plurality of distributed ledger transactions each including an instruction to be executed; verifying at least some of the second plurality of instructions; for each of the second plurality of instructions that are positively verified, executing the instructions; storing the results of the executed instructions in the electronic data record; and The method of any one of claims 1 to 8, further comprising:

10. After executing the positively verified instructions of the second plurality of instructions, storing in at least one of the plurality of distributed ledgers a second verification record indicating each result stored in the electronic data record as a result of the executed instructions of the second plurality of instructions.

10. The method of claim 9, further comprising:

11. At least one of the plurality of first distributed ledger transactions appears on a first distributed ledger of the plurality of distributed ledgers and includes instructions for executing a process associated with a first user; 11. The method of claim 9 or claim 10, wherein at least one of the plurality of second distributed ledger transactions appears on a second distributed ledger of the plurality of distributed ledgers and includes instructions for executing a further process associated with the first user.

12. each of the first plurality of instructions includes an identifier of a user associated with said instruction, and each result of an executed instruction is stored in an electronic data store together with an association to the user associated with said executed instruction; The method comprises: receiving a first status inquiry regarding a status of electronic data stored in the electronic data store associated with a first user; In response to the first status inquiry, an indication of the status of electronic data associated with the first user; and a state certificate for use in verifying the indicated state of electronic data associated with the first user; communicating a status notification, including: The method of any one of claims 1 to 11, further comprising:

13. A computer program adapted to perform the method of any one of claims 1 to 12 when executed on at least one processor of an electronic device.

14. An electronic device configured to perform the method of any one of claims 1 to 12.

15. 1. A computer-implemented method for monitoring the execution of instructions issued via any of two or more different distributed ledgers, comprising: monitoring a plurality of distributed ledgers for distributed ledger transactions including instructions to be executed; identifying a first plurality of distributed ledger transactions, each of which appears on one of the plurality of distributed ledgers, the first plurality of distributed ledger transactions including instructions to be executed; Identifying a first validation record stored in at least one of the plurality of distributed ledgers; using first verification information to verify execution of an instruction in a first plurality of instructions; Verifying the execution of A method comprising:

16. 1. A computer-implemented method for a first user to verify a state of data associated with the first user and stored in an electronic data record, comprising: outputting a status query regarding the state of data associated with the first user in the electronic data record, the status query including an identifier of the first user; an indication of the status of data associated with the first user; and a state certificate for use in verifying the indicated state of data associated with the first user; and receiving a status notification, Identifying a verification record on one or more of a plurality of distributed ledgers for use in verifying the representation of a state of data associated with the first user; verifying the representation of the state of data associated with the first user using the proof of state and the identified verification record; A method comprising:

Images