Digital contracts utilizing block chain transactions

Abstract

To provide a method, a computer apparatus, and a program for encoding a digital contract between parties of a block chain network.SOLUTION: A digital contract method for transferring an aggregate of digital assets from a first party to a second party based on a condition under which a contract is fulfilled. The method comprises the steps of: obtaining a plurality of data elements representing a different condition of the contract, at least one of the conditions being linked to the second party; and generating a hash tree based on the data elements. The hash tree includes: first leaf hashes generated by hashing each data element; and second leaf hashes including a second hash key generated by hashing a secret value known only to a trusted third party, internal hashes, and a root hash. The method also makes a root hash available to the first party for inclusion in a transaction of a block chain.SELECTED DRAWING: Figure 8

Description

[Technical Field]

[0001] The present disclosure relates to a method for enabling nodes of a blockchain network to agree to and enforce digital contracts, also known as "smart contracts." [Background technology]

[0002] Blockchain refers to a form of distributed data structure in which multiple nodes in a peer-to-peer (P2P) network each maintain a duplicate copy of the blockchain. A blockchain contains a chain of blocks of data, with each block containing one or more transactions. Each transaction can point to a previous transaction in a sequence that may span one or more blocks. Transactions can be submitted to the network for inclusion in a new block through a process known as "mining." This involves multiple mining nodes each competing to perform a "proof of work," i.e., solving a cryptographic puzzle based on a pool of pending transactions awaiting inclusion in a block.

[0003] Traditionally, transactions within a blockchain are used to transfer digital assets, i.e., data that acts as a store of value. However, blockchains can also be used to layer additional functionality on top of the blockchain. For example, blockchain protocols allow for the storage of additional user data within the output of a transaction. Modern blockchains have increased the maximum amount of data that can be stored within a single transaction, allowing more complex data to be incorporated. For example, this could be used to store electronic documents within the blockchain, or even audio or video data.

[0004] Each node in the network can have one, two, or all three roles: forwarding, mining, and storage. Forwarding nodes propagate transactions throughout the nodes of the network. Mining nodes mine transactions into blocks. Storage nodes each store a copy of mined blocks in the blockchain. To have a transaction recorded in the blockchain, a party sends the transaction to one of the nodes in the network, where it is propagated. Mining nodes that receive a transaction may race 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 not propagated or mined into a block. Assuming the transaction is verified and thereby accepted into the blockchain, the additional user data therefore remains stored at each node in the P2P network as an immutable public record.

[0005] One of the most promising applications of blockchain technology is digital (or smart) contracts, which are computer-implemented protocols that allow digital agreements to be agreed upon and enforced in both secure and trustless ways. Summary of the Invention

[0006] Several well-known blockchain ledgers use stack-based scripting languages ​​for transactions. The current primitive nature of scripting languages ​​and script size limitations are seen as barriers to the creation of blockchain-based platforms for smart contracts. One example of a smart contract that can be encoded using a scripting language is an escrow smart contract (a condition-based payment protocol), where the right to redeem a transaction output depends on the outcome of an event. However, because the amount of script required to encode this type of contract scales linearly with the number of dependencies, the number of such dependencies that can be included in a transaction is frustratingly small.

[0007] According to one aspect disclosed herein, there is provided a computer-implemented method for encoding a digital contract between a first party in a blockchain network and a second party in the blockchain network, the digital contract for transferring an amount of digital assets from the first party to the second party based on terms under which the contract is fulfilled. The method is performed by a trusted third party and includes the steps of: obtaining a plurality of data elements, each data element representing a different term of the contract, at least one of the different terms being linked to the second party; and generating a hash tree based on the plurality of data elements. The hash tree includes: i) a leaf layer including a first set of leaf hashes, each generated by hashing a respective data element, and a second set of leaf hashes including at least one hash key generated by hashing a secret value known only to the trusted third party; ii) one or more internal layers, each internal layer including a respective set of internal hashes, each internal hash of each internal layer generated by hashing the concatenation of at least two hashes from lower layers; and iii) a root layer including a root hash, generated by hashing the concatenation of at least two hashes from the top internal layer, and making the root hash available to the first party for inclusion in transactions on the blockchain.

[0008] According to another aspect disclosed herein, there is provided a computer-implemented method for generating a digital contract between a first party and a second party in a blockchain network, the digital contract for transferring an amount of digital assets from the first party to the second party based on the terms under which the contract is fulfilled. The method includes: obtaining a root hash of a hash tree executed by the first party and generated by a trusted third party, the hash tree being generated based on: i) a plurality of data elements, each data element representing a different term of the contract, at least one of the different terms being associated with the second party; and ii) one or more different hash keys generated based on a secret value known only to the trusted third party; and generating a transaction for inclusion in the blockchain, the transaction including a locking script for locking the amount of digital assets to the first party, the locking script including the root hash.

[0009] According to another aspect disclosed herein, there is provided a computer-implemented method for executing a digital contract between a first party and a second party in a blockchain network, the digital contract for transferring an amount of digital assets from the first party to the second party based on conditions under which the contract is fulfilled. The method is executed by the second party and includes: acquiring data elements representing terms of the contract, the conditions being linked to the second party; acquiring a certification path for generating candidate root hashes of a hash tree generated by a trusted third party, the certification path including a set of hashes, the set of hashes including a hash key generated based on a secret value known only to the trusted third party, and one or more sets of internal hashes, each set of internal hashes belonging to a different internal layer of the hashes; and generating a transaction for inclusion in the blockchain, the transaction including an unlocking script for unlocking the amount of digital assets from the first party, the unlocking script including the acquired data elements and the acquired certification path.

[0010] Hash trees (also known as Merkle trees) contain cryptographic hashes. While the term "Merkle tree" is sometimes used in the literature to refer to binary hash trees, Merkle's original disclosure was not limited to binary hash trees, and throughout the literature, "hash tree" and "Merkle tree" are used interchangeably. Merkle tree and hash tree are used interchangeably herein unless the context dictates otherwise. The term "tree" refers to a branching data structure, with a "root" at the top and "leaves" at the bottom. Merkle trees are constructed by recursively hashing pairs of nodes until there is only one hash, called the root hash, or Merkle root. The root hash represents a global digital fingerprint of a set of data elements, providing an efficient process for verifying whether a particular data element is in the set. To prove that a particular data element is in the set, a prover need only generate a relatively small number of hashes. This hash constitutes an authentication path, or "Merkle path," that connects a particular data element to the root hash of the hash tree.

[0011] This disclosure recognizes how Merkle trees, or more generally hash trees, can be utilized to compress and encode the terms of a smart contract in a transaction using a single hash value (the Merkle root). Furthermore, the smart contract ensures that if a trusted party attests to the terms being met by a proving party, the proving node can access the digital asset and spend that amount.

[0012] Only a trusted party (e.g., an oracle) has access to the secret value on which one or more leaf hashes are based. Therefore, only the trusted party can generate the Merkle root of the hash tree and a valid Merkle path for which the conditions are met. Based on this, if the proving party (or paying party) can provide a valid Merkle proof that results in the same Merkle root as generated by the trusted party, the proving party (or paying party) can be confident that the trusted party provided the proving party with a Merkle path.

[0013] This disclosure enables secure smart contract execution with minimal script requirements. A verifying party only needs to know the Merkle root to verify that the attesting party has the required data and that the correct key hash has been provided by the trusted party. This is because knowledge of the key hash is necessary for the leaf hash paired with the hash of the data element, but does not by itself enable the computation of other hashes in the Merkle tree. The specific Merkle path applied to valid data is also transmitted by the trusted party, minimizing computational requirements at the prover. In effect, the Merkle path serves as evidence that the data was authenticated by the trusted party. By providing only the Merkle root to the verifier, the smart contract can encode the data (needed to transfer digital assets to the paying party) in a way that does not reveal it until the spending transaction is submitted.

[0014] The depth of the Merkle tree constructed by the trusted party scales logarithmically with the number of data elements (or conditions, outcomes, etc.), allowing for more efficient encoding of smart contracts that rely on many conditions.

[0015] According to another aspect disclosed herein, there is provided a computer-implemented method for encoding a digital contract between a first party in a blockchain network and a second party in the blockchain network, the digital contract being for transferring an amount of digital assets from the first party to the second party based on conditions under which the contract is fulfilled. The method includes, in response to determining that a condition of the contract, executed by a trusted third party and linked to the second party, is satisfied, providing a signature of the trusted third party to the second party for inclusion in the blockchain transaction, the signature signing a data element representing the satisfied condition.

[0016] According to another aspect disclosed herein, there is provided a computer-implemented method for creating a digital contract between a first party in a blockchain network and a second party in the blockchain network, the digital contract for transferring an amount of digital assets from the first party to the second party based on terms under which the contract is executed. The method is executed by the trusted first party and includes the steps of obtaining a root hash of a hash tree, the hash tree including a layer of leaf hashes, at least some of the leaf hashes each generated based on a respective one of a plurality of data elements, each data element representing a different term of the contract, at least one of the different terms linked to the second party; and generating a transaction for inclusion in the blockchain, the transaction including a locking script for locking the amount of the digital asset to the first party, the locking script including the root hash, the locking script configured, when executed together with an unlocking script of a later transaction, to determine whether the unlocking script includes: i) a data element representing a term of the contract signed with a signature of a trusted third party, and ii) a certification path using the signed data element to generate a candidate root hash that matches the obtained root hash.

[0017] According to another aspect disclosed herein, there is provided a computer-implemented method for executing a digital contract between a first party in a blockchain network and a second party in the blockchain network, the digital contract for transferring an amount of digital assets from the first party to the second party based on conditions under which the contract is fulfilled. The method is executed by the second party and includes the steps of: acquiring data elements representing conditions of performance of the contract, the conditions being linked to the second party; acquiring a certification path using the acquired data elements to generate candidate root hashes for a hash tree including a layer of leaf hashes, at least some of which are generated based on a respective one of a plurality of data elements, each data element representing a different condition of the contract, the plurality of data elements including the acquired data elements; acquiring a signature and public key of a trusted third party, the signature signing the fulfillment; and generating a transaction for inclusion in the blockchain, the transaction including an unlocking script for unlocking the amount of digital assets from the first party; The unlocking script includes the obtained certification path, the public key, and the obtained data element signed with the signature.

[0018] The present disclosure also provides techniques for creating and enforcing condition-dependent smart contracts without requiring a trusted party to perform the computation for every new transaction that includes the same data.

[0019] The mutually exclusive terms of the contract can be used (e.g., by a trusted party) to construct a Merkle tree, and only the Merkle root is required by the issuing party to build the smart contract. This reduces the overall size of the contract and requires less unused script data.

[0020] The terms of contract performance are authenticated by a trusted third party, for example by being signed using a Rabin signature. The authenticated terms are included directly in the payment (unlocking) script, thus reducing the amount of work required by the data provider.

[0021] Parties can then ensure that the terms of a smart contract are adhered to without needing the entire agreement explicitly recorded in the transaction. Instead, the payer or winner of the digital asset must attest that they have met some condition and that the specific condition being met is part of the contract.

[0022] According to another aspect disclosed herein, a computer-readable storage medium is provided that includes a transaction for implementing a digital contract between a first party in a blockchain network and a second party in the blockchain network, the digital contract being for transferring an amount of digital assets from the first party to the second party based on conditions under which the contract is fulfilled. The transaction includes a locking script for locking the amount of digital assets to the first party, the locking script including a root hash, and the root hash of a hash tree generated by a trusted third party based on: i) a plurality of data elements, each data element representing a different condition of the contract, at least one of the different conditions being associated with the second party; and ii) one or more different hash keys generated based on a secret value known only to the trusted third party. [Brief explanation of the drawings]

[0023] To facilitate an understanding of embodiments of the present disclosure and to show how such embodiments may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: [Figure 1] Figure 1 is a schematic block diagram of a system that implements blockchain. [Figure 2] Figure 2 shows a schematic example of a transaction that may be recorded in a blockchain. [Figure 3] FIG. 3 is a schematic block diagram of another system implementing a blockchain. [Figure 4] FIG. 4 is a schematic block diagram of the portion of the node software for processing transactions according to the output-based model node protocol. [Figure 5] FIG. 5 is a schematic diagram of an exemplary Merkle tree. [Figure 6] Figure 6 is a schematic diagram of a Merkle proof. [Figure 7] FIG. 7 is an exemplary block diagram illustrating the interactions between parties when executing a smart contract. [Figure 8] FIG. 8 is an exemplary block diagram illustrating the interactions between parties when executing a smart contract. [Figure 9] FIG. 9 is a schematic diagram of an exemplary Merkle tree, where hash keys generated using a secret value form some of the leaves of the tree. [Figure 10] FIG. 10 is a schematic diagram of an exemplary Merkle tree, where the smart contract results of the Merkle tree form the leaves of the Merkle tree. [Figure 11] Figure 11 shows example transactions generated by a verifier and a prover, respectively, whereby a Merkle tree is used to encode the terms of a smart contract. [Figure 12] Figure 12 shows example transactions generated by a verifier and a prover, respectively, whereby a Merkle tree is used to encode the terms of a smart contract. DETAILED DESCRIPTION OF THE INVENTION

[0024] Exemplary System Overview FIG. 1 illustrates an exemplary system 100 for generally implementing a blockchain 150. The system 100 includes a packet-switched network 101, typically a wide-area internetwork such as the Internet. The packet-switched network 101 includes multiple nodes 104 arranged to form a peer-to-peer (P2P) overlay network 106 within the packet-switched network 101. Each node 104 includes a peer computer device, with different ones of the nodes 104 belonging to different peers. Each node 104 includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs). Each node also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may include one or more memory units using one or more memory media. For example, 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.

[0025] The blockchain 150 includes a chain of blocks of data 151, with each copy of the blockchain 150 maintained at each of multiple nodes in the P2P network 160. Each block 151 in the chain includes one or more transactions 152, where 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 includes at least one input and at least one output. Each output specifies an amount representing the total amount of digital assets belonging to the user 103 to whom the output is cryptographically locked (requiring that user's signature to unlock and thereby redeem or spend). Each input points back to the output of a previous transaction 152, thereby linking the transactions.

[0026] At least some of the nodes 104 take on the role of transfer nodes 104F, transferring and thereby propagating transactions 152. At least some of the nodes 104 take on the role of miners 104M, mining blocks 151. At least some of the nodes 104 take on the role of storage nodes 104S (sometimes also referred to as “full-copy” nodes), with each node storing 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 can be a transfer node 104, a miner 104M, a storage node 104S, or any combination of two or all of these.

[0027] For a given current transaction 152j, the input (or each input) contains a pointer that references the output of a previous transaction 152i in the sequence of transactions and specifies that this output is redeemed, or "spent," in the current transaction 152j. In general, the previous transaction can be any transaction in the pool 154 or any block 151. The previous transaction 152i does not necessarily have to exist when the current transaction 152j is created or even when it is sent to the network 106, but the previous transaction 152i must exist and be verified for the current transaction to be valid. Thus, "preceding" herein refers to preceding in the logical order linked by pointers, not necessarily to the time of creation or transmission in chronological order, and thus does not necessarily preclude transactions 152i, 152j from being created or transmitted out-of-order (see later discussion of orphan transactions). The preceding transaction 152i may similarly be referred to as a preceding transaction or a preceding transaction.

[0028] The input of the current transaction 152j also includes the signature of the user 103a to whom the output of the previous 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 the total amount defined in the input of the previous transaction 152i to the new user 103b defined in the output of the current transaction 152j. In some cases, a transaction 152j may have multiple outputs to divide the input total amount among multiple users (one of which may be the original user 103a to provide the changes). In some cases, a transaction may also have multiple inputs, collecting total amounts from multiple outputs of one or more previous transactions and redistributing them into one or more outputs of the current transaction.

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

[0030] An alternative type of transaction protocol, as part of the account-based transaction model, can be called an "account-based" protocol. In the account-based case, each transaction does not define the amount transferred by referencing back the UTXO of a previous transaction in a sequence of past transactions, but rather by referencing the absolute balance of the account. The current state of every account is stored by a separate miner on the blockchain and is constantly updated. In such a system, transactions are ordered using the account's running transaction tally (also called its "position"). This value is signed by the sender as part of the cryptographic signature and is hashed as part of the transaction reference calculation. In addition, an optional data field can also be signed in the transaction. This data field can point back to a previous transaction, for example, if a previous transaction ID is included in the data field.

[0031] In either type of transaction protocol, when a user 103 wants to enact a new transaction 152j, he / she sends the new transaction from his / her computer terminal 102 to one of the nodes 104 of the P2P network 106 (which today is typically a server or a data center, but could in principle be another user terminal). This node 104 checks whether the transaction is valid according to a node protocol applied at each node 104. The details of the node protocol form the overall transaction model and correspond to the type of transaction protocol used in the blockchain 150 in question. The node protocol typically requires the nodes 104 to check that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In the output-based case, this may involve checking that the user's cryptographic signature included in the input of the new transaction 152j matches a condition defined on the output of the previous transaction 152i to which the new transaction pays. Here, this condition typically includes at least checking that the cryptographic signature on the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the new transaction's input points. In some transaction protocols, the condition may be defined, at least in part, by custom script included in the inputs and / or outputs. Alternatively, it may be fixed solely in the node protocol, or a combination thereof. In either case, if the new transaction 152j 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 function as forwarding nodes 104F, applying the same tests according to the same node protocol, and forwarding the new transaction 152j to one or more further nodes 104, and so on.In this manner, the new transaction is propagated throughout the network of nodes 104.

[0032] In an output-based model, the definition of whether a given output (e.g., a UTXO) is paid or not is whether it has still been validly redeemed by another, onward transaction 152j input 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 pay or redeem has not already been paid / redeemed by another valid transaction. Again, if not valid, the transaction 152j is not propagated or recorded in the blockchain. This prevents double spending, which is an attempt to spend the same transaction output more than once. On the other hand, an account-based model prevents double spending by maintaining account balances. Again, because there is a defined order of transactions, the account balance has a single, defined state at any time.

[0033] In addition to validating, 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 underpinned by "proof of work." Mining nodes 104M add new transactions to a pool of valid transactions that have not yet appeared in a block. Miners then compete to assemble a new valid 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 so that, when the nonce is concatenated with the pool of transactions 154 and hashed, the hash output satisfies a specified condition. For example, the specified condition may be that the hash output has a predetermined number of leading zeros. A property of a hash function is that it has an unpredictable output given its input. This search can therefore only be performed by brute force and therefore consumes significant processing resources at each node 104M attempting to solve the puzzle.

[0034] The first minor node 104M to solve the puzzle announces this to the network 106 and provides its solution as a proof, which can be easily checked by other nodes 104 in the network (once the solution is given for the hash, it is easy to check that the hash output matches the conditions). 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 checking the winner's announced solution at each such node. A block pointer 155 is also assigned to the new block 151n that points back to the previously generated block 151n-1 in the chain. Proof of work helps reduce the risk of double spending because it requires a great deal 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 incentivized not to allow double spends to be included in their blocks. Once created, blocks 151 cannot be modified because they are known and maintained by each storage node 104S in the P2P network 106 according to the same protocol. Block pointers 155 also impose a sequential order on blocks 151. Because transactions 152 are recorded in ordered blocks at each storage node 104S in the P2P network 106, this therefore provides an immutable public ledger of transactions.

[0035] Note that different 104M miners are competing at any given time, and may do so based on different snapshots of the unmined transaction pool 154, depending on when they began searching for a solution. Whoever solves each puzzle first defines which transactions 152 will be included in the next new block 151n, and the current unmined transaction pool 154 is updated. Miners 104M then continue competing to generate blocks from the newly defined pending pool 154, and so on. A protocol also exists for resolving any "forks" that may arise, in which two miners 104M solve the puzzle within a very short time of each other, resulting in the propagation of inconsistent views of the blockchain. In essence, the longest branch of any fork becomes the final blockchain 150.

[0036] In most blockchains, winning miners 104M are automatically rewarded with a special type of new transaction that creates a new amount of digital assets out of thin air (as opposed to a regular transaction that transfers an amount of digital assets from one user to another). Thus, the winning node can be said to have “mined” an amount of digital assets. This special type of transaction is sometimes called a “generation” transaction. It automatically forms part of a new block 151n. This reward incentivizes miners 104M to participate in the proof-of-work competition. A regular (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs, further rewarding the winning miner 104M who produces the block 151n containing that transaction.

[0037] Due to the computational resources involved in mining, typically at least each of the minor nodes 104M takes the form of a server, including one or more physical server units or entire data centers. Each transfer node 104M and / or storage node 104S can also take the form of a server or 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.

[0038] The memory of each node 104 stores software configured to execute on the node's 104 processing unit to perform its role and process transactions 152 according to the node protocol. It will be understood that any action attributed to a node 104 herein may be performed by software executing on the processing unit of the respective computing device. Also, the term "blockchain" as used herein is a general term that refers to a general type of technology and is not limited to any particular proprietary blockchain protocol or service.

[0039] Also connected to the network 101 are computing devices 102 for each of multiple parties 103 in consuming user roles. These play the roles of payers and payees in transactions, but do not necessarily participate in mining or propagating transactions for other parties. They do not necessarily execute the mining protocol. Two parties 103 and their respective devices 102 are shown for illustrative purposes: a first party 103a and his / her respective computing device 102a, and a second party 103b and his / her respective computing device 102b. It will be understood that many more such parties 103 and their respective computing devices 102 can exist and participate in the system, but are not shown for convenience. Each party 103 may be an individual or an organization. Purely by way of example, the first party 103a will be referred to herein as Alice and the second party 103b will be referred to as Bob, but it will be understood that this is not limiting and that references herein to Alice or Bob can be replaced with "first party" and "second party," respectively.

[0040] The computing equipment 102 of each party 103 includes a respective processing unit including one or more processors, such as one or more CPUs, GPUs, other accelerator processors, application-specific processors, and / or processors. The computing equipment 102 of each party 103 also includes memory, i.e., computer-readable storage devices in the form of non-transitory computer-readable media or mediums. This memory may include one or more memory units using one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs, and / or optical media such as optical disk drives. The memory on the computing equipment 102 of each party 103 stores software including a respective instance of at least one client application 105 configured to operate on the processing unit. It will be understood that any operations attributed to a given party 103 herein may be performed using software executing on the processing unit of the respective computing equipment 102. The computing equipment 102 of each party 103 includes at least one user terminal. For example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. The computing equipment 102 of a given party 103 may also include one or more other networked resources, such as cloud computing resources, accessed via a user terminal.

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

[0042] The client application 105 has at least a "wallet" functionality. This has two main functions. One of these is to allow each user party 103 to create, sign, and send transactions 152 to be propagated throughout the network of nodes 104 and thereby included in the blockchain 150. The other is to report back to each party the total amount of digital assets they currently own. In an output-based system, this second function involves reconciling the total amount defined in the outputs of various transactions 152 scattered throughout the blockchain 150 belonging to the party in question.

[0043] An instance of a client application 105 on each computing device 102 is operatively coupled to at least one of the transfer nodes 104F of the P2P network 106. This enables the wallet functionality of the client 105 to transmit 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 to which the respective party 103 is a recipient (or, indeed, to inspect other parties' transactions in the blockchain 150, since in embodiments the blockchain 150 is a public facility that provides trust in transactions in part through its public visibility). The wallet functionality on each computing device 102 is configured to form and transmit transactions 152 according to a transaction protocol. Each node 104 executes software configured to validate transactions 152 according to the node protocol and, in the case of a transfer node 104F, forward the transactions 152 for propagation throughout the network 106. Transaction protocols and node protocols correspond to each other, and a given transaction protocol, together with a given node protocol, 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 different subtypes of transactions). The same node protocol is used by all nodes 104 in the network 106 (although many nodes handle different transaction subtypes differently according to rules defined for that subtype, and also different nodes may take on different roles and therefore implement different corresponding aspects of the protocol).

[0044] As described above, the blockchain 150 includes a chain of blocks 151, where each block 151 includes a set of one or more transactions 152 created by the proof-of-work process, as described above. Each block 151 also includes a block pointer 155 that points back to a previously generated block 151 in the chain, defining a sequential order for the blocks 151. The blockchain 150 also includes 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 generation transaction) includes a pointer back to a previous transaction, defining the order of the transactions (note that the shields of transactions 152 allow branching). The chain of blocks 151 leads all the way back to the 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, not to a previous transaction.

[0045] When a given party 103, such as Alice, wishes to submit a new transaction 152j to be included in the blockchain 150, she formulates the new transaction (using a wallet function in 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 or best connected to Alice's computer 102. When any given node 104 receives the new transaction 152j, it processes it according to the node protocol and its respective role. This includes first checking whether the newly received transaction 152j meets certain conditions for being “valid,” examples of which will be described in more detail shortly. In some transaction protocols, the conditions for validation can be set on a per-transaction basis by a script included in the transaction 152. Alternatively, the conditions 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.

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

[0047] Once in 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 152j. (Other minor nodes 104M still try to solve the puzzle based on their old view 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 proof-of-work has been done for pool 154 that contains new transaction 152j, it becomes an immutable part of one of blocks 151 in blockchain 150. Because each transaction 152j contains a pointer back to previous transactions, the order of transactions is also immutably recorded.

[0048] Figure 2 shows an example of a transaction protocol. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the fundamental data structure of a blockchain 150 (each block 151 contains one or more transactions 152). The following is described with reference to an output-based protocol or a "UTXO"-based protocol. However, this is not intended to be limiting to all possible implementations.

[0049] In a UTXO-based model, each transaction (“Tx”) 152 comprises a data structure that includes one or more inputs 202 and one or more outputs 203. Each output 203 may include an unspent transaction output (UTXO), which can be used as a source of input 202 for another new transaction (unless the UTXO has already been redeemed). A UTXO specifies a sum of digital assets (a store of value). It may also include, among other information, the transaction ID of the transaction from which it came. The transaction data structure may also include a header 201, which may include indicators of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the miner 104M.

[0050] Suppose Alice 103a wants to create transaction 152j to transfer the amount of digital assets in question to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It in turn takes the amount of digital assets locked to Alice in the output 203 of the previous transaction 152i and transfers at least a portion of it to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2; Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediate next transaction in the pool 154. Tx1 can point back to any previous (i.e., antecedent) transaction that still has unpaid outputs 203 locked to Alice.

[0051] The preceding transaction Tx0 may already be validated and included in the blockchain 150 when Alice creates her 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 be included. 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 “preceding” and “subsequent,” as used herein in the context of a sequence of transactions, refer to the order of transactions in the sequence defined by transaction pointers specified in the transactions (e.g., which transaction pointers point back to other transactions). They may be equivalently referred to as "predecessor" and "successor," "antecedent" and "descent," "parent" and "child," etc. This does not necessarily imply the order in which they are generated, transmitted to the network 106, or arrive at any given node 104. Nevertheless, a successor transaction (a successor transaction or "child") that points to a predecessor transaction (a predecessor 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 it may be discarded or buffered for a period of time to wait for its parent, depending on the node protocol and / or minor actions.

[0052] One of the one or more outputs 203 of the preceding transaction Tx0 includes a particular UTXO, labeled here as UTXO0. Each UTXO includes a value specifying the aggregate amount of the digital asset represented by the UTXO and a locking script that defines the conditions that must be satisfied by an 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 aggregate amount to a particular party (the beneficiary of the transaction in which it is included). That is, the locking script defines the unlocking conditions, and typically includes a condition that the unlocking script in the input of the subsequent transaction include the cryptographic signature of the party to whom the preceding transaction is locked.

[0053] A locking script (aka scriptPubKey) is a piece of 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 the information needed to pay the transaction output 203, e.g., the requirements for Alice's signature. An unlocking script appears in the transaction output. An unlocking script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the criteria of the locking script. For example, it may include Bob's signature. An unlocking script appears in the transaction input 202.

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

[0055] When a new transaction Tx1 arrives at node 104, the node applies its node protocol, which involves running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria). In an embodiment, this involves concatenating the two scripts. <Sig P A > <P A >||[Checksig P A ]

[0056] where "||" denotes concatenation, "<...>" means to put data on the stack, and "[...]" is a function composed of the unlocking script (a stack-based language in this example). Similarly, the scripts may be executed one after the other on a common stack rather than concatenating them. In either case, when executed together, the scripts authenticate that the locking script on the input of Tx1 contains Alice's signature signing the expected portion of the data, as included in the locking script on the output of Tx0, using Alice's public key PA. To perform this authentication, the expected portion of the data itself (the "message") must also be included in the Tx0 sequence. In an embodiment, the signed data comprises the entirety of Tx0 (thus a separate element must be included specifying the signed portion of the data in the clear, since it is already inherently present).

[0057] The details of authentication with public-private cryptography will be well known to those skilled in the art. Essentially, if Alice signs a message by encrypting it using her private key, then given Alice's public key and the message in the clear (unencrypted), another entity, such as node 104, can authenticate that the encrypted version of the message was signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging this as the signature on a clear version of the message, thus allowing any holder of the public key to authenticate the signature.

[0058] If the unlocking script of Tx1 satisfies one or more conditions specified in the locking script of Tx0 (as shown in the example, if Alice's signature is provided in Tx1 and is authenticated), the node 104 considers Tx1 valid. For a mining node 104M, this means it is added to the transaction pool 154 awaiting proof of work. For a forwarding node 104F, it forwards transaction Tx1 to one or more other nodes 104 in the network 106, which results in it being propagated throughout the network. Once Tx1 is validated and included in the blockchain 150, it defines Tx0 to UTXO0 as a payment. Note that Tx1 is only valid if it pays an outstanding transaction output 203. If it attempts to pay an output that has already been paid by another transaction 152, Tx1 is invalid, even if all other conditions are met. Therefore, node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has already been spent (whether it already forms a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions 152. In fact, a given node 104 may maintain a separate database marking UTXOs 203 that transactions 152 have spent, but ultimately, what defines whether a UTXO has been spent is whether it has already formed a valid input to another valid transaction in blockchain 150.

[0059] Note that the UTXO-based transaction model requires that a given UTXO be spent in its entirety. It is not possible to "leave behind" a fraction of the total amount defined in the UTXO while another fraction is paid. However, the total amount of a UTXO can be split across multiple outputs of subsequent transactions. For example, the total amount defined in UTXO0 in Tx0 can be split across multiple UTXOs in Tx1. Thus, if Alice does not want to give Bob the entire total amount defined in UTXO0, she can use the remaining amount to give herself change or pay another party in the second output of Tx1.

[0060] In practice, Alice also usually needs to include a fee for the winning miner, because today, the generation transaction reward alone is typically not enough to incentivize mining. If Alice does not include a fee for the miner, Tx0 will likely be rejected by the miner's node 104M, and thus, while technically valid, it will not yet be propagated and included in the blockchain 150 (the miner protocol does not force the miner to accept transaction 152 if it does not want to). In some protocols, the mining reward does not require its own separate output 203 (i.e., it does not require a separate UTXO). Instead, the difference between the total sum indicated by input 202 and the total sum specified in the output 203 of a given transaction 152 is automatically given 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 total amount of digital assets specified in UTXO0 is greater than the total amount specified in UTXO1, the difference automatically goes to the winning miner 104M. Alternatively or additionally, however, it is not necessarily excluded that the miner reward may be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0061] Also note that if the aggregate total specified in all outputs 203 of a given transaction 152 is greater than the aggregate total specified in all its inputs 202, this is another ground of invalidity in most transaction models. Therefore, such a transaction will not be propagated or mined into a block 151.

[0062] Alice and Bob's digital assets consist of unspent UTXOs locked in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are dispersed across UTXOs in various transactions 152 throughout the blockchain 150. No single number is stored anywhere in the blockchain 150 that defines the entire balance of a given party 103. It is the role of the wallet function in the client application 105 to collate together the values ​​of all the various UTXOs locked for each party and not yet paid in another onward transaction. This can be done by querying the copy of the blockchain 150 stored on any storage node 104S, e.g., the storage node 104S closest to or best connected to each party's computer device 102.

[0063] Note that script code is often expressed diagrammatically (i.e., not in a precise language). For example, [Checksig P A ], [Checksig P A]=OP_DUP OP_HASH160<H(Pa)> OP_EQUALVERIFY might be written to mean OP_CHECKSIG. The "OP_..." refers to a specific opcode in a scripting language. OP_CHECKSIG (also known as "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 occurrences of the signature ("sig") are removed from the script, but additional requirements, such as a hash puzzle, remain in the transaction to be verified by the "sig" input. As another example, OP_RETURN is a scripting language opcode for generating a non-spendable output of a transaction, which can store metadata within the transaction and thereby immutably record the metadata on the blockchain 150. For example, the metadata could include a document that is desired to be stored on the blockchain.

[0064] signature P A is a digital signature. In an embodiment, it is based on ECDSA using the elliptic curve secp256K1. A digital signature signs a specific piece of 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 portion of the outputs to sign depends on the SIGHASH flag, which is a four-byte code included at the end of the signature that selects which outputs are signed (and therefore fixed at the time of signing).

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

[0066] Optional Side Channels FIG. 3 illustrates a further system 100 for implementing a blockchain 150. The system 100 is substantially the same as that described in connection with FIG. 1, except that additional communication functionality is included. Client applications on Alice's and Bob's computing devices 102a, 120b, respectively, each include additional communication functionality. That is, the system 100 allows Alice 103a to establish a separate side channel 301 with Bob 103b (at the instigation of either party or a third party). The side channel 301 allows for the exchange of data outside of the P2P network. Such communication is sometimes referred to as "off-chain." For example, this can be used to exchange transactions 152 between Alice and Bob without the transaction (yet) being published on the P2P network 106 or progressing on the chain 150 until one of the parties chooses to broadcast it to the network 106. Alternatively or additionally, side channel 301 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0067] The side channel 301 may be established over the same packet-switched network 101 as the P2P overlay network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or a direct wired or wireless link between Alice's and Bob's devices 1021, 102b. In general, the side channel 301 referred to anywhere herein may include any one or more links over one or more network technologies or communication media for exchanging data “off-chain,” i.e., separate from the P2P overlay network 106. When more than one link is used, the bundle or collection of off-chain links as a whole may be referred to as the side channel 301. Thus, note that when Alice and Bob are said to exchange a particular piece of information or data, or the like, over the side channel 301, this does not necessarily mean that all of this data must be transmitted over the exact same link or the same type of network.

[0068] Node Software FIG. 4 illustrates example node software 400 running on each node 104 of the P2P network 106 in an example UTXO or output-based model. The node software 400 comprises a protocol engine 401, a script engine 402, a stack 403, an application-level decision engine 404, and a set of one or more blockchain-related function modules 405. In any given node 104, these may include any one, two, or all three (depending on the node's role or roles): a mining module 405M, a transfer module 405F, and a storage module 405S. The protocol engine 401 is configured to recognize different fields of a transaction 152 and process them according to the node protocol. Another, previous transaction 152m-1 (Txm-1 ), transaction 152m (Tx m ) is received, the protocol engine 401 m The protocol engine 401 identifies the unlocking script in the Tx m Based on the input pointer in Tx m-1 Identify and search for Tx m-1 If it is not already on the blockchain 150, it can be obtained from each node's own pool 154 of pending transactions, or from Tx m-1 If the block 151 is already on the blockchain 150, it can be retrieved from a copy of the block 151 in the blockchain 150 stored on the respective node or another node 104. In either case, the script engine 401 m-1 identifies the locking script in the pointed output of and passes it to the script engine 402.

[0069] Therefore, the script engine 402 executes Tx m-1 Locking script and Tx m 4, but the same can be applied to any pair of transactions, such as Tx0 and Tx1, etc. The script engine 402 executes the two scripts together, as described above, which includes placing data on the stack 403 and popping data from the stack 403 according to the stack-based scripting language (e.g., script) used.

[0070] By executing the scripts together, the script engine 402 determines whether the unlocking script meets one or more criteria defined in the locking script; i.e., does the locking script "unlock" the included output? The script engine 402 returns the result of this determination to the protocol engine 401. If the script engine 402 determines that the unlocking script meets one or more criteria specified in the corresponding locking script, it returns a result of "true." Otherwise, it returns a result of "false."

[0071] In an output-based model, a "true" result from the script engine 402 is one of the conditions for the validity of the transaction. Typically, there are one or more additional protocol-level conditions evaluated by the protocol engine 401 that must also be satisfied. Tx m The total amount of all digital assets designated in the outputs of Tx does not exceed the total amount designated by the inputs, and m-1 The protocol engine 401 evaluates the results from the script engine 402 together with one or more protocol-level conditions, and only if they are all true, does the protocol engine 401 validate the transaction Tx m The protocol engine 401 outputs an indication of whether the transaction is valid to the application level decision engine 404. Tx m Only in the condition where Tx is actually verified will the decision engine 404 determine whether Tx m 151. This allows nodes to select to control one or both of the mining module 405M and the transfer module 405F to perform respective blockchain-related functions related to Tx mand / or the mining module 405M to add Tx m Note, however, that in embodiments, the decision engine 404 does not choose to forward or mine an invalid transaction, but this does not necessarily mean that it is obligated to trigger the mining or forwarding of a valid transaction simply because it is valid. Optionally, in embodiments, the decision engine 404 may apply one or more additional conditions before triggering one or both functions. For example, if the node is a mining node 104M, the decision engine may choose to mine a transaction only if the transaction is valid and has sufficient mining rewards remaining.

[0072] Also note that the terms "true" and "false" herein are not necessarily limited to returning a result expressed in the form of only a single binary digit (bit), although this is certainly one possible implementation. More generally, "true" can refer to any state that indicates a success or positive outcome, and "false" can refer to any state that indicates a failure or negative outcome. For example, in an account-based model (not shown in FIG. 4), a "true" outcome may be indicated by a combination of an implicit, protocol-level validation of a signature by node 104 and an additional positive output of the smart contract (if both individual outcomes are true, the overall result is considered true).

[0073] Merkle tree Figure 5 shows an exemplary structure of a Merkle tree 500. A Merkle tree is also referred to in the art as a hash tree. The terms are used interchangeably herein. Each node in the tree (represented by a circle) is given an index pair (i,j) and is represented as N(i,j). The indexes i,j are numeric labels associated with a particular position in the tree. A characteristic of a Merkle tree is that the construction of each node is governed by the following equation:

number

[0074] FIG. 5 shows that the case where i=j corresponds to leaf node 501, which simply represents the data D i The case where i≠j corresponds to an internal node 502 or a root node 503, which is generated by recursively hashing and concatenating child nodes in the tree until a particular node or root is reached. Leaf nodes of a tree are also referred to herein as leaf hashes. Similarly, internal nodes and root nodes are also referred to as internal hashes and root hashes, respectively. Construction of a Merkle tree requires the use of a cryptographic hash function.

[0075] The main function of a Merkle tree in most applications is to find a block of data D i 504 is a member of a list or set of N data blocks, D∈{D1,...,D N}. Root hash and candidate data block D iGiven a data block D, this can be treated as a "proof-of-existence" of a block in the set. The mechanism for such a proof is known as a hash tree proof (or Merck proof), and i and obtaining a set of hashes known as a hash or authentication path (or Merkle path) for the root R. The authentication path for a data block is the minimal list of hashes required to reconstruct the root R through repeated hashing and concatenation.

[0076] Figure 6 shows a Merkle existence proof for a data block D1 in a tree represented by a root R using a Merkle path. Given a Merkle root R, a data block D1 can perform a Merkle proof to prove that it is a part of the set D∈{D1,...,D N} is proved as follows: 1) Obtain the Merkle root R from a trusted source. 2) Obtain a Merkle path Γ from the source, where Γ is a set of hashes. Γ={N(2,2),N(3,4),N(5,8)} 3) Compute the Merkle proof using D1 and Γ as follows: a. Hash (or double-hash, depending on the implementation) the data block to get: N(1,1)=H(D1) Concatenate with bN(2,2) and hash to get: N(1,2)=H(N(1,1)||N(2,2)) Concatenate with cN(3,4) and hash to get: N(1,4)=H(N(1,2)||N(3,4)) Concatenate and hash with dN(5,8) to get the root. N(1,8)=H(N(1,4)||N(5,8)) R'=N(1,8) e. Compare the calculated root R' with the root R obtained in (1). If I.R'=R, the presence of D1 in the tree, and therefore of the dataset D, is confirmed. II. If R'≠, then the proof fails and D1 is not confirmed as a member of D.

[0077] This shows that performing a Merkle proof for a given block D1 and root R effectively traverses the Merkle tree "upward" by using only the minimum number of hash values ​​required. This is an efficient mechanism for providing a proof of existence for some data as part of the dataset represented by the Merkle tree and its root.

[0078] A hash tree proof involves concatenating the hash of a candidate data field with at least one leaf hash in an ordered set of hashes (a hash tree path). This generates an internal hash (or an internal node of the hash tree). The generated internal hash is then concatenated with one or more hashes in the hash tree path (or a single hash if the hash tree is a binary hash tree). The concatenated internal hash is then hashed to generate the next hash. Depending on the size of the hash tree (e.g., the number of data fields), the next hash may be another internal hash or the root hash. If the next hash is another internal hash, the process of concatenating with one or more internal hashes from the hash tree path and hashing the result continues until the root hash is generated. Note that each hash in the hash tree path is used only once.

[0079] Importantly, the number of operations required to verify that a given data packet belongs to a Merkle tree scales logarithmically with the number of leaf nodes.

[0080] RABIN Signature In current blockchain protocols, a valid Elliptic Curve Digital Signature Algorithm (ECDSA) signature can only be generated if the message being signed is a (serialized) transaction. This means that if a party requires signed data to execute a contract encoded in a transaction, that party must also sign the entire transaction. As a result, current protocols prevent the reuse of signed data.

[0081] However, the Rabin cryptosystem can be used to generate and verify signatures for any data type used in blockchain transactions. Rabin signatures themselves are well known to those in the art. Unlike ECDSA signature schemes that use elliptic curve arithmetic, Rabin signatures rely on the difficulty of integer factorization for security. The Rabin signature algorithm can be summarized as follows:

[0082] Key Generation: The signer's private key is (p, q), where p ≡ 3 mod 4 and q ≡ 3 mod 4, which are prime. The private key is n = p q.

[0083] Signature generation: A message m is

number

number

number

[0084] Signature verification: Given (S,U,n), and message m, check that:

number

[0085] Verification of a Rabin signature is computationally easy and can be done in script using stack operations. Importantly, when used as part of a larger transaction, the verification procedure does not require any knowledge of the contents of the message being signed (other than that it is a data array of arbitrary size). This means that the creator of the locking script only needs to know the public address of the data source. Another feature of the Rabin digital signature algorithm is that the signer has complete control over the bit size of the signing key, allowing them to choose the level of security.

[0086] A small number of arithmetic and stack manipulation opcodes are required to verify a Rabin signature. The opcodes shown below are well known to those skilled in the art. The "Redeem script" for verifying a Rabin signature is as follows: [Table 1]

[0087] In this case, the script will run without fail and will leave a signed message on the stack only if provided with the input. <s> <m> <n>

[0088] where m is the message and (S,U) is a valid Rabin signature. Alternatively, if using the following script, the redemption script can be designed to leave TRUE (or a true representation) as the top stack item. [Table 2]

[0089] This version of Rabin signature check may be used when a successful Rabin signature verification is used to execute an OP_IF branch (as in the case of a blockchain escrow contract). For brevity, the above example Rabin signature verification opcode will be referred to hereafter as [RABIN SIG CHECK].

[0090] Digital (Smart) Contracts Embodiments of the present disclosure provide techniques for building and executing digital contracts, or so-called smart contracts, and for facilitating the building and execution of these contracts.

[0091] A digital contract allows a first party 103a to transfer digital assets to a second party 103b only if the terms of the contract are met. Similarly, a digital contract ensures that the second party 103b can enforce the contract if the terms are met. This is in contrast to a traditional contract, where either party can break the contract or disagree about whether the terms of the contract have been met.

[0092] The embodiments will first be described with reference to FIG. 7. FIG. 7 illustrates a system 700 including a first party (Alice) 103a, a second party (Bob) 103b, and a trusted third party (Oracle) 701. Alice and Bob are each users of a blockchain network and operate computing devices 102a, 102b configured to perform the methods described herein. The Oracle 701 may or may not be a user of the blockchain network. The Oracle 701 also operates a computing device (not shown) configured to perform the methods described herein. The third party (Oracle) is trusted in the sense that Alice 103a and Bob 103b trust data generated and / or published by the third party. For example, the third party 701 may be a weather service that publishes temperature readings, such as average daily temperature readings for a particular city.

[0093] An oracle may take the form of one or more physical server units or a server consisting of an entire data center. Alternatively, an oracle may take the form of a user terminal or a group of user terminals networked together. That is, an oracle may be an individual user or a group of users, such as an organization, e.g., a company, an academic institution, a charity, etc. Generally, an oracle includes a computing device. The computing device includes a processing unit, including 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). The computing device also includes memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium or media. The memory may include one or more memory units using one or more memory media, e.g., magnetic media such as hard disks, electronic media such as solid-state drives, flash memory, or EEPROMs, and / or optical media such as optical disk drives. The oracle's memory stores software configured to execute on the processing units of the node computing devices to perform their respective functions. It will be understood that any operations attributed to Oracle herein may be performed by software executing on a processing unit of an Oracle computing device.

[0094] The oracle can communicate with Alice and Bob, for example, via the Internet 101. Alice and Bob are each configured to send transactions to nodes in the blockchain network 106. Alice and Bob may also communicate via a side channel 301 (not shown in FIG. 7).

[0095] Alice and Bob want to construct a digital contract that ensures that Alice transfers an amount of digital assets if any of multiple possible conditions V of the contract are met. For example, possible conditions could be the price of a commodity or the outcome of an insured event. Alice wants to ensure that the conditions of the contract are met before the digital assets can be claimed by Bob. Alice and Bob also want to ensure that a trusted party is the arbiter of whether the conditions are met.

[0096] To maintain a level of privacy for both Alice and Bob, Alice may not want to include the terms of the contract in the transaction because, once validated, the transaction forms part of the blockchain 150 and is accessible by users of the blockchain. Therefore, Alice wants to encode the terms of the contract within the transaction in a way that they cannot be determined by any unwanted third-party users of the blockchain 150.

[0097] Additionally, or alternatively, a contract may contain many more conditions. One of the main hurdles preventing the execution of smart contracts that use scripts are the strict size limits that apply to individual scripts. There is a 520-byte limit for pay-to-script hashes (P2SHs), and a 10,000-byte limit for bare scripts. While these limits reduce security risks by eliminating the possibility of denial-of-service (DoS)-type attacks against the miner 104M, they also impose very strict limits on the amount of raw script that can be used to represent a smart contract. Therefore, Alice wants to encode the terms of her contract in an efficient way that reduces the size of the script.

[0098] Once the terms are agreed upon, Alice and / or Bob send the set of terms V (or data representing the terms) to the oracle. The oracle uses the contract's distinct terms to generate a Merkle tree 500. That is, each term is hashed (or double-hashed) using a hash function to generate the tree's leaf hashes 501. The root 503 of the hash tree (Merkle root R) is a hash value that encodes the contract's terms. The Merkle root R cannot be reverse-engineered to obtain the terms.

[0099] To ensure that Alice and Bob cannot construct the Merkle root R themselves using only the data elements, the oracle includes the hash key K as one or more leaves of the hash tree 500.

[0100] Each hash key K is a hash value derived from a secret S (e.g., a randomly generated number or string) known only to the oracle. Each hash key K may be the same hash key. Alternatively, each hash key K may be a different hash key. For example, a first hash key K1 may be a hash of the secret key S, and a second hash key K2 may be a hash of the first hash key K1. Alternatively, the first hash key K1 may be a hash of the secret and a first value (e.g., S+i), and the second hash key K2 may be a hash of the secret and a second, different value (e.g., S+2i), etc. Because the secret is known only to the oracle, only the oracle can reconstruct the Merkle root R.

[0101] The oracle sends the Merkle root R to Alice for inclusion in the digital contract. Alternatively, the oracle can publish the Merkle root R, for example, on the Internet 101, so that Alice can access it. Alice can now construct transaction Tx1, which utilizes the Merkle root. Alice constructs transaction Tx1, which includes a locking script that locks the aggregate amount of digital assets to Alice. The locking script includes the Merkle root. Locking scripts are described in more detail below. Once the transaction is constructed, Alice submits transaction Tx1 to the network for inclusion in the blockchain, i.e., by a mining node.

[0102] Later, condition V1 of the contract is met, and Bob wants to receive the agreed-upon amount of digital assets. For example, condition V1 may be a data packet encoding an insurable outcome that allows Bob to receive payment. To do so, Bob needs to generate transaction Tx2, which has an unlocking script that unlocks the locking script of Alice's transaction Tx1. As mentioned above, Alice and Bob agreed that the oracle is trusted to determine whether the condition is met. Upon determining that condition V1 is met, the oracle sends an authentication path (Merkle path) Γ to Bob. The Merkle path Γ includes a hash key K generated by the oracle during the creation of the Merkle tree and one or more hashes of the Merkle tree needed to reconstruct the Merkle root. The Merkle path Γ obtained from the oracle may also include V1 (or a data element representing V1). Alternatively, Bob already has access to V1. Now, Bob constructs an unlocking script, Tx2, that includes V1, hash key K, and one or more hash values. Together, these values ​​can be used to perform a Merkle proof, i.e., to generate candidate Merkle roots and compare them to the Merkle root generated by the oracle (and contained in Tx1). Bob submits transaction Tx2 to the network for inclusion in the blockchain.

[0103] Returning now to the locking script constructed by Alice, during the validation of Tx2, Tx1's locking script is executed alongside Tx2, as shown in Figure 4. The locking script generated by Alice is configured to execute a Merkle proof using the Merkle root contained in Tx1's locking script and elements contained in Tx2's unlocking script. If the candidate Merkle root generated using elements of Tx2's unlocking script matches (i.e., is identical to) the Merkle root contained in Tx1's unlocking script, the digital asset is unlocked from Alice and transferred to a party of Bob's choosing. In other words, the unlocked amount of the digital asset (e.g., part or all of the amount) can be included in the unspent transaction output of Tx2.

[0104] FIG. 7 illustrates one example of information flow between Alice 103a, Bob 103b, and an oracle 701 according to these embodiments. As shown, the oracle obtains the contract's conditions V from Alice. The oracle uses these conditions and a secret to construct a Merkle tree having a Merkle root R. The oracle sends the Merkle root R to Alice, so that Alice can construct transaction Tx1 that incorporates root R in its locking script. Alice broadcasts the transaction to the P2P network. If transaction Tx1 is valid, it is mined into the blockchain. If the oracle deems the contract's conditions V1 satisfied, the oracle provides Bob with a Merkle path Γ and a hash key K (generated using the secret). The Merkle path Γ and the hash key K can be used together to generate the Merkle root R. Bob then constructs transaction Tx2 that incorporates the Merkle path Γ, condition V1, and hash key K in the unlocking script for transaction Tx2. If valid, transaction Tx2 is mined into blockchain 150.

[0105] An embodiment will now be described with reference to FIG. 9. The oracle runs a protocol that uses Merkle trees to both authenticate and compress large amounts of indexed data. By doing so, the oracle enables the creation of multiple transactions that require external data to execute. The oracle is not a party to either the smart contract or the blockchain transaction. Alice and Bob are parties in a smart contract for a blockchain transaction, where Alice is the payer and Bob is the intended recipient of the digital asset. To pay the digital asset, Bob needs to prove that he meets some conditions required by the contract, and part of this proof includes the external data. Therefore, Bob is called the prover, and Alice is called the verifier.

[0106] Starting with an oracle, we create a secret string of bits, or a secret number that is never shared. For example, the secret could be the number 10. A key is securely generated by hashing the secret using a cryptographic hash function, such as SHA256. H(secret)=Key

[0107] The hash digest (denoted Key) can be sent to the prover if appropriate. Furthermore, the sequence of key hashes can be generated using a deterministic key generation protocol, for example: H(secret+1)=Key i i={0,1,…,N}

[0108] As shown in Figure 9, the oracle generates a key i 901 and Data V k A Merkle tree 900 can be constructed with each left leaf node 902 indexed by k∈{1,...,N}. The purpose of the Merkle tree 900 is to provide proof that Alice is requesting data from a prover without publishing the data itself on the blockchain before it is used. If requested by the oracle, she will publish the Merkle root R, which can be used in future blockchain transactions to verify the authenticity of the data.

[0109] Once, once Key i Once obtained, the hash value can be proven to be part of the Merkle tree 900. The prover can provide a Merkle path, which can be verified against a Merkle root already published by the oracle (e.g., sent to Alice). In this case, the Merkle proof allows for verification of the data and its authenticity.

[0110] The advantages of the above are that data can be authenticated using Merkle trees, that generation of keys and Merkle trees is easy and computationally efficient, and that large amounts of independent data can be pre-signed using a single key. Furthermore, the Merkle tree depth (and therefore the Merkle proof) scales logarithmically with the number of possible values, meaning that large amounts of indexed data can be signed.

[0111] Once a valid Merkle proof has been provided by a prover, the key hashes associated with the Merkle tree leaves are revealed, so the key hashes need to be discarded and a new Merkle tree needs to be constructed for each new transaction. However, this requires minimal computation, as the data in the left leaf node remains the same.

[0112] For example, suppose an oracle has four conditions V1,...,V4, which are either publicly known or sent by Alice. First, the oracle publishes a Merkle root so that a verifier can create a validation (i.e., locking) script. Once the verifier uses the Merkle root to construct a locking script, i.e., a transaction encoding a smart contract is created, the oracle can check whether Alice used the correct Merkle root. Once the oracle determines the outcome, the key and Merkle proof can be sent to the prover (Bob).

[0113] For example, suppose data V1-V4 represent the outcomes of a boxing match that allow Bob to pay Alice's output. Consider the following script snippet, which verifies a Merkle proof for V1: Let's try it.

[0114] Step 1: Alice agrees to a smart contract whereby if outcome V1 occurs, she will transfer an amount of digital assets to Bob. Alice and Bob send this data to the oracle.

[0115] Step 2: The oracle builds a Merkle tree using this data V1-V4 and the private key as leaves (see Figure 9). The oracle then sends R to Alice to include as part of her verification algorithm.

[0116] Alice's locking script (snippet): [Table 3]

[0117] The oracle can search for this script in Alice's transactions and ensure that it contains the correct Merkle root. If it does not, the oracle can inform Bob and / or the public that Alice has not yet created a (correct) contract script. This is less of a security vulnerability than asking Alice to create a correct transaction first (she would have to create and sign the transaction using the script). This method simply allows the oracle to verify that the contract was created.

[0118] Step 3: V1 is a valid result. The oracle sends the key Key1 and Merkle path to Bob. Bob can create a Merkle for V1.

[0119] Bob's unlocking script (snippet): <z2> <z4> <key1> <v1>

[0120] Upon executing this proof, the prover knows both the key hash data and the leaf data, and that the data itself is also contained in the unlocking script.

[0121] Explicitly, Alice's locking script hashes V1 and concatenates it with Key1 (i.e., producing Z3). The result is concatenated with Z4 and then hashed (i.e., producing Z1). The result is concatenated with Z2 and hashed (i.e., producing R). The result is then checked for equality with R.

[0122] The data and Merkle path together are a proof of existence, showing that the data was included in the contract. The key hash shows that the oracle authorized Bob to use the data. Including the key hash also provides authenticity of the data, as the oracle can simply give the key hash to Bob if the result is valid.

[0123] FIG. 8 shows a system 800 similar to that of FIG. 7, including Alice 103a, Bob 103b, and a trusted third party (oracle) 701.

[0124] As detailed above, Alice and Bob wish to construct a digital contract that will ensure that Alice transfers an aggregate sum of digital assets if any of multiple possible conditions V of the contract are met. Alice and Bob also wish to ensure that a trusted party is the arbiter of whether the conditions are met.

[0125] In these embodiments, Alice and Bob can agree on the terms of the contract and then, between them, agree on a Merkle tree that encodes those terms. That is, the Merkle tree can be constructed without involving an oracle. For example, Alice can generate a Merkle tree that has a Merkle root. Bob can also generate a Merkle tree that has a Merkle root. Bob can then verify that Alice generated the Merkle root correctly. To accomplish this, Alice and Bob must agree on the method (i.e., algorithm) used to generate the Merkle tree. Alternatively, Alice and Bob can rely on an oracle to generate the Merkle tree and send the Merkle root to Alice and, optionally, to Bob.

[0126] The Merkle trees used in these embodiments can be constructed without using a secret value. The leaves of the Merkle tree can be hashes of the terms of the contract (i.e., hashes of the data elements that represent those terms). Depending on the number of terms, one or more padding elements can be used as nodes (e.g., leaves) of the Merkle tree. For example, if there are seven terms of the contract, one of the hash leaves can be padded (e.g., with a hash of zeros) to form a Merkle tree with eight hash leaves. This can be applied to any of the embodiments described herein.

[0127] Once Alice has the Merkle root R (e.g., by generating a Merkle root), she can generate transaction Tx3, which transfers an amount of digital assets to Bob, based on the requirement that the conditions of the digital contract be met. Alice wants to ensure that a trusted party, the oracle, can attest that the conditions have been met. So, Alice creates an unlocking script that attempts to unlock the transaction output with the oracle's signature R. s 7, Alice's transaction's locking script also determines whether the unlocking script includes a Merkle path Γ for performing a Merkle proof using the data elements. That is, the locking script is configured to determine whether the (signed) data elements and the Merkle path Γ can generate a candidate Merkle root that is identical to the Merkle root R included in Alice's transaction Tx3's locking script.

[0128] Oracle Signature R s may be a Rabin signature. Rabin signatures and how they can be used to sign data elements have been described in detail above. Alice's locking script can be configured to perform a Rabin signature check, e.g., [RABIN SIG CHECK], on the data contained in Bob's unlocking script.

[0129] Alternatively, the oracle signature may be an ECDSA signature.

[0130] In some examples, Alice may also include additional information in the transaction, such as metadata related to the digital contract. For example, the metadata may include a description of the contract. For example, the metadata may be included in the OP_RETURN output of the transaction.

[0131] In some examples, Alice may include a time-based redemption option to redeem the digital asset sum if Bob does not successfully transfer ownership of the digital asset within a predetermined time. For example, the locking script may be configured to allow Alice to unlock the locking script (using an unlocking script of a different transaction generated by Alice) after a period of one month, two months, 33 months, etc. has passed since the transaction was generated or mined into the blockchain. If Bob did not claim the digital asset because, for example, the terms of a contract were not met or the oracle did not provide Bob with a valid signature, Alice may submit a transaction to the blockchain network with an unlocking script configured to unlock the locking script of her previous transaction. The unlocking script may include Alice's signature and public key (or a hash thereof).

[0132] Once the transaction is generated, Alice submits the transaction to one or more nodes in the blockchain network for inclusion in the blockchain.

[0133] If the conditions of the contract are met, the oracle sends Bob a signed data element that represents the met condition and is the same data element that was used to construct the Merkle root R. The data element is then signed by the oracle's signature R. s , e.g., the oracle's Rabin signature. The oracle can also provide the oracle's (Rabin) public key to Bob, e.g., by publishing the (Rabin) public key or by sending the (Rabin) public key directly to Bob.

[0134] Bob can now generate transaction Tx4 having an unlocking script configured to unlock the output of Alice's transaction Tx3, i.e., unlock the locking script in Alice's transaction. The unlocking script of Bob's transaction Tx4 includes the signed data elements, the oracle's public key, and the Merkle path Γ for performing the Merkle proof. Bob can obtain the Merkle path from Alice and / or the oracle (e.g., in an example where Alice and / or the oracle generated the Merkle tree). As another example, Bob can obtain the Merkle path Γ by generating a Merkle path (e.g., in an example where Alice and Bob agreed on the data elements that form the leaves of the Merkle tree). Once generated, Bob can submit the transaction to one or more nodes of the network for inclusion in blockchain 150.

[0135] Figure 8 shows one example of information flow between Alice, Bob, and an oracle according to these embodiments. Alice and Bob can agree on a Merkle tree. This may include sharing the Merkle root R between them (e.g., Alice may send the Merkle root R to Bob, and / or vice versa). In some examples, the oracle has generated the conditions V of the contract that were used to generate the Merkle tree (or data elements representing those conditions). In these examples, the oracle may publish these conditions V or send the conditions V directly to Alice and / or Bob, i.e., without disclosing them to any third party. Alice broadcasts transaction Tx3 to the P2P network. If transaction Tx3 is valid, it is mined into the blockchain. If the oracle deems the contract's condition V1 satisfied, it provides Bob with a signature R that signs the satisfied condition V1. Bob then obtains a Merkle path Γ for the conditions that can be used to generate the Merkle root R. The Merkle path Γ can be sent by Alice or an oracle, or generated by Bob himself. Bob then constructs transaction Tx4, incorporating the Merkle path Γ and the signed condition V1 in the unlocking script of transaction Tx4. If valid, transaction Tx4 is mined into the blockchain.

[0136] Condition-dependent payment scripts (smart contracts) can use the following aspects: First, mutually exclusive sections of a smart contract script can be used to construct a Merkle tree, and only the Merkle root is used by the payer. This reduces the overall size of the contract and unused script data. The complete script can be replaced with the Merkle root. Second, raw data from a third party, authenticated using Rabin signatures or Merkle proofs, can be used directly in the payment script, reducing the amount of work required by the data provider. Third, a third-party data provider can encode complex messages by using a public indexing system. Parties can then ensure that the terms of the smart contract are adhered to without requiring the entire contract to be explicitly recorded in the transaction. Instead, the payer or winner of the digital asset needs to prove that they have met some condition and that the specific condition being met is part of the contract.

[0137] In some cases, it may be impossible or impractical for the oracle to send cleartext messages along with the signature, as this may require the oracle to have a large amount of memory and processing power. Instead, the number of possible states (and therefore the workload) of the oracle may be minimized by using binary / hexadecimal values ​​to represent specific ranges of continuous data. In some examples, an oracle may only be used to report data (e.g., temperature) relevant to a specific set of queries. Oracle conditions may be indexed using a pre-published index. One exemplary scheme is shown in the table below. [Table 4]

[0138] Using this scheme, A ≤ x <B、A=a0かつB=a 255 Within this range, up to 256 oracle conditions can be represented using a single byte. This precision can be increased as the number of bytes increases. For example, if the maximum byte push allowed by a script is 520, then theoretically the previous table can be extended to represent up to approximately 3.4×10 of continuous data. 153 It can represent up to an interval.

[0139] As an example, if an oracle is reporting data from a platinum resistance thermometer, the oracle may use a set range of binary values ​​to represent temperatures in the appropriate range, e.g., between -50°C and 50°C in unit intervals, as shown in the following table: [Table 5]

[0140] This simple encoding system allows an almost infinite range of oracle conditions to be expressed directly in script.

[0141] Embodiments will now be described with reference to Figure 10. In these embodiments, a third party (an oracle) can authenticate the data but does not need to perform the computation for every new transaction that includes the data.

[0142] Consider a contract between Alice and Bob based on the outcome of a boxing match. For example, Alice agrees to transfer digital assets to Bob if boxer A defeats boxer B in rounds 3, 5, 7, 11, or 12. To do so, she establishes a smart contract in the form of a P2SH transaction. Furthermore, to ensure that the validity of the terms is independently verified, Alice and Bob agree to use data (related to the outcome of the boxing match) provided by an oracle. Because Alice and Bob must agree on the format of the smart contract in advance, they can also agree on the structure of the "Merklized contract," and specifically, the Merkle root. The oracle's Rabin public key must be known to both Alice and Bob at the time the transaction containing the smart contract is created. Alternatively, Carol may wish to first publish an index instead of the associated data and signatures.

[0143] Additional security can be provided by imposing a condition that if the output is not transferred to Bob within a certain amount of time, the digital asset is returned to Alice. This provides additional security in case Carol decides not to cooperate (i.e., not to provide a signature).

[0144] Using the indexing system described above, the following table relating results to oracle messages can be published. [Table 6]

[0145] The different conditions (in this case, specific rounds in a boxing match) are encoded as hexadecimal data. A Merkle tree 1000 can then be constructed using the hexadecimal value 1001 as a leaf, as shown in Figure 10. Z6=H(01), Z7=H(02), Z9=H(04), Z 10 =H(05), Z3=H(Z7||Z8), Z4=H(Z7||Z 10 ), Z5=H(Z 11 ||Z 11 ), Z1=H(Z3||Z4), Z2=H(Z5||0), and R = H(Z1||Z2).

[0146] Here, H(·) denotes the double SHA-256 hash function, i.e., H(x) = SHA256(SHA256(x)). Alternatively, a single hash may be used. In this example, a padding value of 1002 is used as a node in the tree. Alice creates a transaction to transfer a sum of digital assets to a winner (who may not be known at the time the transaction is completed). This can be either a non-standard transaction output, or a pay-to-script hash (P2SH) output if the contract creator desires further compression.

[0147] For example, if Boxer A beats Boxer B in the third round, and Bob wants to pay for his win, i.e., transfer digital assets to another address, he needs to provide a valid signature from Carol, as well as proof that the successful outcome was part of the agreed-upon contract.

[0148] Merkle-ized smart contracts allow parties to store and execute contracts in an efficient and secure way. Instead of expressing the full contract explicitly in a script, Alice and Bob have agreed to a Merkle-ized form of the contract. Bob has now obtained a signature from an oracle and would like to demonstrate the following: i) the conditions that allow Bob to pay the UTXO are met, and ii) The condition fulfilled is the satisfaction of a specific provision in the contract. An example of a Merck smart contract is shown below, where the locking script is from Alice's transaction and the unlocking script is from Bob's transaction. [Table 7]

[0149] The first part of the locking script (<Merkle path length> ...OP_CHECKSIG OP_ENDIF) checks whether the unlocking script contains a Merkle path to generate a Merkle root, the terms of the contract signed using the oracle's Rabin signature, and whether the contract transfers ownership of the digital asset to Bob.

[0150] Bob can pay the digital assets by demonstrating (i) that "Round 3" was a necessary condition for him to pay the escrowed assets, and (ii) that "Round 3" was indeed the result. If Bob demonstrates (i) and (ii), the second part of the script (OP_ELSE...OP_ENDIF) becomes unused data. The second part of the script allows Alice to reclaim the digital assets if Bob does not transfer ownership within one month.

[0151] Bob's unlocking script contains the Merkle path, a condition signed with the oracle's public key, Bob's public key, and Bob's signature.

[0152] The size of the locking script is reduced, and unused and unused scripts are minimized. Further compression of the size of the locking script can be achieved using P2SH, shifting the cost of contract execution from the contract creator to the payer, for example by using the following transaction template: Transaction 1 (Alice) P2SH: [Table 8] Transaction 2 (Winner) P2PKH: [Table 9]

[0153] For Merkle-ized smart contracts, the locking script scales logarithmically with the number of leaf nodes, N, because the opcode sequence (OP_SWAP OP_IF OP_SWAP OP_ENDIF OP_CAT OP_SHA256) needs to be repeated for each level of the Merkle tree. For small contracts, the [RABIN SIG CHECK] sequence makes up the largest percentage of bytes in the script. Avoiding the repetition of the Rabin signature check sequence by Merkle-izing the contract significantly reduces the size of transactions.

[0154] To verify the redemption script, the response is required to specify a Merkle path, which means that the size of the response scales logarithmically with the number of leaf nodes. Most of the data in the response is the Rabin signature and public key (roughly 300-400 bytes each for the most secure signatures).

[0155] The table below shows the transaction size savings when using Merkle contracts. [Table 10]

[0156] Figure 11 is an example of a transaction template 1100 that may be used by Alice. Alice's contract may be encoded into a single transaction output 1101. Additional metadata for the contract may be embedded in the OP_RETURN output 1102.

[0157] Alice's transaction locking script may contain three separate elements 1103, 1104, and 1105. The first element 1103 checks that the data in the unlocking script attempting to unlock Alice's transaction is indeed the terms of the contract. The second element 1104 checks that Bob is the intended recipient of the digital asset. The third element 1105 allows Alice to reclaim the digital asset if it is not claimed by Bob within a predetermined period (one month in this example).

[0158] Figure 12 is an example transaction that may be used by Bob to unlock the digital asset locked for Alice using the example transaction shown in Figure 11. Bob provides the Merkle path, the data (representing the condition that was met), and the Rabin signature from the oracle along with his own (ECDSA) signature and public key.

[0159] It will be understood that the above-described embodiments have been described by way of example only.

[0160] More generally, according to a first instantiation of the teachings disclosed herein, there is provided a computer-implemented method for encoding a digital contract between a first party in a blockchain network and a second party in the blockchain network, the digital contract for transferring an amount of digital assets from the first party to the second party based on terms under which the contract is fulfilled. The method is performed by a trusted third party and includes obtaining a plurality of data elements, each data element representing a different term of the contract, at least one of the different terms being linked to the second party, and generating a hash tree based on the plurality of data elements. The hash tree includes: i) a leaf layer including a first set of leaf hashes, each generated by hashing a respective data element, and a second set of leaf hashes including at least one hash key generated by hashing a secret value known only to the trusted third party; ii) one or more internal layers, each internal layer including a respective set of internal hashes, each internal hash of each internal layer generated by hashing the concatenation of at least two hashes from lower layers; and iii) a root layer including a root hash, generated by hashing the concatenation of at least two hashes from the top internal layer, and making the root hash available to the first party for inclusion in transactions on the blockchain. method.

[0161] According to a second, optional instantiation, there may be provided a method according to the first instantiation, wherein obtaining the data element comprises receiving the data element from the first party and / or a second party.

[0162] According to a third, optional instantiation, there may be provided a method according to the first and second instantiations above, wherein making the root hash available comprises transmitting the root hash to the first party.

[0163] According to a fourth, optional instantiation, there may be provided a method according to any one of the first to third instantiations, the method including: identifying a transaction on the blockchain generated by the first party, the transaction including the digital contract, and the digital contract including a locking script locking an amount of the digital asset to the first party; determining whether the locking script includes the root hash; and notifying a second party if the locking script does not include the root hash.

[0164] According to a fifth, optional instantiation, there may be provided a method according to any of the first to fourth instantiations, the method including: determining that a condition of a contract associated with the second party is satisfied; and, in response to the determination, sending an authentication path to the second party, the authentication path including a set of hashes, the set of hashes including a hash key and one or more sets of internal hashes, each set of internal hashes belonging to a different internal layer of the hash tree.

[0165] According to a sixth, optional instantiation, there may be provided a method according to any of the first to fifth instantiations, wherein the second set of leaf hashes includes a plurality of different hash keys, each hash key being generated based on the secret value.

[0166] According to a seventh, optional instantiation, there may be provided a method according to the sixth instantiation, wherein each of the first set of leaf hashes is paired with a different one of the hash keys, and each inner hash at the bottom of the hash tree is generated by hashing the concatenation of a different pair of leaf hashes.

[0167] According to an eighth, optional instantiation, there may be provided a method according to the seventh and fifth instantiations above, wherein the authentication path includes the hash key paired with a leaf hash of the condition associated with a second node.

[0168] According to a ninth instantiation of the teachings disclosed herein, there is provided a trusted third party computing device, the computing device including a memory including one or more memory units, and a processing device including one or more processing units, the memory storing code configured to execute on the processing device, the code configured to execute, on the processing device, the teachings according to any of the first through eighth instantiations.

[0169] According to a tenth instantiation of the teachings disclosed herein, there is provided a computer program embodied in a computer-readable storage device and configured to execute the teachings according to any of the first through eighth instantiations when executed on a trusted third party computing device.

[0170] According to an eleventh instantiation of the teachings disclosed herein, there is provided a computer-implemented method for generating a digital contract between a first party and a second party in a blockchain network, the digital contract for transferring an amount of digital assets from the first party to the second party based on conditions under which the contract is fulfilled. The method includes: obtaining a root hash of a hash tree executed by the first party and generated by a trusted third party, the hash tree being generated based on: i) a plurality of data elements, each data element representing a different term of the contract, at least one of the different terms being associated with the second party; and ii) one or more different hash keys generated based on a secret value known only to the trusted third party; and generating a transaction for inclusion in the blockchain, the transaction including a locking script for locking the amount of digital assets to the first party, the locking script including the root hash.

[0171] According to a twelfth, optional instantiation, there may be provided a method according to the eleventh instantiation, wherein the method includes transmitting the transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

[0172] According to a thirteenth, optional instantiation, there may be provided a method according to any of the twelfth or thirteenth instantiations above, wherein obtaining the root hash comprises receiving the root hash from the trusted third party.

[0173] According to a fourteenth, optional instantiation, there may be provided a method according to the twelfth or thirteenth instantiation, wherein the subsequent transaction on the blockchain generated by the second party comprises an unlocking script including: i) data elements representing terms of the contract; and ii) a hash key and an authentication path including one or more inner hashes of the hash tree; and the locking script, when executed together with the locking script, is configured to generate a candidate root hash by performing a hash tree proof using the data elements and the authentication path, and to generate a value representing either true or false depending on whether the root hash matches a candidate root hash tree.

[0174] According to a fifteenth instantiation of the teachings disclosed herein, there is provided a first party computing device, the computing device including a memory including one or more memory units, and a processing device including one or more processing units, the memory storing code configured to execute on the processing device, the code configured to execute, on the processing device, the teachings according to any of the eleventh through fourteenth instantiations.

[0175] According to a sixteenth instantiation of the teachings disclosed herein, there is provided a computer program embodied in a computer-readable storage device and configured to perform the teachings according to any of the eleventh through fourteenth instantiations when executed on the first party's computing device.

[0176] According to a seventeenth instantiation of the teachings disclosed herein, there is provided a computer-implemented method for executing a digital contract between a first party in a blockchain network and a second party in the blockchain network, the digital contract for transferring an amount of digital assets from the first party to the second party based on terms under which the contract is executed. The method is executed by the second party and includes the steps of: acquiring data elements representing terms of the agreement, the terms being linked to the second party; acquiring an authentication path for generating candidate root hashes of a hash tree generated by a trusted third party, the authentication path including a set of hashes, the set of hashes including a hash key generated based on a secret value known only to the trusted third party, and one or more sets of internal hashes, each set of internal hashes belonging to a different internal layer of the hashes; and generating a transaction for inclusion in the blockchain, the transaction including an unlocking script for unlocking the digital asset amount from the first party, the unlocking script including the acquired data elements and the acquired authentication path.

[0177] According to an eighteenth, optional instantiation, there may be provided a method according to the seventeenth instantiation, comprising transmitting the transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

[0178] According to a nineteenth instantiation of the teachings disclosed herein, there is provided a computing device of the second party, the computing device including a memory including one or more memory units, and a processing device including one or more processing units, the memory storing code configured to execute on the processing device, the code configured to execute, on the processing device, the teachings according to the seventeenth or eighteenth instantiation.

[0179] According to a twentieth instantiation of the teachings disclosed herein, there is provided a computer program embodied in a computer-readable storage device and configured to perform the teachings according to the seventeenth or eighteenth instantiations when executed on the second party's computing device.

[0180] According to a twenty-first instantiation of the teachings disclosed herein, there is provided a computer-implemented method for encoding a digital contract between a first party in a blockchain network and a second party in the blockchain network, the digital contract for transferring an amount of digital assets from the first party to the second party based on conditions under which the contract is fulfilled, the method including, in response to determining that a condition of the contract, executed by a trusted third party and linked to the second party, is satisfied, providing a signature of the trusted third party to the second party for inclusion in the blockchain transaction, the signature signing a data element representing the satisfied condition.

[0181] According to a twenty-second, optional instantiation, there may be provided a method according to the twenty-first instantiation, wherein the signature is a Rabin signature.

[0182] According to a twenty-third, optional instantiation, there may be provided a method according to the twenty-second instantiation, comprising providing the second party with a Rabin public key.

[0183] According to a 24th, optional instantiation, there may be provided a method according to any of the 21st to 23rd instantiations above, wherein providing the signature comprises directly transmitting the signature to the second party.

[0184] According to a 25th, optional instantiation, there may be provided a method according to any of the 21st to 24th instantiations, the method including providing a plurality of data elements to the first party, each data element representing a different term of the contract, and the plurality of data elements including a data element representing a term linked to the second party.

[0185] According to a 26th, optional instantiation, there may be provided a method according to the 25th instantiation, comprising: generating a root hash of a hash tree, the hash tree including a layer of leaf hashes, at least some of the leaf hashes being generated based on respective ones of the plurality of data elements; and providing the root hash to the first party.

[0186] According to a 27th, optional instantiation, there may be provided a method according to the 26th instantiation, comprising providing an authentication path to the second party for generating candidate root hashes for the hash tree using a data element representing the satisfied condition.

[0187] According to a twenty-eighth, optional instantiation, there may be provided a method according to any of the twenty-first to twenty-sixth instantiations, wherein each data element is a different binary or hexadecimal value representing a different term of the agreement.

[0188] According to a twenty-ninth instantiation of the teachings disclosed herein, there is provided a trusted third party computing device, the computing device including a memory including one or more memory units, and a processing device including one or more processing units, the memory storing code configured to execute on the processing device, the code configured to execute, on the processing device, the teachings according to any of the twenty-first through twenty-eight instantiations.

[0189] According to a thirtieth instantiation of the teachings disclosed herein, there is provided a computer program embodied in a computer-readable storage device and configured to execute the teachings according to any of the twenty-first through twenty-eight instantiations.

[0190] According to a thirty-first instantiation of the teachings disclosed herein, there is provided a computer-implemented method for generating a digital contract between a first party in a blockchain network and a second party in the blockchain network, the digital contract for transferring an amount of digital assets from the first party to the second party based on terms under which the contract is executed. The method is executed by the trusted first party and includes the steps of: obtaining a root hash of a hash tree, the hash tree including a layer of leaf hashes, at least some of the leaf hashes each generated based on a respective one of a plurality of data elements, each data element representing a different term of the contract, at least one of the different terms linked to the second party; and generating a transaction for inclusion in the blockchain, the transaction including a locking script for locking the amount of the digital asset to the first party, the locking script including the root hash, the locking script configured, when executed together with an unlocking script of a later transaction, to determine whether the unlocking script includes i) a data element representing a term of the contract signed with a signature of a trusted third party, and ii) a certification path using the signed data element to generate a candidate root hash that matches the obtained root hash.

[0191] According to a thirty-second, optional instantiation, there may be provided a method according to the thirty-first instantiation, wherein the step of obtaining a root hash includes: generating the root hash.

[0192] According to a thirty-third, optional instantiation, there may be provided a method according to the thirty-first instantiation, wherein obtaining the root hash includes obtaining the root hash from the second party and / or the trusted third party.

[0193] According to a thirty-fourth, optional instantiation, there may be provided a method according to any of the thirty-first to thirty-third instantiations, wherein the signature is a Rabin signature.

[0194] According to a 35th, optional instantiation, there may be provided a method according to any of the 31st to 34th instantiations, wherein the authentication path includes a sequence of hash values, one from each layer of the hash tree, and the locking script includes a sequence of opcodes for performing a hash tree proof using the obtained root hash and the sequence of hash values.

[0195] According to a thirty-sixth, optional instantiation, there may be provided a method according to any of the thirty-first to thirty-fifth instantiations, wherein the locking script is configured to allow the first party to redeem the amount of the digital asset if the amount is not transferred to the second party within a predetermined time.

[0196] According to a thirty-seventh, optional instantiation, there may be provided a method according to any of the thirty-first to thirty-sixth instantiations, wherein the locking script is configured to: iii) determine whether the locking script includes a valid signature and public key of the second party.

[0197] According to a thirty-eighth, optional instantiation, there may be provided a method according to any of the thirty-first to thirty-seventh instantiations, wherein the transaction includes a first output and a second output, the first output including the locking script, and the second output including metadata based on the digital contract.

[0198] According to a thirty-ninth, optional instantiation, there may be provided a method according to any of the thirty-first to thirty-eighth instantiations, the method comprising transmitting the transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

[0199] According to a fortieth, optional instantiation, there may be provided a method according to any of the thirty-first to thirty-sixth instantiations, the method comprising generating a second transaction for inclusion in the blockchain, the second transaction including an unlocking script configured to unlock the locking script, the unlocking script including the first party's public key and signature.

[0200] According to a forty-first instantiation of the teachings disclosed herein, there is provided a first party computing device, the computing device including a memory including one or more memory units, and a processing device including one or more processing units, the memory storing code configured to execute on the processing device, the code configured to execute, on the processing device, the teachings according to any of the thirty-first through fortieth instantiations.

[0201] According to a forty-second instantiation of the teachings disclosed herein, there is provided a computer program embodied in a computer-readable storage device and configured to perform the teachings according to any of the thirty-first through fortieth instantiations when executed on a trusted third party computing device.

[0202] According to a 43rd instantiation of the teachings disclosed herein, a computer-implemented method is disclosed for executing a digital contract between a first party in a blockchain network and a second party in the blockchain network, the digital contract being for transferring an amount of digital assets from the first party to the second party based on the terms and conditions under which the contract is executed. The method is executed by the second party and includes the steps of: obtaining data elements representing performance conditions of the contract, the conditions being linked to the second party; obtaining an authentication path using the obtained data elements to generate candidate root hashes for a hash tree, the hash tree including a layer of leaf hashes, at least some of the leaf hashes each generated based on a respective one of a plurality of data elements, each data element representing a different condition of the contract, the plurality of data elements including the obtained data element; obtaining a signature and public key of a trusted third party, the signature signing the performance; and generating a transaction for inclusion in the blockchain, the transaction including an unlocking script to unlock the aggregate amount of digital assets from the first party, the unlocking script including the obtained authentication path, the public key, and the obtained data elements signed with the signature.

[0203] According to a forty-fourth, optional instantiation, there may be provided a method according to the forty-third instantiation above, wherein the signature is a Rabin signature.

[0204] According to a 45th, optional instantiation, there may be provided a method according to any of the 43rd or 44th instantiations above, wherein obtaining the certification path comprises obtaining the certification path from the trusted third party.

[0205] According to a 46th, optional instantiation, there may be provided a method according to any of the 43rd or 44th instantiations above, wherein obtaining the signature and / or the public key of the trusted third party comprises obtaining the signature and / or the public key directly from the trusted third party.

[0206] According to a 47th, optional instantiation, there may be provided a method according to any of the 41st to 46th instantiations, wherein the authentication paths each include a sequence of hash values ​​from a respective layer of the hash tree.

[0207] According to a 48th, optional instantiation, there may be provided a method according to any of the instantiations of 43 to 47, comprising transmitting the transaction to one or more nodes of the blockchain network for inclusion in the blockchain.

[0208] According to a forty-ninth instantiation of the teachings disclosed herein, there is provided a second party computing device, the computing device including a memory including one or more memory units, and a processing device including one or more processing units, the memory storing code configured to execute on the processing device, the code configured to execute, on the processing device, the teachings according to any of the forty-third through forty-eight instantiations.

[0209] According to a fiftieth instantiation of the teachings disclosed herein, there is provided a computer program embodied in a computer-readable storage device and configured to perform the teachings according to any of the forty-third through forty-eighth instantiations when executed on a trusted third party computing device.

[0210] According to a fifty-first instantiation of the teachings disclosed herein, there is provided a computer-readable storage medium including a transaction for implementing a digital contract between a first party in a blockchain network and a second party in the blockchain network. The digital contract is for transferring an amount of digital assets from the first party to the second party based on the terms under which the contract is fulfilled. The transaction includes a locking script for locking the amount of digital assets to the first party, the locking script including a root hash, and the root hash of a hash tree generated by a trusted third party. The hash tree is generated based on i) a plurality of data elements, each data element representing a different term of the contract, at least one of the different terms being associated with the second party, and ii) one or more different hash keys generated based on a secret value known only to the trusted third party.

[0211] According to another instantiation of the teachings disclosed herein, a method may be provided that includes operations of a first party, a second party, and a trusted third party.

[0212] According to another instantiation of the teachings disclosed herein, a system may be provided that includes first party, second party, and trusted third party computing devices.

[0213] Other variations or uses of the disclosed technology may become apparent to those skilled in the art once disclosed herein. The scope of the present disclosure is not limited by the described embodiments, but only by the appended claims. < / key1> < / z4> < / z2> < / n> < / m> < / s>

Claims

1. 1. A computer-implemented method for encoding a digital contract between a first party in a blockchain network and a second party in the blockchain network, comprising: the digital contract is for the transfer of an amount of digital assets from the first party to the second party based on the terms and conditions under which the contract is executed; The method is performed by a trusted third party that is a computer device; and obtaining a plurality of data elements, each data element representing a respective term of the contract, and at least one of the respective terms being linked to the second party; generating at least one hash key by hashing a secret value known only to the trusted third party; generating a hash tree based on the plurality of data elements; Including, The hash tree is i) a leaf layer; a first set of leaf hashes, each generated by hashing a respective data element; and a second set of leaf hashes comprising the at least one hash key; a leaf layer including: ii) one or more internal layers; Each inner layer contains a respective set of inner hashes, Each internal hash of each internal layer is generated by hashing the concatenation of at least two hashes from the lower layers. An inner layer; iii) a root stratum containing the root hash; the root hash is generated by hashing the concatenation of at least two hashes from the highest internal layer; and making the root hash available to the first party for inclusion in transactions on the blockchain; A root layer; Including, The method further comprises: determining the terms of the contract linked to the second party; sending an authentication path to the second party in response to the determination; the authentication path includes a set of hashes; the set of hashes includes a hash key and one or more sets of internal hashes; Each set of inner hashes belongs to an inner layer of each of the hash trees. Steps and A method comprising:

2. The step of obtaining the data elements includes: receiving said data elements from said first party being a computer device and / or said second party being a computer device; The method of claim 1 , comprising:

3. The step of making the root hash available comprises: sending the root hash to the first party; 3. The method of claim 1 or 2, comprising:

4. The method comprises: identifying a transaction on the blockchain generated by the first party; The transaction includes the digital contract; and the digital contract includes a locking script locking the amount of the digital asset to the first party; Steps and determining whether the locking script includes the root hash; if the locking script does not contain the root hash, notifying a second party; 4. The method of claim 1, comprising:

5. the second set of leaf hashes includes a plurality of different hash keys, each hash key being generated based on the secret value; 5. The method according to any one of claims 1 to 4.

6. each of the first set of leaf hashes is paired with a respective one of the hash keys; and Each of the inner hashes at the bottom of the hash tree is generated by hashing the concatenation of each pair of leaf hashes. The method of claim 5.

7. the authentication path includes the hash key paired with a leaf hash of the condition associated with the second party; The method of claim 6.

8. a trusted third party computing device, a memory including one or more memory units; a processing device including one or more processing units; the memory storing code configured to execute on the processing unit; The code is configured to execute, on the processing device, a method according to any one of claims 1 to 7. Computer equipment.

9. A computer program comprising: embodied in a computer-readable storage device; and When executed on a computer device of a trusted third party, it is configured to carry out the method of any one of claims 1 to 7. Computer program.

10. 1. A computer-implemented method for creating a digital contract between a first party in a blockchain network and a second party in the blockchain network, comprising: the digital contract is for the transfer of an amount of digital assets from the first party to the second party based on the terms and conditions under which the contract is executed; The method is performed by the first party; and obtaining a root hash of a hash tree generated by a trusted third party that is a computer device, the hash tree comprising: i) a plurality of data elements, each data element representing a different term of the agreement, at least one of the different terms being related to the second party; and ii) one or more different hash keys generated based on a secret value known only to the trusted third party; and generating transactions for inclusion in the blockchain; the transaction includes a locking script for locking the amount of the digital asset to the first party; and the locking script includes the root hash; and A subsequent transaction on the blockchain generated by the second party is: i) data elements representing the terms of said contract; ii) an authentication path that includes a hash key and one or more inner hashes of the hash tree; an unlocking script including: The locking script, when executed together with the locking script, generating candidate root hashes by performing a hash tree proof using the data elements and the certification path; and generating a value representing either true or false depending on whether the root hash matches a candidate root hash tree; It is configured as follows: method.

11. The method comprises: submitting the transaction to one or more nodes of the blockchain network for inclusion in the blockchain; The method of claim 10, comprising:

12. The step of obtaining the root hash includes: receiving the root hash from the trusted third party; The method of claim 11 , comprising:

13. a computing device of the first party, a memory including one or more memory units; a processing device including one or more processing units; the memory storing code configured to execute on the processing unit; The code is configured to execute, on the processing device, a method according to claim 11 or 12. Computer equipment.

14. A computer program comprising: embodied in a computer-readable storage device; and configured to perform the method of claim 11 or 12 when executed on the first party's computing device; Computer program.

15. 1. A computer-implemented method for executing a digital contract between a first party in a blockchain network and a second party in the blockchain network, comprising: the digital contract is for the transfer of an amount of digital assets from the first party to the second party based on the terms and conditions under which the contract is executed; The method is performed by the second party; and obtaining data elements representing terms of the contract, the terms being linked to the second party; A step of obtaining a certification pass, The certification path is for generating candidate root hashes of a hash tree generated by a trusted third party that is a computer device; and the authentication path includes a set of hashes; the set of hashes includes a hash key generated based on a secret value known only to the trusted third party and one or more sets of internal hashes; Each set of inner hashes belongs to a different inner layer of hashes. Steps and generating transactions for inclusion in the blockchain; the transaction includes an unlocking script for unlocking the amount of digital assets from the first party; and the unlocking script includes the obtained data element and the obtained authentication path. Steps and A method comprising:

16. The method comprises: submitting the transaction to one or more nodes of the blockchain network for inclusion in the blockchain; 16. The method of claim 15, comprising:

17. a computing device of the second party, a memory including one or more memory units; a processing device including one or more processing units; the memory storing code configured to execute on the processing unit; The code is configured to execute, on the processing device, a method according to claim 15 or 16. Computer equipment.

18. A computer program comprising: embodied in a computer-readable storage device; and configured to perform the method of claim 15 or 16 when executed on the second party's computing device. Computer program.

Images