Secure multi-distributed ledger system

Abstract

The present invention provides a method, electronic device, and program for securely controlling user-related data using one or more different distributed ledgers. [Solution] The method includes monitoring multiple distributed ledgers for a distributed ledger transaction containing instructions to be executed, identifying a first set of multiple distributed ledger transactions, each containing instructions that appear on any of the multiple distributed ledgers and are executed, verifying some of the first set of instructions in the identified first set of multiple distributed ledger transactions, executing the instructions for each of the first set of instructions that have been positively verified, and storing the 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 these instructions are executed securely and consistently, and any user data associated with the executed instructions is consistently and reliably updated regardless of the distributed ledger from which each instruction is issued.

Description

[Technical Field]

[0001] This disclosure relates to methods, systems, electronic devices, and computer programs for enabling the execution of instructions using one of two or more different distributed ledgers, for example, so that user-related data can be securely controlled using one of two or more different distributed ledgers. [Background technology]

[0002] Distributed ledger technology (DLT) has a vast range of potential applications, providing a way for data to be stored securely and reliably without the need for a central data authentication authority. Therefore, DLT can enable numerous technological advantages across a wide range of areas, such as improved data transparency, more robust data storage that is not dependent on a single specific storage entity, enhanced data security, and increased resilience to fraud. It has already found use in diverse fields such as distributed electrical energy and peer-to-peer cloud storage.

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

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

[0005] If a transaction block is active, each node will be involved in the new block that is active in other new transactions broadcast to the network of nodes. It is also possible to add blocks. After a certain period, a node publishes a new block to other nodes in the network, and the new block contains various new transactions, as well as cryptographic data that links the new block to a preceding block in the blockchain or a preceding block in the block DAG. By cryptographically linking consecutive blocks together in this way, it can be easily detected if one block in the blockchain or block DAG is altered at any point later (for example, by someone who wishes to tamper with the data stored in the blockchain or block DAG).

[0006] After a new block is published by a node, other nodes in the network can review the contents of the new block, and if accepted, the entire contents of the block are added to their local copy of the distributed ledger. In addition, and also optional, each node can begin working on the next new block, which is again cryptographically bound to one or more preceding blocks. Thus, 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 one or more preceding blocks. This process, in which nodes review published new transactions and published new blocks and accept this node into its copy of the distributed ledger, is often called 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 a transaction, the format and type of information that should be included in a new block, the cryptographic techniques and recipes to be used for transactions and new blocks, and the specific type of consensus mechanism to be used (for example, in Bitcoin, the consensus mechanism utilizes hash-based proof-of-work in each block of the blockchain, which is also the cryptographic link between each consecutive block). If a broadcast transaction does not properly conform to the protocol, that transaction will not be included in any new block. Similarly, if a new block does not properly conform to the protocol, that block will not be accepted into the blockchain by the network of nodes.

[0008] DLTs, including blockchains and block DAGs, were initially proposed to power the cryptocurrency Bitcoin, but have since found many other applications. Initially, new cryptocurrencies such as Litecoin, Ripple, and Namecoin were launched, each operating on its own specific distributed ledger network using its own unique DLT protocol. Since then, it has been recognized that DLTs have the potential to be used far more broadly than cryptocurrencies, and can be utilized 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, which are computer programs or instructions that run on a DLT and can be configured to perform a specific process when certain data appears on the distributed ledger. Another exemplary DLT is Hashgraph, which uses a block DAG. This has resulted in a rapid expansion of the number of different DLTs that exist today, each tailored to its own specific use case, and it is expected that the number of different DLTs will continue to grow 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 [Overview of the project]

[0010] A first aspect of the present disclosure provides a computer implementation method for executing instructions issued through one of two or more different distributed ledgers, the method comprising: monitoring a plurality of distributed ledgers for a plurality of distributed ledger transactions containing instructions to be executed; identifying a first plurality of distributed ledger transactions, each of which appears in one of the plurality of distributed ledgers, each of which contains instructions to be executed; verifying at least some of the first plurality of instructions in the identified first plurality of distributed ledger transactions; executing the instructions for each of the first plurality of instructions that have been positively verified; and storing the results of the executed instructions in an electronic data record.

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

[0012] The first verification record may indicate the order in which the positively verified instructions among the first set of instructions were executed. In addition, or alternatively, the first verification record may indicate the order in which the results of the executed first set 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 on at least partly the stored results of each of the executed instructions of a first plurality of instructions, the first verification record including the first Merkle root of the updated Merkle tree of the electronic data record.

[0014] The method may further include executing a positively validated instruction from a first set of instructions, and then generating a first instruction record based on the executed instruction from the first set of instructions, the first validation record further including the first instruction record.

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

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

[0017] The first verification record can include a sequence identifier indicating the relative order of the verification records stored in at least one of the plurality of distributed ledgers.

[0018] The method includes storing the first verification record in at least one of the plurality of distributed ledgers, then confirming that the first verification record exists in at least one of the one or more distributed ledgers, and if the first verification record does not exist in at least one of the plurality of distributed ledgers, reproducing the first verification record in at least one of the one or more distributed ledgers. and can further include.

[0019] The method further includes storing a copy of each of the executed instructions among the first plurality of instructions, confirming that each of the executed instructions among the first plurality of instructions exists in at least one of the plurality of distributed ledgers, and for each of the executed instructions among the first plurality of instructions that does not exist in at least one of the plurality of distributed ledgers, broadcasting a new distributed ledger transaction to at least one of the plurality of distributed ledgers, wherein the new distributed ledger transaction includes the executed instruction.

[0020] The method may further include determining the order in which to execute a set of first instructions that have been positively verified, and executing the first instructions that have been positively verified according to the determined order.

[0021] The method may further include identifying a second set of distributed ledger transactions, each of which appears in one of a set of distributed ledgers, and each set of distributed ledger transactions containing instructions to be executed; verifying at least some of the second set of instructions; executing each of the second set of instructions that has been positively verified; and storing the results of the executed instructions in an electronic data record.

[0022] The method may further include, after executing a positively validated instruction from a second set of instructions, storing a second validation record in at least one of a set of distributed ledgers, each record indicating the result stored in an electronic data record as a result of the executed instruction from the second set of instructions.

[0023] The second verification record can indicate the order in which the positively verified instructions among the second set of instructions were executed.

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

[0025] The method may include executing a positively validated instruction from a second set of instructions, and then generating a second instruction record based on the executed instruction from the second set of instructions, wherein the second validation record includes the second instruction record.

[0026] The second instruction record can show the order in which the positively validated instructions among the second set of instructions were executed.

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

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

[0029] This method further includes determining the order in which to execute a second set of positively verified instructions, and executing the second set of positively verified instructions according to the determined order. It is possible.

[0030] At least one of a plurality of first distributed ledger transactions may appear in the first distributed ledger of the plurality of distributed ledgers and include instructions for executing a process associated with a first user, and at least one other transaction of the plurality of first distributed ledger transactions may appear in the second distributed ledger of the plurality of distributed ledgers and include instructions for executing further processes associated with the first user.

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

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

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

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

[0035] The method may further include receiving a first status inquiry regarding the status of electronic data stored in an electronic data store associated with a first user, and communicating a status notification in response to the first status inquiry, which includes a display of the status of the electronic data associated with the first user and a certificate of status for use in verifying the displayed status of the electronic data associated with the first user.

[0036] The first status query may relate to the current state of electronic data associated with a first user, and the status notification may further indicate a verification record stored in one or more of several distributed ledgers corresponding to the stored result of the executed instruction record that brought about the current state of the data associated with the first user.

[0037] The first status query may further include an identifier for a verification record stored in one or more of the distributed ledgers, and the display of the electronic data status may be a display of the electronic data status associated with the first user at the time of the identified verification record.

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

[0039] A second aspect of this disclosure provides a computer program (such as a non-transient computer program) configured to perform the method of the first aspect when executed on at least one processor of an electronic device.

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

[0041] A fourth aspect of the present disclosure provides a computer implementation method for monitoring the execution of an instruction issued through one of two or more different distributed ledgers, the method comprising: monitoring a plurality of distributed ledgers for a distributed ledger transaction containing an instruction to be executed; identifying a first plurality of distributed ledger transactions, each of which appears in one of the plurality of distributed ledgers, each of which contains an instruction to be executed; identifying a first verification record stored in at least one of the plurality of distributed ledgers, wherein the first verification information is for verifying the execution of an instruction in the first plurality of instructions; and verifying the execution of an instruction 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 that indicates the electronic data record after the result of the execution of the instruction being verified has been stored in the electronic data record, and verifying the execution of an instruction uses at least the first statement of data modification.

[0043] Verification of the execution of an instruction is stored in at least one of several distributed ledgers, and preceding verification records that precede the first verification record can be used.

[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 will use at least the preceding statement of data modification.

[0045] An electronic data record may contain a Merkle tree, the first statement of data modification contains the first Merkle root, and the preceding statement of data modification contains the preceding Merkle root.

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

[0047] The method may further include receiving a first status query regarding the current state of data associated with a first user in an electronic data record storing the results of each executed command, and communicating a status notification in response to the first status query, which includes a display of the current state of data associated with a first user, an identifier for a verification record stored in one or more of a plurality of distributed ledgers containing verification records for use in verifying the displayed current state of data associated with a first user, and a proof of state for use in verifying the displayed current state of data associated with a first user.

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

[0049] A fifth aspect of this disclosure provides a computer program (such as a non-transient computer program) configured to perform the method of the fourth aspect when executed on at least one processor of an electronic device.

[0050] A sixth aspect of this disclosure provides an electronic device (e.g., a monitor entity disclosed herein) configured to perform the method of the fourth aspect. For example, the electronic device may include one or more processors and memory containing a computer program configured to perform the method of the fourth aspect when run on any of the one or more processors.

[0051] A seventh aspect of the present disclosure provides a computer implementation method for a first user to verify the state of data associated with the first user and stored in an electronic data record, the method comprising: outputting a status query relating to the state of the data associated with the first user in the electronic data record, the status query including the identifier of the first user; receiving a status notification, which includes a display of the state of the data associated with the first user and a proof of the state for use in verifying the displayed state of the data associated with the first user; identifying a verification record on one or more of a plurality of distributed ledgers for use in verifying the display of the state of the data associated with the first user; and verifying the display of the state of the data associated with the first user using the proof of the state and the identified verification record. Status notifications can include displaying validation records.

[0052] An eighth aspect of the present disclosure provides a computer program (such as a non-transient computer program) configured to perform the method of the seventh aspect when executed on at least one processor of an electronic device.

[0053] A ninth aspect of this disclosure provides an electronic device (for example, a first or second user as disclosed herein) configured to perform the method of the seventh aspect. For example, the electronic device may include one or more processors and memory containing a computer program configured to perform the method of the seventh aspect when run on any of the one or more processors.

[0054] A tenth aspect of this disclosure provides a computer implementation method for issuing an instruction to be executed using one of several different distributed ledgers, the method comprising: issuing a first instruction to be executed to a first distributed ledger among several different distributed ledgers, wherein the first instruction includes an identifier of a first user, and the execution of the first instruction results in a 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 among several different distributed ledgers, wherein the second instruction includes an identifier of a first user, and the execution of the second instruction results in a modification of data associated with the first user and stored in an electronic data record. It includes "toto".

[0055] An eleventh aspect of the present disclosure provides a computer program (such as a non-transient computer program) configured to perform the method of the tenth aspect when executed on at least one processor of an electronic device.

[0056] A twelfth aspect of this disclosure provides an electronic device (e.g., an operator disclosed herein) configured to perform the method of the tenth aspect. For example, the electronic device may include one or more processors and memory containing a computer program configured to perform the method of the first aspect when run on any of the one or more processors. The embodiments of this disclosure will be described by reference to the following drawings, merely as examples. [Brief explanation of the drawing]

[0057] [Figure 1] An exemplary representation of System 100 according to one aspect of this disclosure is shown below. [Figure 2] Figure 1 shows a conceptual visualization of the hierarchy of the system's data records, the first DLT, and the second DLT. [Figure 3]Figure 1 shows a sequence diagram illustrating an exemplary process in which a first user of the system can modify data associated with that first user. [Figure 4] Figure 3 shows an exemplary visualization of the data included in a blockchain transaction as part of the process. [Figure 5] Figure 4 shows an exemplary visualization of the data included in an instruction in a blockchain transaction. [Figure 6] Figure 3 shows an exemplary visualization of the data included in the validation record as part of the process. [Figure 7] Figure 1 shows an example of a Merkle tree for the Layer 2 data records of the system. [Figure 8] Figure 6 shows an example of a Merkle tree for instructions to the verification record. [Figure 9] This illustrates a typical representation of a fork in a blockchain. [Figure 10] Figure 3 shows an example of instructions and verification records on the first and second DLTs as part of the process. [Figure 11] Figure 1 shows a sequence diagram illustrating an exemplary process in the system where a first user can verify the current state of their data on the Layer 2 data record. [Modes for carrying out the invention]

[0058] The inventors have recognized that as distributed ledger technology (DLT) grows and evolves, it can become increasingly difficult for different entities to use 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 cryptocurrency, or any other form of data / information / instructions securely stored or executed via DLT), migrating the data or assets / data assets to a different DLT can be extremely difficult if the originally selected DLT turns out 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 could potentially improve the data security and reliability of the DLT because the stored data is no longer tied to a single, specific DLT platform that could potentially suffer from numerous known / 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 uses two or more different DLTs... If the data can be controlled, it can be modified independently through two different, independent mechanisms. This can lead to security and stability vulnerabilities as a result of transactions / instructions related to data that are processed inconsistently and / or in the wrong order. Furthermore, if the data is not consistently updated across all two or more DLTs, inaccuracies / inconsistencies may occur across different DLTs, which can represent further security / stability risks. This may be particularly important if the controlled data is digital currency and could lead to, for example, double-spending or other types of accidental / intentional fraud, but it is more generally important for all types of DLTs and data records. Further details of the technical problems presented here, as well as the technical solutions developed by the inventors, will be described later, particularly with respect to the handling of blockchain rollbacks.

[0059] Throughout the following disclosures, the terms “blockchain,” “distributed ledger,” “blockchain technology,” and “distributed ledger technology (DLT)” are used interchangeably. While blockchain is one specific type of DLT, it will be understood that the present invention is equally applicable to other types of DLTs, such as block DAGs. Therefore, whenever the term “blockchain” is used, it will be understood that this disclosure is equally applicable to any other type of DLT. Furthermore, throughout the following disclosures, the term “transaction” is used in relation to DLTs. Those skilled in the art will understand that “transaction” in this context is not limited to the transfer of ownership of something, such as currency. Rather, “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, and a transaction includes the information to be placed on the DLT, as well as any other data items required for the transaction to be accepted on the DLT (such as a public key, signature, hash, etc.). The information placed on a DLT may relate to the financial transfer of currency, but alternatively, it may be any other type of data or information (e.g., a portion of data that an entity wishes to store in the DLT for later reference, or instructions to perform some further processing via a computer program that can be triggered by the instructions (such as a smart contract)). Therefore, alternative terms to "transaction" may be used, such as "instruction" or "message" in the DLT / blockchain.

[0060] Figure 1 shows an exemplary representation of System 100 according to one aspect of the present disclosure. System 100 includes an operator 110, an electronic data record 115 at least partially controlled / maintained 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 be implemented as part of any suitable electronic computing device / entity, for example, as part of a server or computer, or as part of a mobile computing device such as a smartphone, tablet, or laptop. For example, the functions of each of the operator 110, the first user 140, the second user 150, and the monitor entity 160 (described later) may be encoded in a software / computer program that is stored in memory on the computing device and executed using one or more processors of the computing device. Although two different users are represented, system 100 may, alternatively, include only one user or three or more users, each configured to perform the user operations described later.

[0061] Although two DLTs are shown in Figure 1, Operator 110, First User 140, Second User 150, and Monitor Entity 160 can interface with any number of DLTs. Each DLT reads data from the blockchain, the blockchain DLTs can have their own specific protocols for 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 can be permissioned or open-ended. As a non-limiting example, each DLT could operate according to one of the protocols of Bitcoin, Ethereum, Corda, Quorum, Hyperledger, etc.

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

[0063] Although not shown in Figure 1, Operator 110 and Monitor Entity 160 may optionally communicate with each other. Operator 110 and First User 140 may optionally communicate with each other. Operator 110 and Second User 150 may optionally communicate with each other. Monitor Entity 160 and First User 140 may optionally communicate with each other. Monitor Entity 160 and Second User 150 may optionally communicate with each other. Each communication interface can be implemented using any suitable electronic communication protocol / standard. Although each communication interface shown in Figure 1 is a direct connection, it will be understood that any number of intermediate devices / entities may optionally be present in the communication path.

[0064] Figure 2 shows a conceptual visualization of the hierarchy of data record 115 and the first DLT 120 and second DLT 130. DLTs 120 and 130 can be thought of as being in "Layer 1" of the system structure. Layer 1 can contain any number of different DLTs, each of which is editable and readable by different participants in system 100, e.g., operator 110, first user 140, second user 150, and monitor entity 160. Data record 115 can be thought of as being in "Layer 2" of the system structure. Data record 115 in Layer 2 is maintained / controlled by operator 110. In system 100 of this disclosure, a particular data item or asset may be controlled using two or more DLTs in Layer 1. For example, first user 140 may have a data asset such as a certain amount of digital currency or any other form of information / data that they wish to control using two or more DLTs in Layer 1. This data can be controlled by instructions posted by the user to either the first DLT 120 or the second DLT 130. Operator 110 uses the Layer 2 data records to maintain data consistency that is simultaneously controlled by two or more Layer 1 DLTs. In this way, data associated with a user can be modified in a secure and consistent manner across all Layer 1 DLTs by transactions / instructions posted to any one of the multiple Layer 1 DLTs. Layer 1 can be conceptually thought of as being located at Layer 0 of the system, which may be the public / private network on which the Layer 1 DLTs operate.

[0065] Figure 3 shows a sequence diagram representing an exemplary process in which the first user 140 can issue instructions to be executed.

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

[0067] Figure 4 shows an illustrative visualization of the data contained 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 is broadcast, including DLT transaction request parameters 410 (which may include one or more of the following: sender address, recipient address, 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 an encryption protocol used for any DLT to which the first blockchain transaction 400 is broadcast. According to this disclosure, the first user 140 includes a first instruction 500 in the first blockchain transaction. As will be understood by those skilled in the art, the blockchain transaction typically has available user-defined data fields 430, and the first instruction 500 may be contained in the user-defined data fields 430.

[0068] Figure 5 shows an illustrative visualization of the data contained in the first instruction 500. The first instruction 500 may be configured to include data that allows operator 110 to identify the first user 140, as well as data indicating the nature of the instruction. For example, the instruction may be for performing some modification on the first user's data in the electronic data record 115, or it may be an instruction to trigger some computer program / process (such as a smart contract) held in the electronic data record 115 or elsewhere and linked to operator 110 or the electronic data record 115, such that the execution of the instruction triggers the computer program / process and any other data required according to any security / cryptographic procedures set by operator 110. In this example, the first instruction 500 includes a first user ID 512, which operator 110 can use to uniquely identify any data in the Layer 2 data record 115 associated with the first user, and by extension, the first user 140. The first user ID 512 can uniquely identify the first user 140, or the first user 140 may have multiple different first user IDs, each associated with several different pieces of data about that user within the Layer 2 data record 115. In that case, the first user ID 110 can be considered an account ID that identifies the Layer 2 account of the first user 140.

[0069] In the example shown in Figure 5, the nature of an instruction is indicated using function 514 and variable 518. Depending on the specific types of instructions that system 100 is configured to allow, a variety of different functions may be available for the first user 140 to set, such as “trigger,” “send,” “delete,” “replace,” “transfer,” and “add.” 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 recipients of a message to be communicated). For example, if the first user holds multi-DLT digital currency in a Layer 2 account, function 514 may indicate that a fund transfer of some amount of the first user's currency is desired. In this case, the modified 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 that amount will be transferred. In a further example, function 514 could indicate that a particular process or operation is to be executed / triggered, and variable 518 could contain arbitrary data such as an identification of the address of the routine to be executed and / or the payload passed to the routine, which is necessary for it to occur.

[0070] In the example shown in Figure 5, the security / cryptographic requirements for the multi-DLT system 100 are: The command details 510 are configured to require that the first user sequence number 516 be included and that the first instruction 500 be included in the first user signature 520 (however, both the user sequence number 516 and the first user signature 520 are optional, and in some implementations, the operator 110 may not require the presence of one or both of these in a transaction in order to positively verify the transaction). The first user sequence number 516 may be a value that is incremented / decremented for each new instruction generated by the first user 140. This allows the operator 110 to enhance the security of the multi-DLT system 100 when performing the process of step S330 described later, 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 command details 510 generated using a private key associated with the first user 140, in accordance with any cryptographic protocol defined by the system security criteria for instruction execution. The cryptographic standard used for the first user signature 520 to secure the first instruction 500 may differ from the cryptographic standard used for the DLT transaction signature 420. As a result, operations performed on the Layer 2 data record may be secured to a higher cryptographic standard than that used for the first DLT 120 and / or the second DLT 130. Consequently, this disclosure can enhance the data security of the first DLT 120 and / or the second DLT 130 on which the system operates.

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

[0072] Operator 110 is configured to monitor the first DLT 120 and the second DLT 130 for distributed ledger transactions, including instructions. For example, Operator 110 may be running a participating node on the first and second DLTs and can receive each broadcast transaction. In addition, or alternatively, the operator may read the contents of each block (each containing multiple distributed ledger transactions) added to the first and second DLTs. In addition, or alternatively, Operator 110 may monitor one or more of the first and second DLTs by querying entities that are running nodes on the first and second DLT networks, rather than running nodes on the first and second DLTs.

[0073] In step S320, operator 110 identifies the first distributed ledger transaction as a transaction containing instructions to be executed. Each of the first and second DLTs may contain many distributed ledger transactions not relevant to this disclosure (for example, if these transactions are a general-purpose DLT such as Ethereum), in which case it will be understood that operator 110 is configured to identify the distributed ledger transaction containing instructions so that other transactions on the DLT may be ignored. There are various different ways in which operator 110 may identify a transaction containing instructions to be executed, and these different possibilities are not the subject of this disclosure. Therefore, although not given in detail in this disclosure, as a simple example only, operator 110 may evaluate the contents of all transactions to look for data in the form of instructions described with reference to Figure 5, or in the DLT transaction request parameters 410 and / or user-defined data fields, the user / It should be noted that the system may be configured to look for data that identifies an account (for example, using the first user ID 512, or the Layer 2 account ID to which the transfer is instructed, and comparing them to the user ID / account ID registered with operator 110), or to look for any other items of data that mark the transaction as being related to operator 110 (such as a flag indicating that it contains the instruction on which the transaction is executed).

[0074] In step S330, after identifying the first distributed ledger transaction 400 as relevant, operator 110 validates the first instruction 500. The validation may include any one or more of the following: confirming the correct formatting of the instruction; verifying the first user signature 520 using the cryptographic key registered with the first user and standard symmetric / asymmetric cryptographic techniques; and confirming that the first user sequence number 516 satisfies expectations (for example, that 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 preceding instruction from the first user 140).

[0075] It will be understood 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.). Operator 110 can continuously monitor the first and second DLTs for these instructions and verify their contents when identified. For example, Operator 110 can store a copy of each identified instruction (e.g., in part of the Layer 2 data record 115, or in any other memory accessible to Operator 110), and then periodically or intermittently verify one or more of the identified instructions (e.g., verifying in the order in which the instructions were identified, such that the oldest instruction is verified first, or verifying in any ordering order identified within the instructions, or verifying in any other order, etc.). Optionally, a copy of each instruction that has been positively verified (i.e., passed all verification checks) may be recorded by operator 110 (for example, in part of the Layer 2 data record 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 (for example, prioritizing them based on the time spent pending, or prioritizing them according to any other requirement such as any ordering identified within the instructions, or executing them according to any other ordering scheme or process). Alternatively, operator 110 may execute each instruction immediately after positive verification.

[0076] Before executing an identified instruction, operator 110 may be configured to determine the order in which the instructions are executed. This may occur, for example, before verification of the identified instruction if the instruction is executed immediately after positive verification, or after verification if, for example, the operator verifies the instructions, adds positively verified instructions to a “pending” pool, and selects an instruction from there for execution. It will be understood that operator 110 may be configured to determine the order of execution in any preferred manner, depending on the specific implementation of system 100. For example, this can be based on any execution sequence rules configured for operator 110 to follow, the content of the instructions (e.g., following any sequence numbering contained in user sequence number 516 / variable 518, or determining the correct order based on the nature of the instructions such as function 514 and / or variable 518), and / or the time when operator 110 identified the instructions (e.g., executing the instructions in the order they were identified). In this way, the correct ordering of instruction execution may be maintained by operator 110 regardless of the Layer 1 DLT to which each instruction is posted, thereby maintaining the security, reliability, and robustness of system 100.

[0077] In step S340, the first instruction 500, which has been positively validated, is executed. For example, if instruction detail 510 indicates that a first user 512 wants to transfer an amount of currency from its Layer 2 account to another user's Layer 2 account, operator 110 will modify the electronic data record 115 to reflect the change by storing the result of the executed instruction (in this case, the result would include decreasing the balance in the first user's account and increasing the balance in the other user's account). In a further example, if instruction detail 510 includes additional data that the first user 140 wants to store, operator 110 stores that additional data in the electronic data record 115, along with its association to the first user ID 512, as a result of the executed instruction. In a further example, if the modification detail 510 is an instruction that triggers some other process (e.g., calling a Layer 2 smart contract or some other form of computer code / program to execute a specific 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 with user ID 512, so that the user can later query the current state of the data in the electronic data record 115, whose state depends on the stored results). In this example, the stored results may be values ​​returned by the triggered process, such as process reception, results, or responses, and / or computer code contained within the instruction detail 510, and the storage may optionally trigger further processes and result that are also stored as part of the results.

[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 command and the result, or a sequence number that changes with each further update to the data associated with a 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 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 a command such as a new account balance, or a returned response / received / result of executing a command. Optionally, it may also include the user ID of the user associated with the result, or the user may be associated with the stored result in any other way within the electronic data record 115. Thus, a history record may be constructed for each stored result.

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

[0080] Operator 110 may store / record the entire contents of the first instruction 500 in, for example, a “verification set” (for example, in part of the Layer 2 data record 115, or in any other memory accessible to Operator 110). As will be described in more detail later in the “Instruction Execution Ordering” section, Operator 110 may maintain a record of each executed instruction in a series of consecutive verification sets, each verification set containing one or more executed instructions. This record is, as will be described further in the “Instruction Execution Ordering” section, This may be useful for verifying 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 that shows the stored result (in the electronic data record 115) of the executed first instruction 500.

[0082] Figure 6 shows an exemplary visualization of the data contained in the first verification record 600. The purpose of the first verification record 600 is to enable the first user 140 and / or monitor entity 160 to verify that an instruction was correctly executed by the operator entity 110. The verification details 610 may include information that enables the first user 140 and / or monitor entity 160 to perform this verification. The operator signature 620 is optional and is a digital signature of the verification detail 610 that the operator 110 generates using the private key associated with that verification detail to prove 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 to ensure that the first verification record 600 originates from an entity authorized to execute the instruction and modify the Layer 2 data record 115, and is therefore trustworthy. However, trust in the origin and content of the first verification record 600 may be achieved in any other preferred way.

[0083] The verification detail 610 includes a data record modification statement 614 that shows the Layer 2 data record 115 after the results of the executed instruction have been stored (for example, it may show the stored results of the executed instruction). This may be used by the first user 140 and / or monitor entity 160 to verify the executed instruction. In one particular example where the Layer 2 data record 115 contains a Merkle tree, when operator 110 records the results of the executed instruction, it may update the Merkle tree with 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 intended for use when verifying two or more stored results, such as when two or more instructions have been executed (for example, when its corresponding verification set contains 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 (for example, when operator 110 is configured to store a result for each instruction it executes, this operator may store these results in the Merkle tree in the same order in which the instructions were executed). However, in other implementations, the order in which results are stored may not indicate the order in which instructions were executed, for example, if two or more potentially discontinuously executed instructions cause only one result to be stored. Making the data record modification statement 614 indicate the order in which results are stored can be achieved in many different ways, for example, by using a Merkle tree as described later to generate the data record modification statement in a way that depends on the order in which results are stored.

[0084] In a further example, the Layer 2 data record 115 does not have to contain a Merkle tree, but may be structured in any other way. In this case, the way the data is stored in the Layer 2 data record 115 can indicate the order in which the results were stored, and the data record modification statement 164 may include a database hash of that data so that the database hash can also indicate the order in which the results were stored.

[0085] Optionally, the verification detail 610 may also include an operator ID 612 that uniquely identifies the operator 110. This can be used, for example, when there are multiple operators 110 authorized to execute instructions and modify the Layer 2 data record 115. .

[0086] Furthermore, optionally, the validation detail 610 may include a validation record ID 618 that uniquely identifies the first validation record 600. The first validation record 600 can be uniquely identified using the validation record ID 618. The validation record ID can function as a sequence identifier indicating the relative order of validation records stored in the Layer 1 DLT, for example, if it is an increment / decrement number that increments / decrements the validation record ID 618 appearing in a preceding validation record. However, it will be understood that the first validation record 600 can be uniquely identified in any other way (for example, by a data record modification statement 614 which is likely to be unique to each validation record stored in the first and / or second DLT).

[0087] Optionally, the first verification record 600 may also include an instruction record 616 that indicates the instruction to which the first verification record 600 relates (i.e., the instruction included in the corresponding verification set). As mentioned above and described in more detail below in "Instruction Execution Ordering," each verification set recorded by operator 110 may contain one or more executed instructions, and each verification record stored in the first and / or second DLT by operator 110 may correspond to a verification set (for example, each verification set may optionally be uniquely numbered to indicate the relative order / sequence of the verification sets, and the numbering may be related to or the same as verification 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 verification set. The instruction record 616 may indicate one or more executed instructions in the verification set and may indicate the relative order in which the instructions were executed.

[0088] Instruction record 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; hashes (or some other unique record / identifier / value) of at least a portion of each executed instruction; and / or hashes (or some other unique record / identifier / value) of two or more portions of the executed instructions. If hashes / identifiers of at least a portion of each executed instruction are included, they may optionally be ordered within instruction record 616 in a manner indicating the order in which they were executed. If hashes / identifiers of at least a portion of two or more executed instructions are included, those instructions may be placed in an order corresponding to the order in which they were ordered and then the order in which the hashes were taken, so that the hashes / identifiers generated based on those instructions indicate the sequence of execution.

[0089] Figure 7 shows an example of a Merkle tree for a Layer 2 data record 115. Those skilled in the art will readily understand how the Merkle tree works. In this particular example, four different results of instruction execution are stored in the Layer 2 data record 115 (for example, this could be the result of executing 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 contain any number of leaves. In this example, the hash H1 of leaf 1 relates to the stored result of the executed first instruction 500. The content of leaf 1 (i.e., the stored result of the executed first instruction, or the hash of the stored result of the executed first instruction) depends on the implementation of system 100 and the nature of the instructions being executed. For example, the contents may include a copy of the Layer 2 data relating to the first user 140 after the requested data modification has been made, or it may include the returned result / received data of a program / process triggered by the instruction (and optionally, instruction sequence number 516). In one example where the first instruction 500 relates to a currency transaction, Leaf 1 may contain the first user ID 510 and the balance of the first user account after the transaction has been executed. As previously explained, the ordering of each leaf can indicate the order in which each result is stored, and in some implementations, it can also indicate the sequence in which the operator 110 executed instructions (for example, if the operator is configured to store one or more results for each instruction executed and to store those results in an order corresponding to the order in which the instructions were executed). For example, in Figure 7, the instruction that produced the stored result contained in Leaf 1 may have been executed before the instruction that produced the stored result contained in Leaf 2, etc. The relative ordering of the leaves affects the Merkle root of the tree, which then indicates the relative ordering of the stored results.

[0090] Figure 8 shows an example of a Merkle tree for an instruction to which the first verification record 600 relates. In this particular example, the first verification record 600 relates to four instructions executed by operator 110, resulting in four leaves in the Merkle tree, each representing the result of its execution. However, it will be understood that a Merkle tree can contain any number of leaves. In this example, leaf 1 contains at least a portion of the executed first instruction, e.g., the entire first instruction 500, the hash of the first instruction 500, the instruction detail 510, or the hash of the instruction detail 510 (i.e., the unique cross-DLT ID mentioned above). Optionally, each leaf may also contain some data indicating the execution of an instruction, e.g., the reception or result of a process / program triggered by the instruction. If the relative execution order of each instruction to which the verification record 500 relates is important, the ordering of each leaf can indicate the sequence of instruction execution. For example, in Figure 8, the instruction in leaf 1 may have been executed before the instruction in leaf 2, etc. The relative ordering of the leaves affects the Merkle root of the tree, which then indicates the relative ordering of the instructions that were executed. However, if the relative ordering of the instructions that are executed is not important to the first verification record 600, the ordering of the leaves that make up the Merkle root may be arbitrary. By generating the Merkle tree in this way, operator 110 may include the Merkle root as part of instruction record 616, thereby including all the relatively small / short provable records of the instructions that are executed and the order in which they were executed, as well as optionally.

[0091] Operator 110 can store the first verification record 600 by broadcasting further blockchain transactions to the first DLT 120 and / or the second DLT 130, and the first verification record 600 is contained within a user-defined data field (as previously described with reference to Figure 4). As a result, the first verification record 600 can be stored in a virtually immutable manner that is readable by the first user 140, the second user 150, and the monitor entity 160. The first user 140 and / or the monitor entity 160 can then use the first verification record 600 to verify that Operator 110 has successfully executed the instruction, as will be described later in "Proof of Instruction Execution".

[0092] (Ordering of instruction execution) The ordering of instruction execution can be crucial for the secure and reliable operation of system 100. For example, it has long been recognized that, in order to prevent double-spending of cryptocurrency, it must be possible to determine whether a cryptocurrency has been used before. Some existing standalone blockchains achieve this through the chronological nature of blocks on the blockchain, where each block contains a timestamp, and existing blocks confirm that the cryptocurrency identified in a new transaction has not yet been used.

[0093] However, the inventors believe that reliable ordering is only applicable to applications related to currency. Rather, we recognized that this could be important for all applications in general. For example, in various fields and protocols of the Internet and telecommunications, it will be understood that incorrectly ordered instructions / messaging can be exploited as a security and stability vulnerability. For example, each of the instructions mentioned above may contain communication data such as TCP / IP packets, and there are numerous ways in which ordered and synchronous communication data can affect the security of a system, such as when messages / instructions are out of order or an incomplete set of messages / instructions impairs the security of the system in terms of either integrity or availability. As previously described, the instructions of this disclosure may relate to any form of data instructions / messaging. Therefore, we recognized that maintaining and / or verifying the order of instruction execution can be critical in achieving a secure, reliable, and malpractice-resistant system, not only when used to carry instructions / messages, but also when used for any other purpose.

[0094] However, this is particularly difficult in multi-DLT systems where the system operates on multiple Layer 1 DLTs (e.g., a first DLT120 and a second DLT130). 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 security, reliability, and resistance to fraud. One particular further challenge in maintaining and verifying instruction execution ordering and system consistency across multiple Layer 1 DLTs is "blockchain rollback," where blocks in the blockchain can be lost. For example, a rollback may be caused by a blockchain fork, and one or more blockchain transactions that appeared in the shorter prong of the fork may be lost from the blockchain (or rolled back). Those skilled in the art will readily understand the possibility of a DLT forking and the characteristics of how a DLT behaves when a fork occurs. This result means that, in practice, when the first instruction is executed before the second instruction, a rebroadcasted distributed ledger transaction containing the first instruction (which was previously lost in a ledger rollback) may appear in the distributed ledger after some other distributed ledger transaction containing the second instruction.

[0095] Figure 9 illustrates an illustrative representation of a fork in a blockchain. Transaction 1 is part of block B1 appearing 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 appearing in "prong 2". At some point later, transaction 1 may be appended to the blockchain as part of block B8 on "prong 2" by a node participating in the blockchain, for example. Thus, transaction 1 appears in the blockchain after transaction 2. However, if it is important that transaction 1 precedes transaction 2 (for example, if they are related to consecutive messages), this could cause security or stability breaches or allow fraud to occur in applications utilizing the blockchain. Another cause of rollback may be that participants in the blockchain agree, for some reason, to roll back the blockchain to a specific previous block (such as an Ethereum and Ethereum Classic fork).

[0096] The relative ordering of instruction execution across different Layer 1 DLTs may be important for the security and stability of the system as well as for the verifiability of the operator 110's actions; therefore, losing blockchain transactions can be particularly problematic in this disclosure. In this case, the loss of blockchain transactions on Layer 1 DLTs due to rollback may be particularly problematic. Simply replaying a transaction may be unsafe because the replayed transaction may be out of sequence with the actual execution of the instructions made.

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

[0098] Figure 10 shows an example of instruction 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 contained within a blockchain transaction in a block of either the first DLT 120 or the second DLT 130. Each instruction can take the form of the first instruction 500 described above. 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., an instruction can be issued to any Layer 1 DLT such that the data stored in the electronic data store (e.g., Layer 2 data) associated with the first user 140 is equally controllable by 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, validated in step S330, and executed in step S340 (in this example, validation is performed on all identified instructions, and they all pass validation; however, alternatively, only some of the identified instructions A, Q, and M may pass validation at this point, while others may pass validation later, for example, appearing in a later validation set / record). Operator 110 is configured to determine the correct execution order of instructions A, Q, and M, as described earlier, thereby maintaining system security and reliability. As part of the process in step S340, operator 110 can also record a copy of the executed instructions in a "validation set," for example (for example, as part of the Layer 2 data record 115, or in any other memory accessible to operator 110), as briefly mentioned earlier. For example, operator 110 can identify instruction A and add it to the pending group. Operator 110 does the same for each further identified instruction (in this example, instructions Q and M) until a predetermined period has elapsed or the pending group is full. As each instruction is executed, it may be stored in a verification set. If the relative ordering of instruction executions within the verification 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 the electronic data record 115 (Figure 7) and / or a Merkle tree of the executed instructions (e.g., leaf 1 contains at least part of instruction A, leaf 2 contains at least part of instruction Q, etc., Figure 8). Thus, regardless of the Layer 1 DLT in which the instructions were found, Operator 110 can maintain and record the relative ordering of transaction executions. If the relative ordering of instruction executions within the verification set is not important, the record of the sequence of executions does not need to be recorded.

[0100] Operator 110 can generate a verification record corresponding to the verification set. The verification record can take the form of the first verification record 600 described above. For example, the verification 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., the statement 614 for modifying the data record is generated based on the stored results of the executed instructions A, Q, and M). The verification record n can also be generated based on at least a part of the executed instructions A, Q, and M (e.g., the instruction record 616 can be generated based on at least a part of each of the instructions A, Q, and M). Once generated, Operator 110 can also optionally record / store a copy of the verification record n in a location different from the DLT of layer 1 (e.g., in a part of the data record 115 of layer 2, or in any other memory accessible to Operator 110). This can be useful if the verification record n is lost from any of the DLTs of layer 1 in the future. Operator 110 can also store / record the association between the verification record n and the verification set n (or only a copy of the executed instructions that are part of the verification set n ).

[0101] Optionally, before storing the latest verification record in at least one of the DLTs of layer 1, Operator 110 can check the previous verification record n-1 , and / or the executed instructions related to the previous verification record n-1 (e.g., the executed instructions that are part of the previous verification set n-1 ), and / or the executed instructions related to the current verification record n (e.g., the current verification set n in which the verification record n is about to be stored)It can be confirmed that the executed instructions (which are part of the DLT) still exist in the Layer 1 DLT. If not, they may be added back to at least one of the Layer 1 DLTs.

[0102] For example, in Figure 10, it can be seen that the second DLT130 has a fork. The lower prong of the fork progresses, and the contents of the upper prong are lost. Instructions M and Z, as well as the verification record. n All of these first appear on the upper prong of the second DLT130 and are lost as a result of the rollback caused by this fork. Operator 110 verifies the record n+1 After preparing the verification set, n and verification set n+1 , and verification records n The executed instructions included can be confirmed to appear in the DLT of Layer 1. At this time, operator 110 can confirm instructions M and Z, as well as the verification record. n It can be identified that was lost as a result of the rollback. The operator can broadcast a new blockchain transaction to the second DLT130 where instruction M was lost (this is possible because operator 110 held a copy of instruction M which could be included as part of the new blockchain transaction. It is not important that the new blockchain transaction originates from operator 110 and is signed by the operator. The origin of the distributed ledger transaction at Layer 1 is irrelevant to this system. The user-defined data field of the new transaction contains the entire copy of the previously lost instruction, which is important information for the operation and verification process of this disclosure). This appears in the lower prong of the fork in Figure 10. This is also the verification record. n Another new blockchain transaction containing instruction Z can be broadcast, and both of these also appear in the lower prongs of the fork in Figure 10. Then the latest verification record n+1These can be stored in at least one of the Layer 1 DLTs. Each of these new transactions is represented in a separate block, but some or all of them may appear in a second DLT 130 within the same block. Furthermore, as can be seen from the following explanation, the order in which the new transactions appear in the second DLT 130 is not important.

[0103] The relative order in which 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 for the secure, safe, and reliable operation of System 100) is recorded in the content of the verification records, regardless of where these 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 records. In this case, the verification record n-1 The relevant instructions are in the verification record. n All of the related instructions are executed before this, and this is the verification record n+1 It is possible to determine that all related instructions were executed before the relevant instructions.

[0104] In some system implementations, the relative order of instruction execution within each verification record is known. This may not be important. For example, in systems where only a coarser level of execution order verifiability is required to maintain system security and stability, or when the order in which two or more instructions are executed is important, and the operator 110 is configured to execute instructions so that they appear in different sets of verification so that the execution ordering can be verified in that way, or when the operator 110 is configured to include only one executed instruction in each set of verification.

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

[0106] In this way, regardless of rollbacks, verification data can be maintained that allows for the confirmation and verification of a record of each executed instruction, as well as the execution order (at either a coarse or fine level). Thus, the user can be confident that, once the verification record is included in the Layer 1 DLT, the relevant instructions have been executed by operator 110, and that their ordering relative to previously executed instructions can be verified regardless of any rollbacks in any of the Layer 1 DLTs. This further advantage relates to the period during which the user can be confident that the instructions have been executed. For example, in many blockchain technologies such as Bitcoin, it is recommended that it is best to wait for a certain number of blocks (e.g., 6 blocks) to be added to the blockchain after the block in which a transaction appears, because it relies on blockchain transactions. This is to ensure that transactions are not lost due to forks. Since each block takes a certain period (e.g., about 10 minutes) to be added, this wait can be significant. However, in this 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 instructions have been executed, regardless of any potential future rollbacks (assuming the user has verified its contents, as will be explained later). This can significantly increase the speed and efficiency at which users can be confident in the execution of instructions issued via Layer 1 DLT.

[0107] Each block shown in Figure 10 contains only a single transaction, but it will be understood that in reality, each block is likely to contain many transactions. Blocks that appear empty in Figure 10 are not actually empty, but in this example, they do not contain blockchain transactions that have the orders of this disclosure. In this example, the verification record is stored in both the first and second DLTs. This may be preferable to improve robustness and data integrity, and therefore security, as there must always be at least one copy of the verification record in the Layer 1 DLT, even in the case of a fork (the probability of two DLTs forking independently at the same time and causing both to lose the same verification record is extremely low). However, this is not mandatory, and alternatively, the verification record may be stored in only one of the Layer 1 DLTs.

[0108] In the example above, operator 110 verifies that the instructions for the previous verification record, and / or the previous verification set and / or the current verification set, are present in the Layer 1 DLT. Alternatively, operator 110 can always verify that the instructions for any preceding verification set and any preceding verification record still appear in the Layer 1 DLT.

[0109] (Proof of execution of the command) To ensure that operator 110 is executing the instructions correctly, the user, It is possible to use the modified records stored in the DLT of Ya1 to verify the state of the Layer 2 data record 115.

[0110] Figure 11 shows a sequence diagram illustrating an exemplary process that allows a first user 140 to verify the current state of its 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 monitor entity 160. The monitor entity 160 may be an entity configured to monitor the Layer 1 DLT to identify blockchain transactions containing instructions and to identify verification records stored in the Layer 1 DLT. It may also be configured to determine which verification record is associated with which executed instruction. This can be done, for example, by using the instruction hash contained within the instruction record 616 of the verification record to generate hashes of the relevant parts of each instruction to be identified in the Layer 1 DLT and comparing them with the hashes contained in the instruction record 616 that identify them. Alternatively, if the instruction hashes do not form part of the instruction record 616, the operator 110 can inform the monitor entity 160, for example, via a communication channel between the monitor entity 160 and the operator 110, which instructions are associated with each verification record. Optionally, the monitor entity 160 can use the instruction record 616 to verify this information communicated from the operator 110. For example, if instruction record 616 of verification record 600 indicated by operator 110 contains a Merkle root, monitor entity 160 can generate a Merkle root based on the instructions that operator 110 described as being part of the indicated verification record 600 and the order in which they were included in the Merkle tree as described by operator 110, and compare it to the Merkle root in instruction record 616 of the indicated verification record 600. Alternatively, in addition to communicating which instructions are relevant to the verification record, operator 110 may also provide a proof to prove 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 (ZKProof) if the instruction record contains a hash of two or more executed instructions. As a result, monitor entity 160 can verify the information provided by operator 110 (and, if relevant, the order of instruction execution in the verification record).Furthermore, the monitor entity 160 may optionally monitor the state of the data held in the electronic data record 115 by, for example, updating the shadow copy record it holds by performing each executed instruction, and / or by having the operator 110 communicate to the monitor entity 160 the stored result of each instruction execution (which can be verified by the statement 614 of data record modification in each verification record). Thus, the monitor entity 160 may have a very similar level of operation and knowledge as the operator 110, but unlike the operator 110, it is not authorized to execute instructions, make changes to the Layer 2 data record 115, or store verification records in the Layer 1 DLT.

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

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

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

[0115] Optionally, operator 110 / monitor entity 160 may also communicate to the first user proof that the identified verification record is associated with one or more specific executed instructions (for example, if the user is checking the status of that data after executing a specific instruction, either a specific instruction identified by the user in a first status query, or a specific instruction that resulted in the current state of the user data). This proof can take any preferred form. For example, if the verification record is configured such that the instruction record contains a Merkle root, the proof may be a Merkle proof, or if the instruction record contains hashes of two or more executed instructions, the proof may be a ZK Proof. However, if the verification record is configured to contain hashes of at least some of the executed instructions to which they are associated, the first user can easily prove that any specific instruction associated with them forms part of the identified verification record.

[0116] In step S1130, the first user 140 searches for the relevant validation record in the first DLT 120 or the second DLT 130, and then retrieves any relevant information (for example, The data record modification statement 614 and / or at least part of the instruction record 616 can be retrieved.

[0117] In step S1140, the first user 140 can verify the state of that data using the extracted portions of the state proof and associated verification records. Thus, statements from operator 110 and / or monitor entity 160 to the first user 140 regarding the state of that data can be proven or disproven using cryptographically secure information accessible in the first DLT 120 and / or second DLT 130.

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

[0119] Optionally, the user may read the Layer 1 DLTs and / or query Operator 110 / Monitor Entity 160 to identify the instructions appearing in the associated Layer 1 DLTs (e.g., instructions originating from them, or instructions that in some way identify them, for example, as recipients of a financial transaction). The user may also query Operator 110 / Monitor Entity 160 to determine which instructions were executed and the verification records generated based on the results of each instruction execution (for example, the user may ask Operator 110 / Monitor Entity 160 whether any of instructions A, B, C, etc., were executed, and in return, the user may optionally receive an indication that instruction A was executed and is included in verification record Y, along with proof of inclusion such as a Merkle certificate or ZKProof, as described above). Next, the user can find out which instructions are said to have been executed and when they were executed (and verify their inclusion in the indicated verification record), and then verify the state of those data as a result of the instruction execution (for example, 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, users can issue instructions to any of multiple Layer 1 DLTs in a way that results in secure, consistent, and verifiable execution of those instructions. Thus, users 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 understand that various modifications or alterations can be made to the above-described aspects of this disclosure without departing from the scope of this disclosure.

[0122] In the above description, operator 110 stores ordered verification sets, each containing a copy of one or more executed instructions. Alternatively, operator 110 can simply store each executed instruction along with an association to a verification record partially generated with respect to the result of the executed instruction. The relative ordering of each verification record may be maintained, for example, by the verification record ID, and thus the relative ordering of instruction executions between verification records can be described in this way (and the relative ordering of instruction executions within a verification record may be described by data record modification statements 614 and / or instruction record 616).

[0123] The instruction record 616 within the verification record 600 is optional. For example, some verification records may relate to the starting status of one or more parts of the electronic data record 115, such as the starting balance for a user account in a Layer 2 record. In this case, the instruction record 616 may be omitted, and the data record modification statement 614 may indicate the starting status of one or more parts 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 optionally, further processes may be performed depending on the result. For example, a smart contract may be triggered by the presence of a particular instruction on the first DLT 120. This can verify the execution of the instruction using the process described with reference to Figure 11, and optionally, if verified, perform further actions. In one particular non-limiting example, data such as tokens may thus be migrated from a Layer 2 account to a Layer 1 account on a specific Layer 1 DLT. For example, an instruction to transfer tokens from a Layer 2 account to a migration Layer 2 account may be posted to one of the Layer 1 DLTs. A smart contract may be triggered by a reference in the instruction to the migration Layer 2 account. When this instruction is executed, the result is stored in the Layer 2 electronic data record 115, and as a result, tokens are added to the balance of the migration account. The smart contract can verify the execution of an instruction (for example, by using the user verification process described above, see Figure 11), and if verified, can add tokens to the Layer 1 DLT (for example, at a given Layer 1 token:Layer 2 token ratio). Optionally, the smart contract may then issue a further instruction 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 preferred manner. A similar process can be reversed to migrate Layer 1 tokens to a Layer 2 account.

[0125] Throughout this disclosure, the term “hash” is used frequently. Where a hash is generated based on data, any other preferred type of value that uniquely identifies the data may be generated, alternatively, using any preferred process. For example, where a hash is generated for at least a portion of the instructions that have been executed, alternatively, a value that uniquely identifies at least a portion of the instructions that have been executed may be generated, based on the instructions that have been executed, using any preferred process.

[0126] In some aspects of this disclosure, the use of Merkle trees and Merkle roots is disclosed, for example, in relation to Layer 2 data records 115 and data modification statements 164, and / or executed instructions and instruction records 616. This is just one non-limiting exemplary structure / technique that may be used, and others are possible, as shown above. As further examples of types of data structures that preserve or indicate the relative ordering of information within a data structure, Merkle trees and Merkle roots may be used in Layer 2 data records 115 and data modification statements 164, and / or executed instructions and instruction records 616. A Merkle tree is similar to a Merkle tree, but can combine two or more items at each level. Any other type of data structure that preserves or indicates relative ordering may be used as an alternative in Layer 2 data records 115 and data modification statements 164, and / or executed instructions and instruction records 616. In the example described above, system 100 includes a single operator 110 and a single monitor entity 160. However, Alternatively, 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 load, 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 aspects of the disclosure described above may be implemented by software, hardware, or a combination of software and hardware. For example, the functions of operator 110, user, and / or monitor entity 160 may each be implemented by software including computer-readable code, which, when executed on one or more processors (such as one or more microprocessors or programmable logic) of any electronic device, perform the functions described above. The software may be stored on any suitable computer-readable medium, such as non-transient computer-readable media including read-only memory, random-access memory, CD-ROMs, DVDs, Blu-rays, magnetic tapes, hard disk drives, solid-state drives, and optical drives. The computer-readable medium may be distributed across a network-connected computer system so that computer-readable instructions are stored and executed in a distributed manner.

Claims

1. A computer implementation method for issuing instructions to be executed using one of several different distributed ledgers, To issue a first command to be executed, which includes the identifier of a first user, to a first distributed ledger among the multiple different distributed ledgers, To issue a second command to be executed in a second distributed ledger among the multiple different distributed ledgers, which includes the identifier of the first user, Includes, The execution of the first instruction results in a modification of data associated with the first user and stored in an electronic data record. A method by which the execution of the second instruction results in a modification of data associated with the first user and stored in the electronic data record.

2. The method according to claim 1, wherein the electronic data record is different from the plurality of different distributed ledgers.

3. The first instruction further includes a first function that indicates a function to be performed when the first instruction is executed, The second instruction further includes a second function that indicates a function to be performed when the second instruction is executed. The method according to claim 1 or claim 2.

4. The first instruction further includes one or more variables containing data necessary to execute the first instruction. The second instruction further includes one or more variables containing data necessary to execute the second instruction. The method according to any one of claims 1 to 3.

5. The first instruction further includes a first sequence number associated with the first user, The second instruction includes a second sequence number associated with the first user, The first sequence number differs from the second sequence number in that it indicates the relative order in which the first instruction and the second instruction were generated. The method according to any one of claims 1 to 4.

6. Issuing the first command to be executed to the first distributed ledger among the plurality of different distributed ledgers includes broadcasting a first distributed ledger transaction to the first distributed ledger, the first distributed ledger transaction including a user-defined data field containing the first command. Issuing the second instruction to be executed to the second distributed ledger among the plurality of different distributed ledgers includes broadcasting the second distributed ledger transaction to the second distributed ledger, wherein the first distributed ledger transaction includes a user-defined data field containing the first instruction. The method according to any one of claims 1 to 5.

7. The electronic data record includes a Merkle tree associated with the first user, The method according to any one of claims 1 to 6.

8. The modification of the data associated with the first user includes updating the Merkle tree of the electronic data record, at least in part, based on each of the stored results of the executed instructions of the first plurality of instructions. The method according to claim 7.

9. A computer program configured to perform the method described in any one of claims 1 to 8 when executed on at least one processor of an electronic device.

10. An electronic device configured to perform the method described in any one of claims 1 to 8.

11. When executed on at least one processor of an electronic device, Monitoring multiple distributed ledgers for distributed ledger transactions that include the instructions being executed, Identifying a first set of distributed ledger transactions, each of which appears in one of the aforementioned set of distributed ledgers, and each of the first set of distributed ledger transactions including an instruction to be executed; Identifying a first verification record stored in at least one of the aforementioned multiple distributed ledgers, The execution of the instructions is verified using first verification information for verifying the execution of instructions within a first set of instructions, A computer program configured to perform the following actions.

12. The result of each executed instruction is stored in an electronic data record. The first verification record includes a first statement of data modification indicating the electronic data record after the result of the execution of the instruction being verified has been stored in the electronic data record, Verifying the execution of the said instruction involves using at least the first statement of the data modification, The computer program according to claim 11.

13. Monitoring multiple distributed ledgers for distributed ledger transactions that include the instructions being executed, Identifying a first set of distributed ledger transactions, each of which appears in one of the aforementioned set of distributed ledgers, and each of the first set of distributed ledger transactions including an instruction to be executed; Identifying a first verification record stored in at least one of the aforementioned multiple distributed ledgers, The execution of the instructions is verified using first verification information for verifying the execution of instructions within a first set of instructions, An electronic device configured to perform a certain action.

14. When executed on at least one processor of an electronic device, A status query relating to the status of data associated with a first user in an electronic data record, wherein the status query includes the identifier of the first user, Receiving a status notification, which includes a display of the status of data associated with the first user, and a certificate of status for use in verifying the displayed status of data associated with the first user, Identifying a verification record on one or more of a plurality of distributed ledgers for use in verifying the display of the data status associated with the first user, Using the verification records that prove and identify the aforementioned state, the display of the state of the data associated with the first user is verified, A computer program configured to perform the following actions.

15. The status notification includes the display of the verification record, The computer program according to claim 14.

16. A status query relating to the status of data associated with a first user in an electronic data record, wherein the status query includes the identifier of the first user, Receiving a status notification, which includes a display of the status of data associated with the first user, and a certificate of status for use in verifying the displayed status of data associated with the first user, Identifying a verification record on one or more of a plurality of distributed ledgers for use in verifying the display of the data status associated with the first user, Using the proof of the aforementioned state and the identified verification record, verify the display of the state of the data associated with the first user, An electronic device configured to perform a certain action.

Images