Smart contracts

Abstract

To provide a method implemented in a layered network.SOLUTION: A layered network 1200 comprises a core layer comprising one or more core nodes 1201, one or more intermediate layers each comprising one or more intermediate layer nodes 1202, and one or more outer layers each comprising one or more outer layer nodes 1203. Each of the core nodes is a node of a blockchain network. The intermediate layer nodes are smart contract nodes providing a smart contract service. The outer layer nodes are client nodes of the smart contract service. The method includes, by a smart contract node: recording a state of the smart contract in a record of the state maintained at the first smart contract node. In addition, at least a first transaction also recording the state is recorded on a blockchain of the blockchain network.SELECTED DRAWING: Figure 12

Description

[Technical Field]

[0001] The present disclosure relates to a method for providing smart contracts using blockchain. [Background technology]

[0002] A blockchain refers to a form of distributed data structure in which a copy of the blockchain is maintained at each of multiple nodes in a peer-to-peer (P2P) network. A blockchain comprises a chain of blocks of data, each of which comprises one or more transactions. Each transaction may point back to a previous transaction in a sequence that may span one or more blocks. Transactions may be submitted to the network for inclusion in a new block. New blocks are created by a process known as "mining," which involves multiple mining nodes each competing to perform "proof of work," i.e., solving a cryptographic puzzle based on a pool of outstanding transactions waiting to be included in a block.

[0003] Each node in the network can have any one, two, or all three roles: forwarding, mining, and storage. Forwarding nodes propagate transactions across the nodes of the network. Mining nodes mine transactions into blocks. Storage nodes each store their own unique copy of mined blocks in the blockchain. For a transaction to be recorded in the blockchain, a participant sends the transaction to one of the nodes in the network to be propagated. Mining nodes that receive a transaction may compete to mine the transaction into a new block. Each node is configured to respect the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are neither propagated nor mined into a block. Assuming the transaction is validated and thereby accepted on the blockchain, the transaction (including any user data) therefore remains stored in each of the nodes in the P2P network as an immutable public record.

[0004] Miners who successfully solve the proof-of-work puzzle to create the latest block are typically rewarded with a new transaction, called a "generation transaction," that generates a new amount of digital assets. Proof-of-work incentivizes miners not to cheat the system by including double-spend transactions in their blocks, because mining a block requires a large amount of computational resources and blocks containing attempts to double-spend are likely not accepted by other nodes.

[0005] 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. Every consumable output comprises an element, sometimes called a UTXO ("Unspent Transaction Output"), that specifies the amount of a digital asset. The output may further comprise a locking script that specifies the conditions for redeeming the output. Each input comprises a pointer to such output in a preceding transaction and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, consider a pair of transactions, referred to as a first transaction and a second transaction (or "target" transaction). The first transaction comprises at least one output that specifies the amount of a digital asset and comprises a locking script that defines one or more conditions for unlocking the output. The second target transaction comprises at least one input that comprises a pointer to an output of the first transaction and an unlocking script for unlocking the output of the first transaction.

[0006] In such a model, when a second target transaction is sent to the P2P network to be disseminated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another, earlier, valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not disseminate or include the transaction for mining into a block that will be recorded in the blockchain.

[0007] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred by referencing absolute account balances rather than by referencing the UTXO of a preceding transaction in a sequence of past transactions. The current state of all accounts is stored and periodically updated by a miner separate from the blockchain.

[0008] Traditionally, transactions on a blockchain are used to carry digital assets, i.e., a number of digital tokens. However, blockchains can also be leveraged to layer additional functionality on top of the blockchain. For example, a blockchain protocol may allow for storing additional user data in the output of a transaction. Modern blockchains have increased the maximum data capacity that can be stored in a single transaction, making it possible to incorporate more complex data. For example, this may be used to store electronic documents, or even audio or video data, on the blockchain. [Prior art documents] [Patent documents]

[0009] [Patent Document 1] WO / 2018 / 078584 Summary of the Invention [Problem to be solved by the invention]

[0010] The present disclosure provides a scheme whereby the state of a smart contract is maintained in layers of smart contract nodes layered around a core of blockchain network nodes, and where the state is also stored in the blockchain of the blockchain network. [Means for solving the problem]

[0011] According to one aspect disclosed herein, a method for maintaining the state of a smart contract in a multi-tiered network is provided. The multi-tiered network includes a core tier including one or more core nodes, one or more middle tiers each including one or more middle tier nodes, and one or more outer tiers each including one or more outer tier nodes. Each of the core nodes is a node of a blockchain network, and one or more of the middle tier nodes is a smart contract node that provides a smart contract service for maintaining the state of the smart contract, and one or more of the outer tier nodes is a client node of the smart contract service. The method includes recording, by a first of the one or more smart contract nodes, the state of the smart contract in a state record maintained at the first smart contract node. Additionally, at least a first transaction also recording the state is recorded in a blockchain of the blockchain network.

[0012] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be embodied, reference will now be made, by way of example only, to the accompanying drawings, in which: [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3] FIG. 1 is a schematic representation of an example of a layered network. [Figure 4] FIG. 10 is another schematic representation of an example of a layered network. [Figure 5] FIG. 10 is another schematic representation of an example of a layered network. [Figure 6] FIG. 10 is another schematic representation of an example of a layered network. [Figure 7] FIG. 1 illustrates a schematic diagram of an exemplary certification service implemented in a multi-tiered network. [Figure 8] FIG. 1 is a schematic transaction diagram of an exemplary transaction for recording an order of data items in a blockchain. [Figure 9] FIG. 2 is a schematic diagram of an exemplary indexed list for recording the order of a set of data items within a transaction. [Figure 10] FIG. 10 is a schematic diagram illustrating another example of an indexed list for recording the order of a set of data items within a transaction. [Figure 11] FIG. 10 is a schematic diagram illustrating another example of an indexed list for recording the order of a set of data items within a transaction. [Figure 12] FIG. 1 illustrates a schematic diagram of a system of smart contract nodes implemented at one layer of a multi-layered network. [Figure 13] FIG. 1 is a schematic diagram describing a blockchain-based DFA for zero-coupon bond contracts. [Figure 14] FIG. 1 is a schematic diagram showing a secondary state that exists in parallel with an initial state. [Figure 15] A schematic diagram of a blockchain multi-layered network (BLN) consisting of miners, smart contracts, and users at layers 1 to 3, respectively. [Figure 16] FIG. 1 shows a schematic diagram of a community of nodes connected in a BLN topology. [Figure 17] FIG. 2 is a schematic sequence diagram illustrating a first stage in an exemplary method. [Figure 18] FIG. 10 is a schematic sequence diagram illustrating a second stage in the exemplary method. [Figure 19] FIG. 10 is a schematic sequence diagram illustrating a third stage in the exemplary method. [Figure 20] FIG. 2 is a schematic transaction diagram illustrating an exemplary origin transaction. [Figure 21]1A-1C are schematic transaction diagrams illustrating an example of a partially completed trade transaction at successive stages of partial completion. [Figure 22] 1A-1C are schematic transaction diagrams illustrating an example of a partially completed trade transaction at successive stages of partial completion. [Figure 23] 1A-1C are schematic transaction diagrams illustrating an example of a partially completed trade transaction at successive stages of partial completion. [Figure 24] 1A-1C are schematic transaction diagrams illustrating an example of a partially completed trade transaction at successive stages of partial completion. [Figure 25] FIG. 1 is a schematic transaction diagram illustrating an example of a completed trade transaction. [Figure 26] FIG. 1 is a schematic transaction diagram illustrating an example of a transition transaction. [Figure 27] FIG. 1 is a schematic transaction diagram showing an example of a completed transaction. [Figure 28] FIG. 1 is a schematic transaction diagram illustrating an example UTXO set revocation transaction. DETAILED DESCRIPTION OF THE INVENTION

[0014] Exemplary System Overview FIG. 1 illustrates an exemplary system 100 for implementing a blockchain 150. The system 100 comprises a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 comprises a plurality of nodes 104 configured to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 of the blockchain network 106 comprises a peer's computing equipment, with different ones of the nodes 104 belonging to different peers. Each node 104 comprises a processing unit comprising one or more processors, e.g., one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). Each node also comprises memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may comprise one or more memory units utilizing one or more memory media, e.g., magnetic media such as a hard disk, electronic media such as a solid-state drive (SSD), flash memory or EEPROM, and / or optical media such as an optical disk drive.

[0015] The blockchain 150 comprises a chain of blocks of data 151, with a respective copy of the blockchain 150 maintained at each of multiple nodes in the P2P network 106. 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 the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain typically uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 comprises at least one input and at least one output. Each output specifies an amount representing the amount of digital assets belonging to the user 103 to whom the output is cryptographically locked (requiring that user's signature to be unlocked and thereby redeemed or spent). Each input points back to the output of the previous transaction 152, thereby linking those transactions.

[0016] At least some of the nodes 104 take on the role of transfer nodes 104F, which forward and thereby disseminate transactions 152. At least some of the nodes 104 take on the role of miners 104M, which mine blocks 151. At least some of the nodes 104 take on the role of storage nodes 104S (sometimes called "full copy" nodes), each of which stores a respective copy of the same blockchain 150 in its respective memory. Each miner node 104M also maintains a pool 154 of transactions 152 waiting to be mined into blocks 151. A given node 104 may be a transfer node 104F, a miner 104M, a storage node 104S, or any combination of two or all of these.

[0017] For a given current transaction 152j, the input (or each input) comprises a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed, or "spent," in the current transaction 152j. In general, the preceding transaction can be any transaction in the pool 154 or any block 151. The preceding transaction 152i does not necessarily have to exist at the time the current transaction 152j is created or even sent to the network 106, but the preceding transaction 152i must exist and be validated for the current transaction to be valid. Thus, "preceding" herein refers to something that precedes in the logical sequence linked by the pointer, not necessarily to the time of creation or transmission in the temporal sequence, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out of order (see the discussion of orphan transactions below). The preceding transaction 152i may also be referred to as an ancestor transaction or predecessor transaction.

[0018] The input of the current transaction 152j also comprises the signature of the user 103a to which the output of the preceding transaction 152i is locked. The output of the current transaction 152j can then be cryptographically locked to the new user 103b. Thus, the current transaction 152j can transfer an amount defined in the input of the preceding transaction 152i to the new user 103b as defined in the output of the current transaction 152j. In some cases, a transaction 152j may have multiple outputs to divide the input amount among multiple users (one of whom may be the original user 103a to provide change). In some cases, a transaction may also have multiple inputs to pool together amounts from multiple outputs of one or more preceding transactions and redistribute them into one or more outputs of the current transaction.

[0019] The above is called an "output-based" transaction protocol, sometimes also called an Unspent Transaction Output (UTXO) type protocol (where the outputs are called UTXOs). A user's total balance is not defined by any one number stored in the blockchain; instead, the user needs a special "wallet" application 105 to collate the values ​​of all of their UTXOs, which are scattered across many different transactions 152 in the blockchain 151.

[0020] An alternative type of transaction protocol is sometimes called an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, rather than by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of every account is stored by miners separately from the blockchain and updated periodically. In such a system, transactions are ordered using the account's running transaction tally (also called "position"). This value is signed by the sender as part of the sender's cryptographic signature and hashed as part of the transaction reference calculation. In addition, an optional data field may also be present in the signed transaction. This data field may point back to a previous transaction, for example, if a previous transaction ID is included in the data field.

[0021] In either type of model, when a user 103 wants to execute a new transaction 152j, he sends the new transaction from his computer terminal 102 to one of the nodes 104 (which today are usually servers or data centers, but could in principle be other user terminals) of the P2P validation network 106. This node 104 verifies whether the transaction is valid according to a node protocol that applies to each of the nodes 104.

[0022] The details of the node protocol correspond to the type of transaction protocol used in the blockchain 150 in question, which together form the overall transaction model. The node protocol typically requires the node 104 to verify that the cryptographic signature in a new transaction 152 j matches an expected signature, which depends on the previous transaction 152 i in the ordered sequence of transactions 152. If output-based, this may comprise verifying that a user's cryptographic signature included in the input of the new transaction 152 j matches a condition defined in the output of the preceding transaction 152 i that the new transaction consumes; this condition typically comprises at least verifying that the cryptographic signature in the input of the new transaction 152 j unlocks the output of the previous transaction 152 i to which the new transaction's input points. In some transaction protocols, this condition may be defined at least in part by custom script included in the input and / or output. Alternatively, it may simply be fixed by the node protocol alone, or by a combination of these. In either case, if the new transaction 152 j is valid, the current node forwards it to one or more other nodes 104 in the P2P network 106. At least some of these nodes 104 also act as forwarding nodes 104F, applying the same tests according to the same node protocols to forward the new transaction 152j to one or more further nodes 104, etc. In this way, the new transaction is disseminated throughout the network of nodes 104.

[0023] In an output-based model, the definition of whether a given output (e.g., a UTXO) is spent is whether it has already been validly redeemed by the input of another, earlier transaction 152j according to the node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to consume or redeem has not already been consumed / redeemed by another valid transaction. Again, if it is not valid, the transaction 152j is not propagated or recorded in the blockchain. This protects against double spending, where a spender attempts to consume the output of the same transaction more than once.

[0024] In addition to validity checking, at least some of the nodes 104M also compete to be the first to create a block of transactions in a process known as mining, which is aided by "proof of work." At the mining nodes 104M, new transactions are added to a pool of legitimate transactions that have not yet appeared in a block. Miners then compete to assemble a new legitimate block 151 of transactions 152 from the pool of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a nonce value such that when the "nonce" is concatenated with the pool of transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition may be that the hash output has a certain number of leading zeros. The nature of a hash function is that it has an unpredictable output given its input. This search can therefore only be performed by brute force, consuming a large amount of processing resources at each node 104M attempting to solve the puzzle.

[0025] The first minor node 104M attempting to solve the puzzle announces this to the network 106, providing the solution as a proof that can be easily verified by other nodes 104 in the network (given the solution to the hash, it is simple to verify that it causes the hash output to satisfy the condition). The pool of transactions 154 for which the winner solved the puzzle is then recorded as a new block 151 in the blockchain 150 by at least some of the nodes 104 acting as storage nodes 104S, based on each such node verifying the winner's announced solution. A block pointer 155 is also assigned to the new block 151n that points back to the previously created block 151n-1 in the chain. Proof-of-work helps reduce the risk of double spend; because it requires a large amount of effort to create a new block 151, and because any block containing a double spend is likely to be rejected by other nodes 104, mining nodes 104M are motivated not to allow their blocks to contain double spends. Once created, blocks 151 cannot be altered because they are recognized and maintained according to the same protocol at each of the storage nodes 104S in the P2P network 106. Block pointers 155 also impose a sequential order on blocks 151. This results in an immutable public ledger of transactions, as transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106.

[0026] Pool 154 may be referred to as a "memory pool." As used herein, this term is not limited to any particular blockchain, protocol, or model. It refers to a pool of transactions that a miner has accepted for mining and that the miner has promised not to accept any other transactions that attempt to consume the same output.

[0027] Note that different miners 104M competing to solve the puzzle at any given time may be doing so based on different snapshots of the unmined transaction pool 154 at any given time, depending on when they began searching for a solution. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n, and the current pool 154 of unmined transactions is updated. Miners 104M then continue competing to create blocks from the newly defined prominent pool 154, and so on. There are also protocols for resolving any "forks" that may arise, a situation in which two miners 104M solve a puzzle within a very short time of each other, resulting in conflicting views of the blockchain being propagated. In other words, the tip of the fork that has grown the longest becomes the final blockchain 150.

[0028] In most blockchains, the winning miner 104M is automatically rewarded with a special type of new transaction (as opposed to a regular transaction that transfers an amount of digital assets from one user to another) that creates a new amount of digital assets out of thin air. Thus, the winning node is said to have "mined" a certain amount of digital assets. This special type of transaction is sometimes called a "producing" transaction. It automatically forms part of a new block 151n. This reward motivates the miner 104M to participate in the proof-of-work competition. Often, a regular (non-producing) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the winning miner 104M who created the block 151n in which the transaction was included.

[0029] Depending on the computational resources involved in mining, at least each of the minor nodes 104M typically takes the form of a server with one or more physical server units, or even an entire data center. Each transfer node 104F and / or storage node 104S may also take the form of a server or a data center. However, in principle, any given node 104 can take the form of a user terminal or a group of user terminals networked together.

[0030] The memory of each node 104 stores software configured to execute on the node's 104 processing unit to perform its respective role and handle transactions 152 according to the node protocol. It will be understood that any activity attributed to a node 104 herein may be performed by software executing on the respective computing device's processing unit. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof. Additionally, the term "blockchain" as used herein is a generic term that refers generally to this type of technology and is not limited to any particular proprietary blockchain, protocol, or service.

[0031] Also connected to the network 101 are computing devices 102 for each of a plurality of participants 103, each acting as a consuming user. These play the roles of payer and payee in transactions, but are not necessarily involved in mining or disseminating transactions on behalf of other participants. They do not necessarily execute the mining protocol. Two participants 103 and their respective devices 102 are shown for illustrative purposes: a first participant 103a and its respective computing device 102a, and a second participant 103b and its respective computing device 102b. It will be understood that many more such participants 103 and their respective computing devices 102 may exist and participate in the system, but are not shown for convenience. Each participant 103 may be an individual or an organization. Purely by way of example, the first participant 103a will be referred to herein as Alice, and the second participant 103b will be referred to as Bob, but this is not intended to be limiting, and it will be understood that any reference herein to Alice or Bob may be replaced with “first participant” and “second participant,” respectively.

[0032] The computing device 102 of each participant 103 comprises a respective processing device comprising one or more processors, e.g., one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or FPGAs. The computing device 102 of each participant 103 further comprises memory, i.e., computer-readable storage, in the form of a non-transitory computer-readable medium. This memory may comprise one or more memory units utilizing one or more memory media, e.g., magnetic media such as hard disks, electronic media such as SSDs, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory of the computing device 102 of each participant 103 stores software comprising a respective instance of at least one client application 105 adapted to execute on the processing device. It will be understood that any activity attributed herein to a given participant 103 may be performed using software executing on the processing device of the respective computing device 102. The computing device 102 of each participant 103 comprises at least one user terminal, e.g., a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given participant 103 may also include one or more other networked resources, such as cloud computing resources accessed via a user terminal.

[0033] The client application 105 may initially be provided to the computing equipment 102 of any given participant 103 on a suitable computer-readable storage medium, for example downloaded from a server or provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, an optical disk such as a CD or DVD ROM, or a removable optical drive.

[0034] The client application 105 comprises at least a "wallet" functionality. It has two main functions. One of these is to enable each user party 103 to create, sign, and submit transactions 152 so that they can be disseminated across the network of nodes 104 and included in the blockchain 150. The other is to report to each party the amount of digital assets that they currently own. In an output-based system, this second function comprises reconciling the amounts defined in the outputs of various transactions 152 scattered across the blockchain 150 that belong to the party in question.

[0035] Note: While various client functions are sometimes described as being integrated into a given client application 105, this is not necessarily limiting; instead, any client function described herein may be implemented in a series of two or more separate applications, for example, interfacing via an API or one plugging into another. More generally, client functions may be implemented at the application layer, or at a lower layer such as an operating system, or any combination thereof. While the following is described with respect to a client application 105, it will be understood that this is not limiting.

[0036] An instance of a client application or software 105 on each computing device 102 is operatively coupled to at least one of the forwarding nodes 104F of the P2P network 106. This allows the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact one, some, or all of the storage nodes 104 to query the blockchain 150 for any transactions of which the respective party 103 is the recipient (or, in embodiments, actually investigate other party transactions in the blockchain 150, since the blockchain 150 is a public entity that lends credibility to some transactions by virtue of its public presence). The wallet functionality of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. Each node 104 runs software configured to validate transactions 152 according to the node protocol and, in the case of a forwarding node 104F, to forward them for dissemination throughout the network 106. Transaction protocols and node protocols correspond to each other; a given transaction protocol accompanies a given node protocol and together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150 (although the transaction protocol may allow various transaction subtypes within it). The same node protocol is used by all nodes 104 in the network 106 (although it may handle transactions of different subtypes differently according to rules defined for that subtype, and different nodes may take on different roles and therefore implement different corresponding aspects of the protocol).

[0037] As mentioned, the blockchain 150 comprises a chain of blocks 151, each of which comprises a set of one or more transactions 152 created by the proof-of-work process as previously discussed. Each block 151 also comprises a block pointer 155 that points back to a previously created block 151 in the chain to define a sequential order for the blocks 151. The blockchain 150 also comprises a pool of valid transactions 154 waiting to be included in a new block by the proof-of-work process. Each transaction 152 (other than the creation transaction) comprises a pointer back to a previous transaction to define an order for the sequence of transactions (note that the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 stretches back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 earlier in the chain 150 pointed to the genesis block 153 rather than to a preceding transaction.

[0038] When a given party 103, e.g., Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she organizes the new transaction (using the wallet functionality of her client application 105) according to the associated transaction protocol. She then sends the transaction 152 from her client application 105 to one of one or more forwarding nodes 104F to which she is connected. For example, this may be the forwarding node 104F that is closest to or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, the node 104 handles the new transaction 152j according to the node protocol and its respective role. This involves first verifying whether the newly received transaction 152j meets some conditions for being "legitimate," examples of which will be discussed in more detail shortly. In some transaction protocols, the conditions for validity verification may be configurable on a per-transaction basis by a script included in the transaction 152. Alternatively, this condition may simply be a built-in feature of the node protocol or may be defined by a combination of the script and the node protocol.

[0039] Provided that a newly received transaction 152j passes the test to be considered valid (i.e., it is "validated"), any storage node 104S that receives the transaction 152j adds the new validated transaction 152 to a pool 154 in the copy of the blockchain 150 maintained at that node 104S. Additionally, any forwarding node 104F that receives the transaction 152j disseminates the validated transaction 152 onward to one or more other nodes 104 in the P2P network 106. Because each forwarding node 104F applies the same protocol, assuming the transaction 152j is valid, this means that it will soon be disseminated throughout the P2P network 106.

[0040] Once granted access to pool 154 in the copy of blockchain 150 maintained on one or more storage nodes 104, minor nodes 104M begin competing to solve the proof-of-work puzzle for the latest version of pool 154 that contains new transaction 152. (Other minor nodes 104M may still be trying to solve the puzzle based on their old views of pool 154, but whoever gets there first defines where the next new block 151 ends and the new pool 154 begins, and eventually, someone solves the puzzle for the part of pool 154 that contains Alice's transaction 152j.) Once the proof-of-work is done for pool 154 that contains new transaction 152j, it immutably becomes part of one of the blocks 151 in blockchain 150. Because each transaction 152 contains a pointer back to earlier transactions, the order of transactions is also immutably recorded.

[0041] Because different nodes 104 initially receive different instances of a given transaction, they may have conflicting views about which instance is "valid" before an instance is mined into block 150, at which point all nodes 104 agree that the mined instance is the only valid instance. If a node 104 accepts an instance as valid and then discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as invalid) the un-mined instance that it originally accepted.

[0042] UTXO-based model Figure 2 shows an exemplary transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the basic data structure of a blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not a limitation to all possible embodiments.

[0043] In a UTXO-based model, each transaction (“Tx”) 152 comprises a data structure with one or more inputs 202 and one or more outputs 203. Each output 203 may comprise an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value that specifies an amount of a digital asset, which represents a set number of tokens on the (distributed) ledger. A 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 indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, 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 the miner 104M.

[0044] Suppose Alice 103a wants to create transaction 152j that transfers a disputed amount of digital assets to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." Tx1 takes the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are arbitrary labels only. They do not necessarily mean that Tx0 is the first transaction in the blockchain 151, nor do they mean that Tx1 is the immediate next transaction in the pool 154. Tx1 may point back to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

[0045] The predecessor transaction Tx0 may already be validated and included in the blockchain 150 when Alice creates the new transaction Tx1, or at least when she submits it to the network 106. It may already be included in one of the blocks 151 at that time, or it may still be waiting in the pool 154, in which case it will soon be included in the new block 151. Alternatively, Tx0 and Tx1 may be created and submitted to the network 102 together, or Tx0 may even be submitted after Tx1 if the node protocol allows for buffering of “orphan” transactions. The terms “predecessor” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of transactions in the sequence as defined by transaction pointers specified in the transactions (e.g., which transaction points back to which other transaction). They may be equally replaced by “predecessor” and “successor,” or “ancestor” and “descendant,” “parent” and “child,” etc. This does not necessarily imply the order in which they are created, sent to the network 106, or arrive at any given node 104. Nevertheless, a subsequent transaction (a descendant transaction or "child") that points to a preceding transaction (an ancestor transaction or "parent") is not validated until and unless the parent transaction is validated. A child that arrives at a node 104 before its parent is considered an orphan. It may be discarded or buffered for some time to wait for its parent, depending on the node protocol and / or minor behavior.

[0046] One of the one or more outputs 203 of the preceding transaction Tx0 comprises a particular UTXO, here labeled UTXO0. Each UTXO comprises a value specifying the amount of the digital asset represented by the UTXO and a locking script that defines the conditions that must be met by the unlocking script in the input 202 of the subsequent transaction for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed. Typically, the locking script locks the amount to a particular party (the beneficiary of the transaction in which the locking script is included). That is, the locking script defines the unlocking condition, which typically comprises a condition that the unlocking script in the input of the subsequent transaction comprises the cryptographic signature of the party to which the preceding transaction is locked.

[0047] A locking script (also known as scriptPubKey) is code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called "Script" (capital S). A locking script specifies what information is needed to consume the transaction output 203, for example, the requirements of Alice's signature. An unlocking script appears in the transaction's output. An unlocking script (also known as scriptSig) is code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, it may include Bob's signature. An unlocking script appears in the transaction's input 202.

[0048] Thus, in the example shown, UTXO0 in Tx0's output 203 must contain Alice's signature Sig P in order for UTXO0 to be redeemed (and more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A Locking script [Checksig P A ]. [Checksig PA ] is the public key P from Alice's public-private key pair. A Tx1's input 202 comprises a pointer that points back to Tx1 (e.g., by its transaction ID, TxID0, which in an embodiment is a hash of the entire transaction Tx0). Tx1's input 202 comprises an index that identifies UTXO0 within Tx0 to identify UTXO0 among all other possible outputs of Tx0. Tx1's input 202 also comprises an unlocking script that comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). <Sig P A The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.

[0049] Depending on the implementation, the required signature may be, for example, a traditional Elliptic Curve Digital Signature Algorithm (ECDSA), Digital Signature Algorithm (DSA), or Rivest-Shamir-Adleman (RSA) signature, or any other suitable form of cryptographic signature. The signature challenge may be implemented, for example, as a standard pay-to-public key (P2PK) puzzle or P2PK hash (P2PKH) puzzle, or alternatively, an R-puzzle or the like may be implemented instead as a means to a signature. This example uses P2PK for illustration purposes.

[0050] When a new transaction Tx1 arrives at node 104, the node applies the node protocol, which comprises running the locking script and the unlocking script together to see if the unlocking script meets the conditions defined in the locking script (which may comprise one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ] where '||' denotes concatenation, '<...>' means putting data on the stack, and '[...]' is a function contained in the unlocking script (in this example, a stack-based language). Equivalently, rather than concatenating the scripts, the scripts may be executed one after the other using a common stack. Either way, when executed together, the scripts will create a stack containing Alice's public key P, as contained in the locking script in the output of Tx0. A is used to authenticate that the locking script in Tx1's input contains Alice's signature signing the expected portion of the data. The expected portion of the data itself (the "message") must also be included in Tx0 to perform this authentication. In an embodiment, the signed data comprises the entirety of Tx0 (thus, there is no need to include a separate element specifying the signed portion of the data in the clear, since it was there originally).

[0051] The details of authentication via public-private cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message by encrypting it with her private key, then, given Alice's public key and the message in plaintext (the unencrypted message), another entity, such as node 104, can authenticate that the encrypted version of the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as a signature onto the plaintext version of the message, thereby allowing any holder of the public key to authenticate the signature. Thus, it should be noted that any reference herein to signing a particular piece of data or transaction, etc., may, in embodiments, mean signing a hash of that data or transaction piece.

[0052] Hashes referred to elsewhere in this specification may be implemented by, for example, a SHA (Secure Hash Algorithm) hash function, or an HMAC (Hash-based Message Authentication Code) hash function, or any other suitable form of cryptographic hash function known in the art.

[0053] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (thus, in the illustrated example, if Alice's signature is provided and authenticated in Tx1), node 104 considers Tx1 valid. If node 104 is a mining node 104M, this means that node 104 adds Tx1 to the pool 154 of transactions awaiting proof of work. If node 104 is a forwarding node 104F, node 104F forwards transaction Tx1 to one or more other nodes 104 in network 106, so that it is disseminated throughout the network. Once Tx1 is validated and included in blockchain 150, it defines UTXO0 from Tx0 as being consumed. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If it 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, node 104 also needs to ascertain whether the referenced UTXO in the preceding transaction Tx0 has already been spent (already formed a legal input into another legal transaction). This is one reason why imposing a prescribed ordering on transactions 152 is important for blockchain 150. In practice, a given node 104 may maintain a separate database that marks the UTXOs 203 that transactions 152 have spent in them, but ultimately, what defines whether a UTXO is spent is whether the UTXO has already formed a legal input into another legal transaction in blockchain 150.

[0054] 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 also grounds for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not mined into a block 151.

[0055] Note that in the UTXO-based transaction model, a given UTXO must be spent in its entirety; it cannot "leave behind" part of the amount defined in the UTXO as spent while another part is spent. However, the amount from a UTXO can be split among multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 in Tx0 can be split among multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire amount defined in UTXO0, she can use a reminder to give herself or pay another party the change from the second output of Tx1.

[0056] In practice, Alice would normally need to include a fee for the winning miner, because today, the reward for generating transactions alone is usually insufficient to incentivize mining. If Alice does not include a fee for the miner, Tx0 will likely be rejected by the miner nodes 104M and therefore will not be disseminated or included in the blockchain 150, even though it is technically valid (the miner protocol does not force miners 104M to accept transaction 152 if they do not want to). In some protocols, the mining fee does not require a unique, separate output 203 (i.e., it 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 awarded to the winning miner 104. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference automatically goes to the winning miner 104M. However, it is not necessarily excluded that a miner fee may alternatively or additionally be explicitly specified in its own UTXO of transaction 152's UTXOs 203.

[0057] Alice and Bob's digital assets consist of unspent UTXOs locked to them in any transaction 152 anywhere on the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 across the blockchain 150. There is no single number stored anywhere on the blockchain 150 that defines a given party's 103 total balance. It is the role of the wallet function of the client application 150 to collate together the values ​​of all the various UTXOs locked to each party that have not yet been spent in another, further transaction. The wallet function can do this by querying a copy of the blockchain 150 stored on one of the storage nodes 104S, for example, the storage node 104S closest to or best connected to each party's computing device 102.

[0058] Note that script code is often expressed diagrammatically (i.e., not in a real language). For example, [Checksig P A ] = OP_DUP OP_HASH160 <H(P A )> OP_EQUALVERIFY OP_CHECKSIG is intended to be [Checksig P A]. "OP_..." refers to a specific opcode in the Script language. OP_CHECKSIG (also called "Checksig") is a Script opcode that takes two inputs (a signature and a public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any presence of a signature ('sig') is removed from the script, but additional requirements, such as a hash puzzle, remain for transactions that are verified by the 'sig' input. In another example, OP_RETURN is a Script language opcode for creating a non-consumable output of a transaction that can store metadata within the transaction, thereby immutably recording the metadata on the blockchain 150. For example, the metadata may comprise a document that is desired to be stored on the blockchain.

[0059] signature P A is a digital signature. In an embodiment, it is based on ECDSA using the elliptic curve secp256k1. A digital signature signs specific data. In an embodiment, for a given transaction, the signature signs some of the transaction inputs and all or some of the transaction outputs. The specific portions of the outputs it signs depend on the SIGHASH flag, which is a 4-byte code included at the end of the signature to select which outputs are signed (and therefore fixed at the time of signing).

[0060] A locking script is sometimes referred to as a "scriptPubKey," referring to the fact that each transaction includes the public key of the party to which it is locked. An unlocking script is sometimes referred to as a "scriptSig," referring to the fact that it provides the corresponding signature. However, more generally, it is not required in all applications of blockchain 150 that the condition for a UTXO to be redeemed include authenticating the signature. More generally, a scripting language may be used to define any condition or conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0061] Layered Network Layered Network Structure: A layered network is an overlay network layered on top of a communication channel. For example, the communication channel may be an underlying infrastructure network such as a personal area network, a local area network (e.g., an inter-company P2P network), or a wide area network such as the Internet. In other examples, the layered network may be a network of nodes connected via wired connections. In yet other examples, the connections may be wireless connections, e.g., Bluetooth or Wi-Fi connections. In some examples, some or all of the above example connections may be used to form a layered network.

[0062] Some or all of the nodes in the network are configured to connect (i.e., join or rejoin) the layered network according to a connection protocol. The connection protocol may vary according to the particular layer of the network to which the connecting node is connecting (i.e., attempting to join or rejoin). Before the connection protocol is described in detail, a series of exemplary layered networks that may be created or implemented by the connection protocol will be described. However, it will be understood that these are merely illustrative examples and that in general, any layered network that follows the connection protocol may be created.

[0063] FIG. 3 shows a schematic representation of an example layered network (LN) 300. Generally, an LN includes a core network (or core layer) consisting of core nodes 301 and a series of layers (or shells). The core layer is also referred to as the first layer of the LN. The series of layers extend outward from the core layer, in order from the second layer consisting of second nodes 302 to one or more outer layers. Each outer layer consists of a set of outer nodes 303. While only one outer layer is shown in FIG. 3, it will be understood that an LN may include any number of outer layers. As specific examples, FIG. 5 shows an example LN 500 with five layers, and FIG. 6 shows an example LN 600 with four layers.

[0064] The example LN 300 of Figure 3 includes five core nodes 301, six secondary nodes 302, and eight outer nodes 303. In some LNs 300, the number of nodes may increase with each layer, i.e., the core layer consists of the smallest number of nodes and the outermost layer consists of the largest number of nodes. In other examples, one or more of the layers between the core layer and the outermost layer may consist of the largest number of nodes. In this example, the core layer is the innermost layer of the LN 300, the secondary layer is the middle layer, and the only outer layer is the outermost layer.

[0065] The core layer (the network within the LN) in this example forms a complete graph, i.e., each core node 301 is connected to each other core node 301. For a core layer of five core nodes 301, in the example given, the core layer requires 10 distinct core connections (i.e., connections between two core nodes). In other examples (e.g., FIG. 4), the core layer may not be a complete graph. The core layer may form a "near-complete graph." In a near-complete graph, at least one core node 301 is not connected to at least one other core node 301. It may be that only one core connection is missing. In a particular example of a near-complete graph, each core node 301 may be connected to one or more, but not all, of the other core nodes 301.

[0066] The second layer includes second nodes 302. Note that the term "second node" is used merely as a label for nodes 302 located in the second layer of the LN 300 for structural reasons. Each second node 302 is connected to at least one core node 301. In some examples, each second node 302 may be connected to only one core node 301. Alternatively, some or all of the second nodes 302 may be connected to more than one core node 301. For example, some or all of the second nodes 302 may connect to every core node of the core nodes 301. In the example LN 300 of FIG. 3, each core node 301 is connected to two second nodes 302. However, in this example, some second nodes 302 (those shown as striped circles) are connected to one core node 301, while some second nodes 302 (those shown as white circles and those shown as shaded circles) are connected to two core nodes 301. Second nodes 302 (and outer nodes 303 in the outer layer) connected to the same core node 301 are called "communities." For example, each white node together forms one community, each striped node together forms a community, and each shaded node together forms yet another community. The connection between second nodes 302 and core node 301 is called the "ancestor connection" and is shown as a thick dotted line.

[0067] 3, each second node 302 is connected to two other second nodes 302. In some examples, some or all of the second nodes 302 may not form connections with other second nodes, e.g., some second nodes 302 may be connected to other second nodes 302, while some second nodes may be connected to other second nodes 302. These "intra-tier" connections are shown in FIG. 3 as solid lines between nodes.

[0068] The outer layer of FIG. 3 includes outer nodes 303. Here, the term "outer" in "outer layer" does not necessarily limit it to the outermost layer of the entire LN network, although this is one possibility. Each outer node 303 is connected to at least one second node 302. In some examples, each outer node 303 may be connected to only one second node 302. Alternatively, some or all of the outer nodes 303 may be connected to more than one second node 302. For example, some or all of the outer nodes 303 may be connected to every second node 301. In the exemplary LN 300 of FIG. 3, each outer node 303 is connected to two second nodes 302. Some second nodes 302 (i.e., striped nodes) are connected to two outer nodes 303, and some second nodes 302 (i.e., white nodes and shaded nodes) are connected to three outer nodes 303.

[0069] 3, each outer node 303 is connected to two other outer nodes 303 in the same tier. In some examples, some or all of the outer nodes 303 may not form any connections with other outer nodes 303 in the same tier. Some or all of the outer nodes 303 may form at least one connection with another outer node 303 in the same tier.

[0070] Each outer node 303 is connected to at least one second node 302 and also to at least one core node 301. The connections between the outer nodes 303 and the core nodes 301 are called "core ancestor connections" and are shown as thin dotted lines. Each outer node 303 may be connected to each of the core nodes 301 to which their ancestor second nodes 302 are connected. As shown in FIG. 3, each outer node 303 is connected to each of the core nodes 301 to which their ancestor second nodes 302 are connected, and may not be connected to other core nodes 301. In this case, each outer node 303 belongs to a single community.

[0071] FIG. 4 shows a schematic representation of another example of an LN 400. Like the LN 300 of FIG. 3, the exemplary LN 400 comprises a core layer, a second layer, and an outer layer. These exemplary LNs 300, 400 share the same number of nodes (i.e., five core nodes 301, six second nodes 302, and eight outer nodes 303) but contain different numbers of connections. For example, in this example, the core layer is not a complete graph because some connections between the core nodes 301 do not exist. Another difference is that two communities (white and shaded nodes) comprise a single core node 301, while another community (shaded nodes) comprises three core nodes 301. Yet another difference is that the degree of the nodes in the outer shell of the LN 400 is now 1, which differs from the degree of the nodes in the outer shell of the LN 300, which is 2. That is, in this exemplary LN 400, each outer node 303 is connected to a single other outer node 303. Therefore, the nodes in different layers have different degrees.

[0072] FIG. 5 shows a schematic representation of another example of an LN 500. In this example, only some core nodes 301 are connected to second nodes and outer nodes 303. That is, in this example, only some core nodes 301 form connections with other core nodes 301. Therefore, in this example, the LN 500 comprises a single community (shaded nodes). The LN 500 in this example comprises five layers: a core layer, a second layer, and a third outer layer. The core layer consists of five core nodes 301 that form a semicomplete graph. In this example of a semicomplete graph, only a single core connection is missing. The second layer consists of a single second node 302 connected to two core nodes 301. The second layer consists of a single second node 302 connected to two core nodes 301. The third layer consists of a single outer node 303 connected to the second node 302 via an ancestor connection. The outer node 303 in the third layer is also connected to two core nodes 301 to which the second node 302 is connected. The outer node 303 is connected to the two core nodes 301 via respective core ancestor connections. The fourth layer also consists of a single outer node 304. The outer node 304 in the fourth layer is connected to the outer node 303 in the third layer via an ancestor connection and to the second node 302 via an ancestor connection. The outer node 304 in the fourth layer is also connected to two core nodes 301 to which the second node 302 and outer node 303 in the third layer are connected. The outer node 304 is connected to the two core nodes 301 via respective core ancestor connections. Finally, the fifth layer consists of two outer nodes 305. The two outer nodes 305 in the fifth layer are connected to the outer node 304 in the fourth layer, to the outer node 303 in the third layer, and to the second node 302, each connection being an ancestor connection. The two outer nodes 305 are also connected to the two core nodes 301 via core ancestor connections. In this exemplary LN 500, the second tier nodes and the outer tier nodes are not connected to any other nodes in the same tier.

[0073] FIG. 6 shows a schematic representation of another example of an LN 600. This LN comprises two communities of nodes, as indicated by the white and black nodes. In this example, the core layer forms a complete graph (i.e., a network of nodes). Each community comprises a separate set of three core nodes 301. This example LN 600 comprises four layers: a core layer, a second layer, and two outer layers. Each node in the outer layers is connected to one node in the preceding layer. As with the example LN 500 of FIG. 5, the nodes in the second layer and the outer layers are not connected to any other nodes in the same layer.

[0074] In some embodiments, LN 300, 400, 500, 600 (hereinafter referred to as “300” for brevity) may be a “blockchain layered network (BLN).” The term BLN is defined herein as a layered network that comprises a blockchain network or that comprises at least a portion of a blockchain network, such as blockchain network 106 described with reference to FIG. 1.

[0075] The BLN is inspired by the Mandala network and shares some similar characteristics, but is designed to allow for a more flexible and desirable connection structure, for example, for service and user networks that utilize the blockchain network 106.

[0076] The BLN 300 may comprise at least a portion of a blockchain network 106 at its core. Typically, the nodes of the multi-layered network are overlaid on an underlying infrastructure network, such as the Internet 101. Some or all of the core nodes are nodes 104 of the blockchain network 106. They may comprise mining nodes 104M, storage nodes 104S, or a combination thereof. In an embodiment, each of the core nodes is a mining node 104M and / or a storage node 104S (e.g., a full-copy node).

[0077] Each of the outer nodes 303 (or each outer node in the outermost tier) may be an end-user node comprising a user's computing equipment. This may be an individual user or an organization such as a company, academic institution, or government agency. Accordingly, each outer node 303 may comprise one or more user terminals and / or a server comprising one or more server units at one or more locations. Each outer node 303 comprises a memory comprising one or more memory units and a processing device comprising one or more processing units. These may take the form of either a memory medium and / or a processor, e.g., such as those previously discussed in connection with other network elements or user equipment. The memory stores client software adapted to run on the processing device, which, when executed, is configured to cause the node to operate as a protocol client conforming to a connection protocol according to any of the following embodiments or the like. Optionally, one or more of the end-user nodes may comprise user equipment 103 of users 102 of the blockchain network 106, and the client software may comprise a blockchain wallet application 105 or the like.

[0078] Each second node 302 may be in the form of a server comprising one or more physical server units. Each such node comprises a memory comprising one or more memory units and a processing unit comprising one or more processing units. These may take the form of either a memory medium and / or a processor, e.g., such as those previously discussed with respect to other network elements. The memory stores software adapted to run on the processing unit of the second node 302. When executed, the software is configured to follow a connection protocol according to any of the following embodiments or the like. In some embodiments, when executed, the software is configured to provide a service operating according to any of the embodiments described below or the like.

[0079] In some examples, some or all of the second nodes 302 may operate a smart contract service that is configured to perform a predetermined operation in response to and based on a blockchain transaction transmitted to it by one of the other nodes of the LN 300, such as by the outer node 303. For example, the smart contract may transmit a blockchain transaction to the core node 301 in response to receiving the particular blockchain transaction from the outer node 303.

[0080] In other examples, some or all of the second nodes 302 may operate, among other things, a distributed database. That is, each second node 302 that operates a distributed database is configured to store data received from another node of the LN 300, e.g., an outside node 303. A second node 302 that receives and stores data may be configured to disseminate the data to other second nodes 302 that also operate distributed databases.

[0081] The nodes 301, 302, 303 are configured to form connections between one another at the overlay network level. That is, the nodes 301, 302, 303 of the layered network are configured to follow an overlay network protocol that specifies which connections they can and cannot form with other nodes 301, 302, 303 of the layered network. Thus, while it may (but not necessarily) be physically possible for all nodes to connect to one another through the underlying infrastructure (e.g., the Internet), connectivity between such nodes 301, 302, 303 may be more limited when they participate as nodes 301, 302, 303 of the layered network and operate in accordance with the layered network's associated overlay network protocol. A connection between two nodes 301, 302, 303 of a layered network 300 means that the nodes can communicate directly, which in this context means that they can communicate without having to perform a hop through another node 301, 302, 303 of the layered network 300. In the context of an overlay network such as a layered network, "connection" means a connection (i.e., an edge) at the level of the layered network 300 (i.e., at the level of the overlay network protocol of the layered network).

[0082] In embodiments where the LN 300 is a BLN, some or all of the second nodes 302 may be configured to transmit blockchain transactions to the core node 301 to which those second nodes 302 are connected. In some examples, the second nodes 302 may generate the blockchain transactions before transmitting them to the core node 301. In other examples, the second nodes 302 may forward the blockchain transactions to the core node 301. For example, the second nodes 302 may receive blockchain transactions from the outside nodes 303 and then send the received blockchain transactions to the core node 301. Similarly, a given second node 302 (i.e., some or all of the second nodes) may be configured to obtain blockchain transactions from the core nodes 301 and / or outside nodes 303 connected to the given second node 302.

[0083] Additionally or alternatively, some or all of the outside nodes 303 may be configured to transmit blockchain transactions to the core nodes 301 to which they are connected. The outside nodes 303 may also be configured to transmit blockchain transactions to the second nodes 302 to which they are connected. In some examples, the outside nodes 303 may transmit blockchain transactions to the second nodes 302 and the core nodes 301.

[0084] Some or all of the outer nodes 303 may be configured to transmit blockchain transactions to other outer nodes 303, for example, outer nodes in the same tier or outer nodes in the previous or next tier in an ordered set of tiers.

[0085] In embodiments in which the core nodes 301 of the BLN 300 each perform the role of a blockchain node 104, some or all of the second nodes 302 and / or outer nodes 303 may be configured to request confirmation that a given transaction has been accepted into the pool of transactions of the mining node 104M to which the given second node 302 or outer node 303 is connected. The pool 154 (sometimes referred to as a memory pool) comprises transactions that have been validated according to a set of consensus rules of the blockchain network 106. If a transaction (e.g., a "first transaction") is included in the pool 154, the mining node 104M will not accept another transaction (e.g., a "second transaction") that attempts to double-spend an output referenced by an input of the first transaction. Thus, the second node 302 and / or the outer node 303 can query the core node 301 to confirm that a transaction (e.g., a transaction submitted to the blockchain network 106 by the node 302, 303) has been accepted, or to confirm whether a transaction (e.g., a transaction received from another node in the BLN 300) is an attempt at double spending. The core node 301 is configured to transmit a response to the request to the requesting node 302, 303.

[0086] Additionally or alternatively, the second node 302 and / or the third node 303 may be configured to transmit to the core node 301 a request for a Merkle proof of a transaction mined in block 151 of the blockchain 150. Merkle proofs are familiar to those skilled in the art. A Merkle proof is a sequence of hashes tracing back to the Merkle root. To verify whether a transaction was mined in block 151, the nodes 302, 303 take the transaction's hash, concatenate it with the first hash in the Merkle proof's sequence of hashes (i.e., its hash partner in the Merkle tree at the same level as the transaction's hash), and hash the result. This process of concatenation and hashing is repeated until all of the hashes in the Merkle proof have been utilized. If the resulting hash is identical to the Merkle root, the transaction must be included in the Merkle tree and therefore in block 151. The core node 301 is configured to transmit the Merkle proof to the requesting nodes 302, 303.

[0087] Additionally or alternatively, the second node 302 and / or the third node 303 may be configured to transmit a request for the block header of a given block 151 to the core node 301. Among other data, the block header comprises the Merkle root of the transaction being mined into the block 151. The core node 301 is configured to transmit the Merkle proof to the requesting nodes 302, 303.

[0088] In some embodiments, some or all of the core nodes 301 may be configured to transmit a set of transactions to some or all of the second nodes 302 connected to the core node 301 and / or some or all of the outside nodes. The transactions in the set may share a common attribute. For example, the core node 301 may transmit all transactions that include a particular protocol flag. This flag may be included in the output of the transaction, e.g., in a non-consumable output. As another example, the transactions may comprise a particular (and the same) blockchain address, e.g., they may be payable to the same blockchain address. The outside node 303 may have an agreement with the core node 301 that the core node 301 will send any transaction that is payable to an address associated with the outside node 303. As yet another example, a transaction may comprise a secondary consensus rule set. That is, a transaction may include more than one control branch in its output, with each control branch being specific to its respective consensus rule set. The output may comprise a first control branch specific to the first rule set and a second control branch specific to the second rule set (these two control branches may be contained in an if-else condition). If nodes 302, 303 are configured to implement the second rule set, core node 301 may transmit the transaction to nodes 302, 303. If nodes 302, 303 are configured to implement neither the first rule set nor the second rule set, core node 301 does not transmit the transaction to nodes 302, 303.

[0089] A core node 301 that is a mining node 104M may include an identifier (e.g., a "Miner ID") unique to that mining node 104M in the resulting transaction (also called a "coinbase" transaction) that is mined by the mining node 104M into a block 151. Other nodes in the BLN 300 may use the identifier to identify that mining node 104M on the network.

[0090] Another way to identify the nodes 301, 302, 303 of the LN 300 is through digital certificates. Some or all of the nodes 301, 302, 303 may be associated with digital certificates. The digital certificate includes and certifies the respective node's identifier, such as a public key associated with the node, the node's network address (e.g., IP address), and other identifiers. A node of the LN 300 may use a digital certificate of a different node to connect to that node. For example, the outside node 303 may obtain a digital certificate from the second node 302 and use the second node's identification information contained in the digital certificate to connect to the second node 302.

[0091] A node at a given tier may issue a digital certificate to a node at the next tier in the ordered set of tiers, i.e., core node 301 may issue a digital certificate to a second node, second node 302 may issue a digital certificate to outer node 303 in the first outer tier, etc. In some examples, a node at a given tier may issue a digital certificate to a node at the same tier, e.g., second node 302 may issue a respective digital certificate to one or more other second nodes 302.

[0092] Connection Protocol: As mentioned above, each node connecting to the layered network 300 may connect according to a connection protocol. That is, the connecting node must follow the rules of the connection protocol. The connecting node may only form connections allowed by the connection protocol; other connections may not be formed. In examples, the connecting node may be a core node 301, a second node 302, or an outer node 303. In some examples, each node in the LN 300 must follow the connection protocol. In other examples, only nodes connecting to the LN 300 for the first time or rejoining the LN 300 must follow the connection protocol. Figures 3 through 6 show exemplary LNs 300, 400, 500, and 600 established according to a connection protocol.

[0093] Physically speaking, each of the nodes of LN300 may be connected at some other level, or may be able to connect to each other, in some examples, for example, via the Internet. A connection protocol imposes constraints on which connections can be formed at the overlay network level, i.e., the layered network level, and some connections do not exist or are not allowed. Each connecting node of LN300 is configured to operate according to LN300's overlay level protocol (comprising a connection protocol), which determines which connections a node can and cannot form at the overlay level. In other words, a connection is an allowed communication channel that two nodes are configured to be allowed to form by those protocols. If a node has a connection with another node, it can communicate with that node without hopping through another node in the layered network, but if it does not have that connection, it cannot communicate and may only communicate by hopping through one or more other nodes between which there is a connection.

[0094] The connection protocol requires that a connecting node connect to at least one node in a preceding (inner) tier and at least one core node, with the exception that a core node may in some instances be the innermost tier and therefore cannot connect to a preceding tier. In instances where the connecting node is a second node, these two requirements are equivalent. If the connecting node is an outer node in the first outer tier, the connecting node connects to at least the second node 302 and the core node 301.

[0095] The connection protocol may require that an connecting node connect to more than one core node. The connection protocol may further require that an connecting node connect to more than one but not all of the core nodes, for example, all but one of the core nodes. The connecting node may also be a second node that must connect to more than one core node. That is, some or all of the second nodes must connect to more than one core node (and in some examples, not all of the core nodes).

[0096] The connection protocol may require the connecting node to connect to one or more second nodes. If the connecting node is a second node, this means that the connecting (second) node must connect to one or more different second nodes. If the connecting node is an outer node, the connecting (outer) node must connect to one or more second nodes. The connecting outer node may be an outer node of a first outer tier, or an outer node of a second tier, etc.

[0097] The connection protocol may require that an outer node connected to a node in a preceding tier must connect to some or all of the core nodes (referred to above as "core ancestors") to which the node in the preceding tier is connected. For example, an outer node may be connected to a second node. In that case, the outer node must also connect to the core node to which the second node is connected. If an outer node is connected to more than one second node, the connection protocol may require that the outer node must connect to the core node to which each of the second nodes is connected. As another example, an outer node in a second outer tier may be connected to an outer node in a first outer tier. In that example, the connection protocol requires that the outer node in the second outer tier must connect to the core node to which the outer node in the first outer tier is connected.

[0098] The connection protocol may require that an outer node connect to one or more (e.g., two) outer nodes in the same outer tier. The connection protocol may require that each outer node connect to one or more outer nodes in the same tier. Alternatively, some outer tiers may include outer nodes that form one or more same-tier connections, and some outer tiers may include outer nodes that do not form one or more same-tier connections. The connection protocol may require that each outer node in the same outer tier must connect to the same number of different outer nodes in that tier. For example, each outer node in a first outer tier may be required to connect to two outer nodes. Each outer node in a second outer tier may be required to connect to three outer nodes. That is, the number of outer nodes in the same tier to which an outer node is connected may vary between outer tiers.

[0099] In some embodiments, an outer node in the ith outer tier (e.g., the third outer tier) may be connected to an outer node in the preceding (i-1)th tier (e.g., the second outer tier). The connection protocol may require that outer nodes in successive (i+1)th outer tiers (e.g., all outer nodes) must connect to each node in the (i-1)th tier to which the outer node in the ith outer tier is connected. For example, the fifth tier outer node 305 in LN 500 of FIG. 5 is connected to the fourth tier outer node 304 and the third tier outer node 303. In some examples, the connection protocol may require that the (i+1)th outer tier outer node must connect to each outer node in each preceding tier to which the outer node in the ith outer tier is connected.

[0100] In embodiments in which some or all of the nodes of LN300 are associated with digital certificates, the connection protocol may require that connecting nodes must connect only to nodes associated with the nodes associated with the respective digital certificates. In some embodiments, the connection protocol may require that connecting nodes (e.g., outer nodes) must connect only to respective nodes (e.g., second nodes) if the digital certificate associated with the respective node was issued by a node in a tier preceding the respective node (e.g., a core node) or, in some examples, by a node in the same tier as the respective node (e.g., a different second node).

[0101] In some embodiments, the connection protocol may require that a connecting node can only connect to nodes that issued the connecting node with a digital certificate, i.e., connecting to a node comprises receiving a digital certificate from that node.

[0102] A connection protocol enables the construction of a BLN. Like a Mandala network, a BLN is constructed with multiple layers. Unlike a Mandala network, the first layer may form an incomplete graph (e.g., a semicomplete graph). Other differences between a BLN and a Mandala network are that in a BLN, nodes in each successive layer may have different degrees, a node may be connected to more than one node in the central layer, and / or the degree of a node may vary between layers.

[0103] Preferably, for all nodes outside the central core: (i) Each node is connected to m of the n1 nodes in the central core. (ii) Each node is connected to a node in every layer, and g is the total number of layers. (iii) Each node is a member of only one community. There are at most n2 communities, where n2 is the number of nodes in the second tier. (iv) Each node is connected to every other node by at most three hops, which is called the diameter of the graph.

[0104] In a BLN, a "community" is defined as a set of nodes that share the exact same set of core ancestors. Figure 6 shows a BLN with a network where n = 6, m = 3, and g = 4, depicting nodes from two distinct communities: the black-node community and the white-node community. The white-node community comprises nodes that are connected to all three nodes on the LHS of the central core, while the black-node community comprises nodes that are connected to all three nodes on the RHS of the central core.

[0105] A property of the Mandala network is that every node outside the core layer (i=1) is connected to exactly one core ancestor (i.e., everywhere c i = 1), which contributes significantly to the emergent properties of the Mandala network. Network size (N=Σi n i ) has an average shortest path slope that asymptotically approaches a constant as . Network size (N=Σ i n i ) increases. · Robust to random node failures.

[0106] A property of a BLN is that every non-core node connects to at least one ancestor. However, the definition of a BLN also accepts non-core nodes with at most m connections to core ancestors (i.e., wherever 1 ≤ c i ≦m). i = 1 to 1 ≤ c i For generalizations up to ≦m, a BLN can be understood as an artifact of a blockchain protocol. The protocol that defines a blockchain system relies on a probabilistic security model. Essentially, this means that any participant (node) in the BLN with a given interest in the events recorded in the blockchain 150 must respect the probabilistic security model by connecting to a minimum fraction f of the network hash power, with 100% of the total hash power being distributed among the nodes in the core tier of the BLN. Assuming that the core tier exhibits a uniformly balanced distribution of hash power among the n1 core nodes, the minimum fraction of nodes is f=m / n1 is.

[0107] The blockchain protocol implies a lower bound on the minimum fraction, f = 0.51, but network participants in larger BLNs may require a higher fraction (e.g., f = 0.67) for greater resistance (e.g., against double-spending). BLNs may be characterized by the choice of parameter m, as this dictates the probabilistic security of operations for participants in the BLN, which depends on the specific use case demanding the BLN in question.

[0108] The nodes in the second layer, L2, closest to the core, depend most heavily on the probabilistic security model of the blockchain protocol, and this dependency is due to the fact that the layer is L g The connectivity protocol may require nodes in L2 to connect to exactly c2 = m core ancestors, but nodes in all successive layers with i > 2 may connect to a range of core ancestors 1 < <c i ≦m. In some instances, nodes in all successive layers must connect to m core ancestors.

[0109] Nodes outside the central core of a BLN may have "SPV-like" connections to the core, which means that they can: a) Send a transaction to a core node b) Ask core nodes if the transaction has been accepted into the memory pool / block candidate c) Require Merkle proofs of transactions mined in a block d) Request the latest list of block headers

[0110] These simple and targeted requirements are designed to minimize the burden on the core node 301 as much as possible, while also allowing the widest possible range of scalable solutions to be built on top of it using the BLN. Many use cases do not require anything other than the types of connections described above. In some instances, the second node 302 and / or outer node 303 are configured to be able to perform only actions a) through d) above. However, other solutions, typically at the enterprise level, may require the core to actively provide more data to nodes, such as transactions that meet certain criteria. Thus, actions a) through d) are minimum requirements for the BLN, although additional data transfer between those nodes and the core is possible in some instances.

[0111] For nodes running smart contracts, some nodes may only require SPV-like activities a) through d), while other nodes may require consensus to receive more data from core nodes.

[0112] In some BLNs, users may operate tier 3 or higher nodes, and smart contracts may be operated by tier 2 or higher nodes. Users cannot realistically "listen" to the blockchain continuously for transactions with a specific output address because doing so would require constantly monitoring the blockchain 150 for transactions involving a specific address. Given the ever-increasing number of transactions that can be transmitted to the blockchain per hour, such constant monitoring is impractical for end users. While constantly monitoring the blockchain is common among some blockchain wallet architectures, it is not a scalable solution given that both the number of transactions submitted to the blockchain per hour and the number of blockchain users are expected to increase dramatically in the future. Consider the following example: Alice wants to make a payment to Bob. Alice creates a transaction for the desired amount with an output address that she knows Bob owns. Alice then submits this transaction to the mining network rather than submitting it directly to Bob. For Bob to know that his transaction has been accepted, he must "listen" to the blockchain to see if and when a transaction with his output address has appeared on the network. Bob must ask a mining node to do this on his behalf. This means that the mining node must keep a record of Bob's address and check that every transaction it receives matches this address. Note that miners have no economic incentive to do this. This quickly becomes impractical when you consider that miners must process millions of transactions per second and check that they match millions of addresses.

[0113] Instead, in a BLN, Alice may be directly connected to Bob and can send transactions directly to him. Bob can then send the transaction to miners in the core, simultaneously asking them whether they accept the transaction as valid. Because the transaction includes the miner's fee, miners have an incentive to accept the transaction and an incentive to confirm whether they accepted the transaction, reducing the risk of constructing a block that will be orphaned. To further secure the system, Alice may send Bob Merkle proofs of the inputs to her transaction. Bob, having a copy of the block header, may verify these Merkle proofs. This assures Bob that Alice's inputs were part of the blockchain 150 at some point, and if Alice has already spent them, Bob will have proof of double spending because he received a signature from Alice on the transaction that Alice gave to Bob. Note that Bob may be a smart contract (a second node) and Alice may be a user (an outer node) who wants to interact with that smart contract. If the smart contract is "lightweight" in the sense that the smart contract operator has not made any specific agreements with mining nodes to facilitate the processing of the smart contract, then the smart contract also cannot rely on listening to the blockchain 150 to receive transactions that cause state changes: Alice must send such transactions directly to the smart contract.

[0114] A service provider may operate nodes at tier 2 or higher. The service provider case differs from the user or lightweight smart contract case. A service provider may have a commercial agreement with a core mining node, or a collection of core nodes, which then disseminate a certain subset of transactions to the service provider nodes. Such transactions must be easily identifiable and meet certain criteria. For example, OP_RETURN data with specific protocol flags, for example, Metanet protocol, Tokenized protocol, or Digital Certificate protocol. Output addresses that match a small, specific set, for example, an enterprise-level smart contract or address whitelist / blacklist. The secondary consensus rule set indicated by the OP_VER control branch.

[0115] Additionally, transactions sent to a core that follows these rules or is otherwise identified as part of a community that participates in a service level agreement may have lower (or even zero) transaction fees. Any shortfall may be made up by higher transaction volume or fiat revenue from the service level agreement.

[0116] All nodes in the BLN 300 may be associated with a semi-persistent public key related to their identity that can enable secure communications and provide a link to the public key used in blockchain transactions, either through deterministic derivation of the identity key or by signing or encrypting transaction keys with the identity key.

[0117] There are two ways to identify a mining core node: 1) Miner ID. Miners may choose to identify themselves by adding an identity key to the coinbase transaction input in each block they mine. 2) Network analysis: Some miners choose to remain anonymous, however it is still possible to identify which nodes are constructing blocks by analyzing the network, for example by looking at where new blocks originate from.

[0118] It is important to be able to identify both types of miners so that nodes in the BLN can ask as many miners as possible whether their transactions have been accepted. Core nodes with Miner IDs can issue digital certificates to Layer 2 nodes. This may be because they have service level agreements with these nodes, or because these nodes have requested certificates for fees. In this sense, core nodes can act as Certificate Authorities (CAs).

[0119] With or without a certificate from a core node, a tier 2 node may seek an external CA to issue it a digital certificate. Thus, each tier 2 node may have at least one digital certificate that proves its identity. They may issue certificates to other nodes in tier 2, thereby creating a web of trust between them. tier 2 nodes may issue certificates to tier 3 nodes, which may issue certificates to tier 4 nodes, and so on, creating a hierarchy of certificates called a public key infrastructure (PKI).

[0120] In practice, the PKI may be used not only for the identification of nodes in the BLN, but also to ensure that the correct BLN structure is followed. For example, if a tier 3 node issues certificates to too many tier 4 nodes or does not ensure that it has proper connections to other nodes in the system, the tier 3 node's certificate may be revoked. These certificates may themselves be stored in the blockchain 150. This makes the PKI transparent and easily auditable.

[0121] Sequencing and Timestamping There may be some applications that can be implemented using blockchain where the order of application data is important. To address this, according to embodiments of the present disclosure, one or more nodes of the network may be configured to act as an attestation service to arbitrate between different items of data submitted to the service to determine the final order of the data items, and have that order immutably recorded on the blockchain.

[0122] The attestation service is implemented in one or more attestation nodes. In an embodiment, these are nodes of an overlay network that is superimposed on an underlying infrastructure network such as the Internet. However, it is not excluded that they may alternatively be nodes of an independent network, for example, the infrastructure of a private network within an organization. In any case, the one or more attestation nodes are adapted to receive items of data from one or more client nodes, form transactions that record the order of the received data items, and forward these transactions to one or more core nodes for recording in the blockchain 150. The core nodes are nodes 104 of the blockchain network 106. They may comprise mining nodes 104M, storage nodes 104S, or a combination thereof. In an embodiment, each of the core nodes is a mining node 104M and / or a storage node 104S (e.g., a full-copy node).

[0123] Each client node may be an end-user node comprising the computing equipment of a user of the service. This may be an individual user or an organization such as a company, academic institution, or government agency. Accordingly, each client node may comprise one or more user terminals and / or a server comprising one or more server units at one or more locations. Each client node comprises a memory comprising one or more memory units and a processing device comprising one or more processing units. These may take the form of either a memory medium and / or a processor, e.g., as discussed above in connection with other network elements or user equipment. The memory stores client software adapted to run on the processing device, which, when executed, is configured to cause the node to operate as a client of the attestation service provided by the attestation node, according to any of the following embodiments or the like. Optionally, one or more of the transmitting end-user nodes may comprise user equipment 103 of users 102 of the blockchain network 106, and the client software may comprise a blockchain wallet application 105, or the like. However, not all such transactions are necessarily orchestrated in the user's wallet 105, but the attestation service may be adapted to orchestrate at least some transactions on behalf of such end users.

[0124] The attestation nodes are adapted to provide an attestation service that arbitrates between client nodes and core nodes. Each attestation node may be in the form of a server comprising one or more physical server units. Each such node comprises a memory comprising one or more memory units and a processing unit comprising one or more processing units. These may take the form of either a memory medium and / or a processor, e.g., such as those previously discussed in connection with other network elements. The memory stores attestation service software adapted to run on the processing unit of the attestation node. When executed, this software is configured to provide an attestation service that operates according to any of the embodiments described below or the like. In embodiments, the identity of each attestation node may be authenticated by a certificate authority to enable client nodes, core nodes, and / or other attestation service nodes to verify the identity of the attestation node. The identity of each client node may be authenticated by a certificate authority to enable the attestation service node, core nodes, and / or other client nodes to verify the identity of the client node. Interaction between such nodes to provide or use the attestation service may be conditional on the verification. Alternatively or additionally, node versioning may be used as an alternative mechanism for node identification in the overlay network.

[0125] In an embodiment, the above configuration may be implemented in the form of a layered network 700, for example of the type described with respect to Figures 3 to 6 and also shown by way of example in Figure 7. That is, the layered network comprises a core network comprising a core node 701, at least one middle layer around the core, each middle layer comprising one or more middle layer nodes 702, and at least one outer layer around the outermost middle layers, each outer layer comprising one or more outer layer nodes 703. It should be noted here that the term "outside" in "outer layer" does not necessarily limit it to the outermost layer of the entire layered network 700, although this is one possibility. In an embodiment, the layered network 700 of FIG. 7 may be the layered network 300 of FIG. 3, in which case the outer layer nodes of FIG. 7 may be the third layer nodes of FIG. 3 or FIG. 4, the middle layer nodes 702 of FIG. 7 may be the second layer nodes 302 of FIG. 3 or FIG. 4, and the core nodes 701 of FIG. 7 may be the core nodes 301 of FIG. 3 or FIG. 4.

[0126] As discussed with respect to Figures 3-6, the layered network 700 may be an overlay network that is superimposed on an underlying physical or infrastructure network, such as the Internet. In such an embodiment, the nodes 701, 702, and 703 are configured to form connections between each other at the overlay network level. That is, the nodes 701, 702, and 703 of the layered network are configured to comply with an overlay network protocol that specifies which connections they can and cannot form with other nodes 701, 702, and 703 of the layered network. Thus, while all nodes may be physically able to connect to each other via the underlying infrastructure (e.g., the Internet), connectivity between such nodes 701, 702, and 703 may be more limited when they participate as nodes 701, 702, and 703 of the layered network and operate in accordance with the layered network's associated overlay network protocol. A connection between two nodes 701 / 702 / 703 of a layered network 700 means that the nodes can communicate directly, which in this context means that they do not have to perform a hop through another node 701 / 702 / 703 of the layered network 700. In the context of an overlay network, "connection" means a connection (i.e., an edge) at the level of the overlay network (i.e., at the level of the overlay network protocol of the layered network).

[0127] Each intermediate tier node 702 is connected to at least one core node 701 (blockchain network node 104) in a core network. The core network comprises at least a portion of the blockchain network 106. In embodiments, the core network may itself be a complete network.

[0128] In some cases, some of the middle tier nodes 702 and / or outer tier nodes 703 may comprise nodes other than the peripheral nodes 104 of the blockchain network 106, e.g., mining nodes 104M and / or storage nodes 104S, such as forwarding nodes 104F. Alternatively, they may comprise nodes that do not have any role (mining, storage, or forwarding) in the blockchain network 106 other than as clients of the blockchain network 106.

[0129] Each outer tier node 703 is connected to at least one of the middle tier nodes in at least one middle tier. In embodiments, each outer tier node 703 also has at least one connection to at least one core node 701 (i.e., to the blockchain network 106). In some such embodiments, one or more of the outer tier nodes 703 each have connections to more than one, but not all, of the core nodes 701. In embodiments, the multi-tiered network 700 as a whole may be an incomplete network, i.e., not every single node 701, 702, 703 has a connection to every single other node at the overlay network level. In embodiments, each node in a given tier may be connected to at least one other node in the same tier. For example, each node 702 in a middle tier may be connected to one or more other nodes in the same middle tier, and / or each node 703 in an outer tier may be connected to one or more other nodes in the same outer tier. In an embodiment, connections may also be formed between different middle layer nodes 702 in different middle layers and / or between different outer layer nodes 703 in different outer layers.

[0130] In an embodiment, the layered network 700 may be configured according to any of the protocol rules or structural features described with respect to Figures 3 to 6, with each intermediate layer of the intermediate nodes 702 being a layer between the core layer and the outermost layer, and each outer layer of the outer nodes 703 being a layer outside the second layer (the intermediate layer is between the core layer and the outer layer).

[0131] While the following embodiments are illustrated in the context of a multi-tiered network, this is not intended to be limiting, and more generally, it will be understood that a proof node can be any node in any type of overlay network that arbitrates between one or more client nodes and one or more core nodes 104 of a blockchain network 106.

[0132] In an implementation in the multi-tiered network 700, at least one of the intermediate nodes 702 in at least one intermediate tier assumes the role of a proof node 702A that provides proof services. At least one of the outer nodes 703 in the outer tier in the at least one outer tier is a client node 703C of the proof services provided by the proof node 702A. Each core node 701 is one of the nodes 104, preferably a miner 104M and / or a storage node 104S (e.g., a full-copy node), of the blockchain network 106. For ease of illustration, only two client nodes 703C and two proof nodes 702A are shown in FIG. 7, but it will be understood that there may be more proof nodes. In an embodiment, the client node 703C and the proof node 702A may be part of the same community as each other.

[0133] The client nodes 703C are clients at least in that they are clients of the attestation service. In embodiments, the client software running on one or more of the client nodes 703C may be further configured to cause that node 703C to operate as a client of one or more additional services provided by one or more second-tier nodes 702, such as a database service or a smart contract service. And / or it may be configured to cause that node 703C to operate as a client of one or more core nodes 701 (e.g., 104M, 104S) of the blockchain network 106, such as to be able to query the blockchain 150.

[0134] Also, the fact that client node 703C is described as a client of the attestation service (and optionally one or more other services) does not exclude the possibility that these nodes may themselves be providers of one or more additional services to one or more additional entities (not shown). For example, client node 703C may comprise the computing equipment of a company that offers online services to customers. As used herein, "end user" means an end user of the particular service in question, and is not necessarily limited to an individual consumer at the end of a commercial supply chain (although this is certainly one possibility).

[0135] The following describes how an ordering service entity 702A may use the blockchain 150 to record the order and time that data elements were received from one or more client nodes 703C. Optionally, the ordering service may perform time stamping.

[0136] The method is first described for a single trusted order proof node 702A, which may be modeled as a single middle-tier (e.g., second tier) node in a layered network 700 with a core of blockchain network nodes 104 / 701. Users of this service then become users of outer-tier (e.g., third tier) nodes 703C, which are directly connected to the service 702A and optionally also connected to the blockchain 150 (by connection to at least one core node 701 in the core).

[0137] As data elements are received from client nodes 703C in the outer tier, the middle tier time-stamping service 702A collects the data elements together in such a way that an order is established. After a period of time, e.g., 0.1 seconds, this ordered list of data elements is encapsulated into a transaction and sent via core 701 to blockchain 150, where it is immutably recorded. If a timestamp is added to the record, this also records the order along with the time.

[0138] An exemplary application is determining the final order between updates to, for example, database entries. In this case, each data item received from client node 703C may represent a respective change of state (i.e., update) to the database entry. However, such updates are not necessarily commutative, i.e., order matters. For example, if there are two requests to perform a non-commutative operation on data elements, such as a left-matrix multiplication, order matters. In another example, one may be a request to delete a file and the other may be a request to read the file. Again, the order in which these requests are applied makes a difference in the outcome.

[0139] Another exemplary application is implementing smart contracts in an output-based (e.g., UTXO-based) blockchain model. Because UTXO-based transactions and the like do not natively support smart contracts in the same way that transactions in an account-based model do, smart contract functionality needs to be layered on top of the basic transaction model when a smart contract is to be implemented in an output-based model such as a UTXO-based model. In this case, data items to be recorded on the blockchain 150 may still represent state changes such as changes in ownership. Again, order is important, as it may affect whether an attempted ownership assignment is legitimate, for example.

[0140] Another illustrative application is the ordering and time-stamping of digital certificates from a certificate authority (CA). Digital certificates are used to grant access rights or other electronic authorizations, for example, in SSL / TLS and HTTPS security, the foundation of the Internet. In 2011, a Dutch CA was compromised by an attacker believed to be operating from Iran. Fake certificates were issued for important domains, and log files were altered on the CA's servers. If these log files had been stored on a blockchain using an ordering and time-stamping service as described below, the security provided by proof-of-work would not have made it possible to modify the log files. It is worth noting that the private key of the company's HSM was compromised in the attack. This highlights the fact that classical cryptographic protocols alone cannot always be relied upon to ensure information security; it can be beneficial to rely on other mechanisms, such as proof-of-work, to make such attacks impractical.

[0141] In operation, the proving node 702A is adapted to receive multiple data items from one or more client nodes 703C via an overlay network connection between the middle tier and the outer tier. The data items may be labeled D herein for arbitrary terminology. The multiple data items in question may be received from the same client node 703C or different client nodes 703C, or some may be received from the same client node 703C and some from different client nodes 703C. They may be received directly via the connection between the client node 703C and the proving node 702A, or may be forwarded via one or more other nodes of the multi-tiered network therebetween (i.e., may be received via more than one hop between the transmitting client node 703C and the proving node 702A).

[0142] The proving node 702A is configured to determine the order of the multiple data items D, and therefore determines the sequence of the multiple data items. In an embodiment, the determined order is the order of receipt of the data items at the proving node 702A. However, it is not excluded that some other arbitration rules may be applied. For example, if the data items are time-stamped with the time of transmission or creation by the client node 703C that transmitted them, and the proving node 702A trusts these client nodes, the order may be the reported time of transmission or creation rather than the time of receipt. As another example, the order may depend on a priority scheme that gives different weights to different data items.

[0143] Whatever the determined order, the attestation node 702A authenticates this order by creating a series of blockchain transactions 152 for recording in the blockchain 150. The attestation node 702A generates a series of two or more such transactions, which may be labeled herein, in arbitrary terminology, as Tx0, Tx1, Tx2, .... The attestation node 702A includes an indication of one or more different sets of data items D in the payload of each successive transaction in the series of transactions Tx. The payload may be included in the non-consumable output of the respective transaction. Such output may be made non-consumable by an opcode, e.g., OP_RETURN, that terminates the locking script for that output. However, in other transaction protocols, the payload may be included in other ways. The set of one or more data items indicated in each successive transaction comes after the set indicated in the transaction immediately preceding that transaction in the series of transactions, according to the data item order determined by the attestation node 702A. That is, the order of the transactions in the series of transactions matches the order of the sets in the determined sequence of the data items.

[0144] The proving node 702A receives a set of transactions P1,P2,P3,... Create or otherwise determine a set of corresponding public / private key pairs for

[0145] The proving node 702A receives a set of transactions Tx0 → Tx1 → Tx2 → Tx3 → … The private key of each key pair is used to sign the corresponding transaction in

[0146] Transaction Tx1 includes the signature of P1 in the unlocking script in its input, transaction Tx2 includes the signature of P2, and so on. Each transaction also includes a payload containing an indication of the set of one or more data items D attested by the respective transaction, e.g., in the OP_RETURN field. This payload is signed by each signature (in embodiments utilizing a Script language, an appropriate SIGHASH flag may be used). The initial funding transaction Tx0 is constructed so that it can be unlocked by the signature P1. It may have an output point 0 with a dust value. As an example, Tx1 may be constructed as shown in FIG. 8. All subsequent transactions have the same structure. That is, Tx2 includes a signature using P2 in the input pointing to Tx1 to unlock Tx1, has a locking script in the output that can be unlocked by the signature of P3, and so on. The signatures can be verified by the blockchain network 106 based on the corresponding public keys of the key pairs. Funding transaction Tx0 may or may not include an indication of the first set of data items (the first set of data items in a sequence may be indicated in Tx0 or Tx1).

[0147] Note: The format shown in Figure 8 ignores transaction fees for simplicity. This can be accounted for by adding separate inputs and outputs to the transaction (e.g., managed by a proof service).

[0148] The OP_RETURN statement contains a payload called data1, which contains data element D, or a representation thereof, submitted by the user in the order attested by the attestation service, from the set attested by Tx1 (and similarly for data2 in Tx2, etc.). Because each transaction signs the hash of the previous transaction, this implies the order of payloads: data1, data2, data3, etc.

[0149] Once a blockchain transaction is accepted by the blockchain network 106, it cannot be feasibly double-spent. It also works by publishing an order that is attested to the attestation service provided by the attestation node 702A. This gives users of client nodes 703 confidence that the positions where data elements appear in the order attested by this attestation authority cannot be retroactively changed. Once such a transaction is mined in block 151, the order becomes even less likely to be changed, since replacing an existing block is computationally expensive.

[0150] In some embodiments, the set indicated in each transaction Tx0, Tx1, Tx2, ... consists of only a single data item of data items D per transaction (i.e., each data payload indicates only a single respective D). Alternatively, the set indicated in each such transaction may comprise multiple data items D per transaction (each data payload indicates a different respective set of multiple different data items D). In the latter case, the payload information also specifies the order of the data items D within each transaction's local set. This may be achieved, for example, by an ordered list included in the payload (e.g., the OP_RETURN output) and / or by an index indicating order mapped to the indication of each D. Examples are shown in Figures 9 through 11, which will be discussed in more detail shortly.

[0151] When multiple data items D are indicated per transaction, some basis is needed to determine which data items will be collected together per transaction. In principle, any scheme can be used to separate data items between transactions, but in embodiments, this may be done based on a common time interval. That is, all data items D received by the attesting node 702A in the first instance of the common time interval are included in the first transaction in the series of transactions, and all data items D received in the next instance of the common time interval are indicated in the next transaction in the series, and so on.

[0152] The exact timing of the intervals between transactions may be configured by the implementation, for example, transactions may be issued at 0.1 second intervals.

[0153] Each set of data items may be indicated in a transaction simply by explicitly ("in the clear") including the data items of that set in the payload of each transaction Tx. Alternatively or additionally, they may be indicated in a transformed form, such as a hash, encrypted form, or r-puzzle. Examples are discussed in more detail with respect to Figures 9 through 11. In the context of an ordering proof service, at a minimum, an "indication" of a data item herein means some information that allows a query node examining a transaction to verify the attested order of the data items. In some cases where the explicit value of data item D is not explicitly included in the transaction, this may require the query node to have some knowledge of the value of data item D and simply examine the transaction on-chain or in the memory pool 154 of the blockchain node 104 to confirm the expected order of those items.

[0154] In an embodiment, the proving node 702A may also include at least one timestamp in the payload of each transaction Tx0, Tx1, Tx2... in the sequence of transactions. The timestamp indicates the time the respective data item was received at the proving node 702A. If there is a single data item D per transaction, this may simply be the time of receipt of that data item. If there are multiple data items D per transaction Tx, each transaction payload may include a single timestamp indicating the arrival time of the set (e.g., the time interval at which they were received), or an individual timestamp for each data item D in the set.

[0155] When the attestation service submits a transaction containing a user's data to the blockchain 150, in some embodiments, it also sends this transaction to the client node 703 that submitted data item D. This is possible because the user in the outer tier (e.g., tier 3) is directly connected to the attestation node 702A in the middle tier (e.g., tier 2). In embodiments, because the client node 703 is also directly connected to the blockchain mining node 104M in the core and / or the storage node 104S, it may independently verify that transactions Tx0, Tx1, Tx2... were accepted by the blockchain network 106. Thus, the client node 703A can query the memory pool 154 of the miner 104M and / or query the actual blockchain 150 records on the storage node 104S to confirm that the expected ordering was attested. Other third-party nodes may also verify this in a similar manner via any appropriate connection in the blockchain network 106. In some embodiments, queries by client node 703A may be performed via a connection between client node 703C and the core using only an SPV-like connection as previously discussed with respect to Figures 3 through 6.

[0156] Optionally, the attestation service may also send to the client node 703C that submitted the data item the chain of transactions that preceded the transaction containing the client node's 703C data. This allows users to have confidence that there are no two conflicting chains of transactions submitted to the blockchain by the service in different orders. The length of the transaction chain must be appropriate for the level of trust desired by the user. This trust may be outsourced; for example, a certification authority may certify the accuracy of the transaction chain every hour.

[0157] In embodiments, client nodes 703C within a tier may also be connected to each other and can send each other (mined) transactions, including their and corresponding Merkle proofs. In embodiments, because each outer tier (e.g., tier 3) node is independently connected to the blockchain 150, they can verify that the Merkle proofs are correct. This allows users in the outer tier (e.g., tier 3) to agree on data ordering with only a minimal amount of temporary trust in the time-stamping service, before trust in the proof-of-work on the blockchain takes over.

[0158] Below we examine the OP_RETURN payload data1 in more detail. The goal is for the service to attest to the order in which data elements D1, D2, D3, ... were received over a time interval. Note that the data elements may represent a hash commit of the data relative to one another. It may be at the discretion of the user to choose to publish the data or to record a hash commit of the data instead.

[0159] There are several different ways in which the set of data items D and their relative order can be indicated within a transaction Tx. The simplest way is to simply index each element, and since OP_RETURN is signed, this can be proven by the time-stamping service. However, there are more clever ways to do this that provide further evidence of ordering and allow generalization to distributed time-stamping services.

[0160] Method 1.1: Hash Chain. A unique index i is assigned to each data element D i is assigned to the entry H in the hash chain. i is created. H i The value of depends on the data element and the previous element in the hash chain. This means that each element in the hash chain must have been created after the previous element, enforcing ordering. An example hash chain is shown in the table in Figure 9. This table is included in the transaction payload (data), and optionally, an explicit D column may or may not be included in the transaction.

[0161] One advantage of not explicitly including the value of D is that fewer bits need to be stored in the chain, since the hash can be smaller than D. This also means that if a user does not want to reveal the actual value of D, they do not need to be revealed. In any case, whether or not the value of D is explicitly included, another advantage of hash chains is that they make reordering more difficult. As an illustration, suppose there are 1000 data items D per transaction. Reordering these data items would then require 1000 hashes to be performed, which is computationally intensive. Thus, even if the attestation node 702A is not fully trusted, this gives the user additional confidence that the data items have not been reordered.

[0162] In some embodiments, each data element D iThe timestamp of the reception of i One way to do this is to include a timestamp in the preimage of each element of the hash chain.

[0163]

number

[0164] In this case, a column containing the time is also added to the table in Figure 9.

[0165] The OP_RETURN payload data1 consists of a table such as the one shown in Figure 9. The column "Data" may be omitted to save space or to keep the data elements secret, but note that in that case the only way someone could prove the order of the hash chain would be to know all the data elements.

[0166] Additional security may be provided by replacing the hash function with HMAC, which is described in RFC2104 and introduces a secret symmetric key into the hashing procedure, meaning that only someone with knowledge of the secret key may be able to prove the order of the data.

[0167] Method 1.2: Hash Chain with Merkle Tree. This example is similar to the hash chain in Figure 9, but instead of publishing the entire hash chain, the hash chain is turned into a Merkle tree and only the root is published. In this case, each data item D in the set is modeled as a leaf of a Merkle tree, and the Merkle root is included as an indication in the transaction. Note that the index of the data is implied by the order in which the data appears in the leaves of the Merkle tree. A Merkle proof can later be provided to the user to allow them to verify the existence of the data item and its location in the Merkle tree. This method saves space in the transaction because only 256 bits are required in the OP_RETURN payload for the Merkle root.

[0168] Additionally or alternatively, each data item may be represented in a transaction by a corresponding Merkle proof for its leaf. As will be familiar to those skilled in the art, a Merkle tree makes it possible to prove that a given data item is a member of a set, given a Merkle root and a Merkle proof for the data item (which is a chain of hashes between the root and the leaf).

[0169] Method 2.1: Chain of Signatures. In this method, a new public key is created for each data element D and the element is signed with that new public key. This is in line with the requirements for the time-stamping protocol outlined in RFC3161.

[0170] Consider the sequence of public keys and signatures shown in Figure 10. The idea is that each public key is generated based on the data that precedes it. Similar to a hash chain, each public key (and therefore signature) in the sequence can only be created with knowledge of the previous public key in the sequence, thus enforcing the order.

[0171] In a variation of this method, the entries in the table can each be a transaction in themselves.

[0172] Method 2.2: Chaining r-PUZZLE. R-puzzle is a recently published form of challenge and proof. It is based on the r part of an ECDSA signature (S, R) and provides a way to prove knowledge of a secret without revealing the secret. https: / / www.youtube.com / watch?v=9EHKvNuRcOA&t=978s and https: / / www.youtube.com / watch?v=CqqTCsLzbEA Please refer to.

[0173] An ECDSA (Elliptic Curve Digital Signature Algorithm) signature consists of the combination (S,R), where R is the x-coordinate of the public part of the ephemeral key pair. The same public key is used for each signature, but it is possible to chain ephemeral keys together. This gives the sequence shown in Figure 11. This may be included in the transaction payload (data) either instead of, or in addition to, any of the methods described above.

[0174] where R1 is a random ephemeral key, <S1,R 1i >(H(D i )) is the data H(D i ) is the ephemeral key R 1j This means that the .sigma.cert.P1 signature is signed by P1 using

[0175] In general, any of methods 1.1, 1.2, 2.1, and / or 2.2, and / or others, may be used individually or in conjunction to indicate the ordering of a set of data items D in a transaction payload (data).

[0176] Distributed Case: The above is described in a scenario where the order proof service is provided by an individual node 702A. It is also possible to provide such a service through multiple proving nodes 702A.

[0177] For example, consider a situation involving a distributed attestation service that uses a multi-tiered network 700 to achieve consensus, in which more than one of the middle-tier nodes 702 (e.g., tier 2 nodes) of Figure 7 takes on the role of attestation nodes.

[0178] Assume that the majority of attestation nodes 702A are well-behaved and wish to achieve consensus on the ordering and time-stamping of data to be disseminated around a community (as previously defined) consisting of attestation service nodes 702A and users 703C. Assume that there are N independent attestation service nodes 703A connected to the same subset of m core mining nodes 701, thus defining the community of the multi-tiered network 700. The fact that there are multiple middle-tier (e.g., tier 2) attestation nodes 702A allows many users in outer tiers (e.g., tier 3) to connect to nodes 702A in the middle tier (e.g., tier 2) without the load becoming too high (too many connections) on the middle-tier nodes.

[0179] Then, in a distributed case, for example, the problem to be addressed is how intermediate tier proof nodes 702A (e.g., tier 2 nodes) can reach consensus on the order of, for example, two data items D1, D2 submitted by two users, even if those data items arrive in a different order at one proof node 702A compared to another proof node.

[0180] One way to address this is to use threshold signatures, i.e., as discussed previously, at least M distinct signatures (M>1) are required to unlock transaction Tx, rather than just one. Consider an M-of-N threshold signature system, as described as applied to attestation service node 702A. This is achieved by using private key shares a1, a2, ..., a NAny subgroup of M participants can produce a signature share that, when combined, gives the signature of a message that unlocks the previous transaction in the chain.

[0181] Suppose one of the attestation service nodes 702A produces a candidate transaction Tx1 that includes an OP_RETURN payload data1, which is an ordered list of all data elements D that it has received over a chosen time period. This node may broadcast the candidate transaction to all other attestation service nodes 702A (or at least some of them), asking for their signature shares to sign the transaction. If they receive at least M signature shares (including their own), the transaction may be submitted to the blockchain network 106 and mined into a block 151. This ensures that the ordering of the data elements is agreed upon by at least M-of-N time-stamping services in the decentralized network.

[0182] How is a single attestation node 702A chosen to create a transaction? Above, we assumed that there is only one attestation service node 702A that created the candidate transaction Tx1, and that the other attestation nodes 702A agree on this. But what about the next candidate transaction? There are at least two options: (i) there is always one privileged attestation node 702A that creates the candidate transaction, or (ii) after each transaction is created, one of the attestation nodes 702A is randomly chosen to be the next node to create the next transaction. This may be a predetermined random sequence, or it may be a deterministic random selection based on a seed for the just-issued transaction Tx1. For example, the seed may be taken to be Tx1. Other distributed arbitration algorithms for distributed computing may also be possible.

[0183] Smart Contracts FIG. 12 illustrates an example system of smart contracts implemented in a multi-tiered network 1200 according to embodiments disclosed herein.

[0184] Layered network 1200 includes a core network with one or more core nodes 1201, at least one middle tier around the core, each middle tier including one or more middle tier nodes 1202, and at least one outer tier around the outermost middle tiers, each outer tier including one or more outer tier nodes 1203. Again, the term "outer" in "outer tier" is not necessarily limited to the outermost here, although this is also a possibility. Layered network 1200 may be an overlay network superimposed on an underlying physical or infrastructure network such as the Internet, or alternatively, may be a standalone network such as a private network within an organization.

[0185] The core nodes 1201 are nodes 104 of the blockchain network 106. They may comprise mining nodes 104M, storage nodes 104S, or a combination thereof. In an embodiment, each of the core nodes is a mining node 104M and / or a storage node 104S (e.g., a full-copy node).

[0186] In some cases, some of the middle tier nodes 1202 and / or outer tier nodes 1203 may comprise peripheral nodes 104 of the blockchain network 106, nodes other than mining nodes 104M and / or storage nodes 104S, such as forwarding nodes 104F. Alternatively, they may comprise nodes that do not have any role (mining, storage, or forwarding) in the blockchain network 106 other than as clients of the blockchain network 106.

[0187] The intermediary node 1202 comprises multiple smart contract nodes 1202SC across one or more intermediary tiers of the multi-tiered network 1200. Between them, the smart contract nodes 1202SC provide smart contract services to client nodes 1203C. Each of these smart contract nodes 1202SC is configured to maintain a record of the state of one or more smart contracts. In embodiments, state is disseminated among the smart contract nodes 1202SC, such that the state of at least some smart contracts is replicated across more than one smart contract node 1202SC. In some cases, each smart contract node 1202SC may store a copy of the state of every smart contract in the system. However, in other embodiments, each smart contract node 1202SC stores the state of only one or some of the smart contracts, and the state of each contract may be replicated across only some, but not all, of the smart contract nodes 1202SC.

[0188] Each smart contract node 1202SC may be in the form of a server comprising one or more physical server units. Each such node comprises a memory comprising one or more memory units and a processing unit comprising one or more processing units. These may be in the form of either a memory medium and / or a processor, e.g., such as those previously discussed with respect to other network elements. In addition to the database entries themselves, the memory stores database software adapted to be executed on the processing unit of the attestation node. This software, when executed, is configured to provide a database service operating according to any of the embodiments described below or the like.

[0189] In embodiments, the identity of each smart contract node 1202SC may be authenticated by a certificate authority to enable client node 1203C, core node 1201, and / or other smart contract nodes 1202SC or other intermediate-tier nodes (such as attestation service node 702A or smart contract nodes) to verify the identity of the smart contract node 1202SC. Interactions between such nodes may be conditional on verification. For example, client node 1203C may send a message to smart contract node 1202SC only on the condition that it has verified the identity of the smart contract node 1202SC based on the certificate. Additionally or alternatively, node versioning may be used as an alternative mechanism for node identification in the overlay network.

[0190] Each of the client nodes 1203C may be an end-user node comprising the computing equipment of a user of the smart contract service. Again, this may be an individual user or an organization such as a company, academic institution, or government agency. Accordingly, each client node may comprise one or more user terminals and / or a server comprising one or more server units at one or more locations. Each client node comprises a memory comprising one or more memory units and a processing device comprising one or more processing units. These may be in the form of either a memory medium and / or a processor, e.g., such as those previously discussed with respect to other network elements or user equipment. The memory stores client software adapted to run on the processing device, which, when executed, is configured to cause the node to operate as a client of the smart contract service provided by the smart contract node 1202SC, according to any of the following embodiments or the like. Optionally, one or more of the transmitting end-user nodes may comprise user equipment 103 of a user 102 of the blockchain network 106, and the client software may comprise a blockchain wallet application 105, etc.

[0191] In embodiments, the identity of each client node 1203C may be authenticated by a certificate authority to enable the smart contract node 1202SC, other intermediate nodes (such as the attestation service node 702A or smart contract nodes), the core node 1201, and / or other client nodes 1203C to verify the identity of the client node 1203C. Interactions between such nodes may be conditional on the verification. For example, the smart contract node 1202SC may accept a message from the client node 1203C only on the condition that it has verified the identity of the client node 1203C based on the verification. Alternatively or additionally, node versioning may be used as an alternative mechanism for node identification in the overlay network.

[0192] In embodiments, the layered network 1200 may be configured according to any of the protocol rules or architectural features described with respect to Figures 3 through 6 and / or 7. The nodes 1201, 1202, 1203 are configured to form connections between each other at an overlay network level when the layered network 1200 is an overlay network that is superimposed on an underlying infrastructure network such as the Internet. That is, the nodes 1201, 1202, 1203 of the layered network are configured to follow an overlay network protocol that specifies which connections they can and cannot form with other nodes 1201, 1202, 1203 of the layered network.

[0193] For example, in an embodiment, each middle tier node 1202 is connected to at least one core node 1201 (blockchain network node 104) in the core network. The core network comprises at least a portion of the blockchain network 106. In an embodiment, the core network may itself be a complete network. Each outer tier node 1203 may be connected to at least one of the middle tier nodes in at least one middle tier. In an embodiment, each outer tier node 1203 also has at least one connection to at least one core node 1201 (i.e., to the blockchain network). In some such embodiments, one or more of the outer tier nodes 1203 each have connections to more than one, but not all, of the core nodes 1201. In an embodiment, the entire layered network 1200 may be an incomplete network, i.e., each node 1201, 1202, 1203 does not have a connection to every single other node at the overlay network level. In an embodiment, each node in a given tier may be connected to at least one other node in the same tier. For example, each node 1202 in a middle tier may be connected to one or more other tiers in the same middle tier, and / or each node 1203 in an outer tier may be connected to one or more other tiers in the same outer tier. In embodiments, connections may also be formed between different middle tier nodes 1202 in different middle tiers and / or different outer tier nodes 1203 in different outer tiers.

[0194] A connection between two nodes 1201 / 1202 / 1203 of a layered network 1200 means that the nodes can communicate directly, which in this context means without having to perform a hop through another node 1201 / 1202 / 1203 of the layered network 1200. In the context of an overlay network, "connection" means a connection (i.e., an edge) at the level of the overlay network (i.e., at the level of the overlay network protocol of the layered network).

[0195] For ease of illustration, only two client nodes 1203C and two smart contract nodes 1202SC are shown in Figure 12, but it will be understood that there may be more nodes. In an embodiment, the client node 1203C and the smart contract node 1202SC may be part of the same community as each other.

[0196] The client nodes 1203C are clients at least in that they are clients of the smart contract service. In an embodiment, client software executing on one or more of the client nodes 1203C may further be configured to cause that node 1203C to operate as a client of one or more additional services provided by one or more second tier nodes 1202, such as an ordering proof service or a database service. And / or it may be configured to cause that node 1203C to operate as a client (e.g., 104M, 104S) of one or more core nodes 1201 of the blockchain network 106, such as to be able to query the blockchain 150. Also, the fact that the client nodes 1203C are described as clients of the smart contract service (and optionally one or more other services) does not preclude the possibility that these nodes may themselves also be providers of one or more additional services to one or more additional entities (not shown). For example, the client node 1203C may comprise the computing equipment of a company that offers online services to customers over the web.

[0197] In some embodiments, layered network 1200 of Figure 12 may be layered network 300 of Figure 3 or Figure 4. In this case, outer tier node 1203 of Figure 12 is third tier node 303 of Figure 3 or Figure 4, middle tier node 1202 of Figure 12 is second tier node 302 of Figure 3 or Figure 4, and core node 1201 of Figure 12 is core node 301 of Figure 3 or Figure 4.

[0198] In some embodiments, the multi-tiered network 1200 of Figure 12 may be the multi-tiered network 700 of Figure 7, where the outer tier node 1203 of Figure 12 is the outer tier node 703 of Figure 7, the middle tier node 1202 of Figure 12 is the middle tier node 702 of Figure 7, and the core node 1201 of Figure 12 is the core node 701 of Figure 7. In such embodiments, the attestation service of the attestation node 702A may be integrated into some or all of the same middle tier nodes 702 / 1202 as the smart contract node 1202SC, and / or the attestation node 702A may comprise separate middle tier nodes 702 / 1202 in the same and / or different middle tiers in the same and / or different communities.

[0199] In operation, one or more users of one or more client nodes 1203C determine the terms of the smart contract, which may be negotiated between users of two or more client nodes 1203C via one or more of the connections within one or more of the outer layers of the layered network 1200. Alternatively, the terms may be negotiated separately from the layered network 1200, for example, over the phone or in-person.

[0200] In any event, one of the nodes 1202 / 1203 in the outer or middle tier orchestrates at least a first transaction 152 to record the state of the smart contract on the blockchain 150. The state may comprise the complete terms of the contract or only one or more parameters of the contract, such as whether the contract is valid or expired, or who the current owner of the rights represented by the contract is.

[0201] In an embodiment, the first transaction is orchestrated at least in part by the client node 1203C and sent directly from the client node 1203C to the core tier via one of the connections in the layered network 1200 between the client node 1203C and at least one of the core nodes 1201. In this case, a separate step is required to inform at least one of the smart contract nodes 1202SC about the state of the smart contract. This may be done by sending a copy of the transaction to the smart contract node 1202SC, or by sending a separate message (not in the form of a transaction) that informs the smart contract node 1202SC of the relevant state of the smart contract. This may be done via one or more of the connections between the outer tier and the middle tier of the layered network 1200. Another option is for the smart contract node 1202SC to look up transactions as recorded in the blockchain 150 or in the minor memory pool 154 of the blockchain network 106 through one or more nodes 1201 (104) in the core layer. This lookup may be performed directly via a connection between the smart contract node 1202SC and one or more of the core nodes 1201 in the core layer, or alternatively, it may be performed via more than one hop to the core.

[0202] In other embodiments, the first transaction is orchestrated at least in part by the client node 1203C and sent to the smart contract node 1202SC for forwarding to the core layer 1201 for recording in the blockchain 150. In this case, the smart contract node 1202SC learns about the state of the smart contract from receiving the transaction from the client 1203C. The smart contract node 1202SC may receive the transaction directly from the client node 1203C via a connection in the layered network 1200 between the client 1203C and the smart contract node 1202SC. Alternatively, it may be received indirectly via more than one hop in the layered network 1200. The smart contract node 1202SC may forward the transaction to the core layer directly via a connection in the layered network between the smart contract node 1202SC and one or more of the core nodes 1201, or indirectly via more than one hop.

[0203] In a further possible embodiment, the first transaction may be at least partially orchestrated by smart contract node 1202SC. In this case, smart contract node 1202SC may send the first transaction to the core layer to be recorded in blockchain 150. It may send the first contract directly to the core via a connection in the layered network 1200 to one or more of the core nodes 1201. Alternatively, smart contract node 1202SC may send the first transaction indirectly to the core layer via more than one hop in the layered network 1200.

[0204] In some embodiments, one or more of the terms of the smart contract may be negotiated between two or more client nodes 1203C, and / or between one or more of the client nodes 1203C and the smart contract node 1202SC, by exchanging template versions of a first transaction. This negotiation process may involve each party adding its signature to the transaction upon receiving the template and approving the terms in question. Some examples are discussed below. In some such embodiments, the smart contract node 1202SC may determine the relevant state of the smart contract via the template used in the negotiation, even if it does not see the final version of the transaction before it is recorded on-chain.

[0205] Through any of the above routes, the smart contract node 1202SC learns about the state of the smart contract, which is also stored on the blockchain 150. It can then record that state in a local record maintained at the smart contract node 1202SC. In some embodiments, the smart contract node 1202SC may also propagate the state to one or more other smart contract nodes 1202SC, which also record the state in their own local records. Alternatively, there may be only one smart contract node 1202SC, or there may be multiple smart contract nodes 1202SC in the network 1200, each operating independently (without propagating state between them).

[0206] Any node that wishes to check the state of the smart contract can then check the state either from the smart contract node 1202SC, or from the blockchain 150 through the core node 1201, or from both.

[0207] For example, in embodiments, a client node 1203C may contact one of the smart contract nodes 1202SC to query the state of a smart contract without having to read the state from the blockchain 150 and without having to contact the core layer 1201. This reduces traffic with the core layer after the state is recorded. The state may be queried either from the smart contract node 1202SC that originally recorded the state or from the smart contract node 1202SC to which the state has been disseminated. The querying client node 1203C may be one of the parties to the smart contract or an interested third party. The query may be made directly via a connection in the layered network 1200 between the querying client node 1203C and the queried smart contract node 1202SC, or indirectly via more than one hop within the layered network 1200.

[0208] In another exemplary scenario, a client node 1203C or another smart contract node 1202C may query the state of a smart contract from both the smart contract node 1202SC and the core layer node 1201 and compare the results to ensure there is a consensus. Again, this query may be performed via a direct connection between the relevant pair of nodes 1201, 1202SC, 1203C in the multi-tier network 1200, or indirectly via more than one connection (more than one hop).

[0209] The state of the smart contract may be recorded in the first transaction in any one or more of a variety of possible formats. In embodiments, it may be explicitly recorded in the transaction's payload. Alternatively, the state may be recorded in the payload in a transformed form, such as a hash, which in itself only allows a node to verify that the state records a given knowledge of the expected state (the node cannot see the state from the record). This is sometimes called a "hash commit" of the state. However, in embodiments, the presence of a state transaction in the UTXO set may be interpreted as indicating what state the contract is in, i.e., it is a continuous event rather than a discrete one.

[0210] Payloads may be included in non-consumable outputs of a transaction. For example, outputs may be made non-consumable by including an opcode that terminates the respective locking script, e.g., OP_RETURN when using a scripting language (optionally, also including OP_FALSE before OP_RETURN in the locking script). However, other transaction protocols or scripting languages ​​may provide other means for including application-level payloads (i.e., user data) in transactions.

[0211] In another example of state information, one or more parties to a smart contract may be recorded in one or more outputs. This may be recorded in the payload of one or more non-consumable outputs (e.g., using OP_RETURN or OP_FALSE OP_RETURN), or alternatively, by locking one or more consumable outputs to the parties in question. For example, one output may be locked to party A and another output may be locked to party B to record that A and B are parties to a transaction, or one output may be locked to party A and one output may be locked to party T, where T is the contract trustee and operator of smart contract node 1202SC. In such cases, the public keys in the locking script serve as indicators of the parties to the smart contract. At the blockchain level, this key is used for the standard purpose of verifying the unlocking script of any transaction that attempts to consume the first transaction, but at the application level (i.e., as interpreted by the smart contract service and / or client software), this key is used to indicate the state of the contract (e.g., assignor or assignee).

[0212] In another example of state information, one of the outputs of a transaction may comprise a state puzzle, requiring a solution to the state puzzle to unlock. A set of one or more rules for forming the state puzzle may be stored in one of the smart contract nodes 1202SC. The smart contract node 1202C may be adapted to organize at least the state puzzle portion of the first transaction based on this set of rules as stored in the smart contract node 1202SC. Some examples of this are discussed in more detail below.

[0213] In embodiments, a change in the state of a smart contract may be recorded using a second transaction, for example, to record that the smart contract has expired or to record a change in ownership of an interest represented by the contract (e.g., a bond, etc.). The second transaction may be organized and stored in a manner similar to any of the techniques described above with respect to the first transaction. The new state may be recorded in the second transaction in any of the ways discussed above with respect to the first transaction.

[0214] In some such embodiments, the first and second transactions simply sign two unrelated source transactions (the first and second transactions are not chained together). In this case, the state change may be represented at the application level, rather than the blockchain level, by information contained in the application payloads (e.g., OP_RETURN outputs) of the two transactions. The application-level interpretation is assigned to the transaction by the smart contract service and its clients.

[0215] However, in other embodiments, the second transaction does not consume the output of the first transaction. Specifically, the first transaction may include an output comprising a state puzzle, and the second transaction includes an input that points to that output. The second transaction is required to include a solution to the state puzzle in order to unlock the output of the first transaction. At the blockchain level, this is a requirement for validating the second transaction for recording on the chain. At the application level, this is also interpreted as a condition for recognizing a state change. The smart contract node 1202SC may record the state change in its local record of the smart contract's state only on the condition that the second transaction provides a solution to the state puzzle.

[0216] In embodiments, two different mechanisms for recording state changes may be used together, each for recording a different hierarchical level of state information. A state puzzle mechanism is used to record changes to the initial state of a smart contract in one pair of a first and second transaction, and an OP_RETURN payload mechanism is used to record changes to the secondary state of the smart contract in another pair of a first and second transaction. For example, the initial state may comprise whether an interest, such as a bond, is valid or expired, and the secondary state may comprise the current ownership of the interest. In such cases, parallel states exist simultaneously. In embodiments, one state may trigger a change to another state. For example, in the case of an initial state and a secondary state, a change to the initial state may affect the secondary state (but not vice versa). Examples of implementing initial and secondary states and changes to them are discussed in more detail below.

[0217] In embodiments, the smart contract service may be implemented in conjunction with an ordering mechanism, such as the ordering service described previously, to determine the final order in which state changes should be applied. This may be useful, for example, in situations where various state changes for the same smart contract are being received from different client nodes 1203 and / or disseminated among various smart contract nodes 1202.

[0218] In some scenarios, multiple requests to update the same smart contract may be received at the same smart contract node 1202SC. To accommodate this, the smart contract node 1202SC may be configured to apply state changes in a specified order. In some embodiments, the specified order may be based on the time of receipt at the receiving smart contract node 1202SC or a timestamp added by the sending client node 1203C or the forwarding smart contract node 1202SC. Alternatively, the specified order may be asserted in one or more requests from one of the client nodes 1203C, or in a message from another of the smart contract nodes 1202SC or another intermediate tier node 1202, such as the attestation service node 702A, or from the core 1201. For example, the order may be asserted in the form of an ordered list of multiple updates or in the form of an ordinal index mapped to each update request.

[0219] In embodiments, the specified order may be recorded in the blockchain 150, for example, by the attestation service 702A discussed previously. In such embodiments, a client node 1203C initiating a state change may obtain the order from the attestation service 702A and submit it to the smart contract node 1202SC. In this case, the order attestation service 702 records the order in the blockchain 150 and returns a message with the specified order to the requesting client node 1203C (which is also the client 703C of the attestation service 702A). When the client 1203C makes a request to the smart contract node 1202SC to change the state of the smart contract, it also submits the order it obtained from the attestation service 702A. The smart contract node 1202SC checks this against the order recorded in the blockchain (or minor's memory pool 154) and applies the updates in the specified order, provided that the order submitted by the client 1203C matches the order recorded in the blockchain 150. This verification may occur directly via the connection between the smart contract node 1202SC and the core 1201, or alternatively via more than one hop.

[0220] Alternatively, the smart contract node 1202SC that records the state change may read the order directly from the blockchain 150 and apply the order as read from the blockchain 150 (or the minor memory pool 154).

[0221] In another variant, the attestation service 702A may be integrated into one or more of the smart contract nodes 1202SC. In this case, one of the smart contract nodes 1202SC takes on the role of determining the order (and optionally adding a timestamp) and recording it in the blockchain 150. The smart contract node 1202SC responsible for this order may disseminate the specified order to other smart contract nodes 1202SC around the connections between nodes in the intermediate tier. The other smart contract nodes 1202SC may verify this against the order recorded in the blockchain, or alternatively may read the order directly from the blockchain 150 (or in the miner's memory pool 154). This may be done directly via the connection between the smart contract node 1202SC and the core 1202, or alternatively via more than one hop.

[0222] A specific implementation is described herein by way of example to illustrate some of the principles behind the disclosed scheme. By way of illustration, reference is made to a smart contract node being implemented in layer 2 and a client (user) node in layer 3, although this can be generalized to any intermediate and outer layer, respectively.

[0223] Below, we present a use case for blockchain-based deterministic finite automata (DFA) using an overlay network layer. The network topology follows that defined by the Blockchain Layered Network (BLN) 1200 described above, with the core network consisting of full blockchain clients and the outer shell consisting of Simplified Payment Verification (SPV) nodes. These secondary SPV nodes follow a special set of subrules within a boundary set established by proof-of-work consensus in the core. Secondary nodes do not need to maintain a copy of the blockchain but can instead utilize the SPV paradigm to propagate state transitions according to some external data. Network layers can be identified using digital certificates or node versioning. An exemplary use case is described that allows different users in primary and secondary financial markets to trigger different states using smart contract nodes connected in the BLN topology.

[0224] Terminology: The following explains some of the terms used in the example use cases.

[0225] market: Primary Market - A direct offering of stocks or bonds from an issuer (corporation or government) is considered a primary market. Investment banks handle these transactions, and investors in the primary market are typically large institutional investors who purchase millions of securities at a time. Initial demand is difficult to predict, so selling prices are set low. This makes the primary market very volatile. There are elaborate regulatory procedures for issuing financial institutions to sell securities in the primary market.

[0226] Secondary Market - All trading of securities from issuers takes place in the secondary market between investors. This can take place on a stock exchange (e.g., NASDAQ) or over-the-counter (bonds). The price of a stock is determined by supply and demand between buyers and sellers, while in the primary market, the initial price is set by the issuer. After large institutional investors purchase large amounts of securities in the primary market, some buyers subsequently sell the shares in the secondary market for a profit, allowing investors of all sizes to get involved. While stocks are one of the most traded securities, investment banks, along with corporate and individual investors, trade mutual funds and bonds in the secondary market, while some entities also purchase mortgages in the secondary market.

[0227] Over-the-Counter - A network of decentralized dealers is a private alternative to centralized public exchanges. It allows for non-standard quantities to be sold, and prices are not disclosed until the transaction is completed, making it less transparent than an exchange. Bonds are typically traded in the over-the-counter (OTC) secondary market by investment banks, primarily because they are more diverse than stocks. Broker-dealers negotiate with each other via computer networks and often internally match clients' purchases and sales. Bond prices are affected by changing interest rates and credit ratings. OTC trading is most beneficial in terms of the liquidity it provides and provides significant protection for investors looking to sell bonds before maturity. However, because transactions are executed directly between two parties, they are not policed ​​or subject to the rules of a major exchange, which is sometimes seen as controversial.

[0228] Financial entities: A full blockchain client that stores, records, and updates transactions on the Bitcoin blockchain using the miner-proof-of-work (PoW) consensus mechanism.

[0229] Bond Issuer - A corporation or government entity that issues new bonds to investors or lenders.

[0230] Underwriter - An institutional investor, for example, an investment bank, that acts as a lender to the bond issuer.

[0231] Bond Dealer - Investors can trade marketable bonds among themselves, but trading usually takes place through bond dealers, or more specifically, through the bond trading desks of major investment dealers. These dealers are at the center of a large network of telephones and computer links that connect all interested participants. Dealers also have traders who know everything about a group of bonds and are responsible for setting the buying and selling prices, or "pricing" the bonds. Dealers provide "liquidity" to bond investors so they can buy and sell bonds more easily and with limited price concessions, but dealers can also buy and sell among themselves, either directly or anonymously through bond brokers.

[0232] Bond Investor - A user who purchases bonds. Depending on the size of the investor, bonds may be purchased from dealers in the secondary OTC market or directly from underwriters.

[0233] Brokers - Intermediaries in the secondary market allow anonymous transactions between bond dealers.

[0234] Bond Trustee - A bond trustee or fiscal agent is a trusted third party hired by a bond issuer to enforce the terms outlined in the financial agreement between the bond issuer and the bondholders. The trustee represents the interests of the bondholders.

[0235] Financial Agreement: Bond Purchase Agreement - An agreement between a bond issuer and an underwriter that sets out the terms of sale after private negotiations in the primary bond market. New bonds are not sold to the public but instead directly to underwriters.

[0236] Trust Indenture - A contract that sets out the terms of sale between a bond issuer and investors, i.e., bondholders, following a successful transaction between the relevant parties in the secondary bond market. While a bond purchase agreement is between the issuer and underwriters of a new issue, a trust indenture is a contract between the issuer and a trustee that represents the interests of investors.

[0237] Blockchain-based Deterministic Finite Automata::A Deterministic Finite Automata (DFA) is a finite state machine that accepts or rejects a given sequence of symbols by repeating a state sequence uniquely determined by that sequence. Given a state and an input, there is only one possible new state (possibly the same state), making the outcome of a computation (e.g., of a contract) unique.

[0238] In WO / 2018 / 078584, the states of a DFA are associated with unspent transaction outputs (UTXOs) on the blockchain. Note that the blockchain network continuously tracks all available UTXOs. WO / 2018 / 078584 demonstrates state transitions using the example of a zero-coupon bond (ZCB). This is a bond sold to investors at a deeply discounted price; investors do not receive coupons (interest payments) until the bond's maturity date, i.e., the face value is paid at some point in the future. ZCBs may be corporate, municipal, or treasury (government) bonds and are considered a form of long-term investment. The lack of periodic interest payments makes ZCBs easy to implement as DFAs, as the financial contract requires only simple state transitions (initial preparation and final payment or default). Table 1 summarizes the key features of a ZCB contract.

[0239] [Table 1]

[0240] DFA Transition Table: A DFA is defined as a finite set {S, I, t, s0, F} with the following elements: ·S is a finite set of possible states for the machine. ·I is a finite set of inputs that embodies the occurrence of any event or condition related to the contract, such as a payment being made, an instrument reaching maturity, or a counterparty defaulting. ·t:S×I→S is the transition function. ·s0 is the initial state. ·F⊆S is the set of all possible final outcomes.

[0241] Once all the above elements are established, the DFA is completely defined by a transition table, which specifies all possible current states and future states for an input.

[0242] Table 2 shows the transition table for the ZCB contract. The possible states are defined as S = {s0,f0,f1}, which means that Holding state (s0), and ·Denote the final state F={f0,f1} of the system F, where F is normal termination (if it follows a "happy path") or happy ending (f0), and -A situation heading in a negative direction, such as towards litigation (f1).

[0243] The input considered is I={r,d,e}, which means that · Repayment of principal at (or before) maturity (r), · default of the issuer at (or before) maturity; (d) · Expiration of contract without refund (e)

[0244] [Table 2]

[0245] Figure 13 shows the transition from the holding state to one of two final states. The mechanism by which a DFA moves from one state to another may be embodied by a blockchain transaction. Essentially, a blockchain transaction consumes UTXO associated with one state (the transaction's input) and creates UTXO associated with the next state (the output). The "origin" transaction (o), "transition" transactions (t0, t1), and "completion" transactions (c0, c1) are represented by blue triangles in the schematic.

[0246] Blockchain Layered Network for Smart Contracts: The present disclosure uses a Blockchain Layered Network (BLN) (e.g., 1200) as previously described to enforce state in a DFA system, such as that defined for ZCB in WO / 2018 / 078584.

[0247] In some embodiments, the system may employ a Simplified Payment Verification (SPV) paradigm, whereby only nodes outside the core layer 1201 forward a particular transaction according to the SPV protocol. A system of specialized smart contract nodes 1202SC is linked to the core blockchain network 106 of "mining nodes" 104, which reach consensus according to Proof of Work (PoW), while the former establishes a second layer of consensus (PoW or some other method). This means that transactions constructed by secondary nodes remain valid on the main blockchain system. The smart contract nodes 1202SC can forward states and conditions according to a defined state table (external data). If the format is not the same, the state transition is rejected by the middle and / or outer layers of the multi-layered network 1200.

[0248] In WO / 2018 / 078584, the status of a ZCB is determined by its creation and maturity, i.e., the outcome after the bond reaches maturity. However, since ZCBs are long-term investments, they may be subject to constraints. Therefore, investors may choose to sell their bonds in the secondary market.

[0249] Note that such transactions do not affect the state in the underlying DFA transition table, i.e., the state defined by the creation and maturity of new bonds. However, there is a dependency in the opposite direction: changes in the state of the DFA affect transactions in the market. Figure 14 shows how different states exist in parallel.

[0250] Figure 14 shows the secondary states (curly brackets) resulting from n transactions of a zero-coupon bond, which is now in the initial holding state (top) as defined by the blockchain-based DFA.

[0251] Smart Contract: A smart contract is simply a contract that uses software to facilitate, verify, or enforce the negotiation or execution of some or all parts of the contract. In an output-based (e.g., UTXO-based) model, a smart contract entity is a node that connects to the blockchain.

[0252] In the "SPV" paradigm, nodes outside of the core 1201 may not be able to "listen" to the blockchain other than using the standard SPV protocol, as doing so requires service-level agreements with mining nodes to send specific transactions to the node, which is not a lightweight solution. Note that in the absence of accounts, signing keys may be continually updated, making it difficult to identify transactions that may be related to a smart contract by simply scanning the blockchain.

[0253] In the embodiments disclosed herein, users of a smart contract submit transactions directly to the smart contract. Similarly, if a smart contract is allowed to create a transaction, the transaction is submitted directly to the user (both the user's transaction and the smart contract's transaction should also be submitted independently to the blockchain).

[0254] For robustness, an entire layer of smart contract nodes may be required (layer 2 in our network configuration). Smart contract transactions are propagated around this layer so that the state of the smart contract can be made consistent.

[0255] One reason for using a Blockchain Layered Network (BLN) is the ability to implement smart contracts. Preferably, there is more than one smart contract node 1202SC for robustness and load balancing, and users at Layer 3 send transactions directly to smart contracts at Layer 2, making the system SPV-friendly.

[0256] The smart contract node 1202SC may be part of the transaction fee. All smart contract nodes may work together.

[0257] Tier 2 and / or Tier 3 nodes may spread transactions around the community as they all hope to agree on the state of the smart contract.

[0258] Tier 2 and / or Tier 3 nodes may issue digital certificates that identify them and the rules of the agreement. This can be a permissionless system where nodes welcome people to join for a fee paid per transaction.

[0259] Network Topology: An overview of an example network topology is provided below in Table 3. Miners operate full nodes, while smart contracts and users operate SPV nodes, which reach consensus based on hash power (PoW). Smart contract nodes reach consensus using hash puzzles derived from details outlined in private bond purchase agreements (BPAs). Users reach agreement on transactions in the market using UTXO set membership to represent current bond holders and transactions containing digital certificates drafted from trust instruments (TIs).

[0260] [Table 3]

[0261] Figure 15 shows the entities specified in Table 3 as nodes connected in the BLN topology. Financial entities that trade in both primary and secondary markets appear as users at Layer 3. Therefore, multiple smart contract nodes are desirable to support load balancing when different users interact with each other.

[0262] Multiple communities may also form on account of various types of financial contracts that can be traded in the secondary market. For example, one type of ZCB arises from a "stripped" bond. This is when an investment bank separates the coupons from the bond and sells them separately; the remainder of the stripped bond and the coupons are traded separately in the secondary market. Both are tied to the same underlying condition that defines the remaining term of the bond, but different smart contracts are required to reflect the differences in the trust deeds (i.e., different agreements with the bondholders).

[0263] Bond Issuance, Trading, and Settlement Process: Table 4 lists the objects in an example setup.

[0264] [Table 4]

[0265] FIG. 16 shows a community of nodes connected in a BLN topology.

[0266] Some example methods of using BLNs to record the state and state changes of smart contracts will now be described with reference to Figures 17 through 19.

[0267] Phase I - Creating a new bond. This is an example of recording the initial state. See Figure 17.

[0268] Step S0: Alice hires Trudy as part of the ABC Inc. finance team to create the DFA structure and prepare a smart contract node that can be tied to this external data.

[0269] Step S1: Bob underwrites a new bond in the BPA after private negotiations with Alice.

[0270] Step S2: Alice checks the origin transaction TxID based on the conditions described in the BPA. O Set up and broadcast.

[0271] Step S3: The smart contract node uses TxID to mark the beginning of state s0 according to the DFA transition table. OValidate the UTXO set for. In some embodiments, as shown in the figure, this may optionally comprise the smart contract node (Trudy) querying a core node for the UTXO set. However, this is not limiting, and connecting to a mining node or other core node to validate the UTXO set is not necessarily required. For example, Trudy may maintain its own copy of the UTXO set locally on the smart contract node.

[0272] Phase II - Market Trading. This is an example of recording secondary states. See Figure 18.

[0273] Step S4: Bob creates a trade transaction template TxID to initiate the sale of the bond to Dean. tr In that template, Bob adds a consumable output to himself that shows the cost of the bond.

[0274] Step S5: Dean receives the partially complete TxID tr Add consumable output to Trudy at

[0275] Step S6: Trudy signs the Trust Instrument (TI) embedded in the null data output.

[0276] Step S7: Dean enters payment entry for the bond in TxID tr Sign the trade transaction by adding it to

[0277] Step S8: Bob signs the trade transaction to authorize the sale of the bond.

[0278] Step S9: Bob (or Trudy) broadcasts the complete trade transaction to the layer 1 nodes.

[0279] Steps S4 through S9 may be repeated for every tier 3 user trading bonds in the market (eg, Dean to Brock, Brock to Dean, Dean to Ivan, etc.).

[0280] Phase III - The bond matures or vice versa. This phase may involve recording the changes in the initial and secondary states. See Figure 19.

[0281] Initial state: Step 10: Trudy sends the transition transaction TxID to inform tf Initiate state changes in financial contracts by creating and broadcasting a. ABC Inc. pays the principal amount when the bond matures (input r → state f0), b. ABC Inc. defaults on a payment (input d → state f), or c. The contract expires without refund (input e → state f1).

[0282] Step S11: Trudy submits the complete transaction to inform the outcome of the financial agreement.

number

number

number

[0283] Secondary state: Step S12: Trudy receives the TxID re Revoke UTXO set membership in In step S11a, Trudy creates a payment transaction for the bond holder.

[0284] Comment on Phase I: The trustee stores the transition table externally, creates hash puzzles for each possible state of the DFA, and securely distributes them to all agents (i.e., smart contract nodes) that are allowed to participate in the execution of the contract.

[0285] Payment for the new bond can be processed on-chain or off-chain. Note that if on-chain, this transaction is independent (i.e., not chained) to subsequent transactions, since the creation of the BPA involves private negotiation between the bond issuer and underwriter.

[0286] FIG. 20 shows a schematic diagram of an exemplary origin transaction conforming to WO / 2018 / 078584.

[0287] The BPA conditions are embedded in the locking script of the origin transaction shown in Figure 20 as a hash puzzle given by the table below.

[0288] [Table 5]

[0289] Once the solution to the hash puzzle is given, the transaction is considered spent, which causes a change in the state of the contract, which is broadcast and confirmed in the core blockchain network.

[0290] The difference between the input and output values ​​in Figure 20 is the fee charged by the miner and smart contract node (the latter is explicitly included as an output in the last transaction in Figure 27).

[0291] Comments on Phase II: The trade transaction may be in the form of a Merchant Point of Sale Template, (i) Use UTXO set membership for current bond holders; (ii) Provides an economic incentive for smart contract nodes to broadcast details of new investments around the network (once a TI transaction is mined on the blockchain). To do this, the trust deed contract includes a null data output to the trustee along with a consumable output to the trustee.

[0292] Note that the trustee consumes the output from the previous "trade" transaction (if one exists) to indicate the change of ownership according to UTXO set membership. The trust deed includes the signatures of the bond issuer and the trustee on behalf of the new bondholder. An additional transaction input (a minimal amount, i.e., dust amount) includes the seller's signature to indicate that the bond sale was approved by both parties. In OTC markets, new investors may purchase bonds from dealers, who in turn may purchase them from brokers, and both dealers and brokers take a commission on top of the fee transmitted to the trustee.

[0293] Figure 21 is a schematic diagram of a partially completed trade transaction at step B4: Bob is adding a payment to himself for the sale of a bond.

[0294] Figure 22 is a schematic diagram of a partially complete trade transaction in step S5. Dean adds a consumable output destined for Trudy to handle any future transactions, i.e., UTXO set membership revocation in this example.

[0295] Figure 23 is a schematic diagram of a partially completed trade transaction at step S6: Trudy drafts and signs a trust deed, which is embedded as a digital certificate and includes a signature from the bond issuer.

[0296] Figure 24 is a schematic diagram of a partially completed trade transaction at step S7: The Dean adds an entry to pay for the bond.

[0297] Figure 25 is a schematic diagram of the complete trade transaction in step S8. Bob approves the final transaction and broadcasts it to the blockchain network (or sends it to Trudy for broadcast).

[0298] A comment on Phase III: The successive transitions of the contract execution are performed by smart contract nodes. They obtain the solution of the puzzle corresponding to the current state (s0), interact with the world (external state, e.g., the maturity date) to receive the appropriate input, read the transition tables (or only the part of them that corresponds to the current state), and then determine the appropriate next state (f f ) they can then submit transactions to the blockchain, and if they successfully place a transaction, they get a fee and the DFA goes to state f f becomes.

[0299] The difference between the input and output values ​​in Figure 20 are the fees charged by the miners and smart contract nodes, the latter of which is explicitly included as an output in the final transaction in Figure 27. The first output in Figure 27 returns any unspent funds to the originator (the bond issuer, Alice).

[0300] Figure 27 is a schematic diagram of a transition transaction that conforms to WO / 2018 / 078584.

[0301] Figure 28 is a schematic diagram of a UTXO set retraction transaction.

[0302] The above presented a BLN topology to facilitate the use of smart contracts and blockchain-based DFAs, among others. Systems of dedicated nodes operating under different consensus mechanisms are added to a single network topology. Utilizing the SPV paradigm allows for lightweight communication between nodes in different layers of the BLN. This concept was illustrated with a use case based on trading in financial markets to show how different users can effectively transact with each other and with smart contract nodes.

[0303] conclusion It will be understood that the above embodiments have been described by way of example only. More generally, a method, apparatus or program may be provided according to any one or more of the following statements:

[0304] Statement 1: A method of maintaining a state of a smart contract in a multi-tiered network, the multi-tiered network comprising: a core tier comprising one or more core nodes; one or more middle tiers each comprising one or more middle tier nodes; and one or more outer tiers each comprising one or more outer tier nodes, each of the core nodes being a node of a blockchain network, one or more of the middle tier nodes being smart contract nodes that provide a smart contract service for maintaining the state of the smart contract, and one or more of the outer tier nodes being client nodes of the smart contract service, the method comprising: recording, by a first of the one or more smart contract nodes, the state of the smart contract in a state record maintained at the first smart contract node, and at least a first transaction that also records the state is recorded in a blockchain of the blockchain network.

[0305] It will be understood that "first" in this context is merely an arbitrary designation for a given node of smart contract nodes, and does not, in itself, necessarily imply any special status vis-à-vis other smart contract nodes.

[0306] Statement 2: The one or more smart contract nodes are a plurality of smart contract nodes, and the method comprises disseminating, by a first smart contract node, the state to smart contract state records maintained at other smart contract nodes, the disseminating being performed via one or more connections between the smart contract nodes in one or more intermediate tiers of the multi-tiered network.

[0307] Statement 3: The method of statements 1 or 2, wherein the first transaction is transmitted by one of the client nodes to at least one of the core nodes to be recorded on the blockchain.

[0308] Statement 4: The method of any preceding statement, comprising transmitting, by the first smart contract node, the first transaction from the first smart contract node to at least one of the core nodes for recording on the blockchain.

[0309] Statement 5: The method of statement 3, wherein the first transaction is transmitted directly to at least one core node via at least one connection in the multi-layered network between said one of the client nodes and the core layer.

[0310] Alternatively, it may be transmitted over more than one hop.

[0311] Statement 6: The method of statement 4, wherein the method comprises receiving, by a first smart contract node, a first transaction from the one of the client nodes at the first smart contract node, and wherein the transmitting by the first smart contract node comprises forwarding the first transaction to at least one core node.

[0312] Statement 7: The method of statement 6, wherein one or both of the receiving is performed directly via a connection in the layered network between the first smart contract node and the one of the client nodes, and / or the transferring is performed directly via at least one connection in the layered network between the first smart contract node and the core layer.

[0313] Alternatively, either or both of the receiving leg and the forwarding leg may be via more than one hop.

[0314] Statement 8: The method of any preceding statement, wherein the first transaction is initiated by one of the client nodes.

[0315] Statement 9: The method of any of statements 1 to 7, wherein the first transaction is initiated by a first smart contract node.

[0316] Statement 10: The method of any preceding statement, wherein the state record maintained in at least one of the smart contract nodes is made available to at least one of the client nodes.

[0317] Statement 11: The method of statement 10, wherein the making available enables at least one client node to determine the state without having to query a record on a blockchain.

[0318] Statement 12: The method of statements 10 or 11, wherein the record is made available directly via a connection in the multi-tiered network between at least one smart contract node and at least one client node.

[0319] Alternatively, this can be done via more than one hop.

[0320] Statement 13: The method of any of statements 10 to 12, comprising the first smart contract node performing the making available by making available to at least one client node a record of state maintained at the first smart contract node.

[0321] This may be done directly via a connection in the layered network between the first smart contract node and the client node, or indirectly via more than one hop.

[0322] Statement 14: The method of any of statements 10 to 13, dependent on statement 2, wherein a record maintained in at least one of the other smart contract nodes to which the state is disseminated is made available to at least one client node.

[0323] Again, this may be done directly via a single hop in a layered network, or indirectly via multiple hops.

[0324] Statement 15: The method of any preceding statement, wherein at least one of the smart contract nodes examines records on the blockchain or in a miner's memory pool to verify the state of the smart contract.

[0325] Statement 16: The method of statement 15, wherein at least one smart contract node performs the investigation directly via a connection in the layered network between the at least one smart contract node and at least one of the core nodes.

[0326] Statement 17: The method of statement 15 or 16, wherein the method comprises a first smart contract node performing the investigation.

[0327] Statement 18: The method of statements 15, 16, or 17, wherein the investigation is performed by another node of the smart contract nodes other than the first smart contract node.

[0328] Statement 19: The method of any preceding statement, wherein at least one of the client nodes examines the blockchain or a miner's memory pool to verify the state of the smart contract.

[0329] For example, in embodiments, this may be a secondary state such as ownership. For example, a client node may confirm the UTXO set for the current bond holder.

[0330] Statement 20: The method of statement 19, wherein the investigation by at least one client node is performed via a direct connection in the multi-layered network between the client node and a core layer.

[0331] Alternatively, this can be done via more than one hop.

[0332] Statement 21: The method of any preceding statement, wherein the first transaction comprises one or more inputs, each comprising a cryptographic signature of a respective party to a smart contract.

[0333] Statement 22: The method of any preceding statement, wherein the first transaction input comprises a cryptographic signature of the operator of the first smart contract node.

[0334] Statement 23: The method of any preceding statement, wherein the first transaction comprises one or more outputs, each comprising a locking script that locks the output to a respective party to the smart contract.

[0335] Statement 24: The method of any preceding statement, wherein the first transaction includes an application-level payload comprising one or more conditions of a smart contract.

[0336] Statement 25: The method of any preceding statement, wherein the method comprises signing, by the first smart contract node, at least a portion of the payload including at least one of the conditions with a cryptographic key associated with the first smart contract node.

[0337] Statement 26: The method of statement 24 or 25, wherein the payload is included in a non-consumable output of the first transaction.

[0338] In embodiments, non-consumable outputs may be made non-consumable by including an opcode in each locking script for that output that terminates the respective script. For example, this may be an OP_RETURN opcode.

[0339] Statement 27: The method of any preceding statement, wherein the recording of the state to a record maintained at a first smart contract node comprises recording a first state of the smart contract and recording a change in the state of the smart contract, the change compared to the first state, wherein the first state is recorded in a first transaction on the blockchain and the change in state is recorded in a second transaction on the blockchain.

[0340] Statement 28: The method of statement 27, wherein the first transaction comprises outputs comprising respective locking scripts comprising a state puzzle, such that a solution to the state puzzle is required to unlock the respective locking script, and the method comprises: using a set of rules stored in the first smart contract node, by a first smart contract node, to compile a state puzzle based on the set of rules and include the state puzzle in the first transaction before recording to the blockchain; and wherein the second transaction comprises inputs pointing to the respective outputs comprising the state puzzle, and recording the change in the state of the smart contract in a record maintained at the first smart contract node, under the condition that the inputs provide a solution to the state puzzle.

[0341] Statement 29: The method of any preceding statement, wherein the first transaction is negotiated between at least two of the client nodes via at least one connection within one or more outer layers of the multi-layered network.

[0342] For example, this may comprise exchanging template versions of the first transaction. In an embodiment, a first user of a first of the two client nodes agrees to a template transaction with a second user of a second of the two client nodes. This may comprise adding, as part of the negotiation, respective outputs locked to one of the parties. One of the two nodes may also add outputs locked to the operator of the first smart contract node. One of the two client nodes then sends this template transaction to the first smart contract node, signing it with a cryptographic signature associated with the smart contract node (e.g., signing terms included in the payload). The first smart contract node then returns the signed template to one of the first and second nodes, where the user of that node adds a signature (e.g., to the inputs) and sends it to the other client node so that the user of that client node can add a signature. One of the client nodes then sends the complete signed transaction, including all three signatures, to the core layer to be recorded on the blockchain. For example, a party selling rights represented by a contract such as a bond may have an incentive to do so. This final transmission step may be directly to the core, or may be via a first smart contract node that forwards it to the core.

[0343] Statement 30: The method of any of statements 2 through 7, 10 through 20, or 29, wherein communication between at least some nodes of the multi-layered network, including one or more of the disseminating, transmitting, receiving, forwarding, making available, investigating, and / or negotiating, is performed using a communication protocol.

[0344] In embodiments, the communication protocol may be a communication protocol in which messages are in the form of: a) a transaction sent from a client node to a core node; b) a query from the client node to the core node as to whether the transaction was accepted into the miner's memory pool, and a corresponding response from the core node; c) a request from the client node to the core node for a Merkle proof that the transaction was mined into a block, and a response from the core node with the Merkle proof; and / or d) a request from the client node to the core node for a list of block headers, and a response from the core node with the list of block headers.

[0345] In embodiments, associated client nodes and / or smart contract nodes may be configured to use only a) through d) when communicating over a connection with at least one core node.

[0346] In embodiments, the protocol may be an SPV protocol.

[0347] In embodiments, all communications between client nodes and smart contract nodes may use the protocol. In embodiments, all communications between different client nodes may use the protocol. In embodiments, all communications between different smart contract nodes may use the protocol. In embodiments, all communications between client nodes and core nodes may use the protocol. In embodiments, all communications between smart contract nodes and core nodes may use the protocol.

[0348] In embodiments, all communications between outer tier nodes and middle tier nodes may use the protocol. In embodiments, all communications between different outer tier nodes may use the protocol. In embodiments, all communications between different middle tier nodes may use the protocol. In embodiments, all communications between outer tier nodes and core nodes may use the protocol. In embodiments, all communications between middle tier nodes and core nodes may use the protocol.

[0349] Statement 31: The state record at the first smart contract node comprises recording a plurality of state changes, which are also recorded in one or more transactions on the blockchain, the one or more transactions comprising at least a first transaction, and the method comprises determining, by the first smart contract node, an order of the state changes; and applying the state changes in the record maintained at the first smart contract node in accordance with the order.

[0350] Statement 32: The method of statement 31, wherein determining the order comprises receiving the order from an ordering service implemented in one or more of the intermediate tier nodes of the multi-tier network.

[0351] In embodiments, the ordering service node may be part of the same community as the first smart contract node.

[0352] Statement 33: The method of statements 31 or 32, wherein the order is recorded on a blockchain.

[0353] STATEMENT 34: The method of any preceding statement, wherein the core layer is complete.

[0354] That is, every core node in the core layer has a connection to every other core node in the core layer in the multi-layered network.

[0355] Statement 35: The method of any preceding statement, wherein the layered network as a whole is incomplete.

[0356] That is, not every node in every layer has a connection to every other node in every other core layer in the layered network, and in some such embodiments, every single node in a given layer may not even necessarily have a connection to every single other node in the same layer.

[0357] Statement 36: A computing device comprising: a memory comprising one or more memory units; and a processing device comprising one or more processing units, wherein the memory stores code adapted to be executed on the processing device, the code being configured, when executed on the processing device, to cause the computing device to operate as the first smart contract node by performing the method of any preceding statement.

[0358] Statement 37: A computer program embodied on computer-readable storage configured to, when executed on one or more processors, perform the method of any of statements 1 to 35.

[0359] Statement 38: A method comprising: communicating information regarding a smart contract between two or more nodes of a first network using one or more messages of a communication protocol; and causing a state of the smart contract to be stored in a record on a smart contract node of the network that provides a smart contract service, wherein the state of the smart contract is also stored in a blockchain of the blockchain network.

[0360] In embodiments, the communication protocol may be a communication protocol in which messages are in the form of: a) a transaction sent from a client node to a core node; b) a query from a client node to a core node as to whether the transaction was accepted into the miner's memory pool and a corresponding response; c) a request for a Merkle proof that the transaction was mined into a block and a response comprising the Merkle proof; and / or d) a request for a list of block headers and a response comprising the list of block headers.

[0361] In an embodiment, the communication protocol may be SPV.

[0362] In embodiments, the first network may include core nodes that are nodes of the blockchain network and non-core nodes other than nodes of the blockchain network. The communication may be performed between the non-core nodes or between one of the non-core nodes and one of the core nodes. The core node and the non-core node may include a smart contract node. The communication may be between the smart contract node and one of the core nodes. The method may be performed by the smart contract node. The non-core node may include a client node that is a client of the smart contract node. The communication may be between the client node and the smart contract node. The method may be performed by the smart contract node or the client node or a combination.

[0363] In embodiments, the communication may comprise negotiating a smart contract, e.g., by exchanging template versions of transactions. The causing to be stored may be based, at least in part, on the communication, e.g., on the negotiation. Alternatively or additionally, the communication may comprise querying the state of the contract, e.g., from a smart contract node or from one of the core nodes.

[0364] A transaction may be submitted by one of the smart contract nodes or client nodes to be recorded on the blockchain, for example by submitting it to one of the core nodes.

[0365] Statement 39: A computing device comprising a memory having one or more memory units, a processing device having one or more processing units, and a network interface having one or more network interface units, wherein the memory stores code adapted to be executed on the processing device, and the code, when executed on the processing device, is configured to cause the computing device to perform the method of statement 38, including communicating one or more messages via the network interface.

[0366] Statement 40: A computer program embodied on computer-readable storage configured to, when executed on one or more processors, perform the method of statement 38.

[0367] According to another aspect disclosed herein, there may be provided a method performed by a client node comprising the operations of any of the client nodes disclosed herein. According to further aspects, there may be provided a client node configured to perform such a method, and a computer program for operating a node as a client node in accordance with such a method. According to further aspects, there may be provided a method comprising any one or more of the smart contract nodes and any one or more operations of the client node. According to yet further aspects, there may be provided a corresponding system.

[0368] Other variations and uses of the disclosed techniques may become apparent to those skilled in the art given the disclosure herein, and the scope of the disclosure is limited only by the appended claims, and not by the described embodiments. [Explanation of symbols]

[0369] 100 systems 101 Packet-switched networks, Internet 102 Computer terminals and computer equipment 102a Computer Equipment 102b Computer Equipment 103 Users and related parties 103a First Person 103b Second Person 104 nodes, peripheral nodes 104F forwarding node 104M minor nodes, mining nodes 104S storage node 105 Client applications, blockchain wallet applications 106 Peer-to-peer (P2P) overlay networks, blockchain networks, P2P validation networks 150 Blockchain 151 blocks, data 152 transactions 152i Transactions 152j Transaction 153 Genesis Block 154 Pool 155 Block Pointer 201 Header 202 Input Field 203 Output Fields 300 LN 301 Core Node 302 Second Node 303 outer node 304 outer node 305 outer nodes 400 LN, multi-layer network 500 LN, multi-layer network 600 LN, multi-layer network 700 LN, multi-layer network 701 nodes 702 nodes 702A Certification Service Node 703 nodes 703C User 1200 LN, multi-layer network 1201 core nodes 1202 middle-tier nodes 1202SC Smart Contract Node 1203 outer layer nodes 1203C client node

Claims

1. 1. A method of maintaining a state of a smart contract in a multi-tiered network, the multi-tiered network comprising: a core tier comprising one or more core nodes; one or more middle tiers each comprising one or more middle tier nodes; and one or more outer tiers each comprising one or more outer tier nodes, each of the core nodes being a node of a blockchain network, one or more of the middle tier nodes being smart contract nodes providing a smart contract service for maintaining the state of the smart contract, and one or more of the outer tier nodes being client nodes of the smart contract service, the method comprising: recording the state of the smart contract in the state record maintained at the first smart contract node; At least a first transaction that also records the state is recorded on a blockchain of the blockchain network.

2. the one or more smart contract nodes are a plurality of smart contract nodes, and the method further comprises, by the first smart contract node:

2. The method of claim 1, further comprising: propagating the state to records of the state of the smart contract maintained at other smart contract nodes, wherein the propagating is performed via one or more connections between smart contract nodes in the one or more intermediate tiers of the layered network.

3. 3. The method of claim 1, wherein the first transaction is transmitted by one of the client nodes to at least one of the core nodes to be recorded on the blockchain.

4. 4. The method of claim 1, comprising transmitting, by the first smart contract node, the first transaction from the first smart contract node to at least one of the core nodes to be recorded on the blockchain.

5. 4. The method of claim 3, wherein the first transaction is transmitted directly to the at least one core node via at least one connection in the multi-tiered network between the one of the client nodes and the core layer.

6. by the first smart contract node, receiving the first transaction from the one of the client nodes at the first smart contract node; 5. The method of claim 4, wherein the transmitting by the first smart contract node comprises forwarding the first transaction to the at least one core node.

7. the receiving is performed directly via a connection in the multi-tiered network between the first smart contract node and the one of the client nodes; and / or and / or the transfer is performed directly via at least one connection in the layered network between the first smart contract node and the core layer.

8. 8. The method of claim 1, wherein the first transaction is initiated by one of the client nodes.

9. 8. The method of claim 1, wherein the first transaction is initiated by the first smart contract node.

10. 10. The method of claim 1, wherein the record of the state maintained in at least one of the smart contract nodes is made available to at least one of the client nodes.

11. 11. The method of claim 10, wherein the making available enables the at least one client node to determine the state without having to query the record on the blockchain.

12. 12. The method of claim 10 or 11, wherein the record is made available directly via a connection in the multi-tiered network between the at least one smart contract node and the at least one client node.

13. 13. The method of any one of claims 10 to 12, comprising: the first smart contract node performing the making available by making the record of the state maintained at the first smart contract node available to the at least one client node.

14. 14. A method according to any one of claims 10 to 13 when dependent on claim 2, wherein the record maintained in at least one of the other smart contract nodes to which the state is disseminated is made available to the at least one client node.

15. 15. The method of any one of claims 1 to 14, wherein at least one of the smart contract nodes is adapted to examine the records on the blockchain or in a miner's memory pool to verify the state of the smart contract.

16. 16. The method of claim 15, wherein the at least one smart contract node is adapted to perform the investigation directly via a connection in the layered network between the at least one smart contract node and at least one of the core nodes.

17. 17. The method of claim 15 or 16, comprising the first smart contract node performing the investigation.

18. 18. The method of claim 15, 16, or 17, wherein the investigation is performed by a node other than the first smart contract node that is another of the smart contract nodes.

19. 19. The method of claim 1, wherein at least one of the client nodes consults the blockchain or a miner's memory pool to ascertain the state of the smart contract.

20. 20. The method of claim 19, wherein the probing by the at least one client node is performed via a direct connection in the layered network between the client node and the core layer.

21. 21. The method of claim 1, wherein the first transaction comprises one or more inputs, each input comprising a cryptographic signature of a respective party to the smart contract.

22. 22. The method of any one of claims 1 to 21, wherein the first transaction input comprises a cryptographic signature of an operator of the first smart contract node.

23. 23. The method of any one of claims 1 to 22, wherein the first transaction comprises one or more outputs, each comprising a locking script that locks the output to a respective party to the smart contract.

24. 24. The method of any one of claims 1 to 23, wherein the first transaction includes an application-level payload comprising one or more conditions of the smart contract.

25. by the first smart contract node, 25. The method of any one of claims 1 to 24, comprising signing at least a portion of the payload including at least one of the conditions with a cryptographic key associated with the first smart contract node.

26. 26. The method of claim 24 or 25, wherein the payload is included in a non-consumable output of the first transaction.

27. The recording of the state in the record maintained at the first smart contract node comprises: recording a first state of the smart contract; and recording a change in the state of the smart contract, the change compared to the first state; 27. The method of any one of claims 1 to 26, wherein the first state is recorded in a first transaction on the blockchain and the change in state is recorded in a second transaction on the blockchain.

28. the first transaction comprises an output comprising a respective locking script comprising a state puzzle, such that a solution to the state puzzle is required to unlock the respective locking script, and the method further comprises, by the first smart contract node: using a set of rules stored in the first smart contract node to organize the state puzzle based on the set of rules and include the state puzzle in the first transaction prior to recording it on the blockchain; 28. The method of claim 27, comprising: recording the change in the state of the smart contract in the record maintained at the first smart contract node, under the condition that the second transaction comprises inputs that point to the respective outputs that comprise the state puzzle, and the inputs provide a solution to the state puzzle.

29. 29. The method of claim 1, wherein the first transaction is negotiated between at least two of the client nodes via at least one connection within one or more outer layers of the layered network.

30. and wherein communication between at least some nodes of the multi-layered network, including one or more of the disseminating, transmitting, receiving, forwarding, making available, probing, and / or negotiating, is performed using a communication protocol, wherein messages are a) A transaction sent from a client node to a core node, b) A query from a client node to a core node as to whether the transaction has been accepted into the minor memory pool, and a corresponding response from said core node; c) a request from a client node to a core node for a Merkle proof that a transaction has been mined into a block, and a response from said core node comprising said Merkle proof; and / or d) A request from a client node to a core node for a list of block headers, and a response from said core node with said list of block headers.

30. The method of any one of claims 2 to 7, 10 to 20, or 29, wherein the method is of the form:

31. the recording of the state at the first smart contract node comprises recording a plurality of state changes, the plurality of state changes also being recorded in one or more transactions on the blockchain, the one or more transactions comprising at least the first transaction, and the method further comprising:

31. The method of any one of claims 1 to 30, comprising determining an order of the state changes; and applying the state changes to the record maintained at the first smart contract node in accordance with the order.

32. 32. The method of claim 31 , wherein the determining the order comprises receiving the order from an ordering service implemented in one or more of the intermediate tier nodes of the multi-tiered network.

33. 33. The method of claim 31 or 32, wherein the order is recorded in the blockchain.

34. 34. The method of any one of claims 1 to 33, wherein the core layer is complete.

35. 35. The method of any one of claims 1 to 34, wherein the layered network as a whole is incomplete.

36. a memory comprising one or more memory units; a processing unit having one or more processing units, 36. A computing device, wherein the memory stores code adapted to be executed on the processing unit, the code being configured, when executed on the processing unit, to cause the computing device to operate as the first smart contract node by performing the method of any one of claims 1 to 35.

37. 36. A computer program embodied on a computer readable storage configured to perform the method of any one of claims 1 to 35 when executed on one or more processors.

38. communicating information regarding the smart contract between two or more nodes of the first network using one or more messages of a communication protocol, the messages comprising: a) A transaction sent from a client node to a core node, b) A query from a client node to a core node about whether the transaction has been accepted into the minor memory pool, and the corresponding response; c) a request for a Merkle proof that the transaction was mined into a block, and a response comprising said Merkle proof; and / or d) A request for a list of block headers and a response comprising said list of block headers. Steps are in the form: causing the state of the smart contract to be stored in a record on a smart contract node of the network that provides a smart contract service; The method, wherein the state of the smart contract is also stored on a blockchain of a blockchain network.

39. a memory comprising one or more memory units; a processing device comprising one or more processing units; a network interface comprising one or more network interface units, 39. A computing device, wherein the memory stores code adapted to be executed on the processing unit, the code being configured to, when executed on the processing unit, cause the computing device to perform the method of claim 38, including communicating the one or more messages via the network interface.

40. 39. A computer program embodied on a computer readable storage configured to perform the method of claim 38 when executed on one or more processors.

Images