Tiered Consensus

Abstract

A computer-implemented method using a multi-level (ML) blockchain protocol to reach consensus on a data chain using a core blockchain, the method comprising: obtaining a target data block associated with the data chain; and generating a target ML block of the ML blockchain, the target ML block being a respective core blockchain transaction and comprising: a) the target data block; and b) a target chain output, the target chain output configured to be consumed by a respective chain input of a subsequent ML block, the target chain output comprising a locking script configured to implement a respective consensus-based locking mechanism, the respective consensus-based locking mechanism of each respective ML block being a function of the respective data block of that respective ML block; and c) a target chain input that references a respective chain output of a previous ML block.

Description

[Technical Field]

[0001] This disclosure relates to a method for reaching consensus on data in a data chain using a multi-level (i.e., tiered) data chain protocol. [Background technology]

[0002] A blockchain refers to a form of decentralized data structure in which copies of the blockchain are maintained and widely published on each of several nodes within a decentralized peer-to-peer (P2P) network (hereinafter referred to as the "blockchain network"). A blockchain consists of a chain of data blocks, each containing one or more transactions. Each transaction, other than so-called "coinbase transactions," points back to a preceding transaction in a sequence, which may span one or more blocks back to one or more coinbase transactions. Coinbase transactions are explained further below. Transactions submitted to the blockchain network are included in a new block. New blocks are often created by a process called "mining," which involves each of several nodes competing to perform "proof of work," that is, solving a cryptographic puzzle based on a defined representation of an ordered and validated pending transaction waiting to be included in a new block of the blockchain. Note that the blockchain may be pruned on some nodes, and that block issuance can be achieved simply by issuing a block header.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: carrying digital assets (i.e., several digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or time-ordering index pointers. Blockchain can also be leveraged to layer additional functionality on top of the blockchain. For example, a blockchain protocol may allow the storage of additional user data or indices to data within a transaction. There are no predetermined limits on the maximum amount of data that can be stored within a single transaction, and therefore, increasingly complex data can be incorporated. For example, this may be used to store electronic documents or audio or video data in a blockchain.

[0004] Nodes in a blockchain network (often called "miners") perform a distributed transaction registration and verification process, which will be explained in more detail later. In short, during this process, nodes validate transactions and insert them into block templates, for which nodes attempt to identify a valid proof-of-work solution. Once a valid solution is found, the new block is propagated to other nodes in the network, thus enabling each node to record a new block on the blockchain. To have a transaction recorded on the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network to which it should be propagated. The node receiving the transaction may compete to find a proof-of-work solution that incorporates the validated transaction into a new block. Each node is configured to execute the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are neither propagated nor incorporated into blocks. Assuming a transaction is validated and thus accepted on the blockchain, the transaction (including any user data) remains registered and indexed in that manner at each node in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are typically rewarded with a new transaction called a "coinbase transaction," which distributes a certain amount of digital assets, i.e., several tokens. Detection and rejection of invalid transactions are enforced by the actions of competing nodes acting as agents of the network, and reporting and blocking fraudulent activity is encouraged. Extensive issuance of information allows users to continuously audit node execution. The mere issuance of block headers allows participants to guarantee the ongoing integrity of the blockchain.

[0006] In an "output-based" model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Any consumable output comprises an element specifying a digital asset of a certain amount, which can be derived from the forward sequence of the transaction. A consumable output is sometimes called a UTXO ("unconsumed transaction output"). An output may further comprise a lock script that specifies the conditions for the future redemption of the output. A lock script is a predicate that defines the conditions necessary to activate and transfer a digital token or digital asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such an output in a preceding transaction and may further comprise an unlock script to unlock the lock script of the pointed-to output. Thus, when considering a pair of transactions, we refer to them as the first transaction and the second transaction (or "target" transaction). The first transaction comprises at least one output which comprises a lock script that specifies a digital asset of a certain amount and defines one or more conditions for unlocking the output. The second target transaction has at least one input, which includes a pointer to the output of the first transaction and a lock release script for unlocking the output of the first transaction.

[0007] In such a model, one of the validity criteria applied at each node when a second target transaction is sent to the blockchain network to be propagated and recorded within the blockchain is that the unlock script satisfies all one or more conditions specified in the lock script of the first transaction. Another criterion is that the output of the first transaction has not already been redeemed by another earlier valid transaction. Any node that finds an invalid target transaction according to any of these conditions will neither propagate it (as a transaction to register a valid, but possibly invalid, transaction) nor include it in a new block to be recorded within the blockchain. [Prior art documents] [Patent Documents]

[0008] [Patent Document 1] WO2021014233 [Patent Document 2] WO2020240295 [Overview of the Initiative] [Problems that the invention aims to solve]

[0009] It is recognized in this specification that a blockchain utilizing a UTXO-based transaction model can be used as a carrier of a secondary data chain. In some examples, the secondary data chain may be a secondary blockchain (i.e., a blockchain other than the blockchain serving as the carrier). This can be beneficial, for example, when an existing secondary blockchain or its network cannot grow due to a lack of hash power. For example, units of digital currency coins held by users of a secondary network may be saved by embedding the secondary blockchain within a growable core blockchain. An alternative scenario may be when the owner of a private blockchain requires proof of data integrity. This can be achieved by embedding private data either in its raw form or as cryptographic escrow within a public core blockchain as an immutable record of the data. In other examples, the secondary data chain may be non-blockchain related and generally may be any data structure in which data is arranged as a chain, for example, an append-only log. Examples of such data structures include communication chains (e.g., email or text message chains), move-order type games (e.g., chess), and the like. By using a core blockchain as a carrier of the secondary data chain, the secondary chain inherits the advantages of the core blockchain, including, in particular, data immutability, traceability, transparency, and security.

Means for Solving the Problems

[0010] According to one aspect disclosed herein, a computer-implemented method is provided for reaching consensus regarding a data chain using a core blockchain, using a multi-level (ML) blockchain protocol to reach consensus regarding the data chain, the ML blockchain comprising one or more previous ML blocks, each previous ML block being a respective core blockchain transaction and comprising a) respective data blocks associated with the data chain and b) respective chain outputs, each chain output being configured to be consumed by a respective chain input of a subsequent ML block, and comprising a lock script configured to implement a respective consensus-based lock mechanism that can be unlocked by any one or more of a plurality of ML block producers, the method being executed by an ML block producer and comprising the steps of obtaining a target data block associated with the data chain, and generating a target ML block of the ML blockchain, the target ML block being a respective core blockchain transaction and comprising a) the target data block, and b) a target chain output, the target chain output being configured to be consumed by a respective chain input of a subsequent ML block and comprising a lock script configured to implement a respective consensus-based lock mechanism, each respective consensus-based lock mechanism of each respective ML block being a function of the respective data block of that respective ML block, and c) a target chain input that references the respective chain outputs of the previous ML blocks and is configured to unlock the respective consensus lock mechanisms of those previous ML blocks, and recording the target ML block on the core blockchain.

[0011] The term "multi-level" (ML) protocol refers to a protocol that structures a secondary data chain as a higher-level chain of data above (i.e., using) a lower-level core blockchain (i.e., a first-level blockchain). This data chain may be interpreted as a second-level blockchain, as it comprises blocks of data (i.e., ML blocks) in the form of core transactions of the first-level blockchain. It should be noted that even in examples where the secondary data chain itself is not a blockchain (e.g., a communication chain), the secondary data is still structured (i.e., embedded) on top of the core blockchain using blocks called ML blocks. According to the ML protocol, an ML block is a core blockchain transaction. Each ML block (core blockchain transaction) comprises a data block, i.e., a chunk of data, associated with the secondary data chain. For example, each data block may be an entry (or set of entries) in an off-chain database, a message in a communication chain, a sequence in a move-order type game, a bank transfer or payment made by a user, or a transaction made by a financial institution. The data blocks may or may not be in an encrypted form, and may or may not be hashed using a hash function, for example.

[0012] An ML block also includes chain inputs and chain outputs used to chain together ML blocks, similar to how block headers in the core blockchain are used to chain together core blocks. The chain inputs and chain outputs utilize a consensus mechanism to lock and unlock core blockchain transactions representing ML blocks. A consensus lock mechanism is a lock mechanism configured to be unlocked by any one or more of several ML block producers. In this way, ML block producers can reach consensus, or agreement, on the data blocks provided by the ML block being unlocked. In some examples, the consensus lock mechanism is a function of the data block. For example, the consensus lock mechanism may consist of a proof-of-work puzzle containing the hash of the data block. The ML protocol establishes a tiered consensus, thereby enabling ML block producers to reach consensus on the data blocks within an ML block, and core nodes in the core blockchain network to reach consensus on the ML block (core blockchain transaction).

[0013] In summary, the core blockchain transaction chain acts as a chain of blocks in the ML data chain (or ML blockchain). Each ML block contains embedded data in a secondary data chain, such as a secondary blockchain.

[0014] References to the accompanying drawings are made merely as examples to aid in understanding the embodiments of this disclosure and to show how such embodiments may be effective. [Brief explanation of the drawing]

[0015] [Figure 1] This is a schematic block diagram of a system for implementing blockchain technology. [Figure 2] This diagram schematically illustrates some examples of transactions that may be recorded on the blockchain. [Figure 3A] This is a schematic block diagram of the client application. [Figure 3B] Figure 3A is a schematic mockup of an example user interface that may be presented by the client application. [Figure 4] This is a schematic block diagram of several node software programs for processing transactions. [Figure 5] This diagram schematically illustrates an example system for implementing a multilevel blockchain protocol. [Modes for carrying out the invention]

[0016] 1. Overview of the Example System Figure 1 shows an exemplary system 100 for implementing blockchain 150. System 100 may include a packet-switched network 101, typically a wide-area internet such as the internet. The packet-switched network 101 may include a plurality of blockchain nodes 104 configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a nearly complete graph. Thus, each blockchain node 104 is strongly connected to the other blockchain nodes 104.

[0017] Each blockchain node 104 has peer computer equipment, in which various nodes 104 belong to different peers. Each blockchain node 104 has processing equipment comprising one or more processors, for example, one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs), and other equipment such as application-specific integrated circuits (ASICs). Each node also has memory, i.e., computer-readable storage in the form of one or more non-temporary computer-readable media. The memory may comprise one or more memory units employing one or more memory media, for example, magnetic media such as hard disks, solid-state drives (SSDs), flash memory, or electronic media such as EEPROMs, and / or optical media such as optical disc drives.

[0018] Blockchain 150 comprises a chain of blocks of data 151, and each copy of Blockchain 150 is maintained in each of the multiple blockchain nodes 104 within the distributed network or blockchain network 106. As mentioned above, maintaining a copy of Blockchain 150 does not necessarily mean remembering Blockchain 150 as a whole. Instead, Blockchain 150 may be pruned from the data, as long as each blockchain node 150 remembers the block header (described below) of each block 151. Each block 151 in the chain comprises one or more transactions 152, where a transaction, in this context, refers to a type of data structure. The nature of that data structure depends on the type of transaction protocol used as part of the transaction model or transaction scheme. A given blockchain uses a particular transaction protocol throughout. In one general type of transaction protocol, the data structure of each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing the quantity of a digital asset as a characteristic, an example of which is user 103, whose output is cryptographically locked (requiring the user's signature or other solution to unlock and thereby redeem, i.e., consume). Each input points back to the output of the preceding transaction 152, thereby linking the transactions.

[0019] Each block 151 also has a block pointer 155 that points back to a previously created block 151 in the chain, so as to define the sequential order to block 151. Each transaction 152 (other than coinbase transactions) has a pointer that points back to a previous transaction so as to define the order of the transaction in the sequence (note that the sequence of transactions 152 is allowed to fork). The chain of block 151 proceeds completely back to the genesis block (Gb) 153, which was the first block in the chain. One or more initial original transactions 152 in chain 150 pointed to the genesis block 153 rather than a preceding transaction.

[0020] Each blockchain node 104 is configured to forward transaction 152 to other blockchain nodes 104, thereby propagating transaction 152 across the entire network 106. Each blockchain node 104 is configured to create block 151 and store each copy of the same blockchain 150 in its own memory. Each blockchain node 104 also maintains an ordered set (i.e., a “pool”) 154 of transactions 152 waiting to be incorporated into block 151. The ordered pool 154 is often referred to as a “mempool”. This term, as used herein, is not intended to be limited to any particular blockchain, protocol, or model. It refers to an ordered set of transactions that a node 104 has accepted as valid and that a node 104 should be obligated not to accept any other transaction attempting to consume the same output.

[0021] In a given current transaction 152j, its (or each) input contains a pointer to the output of a preceding transaction 152i in the sequence of transactions, specifying that this output will be redeemed, or "consumed," in the current transaction 152j. Generally, a preceding transaction can be any transaction in an ordered set 154 or any block 151. A preceding transaction 152i does not necessarily need to exist at the time the current transaction 152j is created and sent to the network 106, but for the current transaction to be valid, a preceding transaction 152i must exist and be valid. Thus, "preceding" as used herein refers to a preceding element in a logical sequence linked by a pointer, not necessarily at the time of creation or sending in a temporal sequence, and therefore does not necessarily exclude the possibility that transactions 152i and 152j may be created or sent out of order (see the following explanation in orphan transactions). The preceding transaction 152i is sometimes referred to as the antecedent transaction or preceding element transaction.

[0022] The input to the current transaction 152j also includes input authorization, for example, the signature of user 103a, which locks the output of the preceding transaction 152i. Now, the output of the current transaction 152j may be cryptographically locked to a new user or entity 103b. Thus, the current transaction 152j can transfer the amount specified in the input to the preceding transaction 152i to a new user or entity 103b as specified in the output of the current transaction 152j. In some cases, transaction 152 may have multiple outputs to divide the input amount among multiple users or entities (one of which may be the original user or entity 103a for making change). In some cases, the transaction may also have multiple inputs to collect amounts from multiple outputs of one or more preceding transactions and to redistribute one or more outputs of the current transaction.

[0023] According to output-based transaction protocols such as Bitcoin, when a party 103, such as an individual user or organization, wishes to formulate a new transaction 152j (either manually or through an automated process employed by the party), the formulating party sends the new transaction from its computer terminal 102 to the recipient. The formulating party or recipient then sends this transaction to one or more blockchain nodes 104 of the network 106 (which are generally servers or data centers today, but in principle could be other user terminals). It is not ruled out that the party 103 formulating the new transaction 152j may send the transaction directly to one or more blockchain nodes 104, and in some examples, may not send it to the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applicable to each blockchain node 104. A blockchain node protocol typically requires blockchain node 104 to check that the cryptographic signature in a new transaction 152j is consistent with the expected signature, which depends on the preceding transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may involve checking that the cryptographic signature or other authorization of party 103, included in the input of the new transaction 152j, is consistent with a condition specified in the output of the preceding transaction 152i, which the new transaction assigns, and this condition typically involves checking that the cryptographic signature or other authorization in the input of the new transaction 152j unlocks the output of the preceding transaction 152i to which the input of the new transaction is linked. This condition may be specified, at least in part, by a script included in the output of the preceding transaction 152i.Alternatively, it can be fixed simply by the blockchain node protocol alone, or by a combination thereof. In either case, if the new transaction 152j is valid, blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol and thus forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0024] In the output-based model, whether a given output (e.g., UTXO) is allocated (e.g., consumed) is determined by whether it has already been validly redeemed according to the blockchain node protocol by the input of another transaction 152j located ahead of it. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not already been redeemed by another transaction. Again, if invalid, transaction 152j is not propagated (unless flagged as invalid and propagated for warning) or recorded in blockchain 150. This protects against double consumption, where a trader attempts to allocate the output of the same transaction more than once. The account-based model, on the other hand, protects against double consumption by maintaining account balances. Again, because there is a defined order of transactions, at any one time the account balance has a defined single state.

[0025] In addition to activating transactions, blockchain node 104 also competes to be the first to create a block of transactions in a process usually called mining, which is supported by "proof of work". At blockchain node 104, the new transaction is added to an ordered pool 154 of valid transactions that have not yet appeared in block 151 to be recorded on blockchain 150. The blockchain node then competes to assemble a new valid block 151 of transaction 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves concatenating and hashing a nonce to the representation of the ordered pool of pending transactions 154, and then searching for a "nonce" value such that the output of the hash satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash has leading zeros to some predetermined number. Note that this is just one particular type of proof of work puzzle, and other types are not excluded. A characteristic of hash functions is that they have an output that is unpredictable with respect to their inputs. Therefore, this search can only be performed by brute force, and thus consumes a considerable amount of processing resources on each blockchain node 104 attempting to solve the puzzle.

[0026] The first blockchain node 104, which is to solve the puzzle, notifies the network 106 of this and provides the solution as proof, which can then be easily checked by other blockchain nodes 104 in the network (once the solution is given to the hash, it is easy to check that the solution satisfies the conditions in the hash output). The first blockchain node 104 accepts the block and thus propagates it to the threshold consensus of the other nodes that enforce the protocol rules. An ordered set of transactions 154 is then recorded in blockchain 150 as a new block 151 by each of the blockchain nodes 104. A block pointer 155 is also assigned so that the new block 151n points back to previously created blocks 151n-1 in the chain. A significant amount of effort, for example taking the form of a hash, required to create a proof-of-work solution signals the intention of the first node 104 to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it assigns the same output as a previously validated transaction, otherwise known as double consumption. Once created, block 151 cannot be modified as it is recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on block 151. Since each blockchain node 104 in the network 106 records transactions 152 in an ordered block, this thus provides an immutable public ledger of transactions.

[0027] It should be noted that different blockchain nodes 104 competing to solve the puzzle at any given time may be doing so based on different snapshots of the pool of unissued transactions 154 at any given time, depending on when they began searching for the solution or the order in which the transactions were received. Whoever solves each of those puzzles first will determine which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unissued transactions 154 will be updated. The blockchain nodes 104 then continue to compete to create a block from the newly defined ordered pool of unissued transactions 154, and so on. There also exists a protocol to resolve any possible "fork" that may occur, which is when two blockchain nodes 104 solve those puzzles within a very short time of each other, and as a result, conflicting views of the blockchain are propagated between the nodes 104. In short, any prong of the fork that stretches the longest will become the final blockchain 150. Please note that since the same transaction appears in both forks, this should not affect any network users or agents.

[0028] According to the Bitcoin blockchain (and most other blockchains), a node successfully constructing a new block 104 is given the ability to allocate the accepted additional amount of digital assets into a new special type of transaction that distributes a specified additional quantity of digital assets (as opposed to inter-agent or inter-user transactions, which transfer a certain amount of digital assets from one agent or user to another). This special type of transaction is usually called a "coinbase transaction," but may also be called an "initiation transaction" or "generation transaction." It typically forms the first transaction of a new block 151n. To comply with protocol rules that allow this special transaction to be redeemed later, proof of work signals the intention of the node constructing the new block. Blockchain protocol rules may require a redemption period, for example, 100 blocks, before this special transaction can be redeemed. Often, a regular (non-generating) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was issued. This fee is commonly referred to as the "transaction fee" and is described below.

[0029] Due to the resource requirements for transaction activation and issuance, generally, at least each of the blockchain nodes 104 takes the form of a server comprising one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 can take the form of a networked set of user terminals or a group of user terminals.

[0030] The memory of each blockchain node 104 stores software configured to run on the processing unit of the blockchain node 104 in order to perform one or more of its respective roles and process transactions 152 in accordance with the blockchain node protocol. It will be understood herein that any action that is said to be in the blockchain node 104 may be performed by software running on the processing unit of each computer device. The node software may be implemented in one or more applications in the application layer, or in lower layers such as the operating system layer or protocol layer, or in any combination thereof.

[0031] Each computer device 102 of multiple parties 103 in the role of consuming users is also connected to the network 101. These users may interact with the blockchain network 106 but do not participate in activating transactions or building blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some parties may act as storage entities that store copies of the blockchain 150 (e.g., they obtain a copy of the blockchain from a blockchain node 104).

[0032] Some or all of Party 103 may be connected as part of a different network, for example, a network superimposed on top of the blockchain network 106. Users of the blockchain network (often called “clients”) may be said to be part of the system including the blockchain network 106, but these users are not blockchain nodes 104 as they do not perform the required roles of blockchain nodes. Instead, each Party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to (i.e., communicating with) the blockchain nodes 106. Two parties 103 and their respective devices 102, namely, the first party 103a and its respective computer device 102a, and the second party 103b and its respective computer device 102b, are illustrated for illustrative purposes. There may be many more such parties 103 and their respective computer devices 102 participating in the system 100, but for convenience, it will be understood that they are not illustrated. Each Party 103 may be an individual or an organization. For purely illustrative purposes, the first party 103a is referred to as Alice and the second party 103b as Bob, but it should be understood that this is not limiting, and any reference in this specification to Alice or Bob may be replaced with “first party” and “second party,” respectively.

[0033] Each computer device 102 of Party 103 comprises one or more processors, for example, one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. Each computer device 102 of Party 103 further comprises memory, i.e., computer-readable storage in the form of one or more non-temporary computer-readable media. This memory may comprise one or more memory units employing one or more memory media, for example, magnetic media such as hard disks, SSDs, flash memory, or electronic media such as EEPROMs, and / or optical media such as optical disc drives. The memory on each computer device 102 of Party 103 stores software comprising at least one instance of a client application 105 configured to run on the processing unit. It will be understood that any action deemed to be in a given Party 103 herein may be performed using software running on the processing unit of each computer device 102. Each computer device 102 of Party 103 comprises at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computer equipment 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources, which are accessed via a user terminal.

[0034] The client application 105 may first be provided to any given party 103's computer equipment 102 on one or more suitable computer-readable storage media, for example, by downloading from a server, or by being installed on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or removable optical drive.

[0035] The client application 105 has at least a “wallet” function. It has two main functions. One of these is to enable each party 103 to create, authorize (e.g., sign) and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated across the entire network of blockchain nodes 104 and thereby included in blockchain 150. The other is to report back to each party the amount of digital assets that person currently owns. In an output-based system, this second function comprises matching the amounts specified in the outputs of various transactions 152 scattered across the entire blockchain 150 belonging to the party in question.

[0036] Note: While various client functionalities may be described as being integrated into a given client application 105, this is not necessarily limited. Instead, any client functionality described herein may instead be implemented as a pair of two or more separate applications, for example, interfaced via an API, or one being a plug-in to the other. More generally, client functionalities may be implemented at the application layer, or at lower layers such as the operating system, or any combination thereof. The following description will be based on client application 105, but it should be understood that this is not an exhaustive description.

[0037] Each instance of a client application or software 105 on each computer device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This allows the wallet function of client 105 to send transaction 152 to the network 106. Client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transaction to determine which party 103 is the recipient (or, in an embodiment, the blockchain 150 is a public mechanism that gives credit in transactions, partly through its public view, so it certainly checks the transactions of other parties in the blockchain 150). The wallet function on each computer device 102 is configured to organize and send transaction 152 according to the transaction protocol. As presented above, each blockchain node 104 runs software configured to activate transaction 152 according to the blockchain node protocol and to forward transaction 152 to propagate them throughout the blockchain network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol implements a given transaction model together with a given node protocol. The same transaction protocol is used for all transactions 152 in blockchain 150. The same node protocol is used by all nodes 104 in network 106.

[0038] When a given party 103, for example Alice, wishes to send a new transaction 152j to be included in blockchain 150, she organizes the new transaction according to the relevant transaction protocol (using the money management function in Alice's client application 105). Alice then sends transaction 152 from the client application 105 to one or more blockchain nodes 104 to which Alice is connected. For example, this could be the blockchain node 104 best connected to Alice's computer 102. When any given blockchain node 104 receives the new transaction 152j, it processes it according to the blockchain node protocol and its respective role. This involves first checking whether the newly received transaction 152j meets several conditions for being "valid," an example of which is briefly described in more detail. In some transaction protocols, the conditions for validity may be configurable on a per-transaction basis by a script contained within transaction 152. Alternatively, the conditions may simply be a built-in function of the node protocol or may be defined by a combination of the script and the node protocol.

[0039] Under the conditions that a newly received transaction 152j passes the test to be considered valid (i.e., under the conditions that it is "activated"), any blockchain node 104 that receives transaction 152j adds the newly activated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Furthermore, any blockchain node 104 that receives transaction 152j propagates the activated transaction 152 forward to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, and assuming that transaction 152j is valid, this means that it will soon propagate throughout the entire network 106.

[0040] Once allowed to enter the ordered pool of pending transactions 154 maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve the proof-of-work puzzle on the latest version of each of those pools of 154, including the new transaction 152 (it should be recalled that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools of transactions 154, but whoever gets there first will determine the set of transactions that will be included in the latest block 151. Ultimately, blockchain node 104 solves the puzzle on the portion of the ordered pool 154 that contains Alice's transaction 152j). Once proof-of-work has been done on the pool 154 containing the new transaction 152j, it immutably becomes part of one of the blocks 151 in blockchain 150. Each transaction 152 has a pointer back to an earlier transaction, and thus the order of transactions is also immutably recorded.

[0041] Different blockchain nodes 104 may initially receive different instances of a given transaction, and therefore have conflicting views on which instance is "valid" before one instance is issued in a new block 151, and in this regard, all blockchain nodes 104 agree that the issued instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance is recorded in blockchain 150, that blockchain node 104 must accept this and discard (i.e., treat as invalid) the instance it initially accepted (i.e., the instance not issued in block 151).

[0042] Alternative types of transaction protocols operated by some blockchain networks are sometimes referred to as “account-based” protocols as part of account-based transaction models. In account-based examples, each transaction specifies the amount to be transferred not by referencing the UTXO of a preceding transaction in a sequence of past transactions, but rather by referencing the complete account balance. The current state of all accounts is stored and constantly updated by nodes of that network, separate from the blockchain. In such a system, transactions are ordered using the transactional account (also called “position”) in which the account is operating. This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be signed by the transaction. This data field may point back to a previous transaction, for example, if a previous transaction ID is included in that data field.

[0043] 2. UTXO-based models Figure 2 illustrates an exemplary transaction protocol, which is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of blockchain 150 (each block 151 contains one or more transactions 152). The following will be described by reference to output-based or "UTXO"-based protocols. However, this is not necessarily limited to all possible embodiments. While the exemplary UTXO-based protocol is described with reference to Bitcoin, it should be noted that it may be equally applicable to other exemplary blockchain networks.

[0044] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may have an unspent transaction output (UTXO) that can be used as a source for the input 202 of another new transaction (if the UTXO has not already been redeemed). The UTXO contains a value that specifies a digital asset of a certain amount. This represents a set number of tokens on the distributed ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which the UTXO originated. The transaction data structure may also comprise a header 201, which may comprise an indicator of the size of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0045] For example, Alice 103a wants to create transaction 152j to transfer a certain amount of digital asset to Bob 103b. In Figure 2, Alice's new transaction 152j is labeled "Tx1". It takes a certain amount of digital asset locked in Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least some of this to Bob. In Figure 2, the preceding transaction 152i is labeled "Tx0". Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in blockchain 151, or that Tx1 is the next transaction in pool 154. Tx1 could point back to any preceding (i.e., predecessor) transaction that still has the unspent output 203 locked in Alice.

[0046] At the time Alice creates her new transaction Tx1, or at least by the time Alice sends it to network 106, a preceding transaction Tx0 may already be active and included in block 151 of blockchain 150. At that time, the preceding transaction Tx0 may already be included in one of the blocks 151, or it may still be waiting in an ordered set 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and sent together to network 106, or, if the node protocol allows buffering of “orphan” transactions, Tx0 may even be sent after Tx1. As used herein in the context of transaction sequences, the terms “preceding” and “subsequent” refer to the order of transactions in a sequence, as defined by transaction pointers specified within the transactions (e.g., which transactions point back to which others). These may be equivalent to “predecessor” and “successor,” or “predecessor” and “descendant,” “parent” and “child,” etc. This does not necessarily imply the order in which they are created, sent to network 106, or arrive at any given blockchain node 104. However, a subsequent transaction (descendant transaction or “child”) pointing to a preceding transaction (predecessor transaction or “parent”) will not be activated until the parent transaction is activated, and unless the parent transaction is activated. A child that arrives at blockchain node 104 before its parent is considered an orphan. Depending on the node protocol and / or node behavior, orphans may be discarded or buffered for some time to wait for their parent.

[0047] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO, which is here labeled UTXO0. Each UTXO contains a value specifying a digital asset of a certain amount represented by the UTXO, and a lock script that specifies the conditions that must be met by the unlock script in the input 202 of the subsequent transaction for the subsequent transaction to be activated, and therefore for the UTXO to be successfully redeemed. Typically, the lock script locks the amount to a specific party (the beneficiary of the transaction in which it is contained). That is, the lock script typically specifies unlock conditions, which include the condition that the unlock script in the input of the subsequent transaction contains the cryptographic signature of the party to which the preceding transaction is locked.

[0048] A lock script (also called scriptPubKey) is a snippet of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (uppercase S) used by blockchain networks. The lock script specifies what information is needed to consume transaction output 203, for example, the requirement for Alice's signature. The unlock script appears in the output of the transaction. The unlock script (also called scriptSig) is a snippet of code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. The unlock script appears in the input 202 of the transaction.

[0049] Therefore, in the illustrated example, UTXO0 in output 203 of Tx0 is signed by Alice Sig P for UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem UTXO0 to be valid). A Lock script that requires [Checksig P A [Equipped with] [Checksig P Ais the public key P from Alice's public - private key pair A and includes the notation (i.e., hash) of A . The input 202 of Tx1 includes a pointer that points back to Tx1 (e.g., in an embodiment, the transaction ID of it, TxID0, which is the hash of the entire transaction Tx0). The input 202 of Tx1 includes an index that identifies UTXO0 within Tx0 to distinguish it among any other possible outputs of Tx0. The input 202 of Tx1 includes an unlock script <Sig P A > that includes Alice's cryptographic signature created by applying Alice's private key from the key pair to a predefined part of the data (which may be called "message" in cryptography). The data (i.e., "message") that needs to be signed by Alice to provide a valid signature may be defined by the lock script, or by the node protocol, or by a combination of these.

[0050] When a new transaction Tx1 arrives at the blockchain node 104, the node applies the node protocol. This involves operating the lock script and the unlock script together to check whether the unlock script satisfies the conditions defined in the lock script (where this condition may have one or more criteria). In an embodiment, this involves concatenating the two scripts, i.e., <Sig P A > <P A > || [Checksig P A where "||" represents concatenation, "<...>" means the location of data on the stack, and "[...]" is a function provided by the lock script (in this example, a stack - based language). Equivalently, instead of concatenating the scripts, the scripts may be operated one after another using a common stack. In either case, when operated together, the scripts check whether the public key P of Alice, such as that included in the lock script within the output of Tx0 A ​The unlock script in the input of Tx1 authenticates that it contains Alice's signature to sign the expected portion of the data. For this authentication to be performed, the expected portion of the data itself ("message") must also be included. In this embodiment, the signed data comprises the entirety of Tx1 (therefore, a separate element specifying the signed portion of the data in plaintext does not need to be included, as it already essentially exists).

[0051] Details of authentication using public-secret cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message using her private key, and then Alice's public key and the message in plaintext are given, another entity, such as node 104, can authenticate that the message must be signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging it as a signature on the message, thus enabling any holder of the public key to authenticate the signature. Therefore, any reference herein to signing a particular piece of data or part of a transaction, etc., may in embodiments mean signing a hash of that piece of data or part of a transaction.

[0052] Blockchain node 104 considers Tx1 valid if the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (for example, in the illustrated example, Alice's signature is provided and authenticated in Tx1). This means that blockchain node 104 adds Tx1 to the ordered pool of pending transactions 154. Blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in network 106 so that transaction Tx1 is propagated throughout network 106. If Tx1 is valid and included in blockchain 150, this means that UTXO0 from Tx0 has been consumed. Note that Tx1 can only be valid if it consumes an unconsumed transaction output 203. If Tx1 attempts to consume an output that has already been consumed by another transaction 152, Tx1 becomes invalid, even if all other conditions are met. Therefore, blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been consumed (i.e., whether it has already formed a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a prescribed order on transaction 152. In practice, a given blockchain node 104 could maintain a separate database marking which UTXO 203 in which transaction 152 has been consumed, but ultimately, what determines whether a UTXO has been consumed is whether it has already formed a valid input to another valid transaction in blockchain 150.

[0053] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this is another ground for invalidity in most transaction models. Therefore, such a transaction will neither propagate nor be included in block 151.

[0054] In a UTXO-based transaction model, it should be noted that a given UTXO must be consumed as a whole. A UTXO cannot "leave behind" a portion of the amount it specifies, with another small portion being consumed. However, the amount from a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount specified in UTXO0 within Tx0 can be split among multiple UTXOs within Tx1. Therefore, if Alice does not wish to give Bob the entire amount specified in UTXO0, she can use the remainder in the second output of Tx1 to give herself change or to pay another party.

[0055] In practice, Alice also needs to include a fee for the Bitcoin node 104 to successfully include Alice's transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain node 104 and, therefore, although technically valid, may not be propagated and may not be included in blockchain 150 (the node protocol does not force blockchain node 104 to accept transaction 152 if they do not wish it to). In some protocols, the transaction fee does not require its own separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount pointed to by input 202 and the total amount specified in the output 203 of a given transaction 152 is automatically given to blockchain node 104 issuing the transaction. For example, a pointer to UTXO0 is only an input to Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by node 104, which wins the proof-of-work competition to create the block containing UTXO1. However, as an alternative or addition, it is not necessarily excluded that a transaction fee may be explicitly specified within one of the UTXO203 of transaction 152.

[0056] Alice and Bob's digital assets consist of UTXOs locked to them in any transaction 152 somewhere within blockchain 150. Therefore, typically, the assets of a given party 103 are scattered across the entire blockchain 150, encompassing a total of UTXOs from various transactions 152. There is no single number stored anywhere in blockchain 150 that defines the total balance of a given party 103. It is the role of the money management function in the client application 105 to match the values ​​of all the various UTXOs locked to each party and not yet consumed in other transactions located ahead. This can be done by querying copies of blockchain 150, such as those stored in one of the Bitcoin nodes 104.

[0057] It should be noted that script code is often expressed in a general way (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. For example, OP_RETURN is a Script language opcode that, when preceded by OP_FALSE at the beginning of a lock script, creates an immutable output of a transaction that can store data within the transaction, thereby immutably recording the data in blockchain 150. For example, the data may consist of documents that are desired to be stored in the blockchain.

[0058] Typically, the input to a transaction is the public key P AThis includes a corresponding digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific fragment of data. In some embodiments, for a given transaction, the signature signs a portion of the transaction input and some or all of the transaction output. Which particular portion of the output it signs depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature to select which output is signed (and therefore fixed at the time of signing).

[0059] A lock script is sometimes called a “scriptPubKey,” referring to the fact that it typically contains the public key of the party to which each transaction is locked. An unlock script is sometimes called a “scriptSig,” referring to the fact that it typically supplies the corresponding signature. However, more generally, in all applications of Blockchain 150, the condition for a UTXO to be redeemed does not necessarily involve authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms “lock script” and “unlock script” may be preferred.

[0060] 3. Side Channel As shown in Figure 1, the client applications on Alice's and Bob's computer devices 102a and 120b, respectively, may each have additional communication functionality. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (instigated by either a party or a third party). The side channel 107 allows for the exchange of data independently of the blockchain network. Such communication is sometimes called “off-chain” communication. For example, it may be used to exchange transaction 152 between Alice and Bob without the transaction being (still) registered on the blockchain network 106 or progressing onto chain 150 until one of the parties chooses to broadcast it to network 106. Sharing a transaction in this manner is sometimes called sharing a “transaction template.” A transaction template may not have one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or periods, data content, etc.

[0061] Side channel 107 may be established via the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, side channel 301 may be established via a variety of networks, such as a mobile cellular network, a local area network such as a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. Generally, side channel 107 as referred to anywhere in this specification may be “off-chain,” that is, it may have any one or more links via one or more networking technologies or communication media for exchanging data separately from the blockchain network 106. If two or more links are used, the bundle or collection of off-chain links as a whole may be referred to as side channel 107. Therefore, when it is said that Alice and Bob exchange several fragments of information or data via side channel 107, this does not necessarily imply that all these fragments of data must be sent via the exact same link or the same type of network.

[0062] 4. Client Software Figure 3A shows an exemplary implementation of a client application 105 for implementing an embodiment of the scheme of this disclosure. The client application 105 comprises a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to perform lower-level transaction-related functionalities of the client 105, such as organizing transactions 152, receiving and / or sending transactions and / or other data via side channels 301, and / or sending transactions to one or more nodes 104 to be propagated through the blockchain network 106, as will be briefly described in more detail in accordance with the scheme described above. According to the embodiments disclosed herein, the transaction engine 401 of each client 105 comprises functions 403, etc.

[0063] The UI layer 402 is configured to render a user interface via the user input / output (I / O) means of each user's computer device 102, including outputting information to each user 103 via the user output means of the device 102 and receiving input back from each user 103 via the user input means of the device 102. For example, the user output means may include one or more display screens (touchscreen or non-touchscreen) for providing visual output, one or more speakers for providing acoustic output, and / or one or more haptic output devices for providing haptic output. The user input means may include, for example, one or more touchscreen input arrays (same as or different from those used for the output means), one or more cursor-based devices such as a mouse, trackpad, or trackball, one or more microphones and speech or utterance recognition algorithms for receiving voice or utterance input, one or more gesture-based input devices for receiving input in the form of hand or body gestures, or one or more mechanical buttons, switches, or joysticks.

[0064] Note: While various functionalities described herein may be described as being integrated within the same client application 105, this is not necessarily limiting. Instead, they can be implemented as a pair of two or more separate applications, for example, one of which may be a plug-in to the other, or interfaced via an API (Application Programming Interface). For example, the functionality of the transaction engine 401 may be implemented in an application separate from the UI layer 402, or the functionality of a given module such as the transaction engine 401 may be divided among two or more applications. It is also not excluded that some or all of the functionalities described may be implemented, for example, at the operating system layer. Wherever a reference is made herein to a single or given application 105, this is merely an example, and it should be understood that, more generally, the functionalities described may be implemented in any form of software.

[0065] Figure 3B provides a mockup of an example UI 500 that may be rendered by the user interface (UI) layer 402 of the client application 105a on Alice's device 102a. It will be understood that a similar UI may be rendered by client 105b on Bob's device 102b or by any other party's client.

[0066] As an example, Figure 3B shows UI500 from Alice's perspective. UI500 may comprise one or more UI elements 501, 502, 502 rendered as separate UI elements via a user output means.

[0067] For example, the UI elements may comprise one or more user-selectable elements 501, which may be different on-screen buttons or different options in a menu. User input means are arranged to allow user 103 (in this case, Alice 103a) to select or otherwise manipulate one of the options by clicking or touching the UI elements on the screen or by speaking the name of the desired option (note that the term “manually” as used herein is intended merely to contrast with “automatic” and is not necessarily limited to the use of one or more hands). The option enables the user (Alice) to do what.

[0068] Alternatively or additionally, a UI element may comprise one or more data entry fields 502 through which a user can interact. These data entry fields may be rendered, for example, on a screen, via a user output means, and data may be entered into the fields via a user input means, such as a keyboard or touchscreen. Alternatively, data may be received orally, for example, based on speech recognition.

[0069] Alternatively or additionally, a UI element may have one or more information element outputs for outputting information to the user. For example, these may be rendered on the screen or audibly.

[0070] It will be understood that rendering various UI elements, selecting options, and entering data are not the materials themselves. The functionality of these UI elements will be explained in more detail and briefly. It will also be understood that UI500 shown in Figure 3 is merely a diagrammatic mockup, and that in reality, it may have one or more additional UI elements that are not shown for the sake of brevity.

[0071] 5. Node Software Figure 4 shows an example of node software 450 running on each blockchain node 104 of network 106 in an example of a UTXO or output-based model. Note that another entity may run the node software 450 without being classified as a node 104 on network 106, i.e., without performing the actions required of node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level determination engine 454, and a set of one or more blockchain-related functional modules 455. Each node 104 may run node software that includes, but is not limited to, all three: a consensus module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., database). The protocol engine 401 is typically configured to recognize various fields of transaction 152 and process them according to the node protocol. j ) is preceded by another transaction 152i (Tx m-1 When it is received with an input pointing to the output of (for example, UTXO), the protocol engine 451 will j Identify the unlock script within and pass it to script engine 452. Protocol engine 451 also handles Tx j Based on the pointer in the input, Tx i Identify and extract Tx i It may be issued on blockchain 150, in which case the protocol engine will take a copy of block 151 of blockchain 150 stored at node 104 and send a transaction. i You may extract it. Alternatively, Tx i It may not have been issued on blockchain 150 yet. In that case, the protocol engine 451 will extract the Tx from an ordered set of unissued transactions 154 maintained by node 104. i You can extract it. In any case, script engine 451 is Txi Identify the lock script within the referenced output and pass it to script engine 452.

[0072] Therefore, script engine 452 is Tx i The lock script, and Tx j It has a lock-release script from the corresponding input. For example, transactions labeled Tx0 and Tx1 are shown in Figure 2, but the same can be applied to any pair of transactions. The script engine 452 makes the two scripts work together as previously described, which involves placing data on the stack 453 and taking data from the stack 453, according to the stack-based scripting language being used (e.g., Script).

[0073] By running the scripts together, the script engine 452 determines whether the unlock script satisfies one or more criteria specified in the lock script—that is, whether the output contained within the lock script "unlocks" it. The script engine 452 returns the result of this decision to the protocol engine 451. If the script engine 452 determines that the unlock script satisfies one or more criteria specified in the corresponding lock script, it returns the result "true". Otherwise, the script engine 452 returns the result "false".

[0074] In output-based models, the result "true" from script engine 452 is one of the conditions for transaction validity. Typically, Tx j The total value of digital assets specified in the output of does not exceed the total value indicated by its input, and Tx iThere are also one or more further protocol-level conditions, which must also be satisfied and are evaluated by the protocol engine 451, such as that the output pointed to has not already been consumed by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 together with one or more protocol-level conditions, and only if they are all true does transaction Tx j Enable it. The protocol engine 451 outputs to the application level determination engine 454 whether the transaction is valid. Tx j Only under the condition that it is indeed enabled, the decision engine 454 will Tx j You may choose to control both the consensus module 455C and the propagation module 455P to perform their respective blockchain-related functions. This means that the consensus module 455C will send the Tx to each ordered set of nodes in order to incorporate it into block 151. j Adding the propagation module 455P to another blockchain node 104 in network 106, Tx j The system includes forwarding the transaction. Optionally, in the embodiment, the application-level decision engine 454 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may choose to issue a transaction only if both conditions are met: the transaction is valid and there is sufficient funds remaining for the transaction charges.

[0075] It should be noted that the terms “true” and “false” as used herein are not necessarily limited to returning results expressed solely as a single binary digit (bit), although this is certainly one possible implementation. More generally, “true” can refer to any state indicating a successful or positive outcome, and “false” can refer to any state indicating a failed or negative outcome. For example, in an account-based model, a “true” outcome might be indicated by a combination of implicit protocol-level activation of a signature and an additional positive output from a smart contract (if both individual outcomes are true, the overall outcome is considered to signal true).

[0076] 6. Core Blockchain Examples This section describes an example of a core (i.e., first-tier) blockchain that can be used as a carrier for a secondary data chain according to embodiments of the present invention. Note that these examples are for illustrative purposes only.

[0077] 6.1 Core Transactions A transaction is a message with inputs and outputs, typically used to transfer ownership or control of a certain amount of digital assets from one set of addresses to another.

[0078] The example fields correspond to the following information. • Version: A 4-byte integer with no functions or constraints on its value. • Input: An array of transaction inputs, each having the following subfields. Output point: A structure that identifies a UTXO being consumed, comprising the following: • TxID: A 32-byte transaction identifier (TxID) for a UTXO that is being consumed. • Index: A 4-byte output index n for the UTXO being consumed. 〇 Unlock Script: A script that enables coin consumption when combined with the lock script for input. nSeq: A 4-byte integer that defaults to 0xFFFFFFFF. A value smaller than this default (maximum) indicates that this transaction does not have to be final and may be replaced by a transaction that consumes the same input but has a larger sequence number. A transaction is considered final when all sequence numbers are set to the maximum or when the lock time is reached. • Output: An array of transaction outputs, each having the following subfields. ○Value: An 8-byte integer indicating the output value (in Satoshi units). 〇 Lock Script: A lock script that contains conditions that must be met in order to spend coins. • Lock time: A 4-byte integer that defaults to 0. Values ​​greater than 0 impose a delay and indicate the earliest time a transaction may be included in a block, either by the block height (if the value < 500,000,000) or by UNIX time.

[0079] 6.2 Data Output Within a core blockchain transaction, one or more outputs may include one or more opcodes that enable the inclusion of a data payload within the output. For example, the OP_RETURN code may be followed by some data (in string form). The opcode is placed at the end of the unlock script, which allows the transaction to act as a data carrier without interrupting the signature validation process. When a data transaction is issued on the blockchain, there exists an immutable record of the data to be embedded within the output. The OP_RETURN code may be preceded by OP_FALSE(0), which represents a UTXO created by a non-consumable output (i.e., not requiring to be remembered by the complete node in the UTXO set), or it may be used without OP_FALSE to create a consumable UTXO. Other opcodes, such as OP_PUSH and OP_DROP, may be used to place data within the output.

[0080] 6.3 Core Block A block is a data structure that includes a set of transactions and several additional fields related to how blocks are appended to the longest chain (i.e., the chain with the most proof-of-work). The fields of an example block are as follows: • Block header: A structure that provides information about how and when a block was mined, as well as what the block contains. It consists of the following six subfields: Version: A 4-byte integer indicating the set of protocol rules used for block activation. 〇 Hash of the previous block header: The 32-byte SHA-256 double hash of the previous block header. ○ Merkle Root: A 32-byte SHA-256 double hash derived from the transaction's Merkle tree. Timestamp: A 4-byte integer encoding the Unix time when the block producer generated the header. 〇Hard Target: A 4-byte integer that encodes the hardness of the target required for a block to be mined. Nonce: A 4-byte integer chosen to achieve the required hardness of the block header hash. • Transaction: A structure that details transactions within a block. It includes the following: Transaction count: A variable-length integer indicating the number of transactions contained within a block. Transaction List: A structure containing transaction data for a complete list of transactions included in a block. The first transaction in this list is always a coinbase transaction (see below).

[0081] 7. Tiered Consensus Figure 5 shows an exemplary system 500 for implementing a multilevel (ML) blockchain protocol. System 500 may comprise one or more entities configured to submit data blocks to an ML block producer 501. For example, system 500 may comprise one or more users, e.g., Alice 103a and Bob 103b, each configured to generate and submit data blocks to the ML block producer. It will be understood that system 500 may comprise any number of users. It should also be noted that entities configured to submit data blocks to the ML block producer 501 do not need to be users in the sense of a human operating a device. That is, one or more such entities may be a machine, a smart contract, etc. The ML block producer 501 is configured to receive and / or generate data blocks and generate ML blocks, i.e., core blockchain transactions. The ML block producer 501 is also configured to submit ML blocks to the core blockchain network 106. The ML block producer 501 may be a blockchain node 104 of the core blockchain network 106. That is, the ML block producer 501 may be configured to generate both ML blocks and core blockchain blocks 151. In these examples, the ML block producer may generate a core block comprising one or more ML blocks and submit that core block to the core network 106. In other examples, the ML block producer may be a simplified payment verification (SPV) client application, i.e., a client application configured to implement an SPV method. Those skilled in the art will be familiar with the SPV method. It is not excluded that the ML block producer may be a user, for example, Alice 103a. That is, user 103 may generate ML blocks and submit them to the blockchain network 106.System 500 may include multiple ML block producers 501.

[0082] The ML blockchain protocol uses core blockchain transactions to embed data chains ("secondary data chains"), for example, data associated with a secondary blockchain. The data associated with a secondary data chain (e.g., secondary blockchain transactions) is embedded within the output of core blockchain transactions, which are interpreted as blocks on the ML blockchain. The data may be encrypted. Each data block contains fragments, chunks, entries, etc., of the secondary data chain.

[0083] The ML block producer 501 is configured to generate ML blocks based on acquired (e.g., received) data blocks. That is, the ML block producer 501 is configured to construct ML blocks (core blockchain transactions), where each ML block comprises one of the acquired data blocks. The data block may be placed within the output of the ML block, for example, within the first output of the ML block. ML blocks containing chain outputs are used to chain ML blocks. The chain output may, but is not required, be the first output to appear in the ML block. In some examples, the chain output may comprise a data block. The ML block also contains a chain input that references and unlocks the chain outputs of previous ML blocks in the ML blockchain. Again, the chain output may be the first input to appear in the ML block. The chain output is configured to implement a consensus-based lock script. More details on the consensus-based lock script are provided below.

[0084] The ML block producer 501 is configured to record ML blocks on the core blockchain as core blockchain transactions. Depending on the capabilities of the ML block producer 501, this may involve including the ML block within a core block of the core blockchain. Alternatively, the ML block producer 501 may submit the ML block to one or more nodes of the core blockchain network 106.

[0085] In some examples, each ML block (i.e., core blockchain transaction) may have a flag or other such identifier that allows the block producer 501 and / or the user to identify the ML block. The flag identifier, etc., may be included in the output of the ML block (e.g., chain output). Additionally or alternatively, an ML block may have a specific version number (e.g., a 4-byte integer) that is known to be associated with the ML protocol.

[0086] Next, returning to the consensus-based locking mechanism, each chain output has a lock script configured to be unlocked by one or more of several ML block producers 501. In some examples, several ML block producers 501 may be predefined. In other examples, several ML block producers 501 may not be predefined.

[0087] The consensus mechanism of a given ML block is a function of the data blocks of the corresponding ML block. In other words, the lock script that enforces the consensus mechanism is based on the data blocks. As described above, ML blocks are chained together via chain inputs and chain outputs. That is, the chain input of the nth ML block consumes the chain output of the (n-1)th block, the chain input of the (n+1)th block consumes the chain output of the nth block, and so on. In these embodiments, the chaining of ML blocks is based on the secondary data itself. Note that "consuming" does not necessarily imply the transfer of currency or financial assets, and more generally, inputs may consume outputs (where spending is an example of consuming).

[0088] In some examples, each chain output may have a puzzle, and each chain input may have a solution to the puzzle of the chain output being consumed. The puzzle may be a proof-of-work (PoW) hash puzzle. That is, the lock script of a given chain output may be configured to execute a PoW hash puzzle. This is analogous to how some core blockchains require a PoW puzzle to be solved in order to append a new core block. The PoW hash puzzle of a given ML block is a function of the data block and target hardness of that ML block. Those skilled in the art will be familiar with the concepts of PoW hash puzzles and target hardness in essence. The target hardness may be the same for all ML blocks, or it may be changed to make solving the hash puzzle easier or harder, which affects the rate at which new ML blocks can be added to an ML chain. More specifically, the PoW hash puzzle of a given ML block is a function of the data block of that ML block, for example, a function of the data block hash (i.e., the hash of the data block). The PoW hash puzzle is configured to take the data block hash of the next ML block (i.e., the hash of the data block of the next ML block) as input from the chain input of the next ML block, combine (e.g., concatenate) the data block hash of the current ML block with the data block hash of the next ML block, and determine whether the hash of the combination satisfies an esoteric target. Depending on the particular PoW hash puzzle, this may also involve determining whether the hash of the combination is less than (or less than) an esoteric target, which is itself a number. The PoW hash puzzle is configured so that the lock script only unlocks if the esoteric target is satisfied.

[0089] In these examples, when constructing a new ML block, the ML block producer 501 must find a data block hash ("solution") that satisfies the obscurity target of the current ML block, which is set and placed within the lock script of the previous ML block when processed by the PoW puzzle of the previous ML block. To find such a solution, the ML block producer 501 may modify parts of the data block such that the obscurity target is satisfied when the data block hashes are joined and hashed. The parts of the data block to be modified may be nonce values. For example, the ML block producer 501 may iterate through a sequence of nonce values ​​until it finds a nonce value that yields a solution to the PoW hash puzzle.

[0090] This PoW consensus mechanism is similar to those used by several core blockchain networks. For example, the PoW system used in the Bitcoin blockchain requires block producers to solve a hash puzzle, and such a PoW system must find a candidate block whose block header hash is below a certain value (an obscurity target D). This type of hash puzzle can be represented in a script as follows: <BlockHeader> OP_SHA256 <D> OP_LESSTHAN

[0091] A similar script may be used to execute the PoW puzzle of the consensus mechanism described above. For each ML block, the chain input refers to the chain output (sometimes called an output point) of the previous ML block. This previous chain output has a lock script that includes a hash puzzle based on the previous secondary data block. To unlock the previous chain output, the ML block producer 501 must provide values ​​based on their current secondary data block, and satisfying that the hash puzzle placed within the previous ML block is solved by the current ML block. The following conditions in the chain output of each ML block (created at height h) guarantee the validity of the ML chain. 1. The output point is the previous ML block MLB. h-1 Refer to the chain output (i.e., UTXO). 2. The unlock script retrieves the hash of the current secondary data block, i.e., <H(DataBlock h )> It will be set to this. 3. The output is a new lock script, i.e., <H(DataBlock h )> OP_CAT OP_SHA256 < D > OP_LESSTHAN This is set, however D is the current obscure target of the secondary chain.

[0092] Using these conditions, MLB h When enabling chain output, the unlock script is MLB h-1 This is concatenated with the lock script at index 0, giving the following: <H(DataBlock h )> <H(DataBlock h-1 )> OP_CAT OP_SHA256 < D > OP_LESSTHAN

[0093] The following conditions will cause this combined script to evaluate to true: H(H(DataBlock h )||H(DataBlock h-1 )) <D

[0094] In Bitcoin's Proof-of-Work (PoW) system, for example, only the current block header is explicitly included in the validity condition. However, since each block header contains the hash of the previous block header, the relationship to previous blocks is implicitly enforced. This is also true for secondary block data, but an additional layer of chain binding is enforced via the ML protocol. In the ML protocol, the hash puzzle that builds the chain between adjacent blocks also acts as a lock script for UTXOs. It is important that each lock script puzzle has a unique value; otherwise, any value known to have a hash below the obscurity target could be used to consume a UTXO. All previous data block hashes that used the same (or more difficult) obscurity target have this property, and a malicious actor could use any of these to consume a UTXO and break the UTXO chain. To address this vulnerability, the ML protocol explicitly includes the value of the most recent secondary data block hash in each lock script. This value is unpredictable and ensures that the solution can only be found by applying hash power.

[0095] The obscure target is set according to ML protocol rules and may change as the combined hash power is poured into ML block generation. The puzzle in the script above requires two hash operations for each iteration of the PoW calculation, i.e., the current data block must be hashed, with a fixed value H(DataBlock). h-1Note that it must be concatenated with and hashed a second time. The first hash is not strictly necessary, but it reduces the size of the unlock script and therefore the ML transaction fee. If this extra hash operation is used, the secondary chain obfuscation target may also be adjusted to compensate.

[0096] As an alternative to the PoW hash puzzle described above, each ML block may include a PoW R puzzle in its chain output. The R puzzle is used to prove knowledge of the ephemeral key k used to derive the r value of the ECDSA signature, i.e., r=[R] x And so R = k·G mod n = (x, y).

[0097] Ephemeral keys are independent of public-private key pairs, but they are a crucial security parameter in ECDSA signatures. They are designed for single use to prevent the compromise of the private key. The main features of the R puzzle are as follows: 1. Allow users to use any public-private key pair when solving knowledge proofs. 2. To prevent signature forgery by someone who intends to sabotage the proof, an extra signature is usually used. 3. Present an alternative to P2PKH, i.e., a hash puzzle, within the script.

[0098] The PoW r puzzle requires consumers not only to solve the r puzzle but also to find a value (e.g., a nonce) that yields a hash value below a certain hardness target D. Following the same logic described above for how the PoW hash puzzle chains consecutive UTXOs, the PoW r puzzle facilitates checking the expression below in the script. H(H(r h ||DataBlock h )||H(r h-1 ||DataBlock h-1 )) <D

[0099] To simplify the calculation, the puzzle is created based on the r value of the ECDSA signature, but puzzles based on R may also be covered. The chain output of the ML block may have a lock script like the following: OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_2 OP_ROLL OP_CAT OP_SHA256 <H(r h ||DataBlock h )> OP_CAT OP_SHA256 <d>OP_LESSTHAN OP_VERIFY OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIG

[0100] The chain input of the following ML block (at height h+1) has the following unlock script:

[0101]

number

[0102] Signatures r This uses the required r value. P is the public key of the ML block producer. The extra signature 'sig' is based on a different r value and is added for security reasons as described above, to prevent a malicious node from forging a signature that unlocks the R puzzle without actual knowledge of the r value in signature sig=(r,s). In some examples, this extra signature is not required.

[0103] The first line of the lock script extracts 'r'. The second line constructs the left-hand side of the PoW expression. The third line checks that the conditions on the right-hand side of the PoW expression are met. The fourth line performs a signature verification check on both signatures in the unlock script.

[0104] It should be understood that the lock script above is merely one example of how a PoW r puzzle can be implemented. More generally, a PoW r puzzle has a first hash value and an obscurity target. The first hash value is the hash of the data block of the current ML block concatenated with the r value. The PoW r puzzle is configured to take the data block and signature of the next ML block as input from the chain input of the next ML block. The PoW r puzzle is configured to extract the r value from the signature, concatenate (e.g., combine) the extracted r value with the data block of the next ML block, and generate a second hash value by hashing the concatenated r value with the data block. The PoW puzzle is also configured to check that the hash of the concatenation (e.g., combine) of the first and second hash values ​​satisfies the obscurity target.

[0105] Alternative methods may be used to chain ML blocks together or to reach consensus across a chain of ML blocks. For example, a given chain output of an ML block may be locked to a public key associated with a threshold secret key. This may be enforced using a pay-to-public-key-hash (P2PKH) lock script. Each of the set of ML block producers may have a share of a threshold secret key, which requires a threshold number of ML block producers to contribute in order to generate a valid signature and thus append a new ML block to the chain. More specifically, in order to validate the chain output (and thus the ML block), a threshold number of ML block producers holding key shares must agree that the ML block is valid. Assuming that ML block producers submitting their candidate ML blocks for peer approval provide their signature shares, then a threshold scheme of 2 out of n would require approval from at least one authorized peer in the secondary network for the block to be valid. A method with a higher threshold would require approval from two or more peers to activate the ML block.

[0106] As another example, a given chain output of an ML block may have a multi-signature lock script locked on two or more of several public keys. That is, each chain output may have a multi-signature consumption condition with the requirement of two out of n, allowing a valid signature to be made by any two or more of the n private keys corresponding to the list of public keys. This means that a group of approved parties (i.e., ML block producers) can be established, where at least two of them are needed to add a linked new transaction to the UTXO chain, and therefore a new ML block to the ML chain.

[0107] Each of the consensus mechanisms described is a function of each data block contained within each ML block that contains the consensus mechanism (in the form of a lock script). This ensures that the lock script always enforces a "consensus" on the data. For example, PoW puzzles and PoW r puzzles enforced by the lock script of a previous ML block require that the hash of each data block in the current ML block be included in the chain input of that ML block. In the case of a signature-based consensus mechanism, the signature is a function of the data block. That is, a sighash flag may be used to compel the signature to sign all outputs containing data blocks (i.e., SINGLE, S|ACP, ALL, ALL|ACP), for example, all outputs (ALL, ALL|ACP). This ensures that the data block is included in the signed message (regardless of which output it is in). In the case of threshold signing, each party must sign the exact same data (using the same sighash flag) for the joining of signature shares to be valid. The sighash flag may be set to compel the signature to sign the data. In the case of a multi-signature mechanism, different sighash flags may be used, such that the lock script requires each party to use certain sighash flags when signing the data block.

[0108] Each chain output may implement a specific type of locking mechanism, differing only in certain data rather than the format or function of the lock script, i.e., the same consensus mechanism. For example, each chain output may have a lock script configured to implement the same consensus mechanism in the form of a PoW puzzle. Each PoW puzzle is unique in the sense that at least some of the data (e.g., hashes of previous block headers and the current block header) is specific to a given ML block, but the format of the lock script (e.g., opcodes) is the same. As another example, in the case of a P2PKH lock script, the format is the same, but the public key hashes contained within each lock script are different.

[0109] As described above, data blocks may contain raw data, or they may be encrypted or otherwise encoded. This may be done to conceal the raw data (e.g., if the data is secret or confidential) and / or to reduce the size of the data. One option is that the raw data (i.e., secondary data from the secondary data chain) may be hashed before being embedded in the ML block. Note that if only the hash of the secondary data is to be embedded, the user may choose to submit the hashed raw data to the ML block producer. In this way, the ML block producer can verify the data hash to be embedded into the provided hash. The hashing method reduces the memory burden on the core chain, but there is a trade-off in the ease of data retrieval, as the secondary chain data can no longer be read directly from the core chain database. Instead, the ML block producer is responsible for storing and maintaining the complete secondary data chain (e.g., in a database).

[0110] In some embodiments, the secondary data chain is a secondary blockchain, i.e., a blockchain other than the core blockchain. The secondary blockchain may be the same type of blockchain as the core blockchain (i.e., a UTXO-based blockchain) or a different type of blockchain (e.g., an account-based blockchain). In these embodiments, each data block may comprise one or more blocks of the secondary blockchain. Preferably, each data block consists of a single block of the secondary blockchain. In other examples, each data block may comprise one or more transactions of the secondary blockchain. These embodiments may bestow upon secondary blockchain data advantages associated with the core blockchain that are not present in the secondary blockchain. These advantages depend on the specific secondary blockchain but may include, among other things, faster block propagation and / or activation, lower transaction fees, data integrity, security via proof-of-work, immutability, and more.

[0111] However, it should be understood that secondary data chains can take forms other than blockchain. In general, a secondary data chain can be any data structure in which data is added, such as blocks, chunks, fragments, or entries. In some examples, a secondary data chain is a chain of application-specific data. The application may be a communication application, such as an (instant) messaging application or an email application. In other examples, the application may be a game. In other examples, the application may be an image application, such as one through which photos or other images are added to a gallery.

[0112] Regardless of the specific format of the secondary data chain, when issued on the core chain, an ML block provides a public, immutable record of the secondary data chain. Each data block embedded from the secondary chain has a unique identifier on the core chain, i.e., the block height and TxID of the ML block containing the embedded block.

[0113] In practice, an ML block producer may be a node in the core network. However, in at least some embodiments, an ML block producer may be a Simple Payment Verification (SPV) client or user. SPV clients and users may have less capability compared to blockchain nodes, for example, they may not be able to submit core blocks to the core network or activate core transactions (ML blocks) according to the core chain protocol when this would require them to access a set of UTXOs. Therefore, in these embodiments, the SPV client would need a way to periodically check the UTXO set of the core blockchain to activate core transactions. The SPV client may have a communication channel with a node for this purpose. In some examples, it is not necessary for the SPV client to activate transactions, as transactions are activated by the core node and rejected if invalid.

[0114] If the ML block producer is a user, for example, Alice, then Alice will need a way to identify the leading edge of a UTXO chain (i.e., an ML data chain) associated with a secondary data chain (e.g., a specific application), rather than accessing a UTXO set. This may be done by querying the UTXO set or by communicating with any other authorized user, i.e., a core node, for that chain.

[0115] The ML block producer can preferably identify the UTXO chain tip, i.e., the most recent valid ML block. This is easy if it is locked to a single P2PKH, as the user knows that no one else can authorize the core transaction in the UTXO chain. This is also easy for the node, as the node has a complete copy of the blockchain history (including the memory pool and UTXO set). However, for SPV clients performing PoW, or in situations where one party or subgroup within a larger group can authorize the core transaction, the SPV client may need to be aware of the UTXO chain tip and any missing preceding ML blocks, for example, if the client is offline and has not received those ML blocks. The SPV client may request the most recent ML block from the node.

[0116] 8. Conclusion As the disclosures herein are given, other variations or uses of the techniques disclosed may become apparent to those skilled in the art. The scope of this disclosure is not limited by the embodiments described herein, but is limited only by the appended claims.

[0117] For example, some of the embodiments described above have been explained in relation to a Bitcoin network 106, a Bitcoin blockchain 150, and a Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is one specific example of blockchain 150, and that the above description may be generally applicable to any blockchain. That is, the present invention is by no means limited to the Bitcoin blockchain. More generally, any above references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described properties of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104 as described above.

[0118] In a preferred embodiment of the present invention, the blockchain network 106 is a Bitcoin network, and the Bitcoin node 104 performs at least all of the described functions of creating, issuing, propagating, and storing block 151 of blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some of these functions, rather than all of them. That is, a network entity may perform the functions of propagating and / or storing blocks without creating and issuing blocks (it should be noted that these entities would not be considered nodes of the preferred Bitcoin network 106).

[0119] In other embodiments of the present invention, the blockchain network 106 does not have to be a Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or more functions, though not all, of creating, issuing, propagating, and storing blocks 151 of blockchain 150. For example, in those other blockchain networks, “node” may be used to refer to a network entity configured to create and issue blocks 151 but not to store and / or propagate those blocks 151 to other nodes.

[0120] More generally, any reference to the term “Bitcoin node” 104 above may be replaced with the term “network entity” or “network element,” such entities / elements configured to perform some or all of the roles of creating, issuing, propagating, and storing blocks. The functionality of such network entities / elements may be implemented in hardware in a similar manner to that described above with reference to blockchain nodes 104.

[0121] It should be understood that the embodiments described above are merely illustrative. More generally, methods, apparatus, or programs may be provided in accordance with any one or more of the following statements.

[0122] Statement 1. A computer implementation method that uses a multilevel (ML) blockchain protocol to reach consensus with respect to a data chain using a core blockchain, wherein the ML blockchain comprises one or more previous ML blocks, each previous ML block being a respective core blockchain transaction, comprising a) a respective data block associated with a data chain and b) a respective chain output, each chain output configured to be consumed by the respective chain input of subsequent ML blocks, and comprising a lock script configured to implement a consensus-based lock mechanism that can be unlocked by any one or more of a plurality of ML block producers, the method being executed by an ML block producer, and Retrieving the target data block associated with the data chain, The method for generating a target ML block on an ML blockchain is to provide a target ML block that is a core blockchain transaction and comprises a) a target data block and b) a target chain output, wherein the target chain output is configured to be consumed by the chain input of each subsequent ML block and comprises a lock script configured to implement each consensus-based lock mechanism, the respective consensus-based lock mechanism of each ML block comprising a target chain output which is a function of the respective data block of that ML block, and c) a target chain input which references the respective chain output of previous ML blocks and is configured to unlock the respective consensus lock mechanism of those previous ML blocks. It includes recording the target ML block onto the core blockchain.

[0123] Statement 2. The method of Statement 1, wherein each chain output of each ML block is provided with the same type of consensus-based locking mechanism.

[0124] Statement 3. The method of Statement 2, wherein each consensus-based locking mechanism comprises each proof-of-work (PoW) puzzle, each PoW puzzle comprising at least each hash of each data block and each hardened target, and the PoW puzzle is configured such that each chain input of a subsequent ML block comprises at least each hash of each data block of the subsequent ML block, and as a result, when executed, the PoW puzzle is configured such that it hashs the sum of each hash and the resulting hash value satisfies each hardened target.

[0125] Statement 4. The method of Statement 3, wherein each hash of at least each data block of a subsequent ML block comprises a hash of at least each data block of a subsequent ML block and its respective nonce value.

[0126] Statement 5. The method of Statement 4, comprising determining a target nonce value that yields a target hash value that satisfies each hard-to-solve target of the previous ML block's PoW puzzle referenced by the target chain input.

[0127] Statement 6. The method of Statement 2, wherein each consensus-based locking mechanism comprises each PoW r puzzle, each PoW r puzzle comprises each first hash value and each hardening target, each first hash value is generated by hashing the hash of at least each data block combined with each r value, where each r value is each component of a digital signature, and the PoW r puzzle is configured such that each chain input of a subsequent ML block comprises i) each hash of at least each data block of the subsequent ML block and ii) each signature using each r value, and the PoW r puzzle is configured such that, when executed, it extracts each r value from the signature and generates each second hash value by hashing the hash of at least each data block of the subsequent ML block combined with the extracted r value, and the resulting hash value satisfies each hardening target.

[0128] Statement 7. The method of Statement 6, wherein each hash of at least each data block of a subsequent ML block comprises a hash of at least each data block of the subsequent ML block and its respective nonce value.

[0129] Statement 8. The method of Statement 7, comprising determining a target nonce value that yields a target hash value that satisfies each hard target of the PoW r puzzle of the previous ML block referenced by the target chain input.

[0130] Statement 9. The method of Statement 1, wherein each consensus-based locking mechanism of each ML block comprises a multi-signature lock script locked to one or more of a predetermined set of public keys.

[0131] A multi-signature lock script may be locked on two or more of a given set of public keys.

[0132] Statement 10. The method of Statement 1, wherein each consensus-based locking mechanism of each ML block requires each signature corresponding to each threshold secret key, and at least two different signature shares produced by different ML block producers are required to generate each signature.

[0133] Statement 11. The method of any of the statements described above, wherein the chain output comprises each data block.

[0134] In some examples, any signature contained within each chain input that unlocks each chain output of a previous ML block must use a sighash flag (e.g., SINGLE, SINGLE|ACP, ALL, ALL|ACP) to sign each chain output with its respective data block.

[0135] Statement 12. In any of the methods in Statements 1-10, each data block is part of a different output compared to its respective chain output.

[0136] In some examples, any signature contained within each chain input that unlocks each chain output of a previous ML block must use the sighash flag (e.g., ALL, ALL|ACP) to sign the output with each data block.

[0137] Statement 13. The method of any statement described above, which involves recording the target ML block on the core blockchain, comprises submitting the target ML block to the core blockchain network.

[0138] Statement 14. A method of any statement described above, which involves recording the target ML block on the core blockchain, comprises submitting the core block to the core blockchain network, the core block comprising the target ML block.

[0139] Statement 15. The method of any of the statements above, wherein the acquisition of the target data block comprises receiving the target data block.

[0140] Statement 16. The method of any of the statements above, wherein the acquisition of the target data block comprises generating the target data block.

[0141] Statement 17. The target data block is encrypted in the manner of any of the statements above.

[0142] Statement 18. The method of Statement 17, wherein the target data block is encrypted using a hash function.

[0143] Statement 19. In the manner of any statement above, the data chain is a secondary blockchain, and each data block contains a blockchain transaction of the secondary blockchain.

[0144] Statement 20. One of the methods described in Statements 1 to 18, wherein each data set includes application-specific data.

[0145] For example, data related to a specific communication or messaging application, such as an email application or a social media application.

[0146] Statement 21. In any of the above statements, the ML Block Producer is a blockchain node of the core blockchain.

[0147] Statement 22. In any of the methods described in Statements 1-20, the ML Block Producer is not a blockchain node of the core blockchain.

[0148] Statement 23. In the manner of Statement 22, the ML Block Producer is a simplified payment verification client.

[0149] Statement 24. Computer equipment, A memory comprising one or more memory units, The system comprises a processing unit having one or more processing units, the memory storing code configured to run on the processing unit, and the code configured to perform any of the methods described in the preceding statements when it is on the processing unit.

[0150] Statement 25. A computer program embedded on computer-readable storage and configured to perform any of the methods described in Statements 1 through 23 when running on one or more processors. [Explanation of Symbols]

[0151] 100 Systems 101 Packet-switched network 102 Computer terminals, computer equipment 103 users, party 104 Blockchain Nodes 105 Client, Client Application 106 Peer-to-peer (P2P) networks, core blockchain networks 107 Side Channel 150 Blockchains 151 data, blocks, core blockchain blocks 152 transactions 153 Genesis Block (Gb) 154 ordered sets, ordered pools 155 Block pointers 201 Header 202 Input, Input Field 203 Output, Output Field, Unconsumed Output, Transaction Output, Unconsumed Transaction Output, UTXO 401 Transaction Engine 402 User Interface (UI) Layer 403 Function 450 node software 451 Protocol Engine 452 Script Engine 453 stacks 454 Application Level Determination Engine 455 Blockchain-related functional modules 455C Consensus Module 455P propagation module 455S Memory Module 500 User Interface (UI), System 501 User Selectable Elements, ML Block Producer 502 Data Entry Field 503 Information Element< / d>

Claims

1. A method implemented by a computer using a multilevel (ML) blockchain protocol to reach consensus on a data chain that uses a core blockchain, The ML blockchain has one or more previous ML blocks, Each previous ML block is a core blockchain transaction and comprises a) the respective data block associated with the data chain and b) the respective chain output. Each of the chain outputs is configured to be consumed by the respective chain inputs of subsequent ML blocks, and includes a lock script configured to implement a consensus-based lock mechanism that can be unlocked by any one or more of the multiple ML block producers, The above method is performed by an ML block producer, and The steps include: obtaining the target data block associated with the aforementioned data chain; A step of generating a target ML block in the aforementioned ML blockchain, The aforementioned target ML block is These are each core blockchain transactions, A step comprising: a) the target data block; b) a target chain output, the target chain output being configured to be consumed by the chain inputs of subsequent ML blocks and comprising a lock script configured to implement the respective consensus-based lock mechanism, wherein the respective consensus-based lock mechanism of each ML block is a function of the respective data block of each ML block; and c) a target chain input being configured to reference the respective chain outputs of previous ML blocks and to unlock the respective consensus-based lock mechanisms of the previous ML blocks. The steps include recording the target ML block on the core blockchain and A computer-based method comprising the following:

2. The method according to claim 1, wherein each of the chain outputs of each ML block is provided with the same type of consensus-based locking mechanism.

3. Each of the aforementioned consensus-based locking mechanisms is equipped with its own proof-of-work (PoW) puzzle, Each of the aforementioned PoW puzzles comprises at least the hash of each of the respective data blocks and each of the respective hard-to-solve targets, The method according to claim 2, wherein the PoW puzzle is configured to require that each of the chain inputs of the subsequent ML block comprises at least the respective hashes of each of the respective data blocks of the subsequent ML block, and as a result, when executed, the PoW puzzle is configured to require that the combination of the respective hashes hash and that the resulting hash value satisfies the respective hard-to-solve target.

4. The method according to claim 3, wherein the hash of at least each of the data blocks of the subsequent ML block comprises a hash of at least each of the data blocks of the subsequent ML block and their respective nonce values.

5. The method according to claim 4, further comprising the step of determining a target nonce value that yields a target hash value that satisfies each of the hard targets of the PoW puzzle of the previous ML block referenced by the target chain input.

6. Each of the aforementioned consensus-based locking mechanisms is equipped with its own PoW r puzzle, Each of the aforementioned PoW r puzzles has its own first hash value and its own hard target, Each of the aforementioned first hash values ​​is generated by hashing the hash of at least each of the aforementioned data blocks, which is combined with each of the aforementioned r values, where each of the aforementioned r values ​​is a component of the digital signature. The PoW r puzzle is configured such that each chain input of the subsequent ML block comprises i) the hash of at least each of the data blocks of the subsequent ML block and ii) each signature using the respective r values. The method according to claim 2, wherein when the PoW r puzzle is executed, it is required to extract the respective r values ​​from the signature, generate a respective second hash value by hashing the respective hashes of at least the respective data blocks of the subsequent ML block combined with the extracted r values, and the resulting hash value satisfies the respective hardness target.

7. The method according to claim 6, wherein the hash of at least each of the data blocks of the subsequent ML block comprises a hash of at least each of the data blocks of the subsequent ML block and their respective nonce values.

8. The method according to claim 7, comprising the step of determining a target nonce value that results in a target hash value that satisfies each of the hard targets of the PoW r puzzle of the previous ML block referenced by the target chain input.

9. The method according to claim 1, wherein each consensus-based locking mechanism of each ML block comprises a multi-signature lock script locked to one or more of a predetermined set of public keys.

10. Each of the consensus-based locking mechanisms in each ML block requires a signature corresponding to its respective threshold secret key. The method according to claim 1, wherein at least two different signature shares produced by different ML block producers are required to generate each of the signatures.

11. The method according to claim 1, wherein the chain output comprises the respective data blocks.

12. The method according to claim 1, wherein each of the data blocks is part of an output that is different from each of the chain outputs.

13. The method according to claim 1, wherein the step of recording the target ML block on the core blockchain comprises the step of submitting the target ML block to the core blockchain network.

14. The step of recording the target ML block on the core blockchain comprises the step of submitting the core block to the core blockchain network. The method according to claim 1, wherein the core block comprises the target ML block.

15. The method according to claim 1, wherein the step of acquiring the target data block comprises the step of receiving the target data block.

16. The method according to claim 1, wherein the step of acquiring the target data block comprises the step of generating the target data block.

17. The method according to claim 1, wherein the target data block is encrypted.

18. The method according to claim 17, wherein the target data block is encrypted using a hash function.

19. The aforementioned data chain is a secondary blockchain, The method according to claim 1, wherein each data block comprises a blockchain transaction of a secondary blockchain.

20. The method according to claim 1, wherein each of the aforementioned data blocks comprises application-specific data.

21. The method according to claim 1, wherein the ML block producer is a blockchain node of the core blockchain.

22. The method according to claim 1, wherein the ML block producer is not a blockchain node of the core blockchain.

23. The method according to claim 22, wherein the ML block producer is a simplified payment verification client.

24. Computer equipment, A memory comprising one or more memory units, A processing apparatus comprising one or more processing units A computer device comprising, wherein the memory stores code configured to run on the processing device, and the code is configured to perform the method according to any one of claims 1 to 23 when executed on the processing device.

25. A computer program embedded on computer-readable storage and configured to perform the method described in any one of claims 1 to 23 when operating on one or more processors.

Images