WO2023156102A1 - Attestation à un ensemble de sorties de transaction non consommées - Google Patents
Attestation à un ensemble de sorties de transaction non consommées Download PDFInfo
- Publication number
- WO2023156102A1 WO2023156102A1 PCT/EP2023/050839 EP2023050839W WO2023156102A1 WO 2023156102 A1 WO2023156102 A1 WO 2023156102A1 EP 2023050839 W EP2023050839 W EP 2023050839W WO 2023156102 A1 WO2023156102 A1 WO 2023156102A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- transaction
- blockchain
- node
- outputs
- leaf
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Definitions
- the present disclosure relates to attesting to a set of unconsumed outputs (e.g. UTXOs) of blockchain transactions.
- a set of unconsumed outputs e.g. UTXOs
- a blockchain refers to a form of distributed data structure, wherein a duplicate copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (referred to below as a "blockchain network”) and widely publicised.
- the blockchain comprises a chain of blocks of data, wherein each block comprises one or more transactions.
- Each transaction other than so-called “coinbase transactions”, points back to a preceding transaction in a sequence which may span one or more blocks going back to one or more coinbase transactions.
- Coinbase transactions are discussed further below.
- New blocks are created by a process often referred to as “mining”, which involves each of a plurality of the nodes competing to perform "proof-of-work", i.e. solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain.
- mining a process often referred to as "mining”
- proof-of-work i.e. solving a cryptographic puzzle based on a representation of a defined set of ordered and validated pending transactions waiting to be included in a new block of the blockchain.
- the blockchain may be pruned at some nodes, and the publication of blocks can be achieved through the publication of mere block headers.
- the transactions in the blockchain may be used for one or more of the following purposes: to convey a digital asset (i.e. a number of digital tokens), to order a set of entries in a virtualised ledger or registry, to receive and process timestamp entries, and/or to time- order index pointers.
- a blockchain can also be exploited in order to layer additional functionality on top of the blockchain.
- blockchain protocols may allow for storage of additional user data or indexes to data in a transaction.
- Nodes of the blockchain network (which are often referred to as “miners") perform a distributed transaction registration and verification process, which will be described in more detail later.
- a node validates transactions and inserts them into a block template for which they attempt to identify a valid proof-of-work solution. Once a valid solution is found, a new block is propagated to other nodes of the network, thus enabling each node to record the new block on the blockchain.
- a user e.g. a blockchain client application
- Nodes which receive the transaction may race to find a proof-of-work solution incorporating the validated transaction into a new block.
- Each node is configured to enforce the same node protocol, which will include one or more conditions for a transaction to be valid. Invalid transactions will not be propagated nor incorporated into blocks. Assuming the transaction is validated and thereby accepted onto the blockchain, then the transaction (including any user data) will thus remain registered and indexed at each of the nodes in the blockchain network as an immutable public record.
- the node who successfully solved the proof-of-work puzzle to create the latest block is typically rewarded with a new transaction called the "coinbase transaction" which distributes an amount of the digital asset, i.e. a number of tokens.
- the detection and rejection of invalid transactions is enforced by the actions of competing nodes who act as agents of the network and are incentivised to report and block malfeasance.
- the widespread publication of information allows users to continuously audit the performance of nodes.
- the publication of the mere block headers allows participants to ensure the ongoing integrity of the blockchain.
- the data structure of a given transaction comprises one or more inputs and one or more outputs.
- Any spendable output comprises an element specifying an amount of the digital asset that is derivable from the proceeding sequence of transactions.
- the spendable output is sometimes referred to as a UTXO ("unspent transaction output").
- the output may further comprise a locking script specifying a condition for the future redemption of the output.
- a locking script is a predicate defining the conditions necessary to validate and transfer digital tokens or assets.
- Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e.
- a reference to such an output in a preceding transaction, and may further comprise an unlocking script for unlocking the locking script of the pointed-to output.
- the first transaction comprises at least one output specifying an amount of the digital asset, and comprising a locking script defining one or more conditions of unlocking the output.
- the second, target transaction comprises at least one input, comprising a pointer to the output of the first transaction, and an unlocking script for unlocking the output of the first transaction.
- one of the criteria for validity applied at each node will be that the unlocking script meets all of the one or more conditions defined in the locking script of the first transaction. Another will be that the output of the first transaction has not already been redeemed by another, earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate it (as a valid transaction, but possibly to register an invalid transaction) nor include it in a new block to be recorded in the blockchain.
- a hash tree in general is a data structure comprising a root node, one or more internal layers, and a leaf layer, arranged in a hierarchy from root (highest layer) to leaf layer (lowest in the hierarchy).
- Each of the internal layers and the leaf layer comprises a plurality of nodes at that layer.
- the root node is a hash of the nodes in the next layer down in the hierarchy, and in each internal layer, each node is a hash of a different subset of the nodes at the next layer down in the hierarchy.
- the leaf nodes themselves are typically also hashes, each a hash of respective preimage data.
- each leaf can be used to designate a different corresponding subset of the transaction outputs (e.g. the UTXOs of a given transaction), e.g. by each leaf comprising hash of its corresponding subset of UTXOs (or the like).
- the hash tree comprises a plurality of layers arranged in a hierarchy from a leaf layer up to a root layer with one or more internal layers in between.
- the root layer comprises a root node
- each internal layer and the leaf layer each comprise a respective plurality of nodes with each node having an indexed position within its respective layer.
- each node within the layer comprises a hash of a combination of a different corresponding subset of at least two of the nodes at the next layer down in the hierarchy.
- at least some of the leaf nodes can each either A) designate a corresponding subset of one or more of the unconsumed outputs or B) comprise a placeholder value.
- the method further comprises, on each of one or more occasions: I) determining an update to the set of unconsumed outputs, each update comprising an addition of one or more new outputs and/or removal of one or more outputs which have now been consumed, and II) recomputing the hash tree to reflect the update.
- the update comprises removal of at least one output and on at least one of the occasions the update comprises the addition of at least one new output.
- the recomputing of the hash tree comprises: when any output is removed, removing the leaf node designating the removed output and replacing the removed leaf node, at the same position in the leaf layer, with a new leaf node which either: A) designates an updated subset of one or more unconsumed outputs not including the removed output, or B) comprises a placeholder value; and when any new output is added, forming a new leaf node designating a subset of one or more unconsumed outputs including at least the new output, wherein the new leaf node is inserted in the tree in place of a replaceable leaf node when available, at the same position in the leaf layer, a replaceable leaf node being a leaf node that either: A) designates an output being removed, or B) comprises a placeholder value; but otherwise if no replaceable leaf node is available, the tree is expanded to accommodate the new leaf node.
- the disclosed method uses a scheme of placeholder values, which could also be described as "dummy" leaves.
- the method allows a placeholder value to be added to replace a removed leaf node removed from any arbitrary position in the leaf layer.
- the placeholder values are not constrained to being added only to pad out the right hand side of the tree.
- the method preferably allows a new node to be added to replace a placeholder value that may have been included at any position in the leaf layer, including the possibility of a placeholder value that is left of a non-placeholder leaf node (one that actually designates one or more transaction outputs).
- the new nodes are not necessarily only added in place of right-hand padding of the tree.
- Figure 1 is a schematic block diagram of a system for implementing a blockchain
- Figure 2 schematically illustrates some examples of transactions which may be recorded in a blockchain
- FIGS 3 and 4 schematically illustrate the concept of a Merkle tree by way of example
- Figure 5 schematically illustrates a scheme for indexing nodes of a Merkle tree
- Figure 6 schematically illustrates by way of example the concept of a holey Merkle tree
- Figure 7 is a flow chart of an example method according to embodiments disclosed herein.
- Figure 8 is a flow chart of a method of providing and executing a hash puzzle
- Figure 9 is a schematic transaction diagram of a an example of a challenge transaction and a corresponding candidate transaction
- Figure 10 is a schematic illustration of a an example of a process of updating a holey Merkle tree
- Figure 11 schematically illustrates a relationship between the changelog ⁇ , the new set of leaves.
- the state of the blockchain at a particular block height can be considered as the set of unspent transaction outputs recorded on chain, sometimes known as the UTXO set.
- a given node (or "miner") of the blockchain network may also maintain a local UTXO set that additionally includes those in the pool of pending transactions maintained at the node.
- the UTXO set is used for validating incoming transactions, and each blockchain node therefore maintains a local copy of the UTXO set, according to the worldview of that node.
- the UTXO set must be derived from the historical transactions that have occurred on the blockchain.
- a deterministic mechanism for processing, structuring, and committing to the UTXO set, e.g. at any given block height, such that the mechanism can be utilised by any observer to check the membership of a particular UTXO at a given block height.
- the disclosure provides a new data structure for a UTXO set, structuring the UTXO set as a Holey Merkle Tree (HMT).
- HMT Holey Merkle Tree
- the disclosure also provides an efficient algorithm to update the UTXO set by incremental deterministic UTXO set updates.
- Embodiments also provide a commitment scheme that ensures the integrity of the UTXO set, by incentivising miners to publicly commit to a particular UTXO set snapshot.
- the disclosed embodiments for committing to the state of the UTXO set at a particular block height enable an efficient verification on a given UTXO set for the given block height. Once the UTXO set is verified, it can be used in a wide variety of applications to enable users to check membership of UTXOs in the set at a particular historical point in time.
- FIG. 1 shows an example system 100 for implementing a blockchain 150.
- the system 100 may comprise a packet-switched network 101, typically a wide-area internetwork such as the Internet.
- the packet-switched network 101 comprises a plurality of blockchain nodes
- each blockchain node 104 is therefore highly connected to other blockchain nodes 104.
- Each blockchain node 104 comprises computer equipment of a peer, with different ones of the nodes 104 belonging to different peers.
- Each blockchain node 104 comprises processing apparatus comprising one or more processors, e.g. one or more central processing units
- CPUs central processing unit
- accelerator processors application specific processors and/or field programmable gate arrays (FPGAs)
- FPGAs field programmable gate arrays
- Each node also comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media.
- the memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as a hard disk; an electronic medium such as a solid-state drive (SSD), flash memory or
- EEPROM electrically erasable programmable read-only memory
- optical medium such as an optical disk drive
- the blockchain 150 comprises a chain of blocks of data 151, wherein a respective copy of the blockchain 150 is maintained at each of a plurality of blockchain nodes 104 in the distributed or blockchain network 106.
- maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in full. Instead, the blockchain 150 may be pruned of data so long as each blockchain node 150 stores the block header (discussed below) of each block 151.
- Each block 151 in the chain comprises one or more transactions 152, wherein a transaction in this context refers to a kind of data structure. The nature of the data structure will depend on the type of transaction protocol used as part of a transaction model or scheme. A given blockchain will use one particular transaction protocol throughout.
- each transaction 152 comprises at least one input and at least one output.
- Each output specifies an amount representing a quantity of a digital asset as property, an example of which is a user 103 to whom the output is cryptographically locked (requiring a signature or other solution of that user in order to be unlocked and thereby redeemed or spent).
- Each input points back to the output of a preceding transaction 152, thereby linking the transactions.
- Each block 151 also comprises a block pointer 155 pointing back to the previously created block 151 in the chain so as to define a sequential order to the blocks 151.
- Each of the blockchain nodes 104 is configured to forward transactions 152 to other blockchain nodes 104, and thereby cause transactions 152 to be propagated throughout the network 106.
- Each blockchain node 104 is configured to create blocks 151 and to store a respective copy of the same blockchain 150 in their respective memory.
- Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into blocks 151.
- the ordered pool 154 is often referred to as a "mempool”.
- This term herein is not intended to limit to any particular blockchain, protocol or model. It refers to the ordered set of transactions which a node 104 has accepted as valid and for which the node 104 is obliged not to accept any other transactions attempting to spend the same output.
- the (or each) input comprises a pointer referencing the output of a preceding transaction 152i in the sequence of transactions, specifying that this output is to be redeemed or "spent" in the present transaction 152j.
- Spending or redeeming does not necessarily imply transfer of a financial asset, though that is certainly one common application. More generally spending could be described as consuming the output, or assigning it to one or more outputs in another, onward transaction.
- the preceding transaction could be any transaction in the ordered set 154 or any block 151.
- the preceding transaction 152i need not necessarily exist at the time the present transaction
- preceding refers to a predecessor in a logical sequence linked by pointers, not necessarily the time of creation or sending in a temporal sequence, and hence it does not necessarily exclude that the transactions 152i, 152j be created or sent out-of-order (see discussion below on orphan transactions).
- the preceding transaction 152i could equally be called the antecedent or predecessor transaction.
- the input of the present transaction 152j also comprises the input authorisation, for example the signature of the user 103a to whom the output of the preceding transaction
- the output of the present transaction 152j can be cryptographically locked to a new user or entity 103b.
- the present transaction 152j can thus transfer the amount defined in the input of the preceding transaction 152i to the new user or entity
- 152 may have multiple outputs to split the input amount between multiple users or entities
- a transaction can also have multiple inputs to gather together the amounts from multiple outputs of one or more preceding transactions, and redistribute to one or more outputs of the current transaction.
- an output-based transaction protocol such as bitcoin
- a party 103 such as an individual user or an organization
- wishes to enact a new transaction 152j either manually or by an automated process employed by the party
- the enacting party sends the new transaction from its computer terminal 102 to a recipient.
- the enacting party or the recipient will eventually send this transaction to one or more of the blockchain nodes
- a blockchain node 104 that receives a transaction checks whether the transaction is valid according to a blockchain node protocol which is applied at each of the blockchain nodes 104.
- the blockchain node protocol typically requires the blockchain node 104 to check that a cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in an ordered sequence of transactions 152.
- this may comprise checking that the cryptographic signature or other authorisation of the party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i which the new transaction spends (or "assigns"), wherein this condition typically comprises at least checking that the cryptographic signature or other authorisation in the input of the new transaction 152j unlocks the output of the previous transaction 152i to which the input of the new transaction is linked to.
- the condition may be at least partially defined by a script included in the output of the preceding transaction 152i . Alternatively it could simply be fixed by the blockchain node protocol alone, or it could be due to a combination of these.
- the blockchain node 104 forwards it to one or more other blockchain nodes 104 in the blockchain network 106. These other blockchain nodes 104 apply the same test according to the same blockchain node protocol, and so forward the new transaction 152j on to one or more further nodes 104, and so forth. In this way the new transaction is propagated throughout the network of blockchain nodes 104.
- the blockchain nodes then race to assemble a new valid block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically this comprises searching for a "nonce" value such that when the nonce is concatenated with a representation of the ordered pool of pending transactions 154 and hashed, then the output of the hash meets a predetermined condition.
- the predetermined condition may be that the output of the hash has a certain predefined number of leading zeros. Note that this is just one particular type of proof-of- work puzzle, and other types are not excluded. A property of a hash function is that it has an unpredictable output with respect to its input. Therefore this search can only be performed by brute force, thus consuming a substantive amount of processing resource at each blockchain node 104 that is trying to solve the puzzle.
- the first blockchain node 104 to solve the puzzle announces this to the network 106, providing the solution as proof which can then be easily checked by the other blockchain nodes 104 in the network (once given the solution to a hash it is straightforward to check that it causes the output of the hash to meet the condition).
- the first blockchain node 104 propagates a block to a threshold consensus of other nodes that accept the block and thus enforce the protocol rules.
- the ordered set of transactions 154 then becomes recorded as a new block 151 in the blockchain 150 by each of the blockchain nodes 104.
- the significant amount of effort, for example in the form of hash, required to create a proof-of-work solution signals the intent of the first node 104 to follow the rules of the blockchain protocol.
- rules include not accepting a transaction as valid if it spends or assigns the same output as a previously validated transaction, otherwise known as double-spending.
- the block 151 cannot be modified since it is recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106.
- the block pointer 155 also imposes a sequential order to the blocks 151. Since the transactions 152 are recorded in the ordered blocks at each blockchain node 104 in a network 106, this therefore provides an immutable public ledger of the transactions.
- a node that successfully constructs a new block 104 is granted the ability to newly assign an additional, accepted amount of the digital asset in a new special kind of transaction which distributes an additional defined quantity of the digital asset (as opposed to an inter-agent, or inter-user transaction which transfers an amount of the digital asset from one agent or user to another).
- This special type of transaction is usually referred to as a "coinbase transaction", but may also be termed an "initiation transaction” or "generation transaction”. It typically forms the first transaction of the new block 151n.
- the proof-of-work signals the intent of the node that constructs the new block to follow the protocol rules allowing this special transaction to be redeemed later.
- the blockchain protocol rules may require a maturity period, for example 100 blocks, before this special transaction may be redeemed.
- a regular (non-generation) transaction 152 will also specify an additional transaction fee in one of its outputs, to further reward the blockchain node 104 that created the block 151n in which that transaction was published. This fee is normally referred to as the "transaction fee", and is discussed blow.
- each blockchain node 104 stores software configured to run on the processing apparatus of the blockchain node 104 in order to perform its respective role or roles and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any action attributed herein to a blockchain node 104 may be performed by the software run on the processing apparatus of the respective computer equipment.
- the node software may be implemented in one or more applications at the application layer, or a lower layer such as the operating system layer or a protocol layer, or any combination of these.
- Some or all of the parties 103 may be connected as part of a different network, e.g. a network overlaid on top of the blockchain network 106. Users of the blockchain network
- clients may be said to be part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 as they do not perform the roles required of the blockchain nodes. Instead, each party 103 may interact with the blockchain network 106 and thereby utilize the blockchain 150 by connecting to
- Two parties 103 and their respective equipment 102 are shown for illustrative purposes: a first party 103a and his/her respective computer equipment 102a, and a second party 103b and his/her respective computer equipment 102b. It will be understood that many more such parties 103 and their respective computer equipment 102 may be present and participating in the system 100, but for convenience they are not illustrated.
- Each party 103 may be an individual or an organization. Purely by way of illustration the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be appreciated that this is not limiting and any reference herein to Alice or Bob may be replaced with "first party" and
- the computer equipment 102 of each party 103 comprises respective processing apparatus comprising one or more processors, e.g. one or more CPUs, GPUs, other accelerator processors, application specific processors, and/or FPGAs.
- the computer equipment 102 of each party 103 further comprises memory, i.e. computer-readable storage in the form of a non-transitory computer-readable medium or media.
- This memory may comprise one or more memory units employing one or more memory media, e.g. a magnetic medium such as hard disk; an electronic medium such as an SSD, flash memory or EEPROM; and/or an optical medium such as an optical disc drive.
- the memory on the computer equipment 102 of each party 103 stores software comprising a respective instance of at least one client application 105 arranged to run on the processing apparatus.
- any action attributed herein to a given party 103 may be performed using the software run on the processing apparatus of the respective computer equipment 102.
- the computer equipment 102 of each party 103 comprises at least one user terminal, e.g. a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch.
- the computer equipment 102 of a given party 103 may also comprise one or more other networked resources, such as cloud computing resources accessed via the user terminal.
- the client application 105 may be initially provided to the computer equipment 102 of any given party 103 on suitable computer-readable storage medium or media, e.g. downloaded from a server, or provided on a removable storage device such as a removable SSD, flash memory key, removable EEPROM, removable magnetic disk drive, magnetic floppy disk or tape, optical disk such as a CD or DVD ROM, or a removable optical drive, etc.
- the client application 105 comprises at least a "wallet" function. This has two main functionalities. One of these is to enable the respective party 103 to create, authorise (for example sign) and send transactions 152 to one or more bitcoin nodes 104 to then be propagated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150.
- this second functionality comprises collating the amounts defined in the outputs of the various 152 transactions scattered throughout the blockchain 150 that belong to the party in question.
- client functionality may be described as being integrated into a given client application 105, this is not necessarily limiting and instead any client functionality described herein may instead be implemented in a suite of two or more distinct applications, e.g. interfacing via an API, or one being a plug-in to the other. More generally the client functionality could be implemented at the application layer or a lower layer such as the operating system, or any combination of these. The following will be described in terms of a client application 105 but it will be appreciated that this is not limiting.
- the instance of the client application or software 105 on each computer equipment 102 is operatively coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet function of the client 105 to send transactions 152 to the network 106.
- the client 105 is also able to contact blockchain nodes 104 in order to query the blockchain
- the blockchain 150 for any transactions of which the respective party 103 is the recipient (or indeed inspect other parties' transactions in the blockchain 150, since in embodiments the blockchain 150 is a public facility which provides trust in transactions in part through its public visibility).
- each computer equipment 102 is configured to formulate and send transactions 152 according to a transaction protocol.
- each blockchain node 104 runs software configured to validate transactions 152 according to the blockchain node protocol, and to forward transactions 152 in order to propagate them throughout the blockchain network 106.
- the transaction protocol and the node protocol correspond to one another, and a given transaction protocol goes with a given node protocol, together implementing a given transaction model.
- the same transaction protocol is used for all transactions 152 in the blockchain 150.
- the same node protocol is used by all the nodes 104 in the network 106.
- a given party 103 say Alice, wishes to send a new transaction 152j to be included in the blockchain 150, then she formulates the new transaction in accordance with the relevant transaction protocol (using the wallet function in her client application 105). She then sends the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. E.g. this could be the blockchain node 104 that is best connected to Alice's computer 102.
- any given blockchain node 104 receives a new transaction 152j, it handles it in accordance with the blockchain node protocol and its respective role. This comprises first checking whether the newly received transaction 152j meets a certain condition for being "valid", examples of which will be discussed in more detail shortly. In some transaction protocols, the condition for validation may be configurable on a per-transaction basis by scripts included in the transactions 152.
- condition could simply be a built-in feature of the node protocol, or be defined by a combination of the script and the node protocol.
- any blockchain node 104 that receives the transaction 152j will add the new validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j will propagate the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Since each blockchain node
- Each transaction 152j comprises a pointer back to an earlier transaction, so the order of the transactions is also immutably recorded.
- Different blockchain nodes 104 may receive different instances of a given transaction first and therefore have conflicting views of which instance is 'valid' before one instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid, and then discovers that a second instance has been recorded in the blockchain 150 then that blockchain node 104 must accept this and will discard (i.e. treat as invalid) the instance which it had initially accepted (i.e. the one that has not been published in a block
- An alternative type of transaction protocol operated by some blockchain networks may be referred to as an "account-based" protocol, as part of an account-based transaction model.
- each transaction does not define the amount to be transferred by referring back to the UTXO of a preceding transaction in a sequence of past transactions, but rather by reference to an absolute account balance.
- the current state of all accounts is stored, by the nodes of that network, separate to the blockchain and is updated constantly.
- transactions are ordered using a running transaction tally of the account
- This value is signed by the sender as part of their cryptographic signature and is hashed as part of the transaction reference calculation.
- an optional data field may also be signed the transaction. This data field may point back to a previous transaction, for example if the previous transaction ID is included in the data field.
- FIG. 2 illustrates an example transaction protocol.
- This is an example of a UTXO-based protocol.
- a transaction 152 (abbreviated "Tx") is the fundamental data structure of the blockchain 150 (each block 151 comprising one or more transactions 152). The following will be described by reference to an output-based or "UTXO" based protocol. However, this is not limiting to all possible embodiments. Note that while the example UTXO-based protocol is described with reference to bitcoin, it may equally be implemented on other example blockchain networks.
- each transaction (“Tx") 152 comprises a data structure comprising one or more inputs 202, and one or more outputs 203.
- Each output 203 may comprise an unspent transaction output (UTXO), which can be used as the source for the input 202 of another new transaction (if the UTXO has not already been redeemed).
- the UTXO includes a value specifying an amount of a digital asset. This represents a set number of tokens on the distributed ledger.
- the UTXO may also contain the transaction ID of the transaction from which it came, amongst other information.
- the transaction data structure may also comprise a header 201, which may comprise an indicator of the size of the input field(s) 202 and output field(s) 203.
- the header 201 may also include an ID of the transaction. In embodiments the transaction ID is the hash of the transaction data (excluding the transaction ID itself) and stored in the header 201 of the raw transaction 152 submitted to the nodes 104.
- Tx a transaction 152j transferring an amount of the digital asset in question to Bob 103b.
- Alice's new transaction 152j is labelled " Tx" . It takes an amount of the digital asset that is locked to Alice in the output 203 of a preceding transaction 152i in the sequence, and transfers at least some of this to Bob.
- the preceding transaction 152i is labelled "Tx 0 " in Figure 2.
- Tx 0 and Tx 1 are just arbitrary labels. They do not necessarily mean that Tx 0 is the first transaction in the blockchain 151, nor that Tx 1 is the immediate next transaction in the pool 154. Tx 1 could point back to any preceding (i.e. antecedent) transaction that still has an unspent output 203 locked to Alice.
- the preceding transaction Tx 0 may already have been validated and included in a block 151 of the blockchain 150 at the time when Alice creates her new transaction Tx 1 , or at least by the time she sends it to the network 106. It may already have been included in one of the blocks 151 at that time, or it may be still waiting in the ordered set 154 in which case it will soon be included in a new block 151. Alternatively Tx 0 and Tx 1 could be created and sent to the network 106 together, or Tx 0 could even be sent after Tx 1 if the node protocol allows for buffering "orphan" transactions.
- One of the one or more outputs 203 of the preceding transaction Tx 0 comprises a particular
- Each UTXO comprises a value specifying an amount of the digital asset represented by the UTXO, and a locking script which defines a condition which must be met by an unlocking script in the input 202 of a subsequent transaction in order for the subsequent transaction to be validated, and therefore for the UTXO to be successfully redeemed.
- the locking script locks the amount to a particular party (the beneficiary of the transaction in which it is included). I.e. the locking script defines an unlocking condition, typically comprising a condition that the unlocking script in the input of the subsequent transaction comprises the cryptographic signature of the party to whom the preceding transaction is locked.
- the locking script (aka scriptPubKey) is a piece of code written in the domain specific language recognized by the node protocol.
- a particular example of such a language is called
- Script (capital S) which is used by the blockchain network.
- the locking script specifies what information is required to spend a transaction output 203, for example the requirement of
- Unlocking scripts appear in the outputs of transactions.
- the unlocking script (aka scriptSig) is a piece of code written the domain specific language that provides the information required to satisfy the locking script criteria. For example, it may contain
- [Checksig P A ] contains a representation (i.e. a hash) of the public key PA from a public- private key pair of Alice.
- the input 202 of Tx 1 comprises a pointer pointing back to Tx 1 (e.g. by means of its transaction ID, TxID 0 , which in embodiments is the hash of the whole transaction Tx 0 ).
- the input 202 of Tx 1 comprises an index identifying UTXO 0 within Tx 0 , to identify it amongst any other possible outputs of Tx 0 .
- the input 202 of Tx 1 further comprises an unlocking script ⁇ Sig P A > which comprises a cryptographic signature of Alice, created by Alice applying her private key from the key pair to a predefined portion of data
- the data (or “message”) that needs to be signed by Alice to provide a valid signature may be defined by the locking script, or by the node protocol, or by a combination of these.
- the node applies the node protocol. This comprises running the locking script and unlocking script together to check whether the unlocking script meets the condition defined in the locking script (where this condition may comprise one or more criteria). In embodiments this involves concatenating the two scripts:
- [...] is a function comprised by the locking script (in this example a stack-based language).
- the scripts may be run one after the other, with a common stack, rather than concatenating the scripts. Either way, when run together, the scripts use the public key P A of Alice, as included in the locking script in the output of Tx 0 , to authenticate that the unlocking script in the input of Tx 1 contains the signature of Alice signing the expected portion of data.
- the expected portion of data itself (the "message") also needs to be included in order to perform this authentication.
- the signed data comprises the whole of Tx 1 (so a separate element does not need to be included specifying the signed portion of data in the clear, as it is already inherently present).
- any reference herein to signing a particular piece of data or part of a transaction, or such like, can in embodiments mean signing a hash of that piece of data or part of the transaction.
- Tx 1 If the unlocking script in Tx 1 meets the one or more conditions specified in the locking script of Tx 0 (so in the example shown, if Alice's signature is provided in Tx 1 and authenticated), then the blockchain node 104 deems Tx 1 valid. This means that the blockchain node 104 will add Tx 1 to the ordered pool of pending transactions 154. The blockchain node 104 will also forward the transaction Tx 1 to one or more other blockchain nodes 104 in the network 106, so that it will be propagated throughout the network 106. Once Tx 1 has been validated and included in the blockchain 150, this defines UTXO 0 from Tx 0 as spent. Note that Tx 1 can only be valid if it spends an unspent transaction output 203.
- Tx 1 will be invalid even if all the other conditions are met.
- the blockchain node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx 0 is already spent (i.e. whether it has already formed a valid input to another valid transaction). This is one reason why it is important for the blockchain 150 to impose a defined order on the transactions 152. In practice a given blockchain node 104 may maintain a separate database marking which
- UTXOs 203 in which transactions 152 have been 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 the blockchain 150. If the total amount specified in all the outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another basis for invalidity in most transaction models. Therefore such transactions will not be propagated nor included in a block 151.
- UTXO-based transaction models a given UTXO needs to be spent as a whole. It cannot "leave behind" a fraction of the amount defined in the UTXO as spent while another fraction is spent. However the amount from the UTXO can be split between multiple outputs of the next transaction. E.g. the amount defined in UTXO 0 in Tx 0 can be split between multiple UTXOs in Tx 1 . Hence if Alice does not want to give Bob all of the amount defined in UTXO 0 , she can use the remainder to give herself change in a second output of Tx 1 , or pay another party.
- Alice will also usually need to include a fee for the bitcoin node 104 that successfully includes her transaction 104 in a block 151. If Alice does not include such a fee,Tx 0 may be rejected by the blockchain nodes 104, and hence although technically valid, may not be propagated and included in the blockchain 150 (the node protocol does not force blockchain nodes 104 to accept transactions 152 if they don't want). In some protocols, the transaction fee does not require its own separate output 203 (i.e. does not need a separate
- any difference between the total amount pointed to by the input(s) 202 and the total amount of specified in the output(s) 203 of a given transaction 152 is automatically given to the blockchain node 104 publishing the transaction.
- a pointer to UTXO 0 is, the only input to Tx 1 , and Tx 1 has only one output UTXO 1 .
- the difference may be assigned (or spent) by the node 104 that wins the proof-of-work race to create the block containing UTXO 1 .
- a transaction fee could be specified explicitly in its own one of the UTXOs 203 of the transaction 152.
- Alice and Bob's digital assets consist of the UTXOs locked to them in any transactions 152 anywhere in the blockchain 150.
- the assets of a given party 103 are scattered throughout the UTXOs of various transactions 152 throughout the blockchain 150.
- script code is often represented schematically (i.e. not using the exact language). For example, one may use operation codes (opcodes) to represent a particular function. "OP_" refers to a particular opcode of the Script language. As an example,
- OP_RETURN is an opcode of the Script language that when preceded by OP_FALSE at the beginning of a locking script creates an unspendable output of a transaction that can store data within the transaction, and thereby record the data immutably in the blockchain 150.
- the data could comprise a document which it is desired to store in the blockchain.
- an input of a transaction contains a digital signature corresponding to a public key
- PA In embodiments this is based on the ECDSA using the elliptic curve secp256kl.
- a digital signature signs a particular piece of data. In some embodiments, for a given transaction the signature will sign part of the transaction input, and some or all of the transaction outputs.
- the particular parts of the outputs it signs depends on the SIGHASH flag.
- the SIGHASH flag is usually a 4-byte code included at the end of a signature to select which outputs are signed
- the locking script is sometimes called "scriptPubKey” referring to the fact that it typically comprises the public key of the party to whom the respective transaction is locked.
- the unlocking script is sometimes called “scriptSig” referring to the fact that it typically supplies the corresponding signature.
- the scripting language could be used to define any one or more conditions. Hence the more general terms “locking script” and “unlocking script” may be preferred.
- HASH TREES A hash tree, also known as a Merkle tree, is a data structure which can be used to attest to
- An example hash tree 400 is illustrated by way of example in Figure 3.
- the hash tree 300 comprises a plurality of layers arranged in a hierarchy from a leaf layer
- the root layer comprises a single root node 304.
- Each internal layer comprises a respective plurality of internal nodes 303 within that layer.
- the leaf layer comprises a respective plurality of leaf nodes 302. Within each of the internal layers and the leaf layer, each node
- the root node 304 is a hash of a combination (typically a concatenation) of all the internal nodes 303 in the next layer down in the hierarchy (which will be two nodes 303 in the case of a binary tree).
- each internal node 303 within the layer comprises a hash of a combination (typically a concatenation) of a different corresponding subset of at least two of the nodes 302/303 at the next layer down in the hierarchy.
- each internal node 303 will be the hash of the combination (e.g. concatenation) of a different respective pair of the nodes in the next layer down 302/303.
- Each leaf node designates a respective data item 301, also labelled herein D.
- Each leaf node designates a respective data item 301, also labelled herein D.
- each leaf node 302 could designate its respective data item D i by comprising an explicit copy of D i , in the clear.
- each leaf node 302 instead comprises a hash of a respective preimage wherein the respective preimage comprises D i .
- the data D i is not derivable from the leaf node 302, but nonetheless the leaf node 302 may be said to designate or signify its respective data item D i in that this particular leaf node 302 is the element of the tree 303 which nominates the respective data item as being part of the set of data items D 0 , D 1 , ...
- each subset of nodes at each layer may be exactly two nodes, i.e. the tree is a binary tree. In other words each node (except the leaves) branches to two other nodes at the next layer down.
- Merkle tree is sometimes assumed in the literature to imply a binary tree. However that limitation was not imposed by Mr Merkle in his original patent and that convention is not adopted here. More generally a Merkle tree as referred to herein may refer to hash tree of any degree of branching, or even uneven branching. The term Merkle tree may be used throughout the following description, but this may equally be replaced with the term hash tree anywhere herein.
- UTXOs or transaction outputs may also be referred to as "spent” and “unspent”, respectively. However this does not necessarily imply a financial transaction and the term
- the set of unspent UTXOs 203 being attested to by the Merkle tree 300 may be the current set of unspent transaction outputs that have already been successfully recorded in blocks
- the set UTXOs in question may be the union of set of UTXOs recorded in blocks 152 on-chain 150 and the set of UTXOs of pending transactions 152 currently in the pool of a given miner, or a given blockchain node 104 (i.e. a given node 104 of the blockchain network 106).
- node may be used differently in different contexts to refer either to a node 104 of the blockchain network 106 or a node 302/303/304 of the Merkle tree 300, which are not the same thing.
- miner or “mining” as used most generally herein does not necessarily imply a financial reward for the task of incorporating blocks on chain. More generally “mining” may refer to the race to win the proof-of-work puzzle required to generate blocks 152 that are accepted by the blockchain network 106, and a “miner” is any party that participates in the proof-of-work race.
- mining as used anywhere herein could equally be replaced with operator of a node 104 of the blockchain network 106.
- a Merkle tree could also be used to attest to other sets of UTXOs.
- the set of UTXOs in question could be a more specific set of unspent UTXOs, such as the set of unspent UTXOs of which a particular party is the payer 102a or payee 102b.
- each leaf node 302 designates (i.e. signifies, nominates or attests to) a different respective subset of the UTXOs in the set.
- each data item D i comprises an indication (identifier) of the respective subset being designated by the respective leaf node 302.
- the respective leaf node 302 designates its respective subset of UTXOs not by comprising the indication of that subset explicitly, but instead by comprising a hash of a preimage wherein the preimage comprises the indication of the respective subset (optionally the preimage could comprise the indication combined, e.g. concatenated, with another piece of data such as a salt).
- D i is the preimage of the leaf node 302.
- each leaf node 302 may correspond to a different respective transaction (Tx) 152, and the subset of UTXOs 203 designated by the respective leaf node 302 may comprise all the unspent UTXOs in the transaction (which could be one or more outputs of the transaction).
- the indication comprised by D i may comprise the transaction identifier (TxID) of the respective transaction along with an indication of which UTXOs within that transaction are unspent (or equivalently which outputs are spent).
- each leaf node 302 could correspond to a different individual UTXO, i.e.
- a given leaf node 302 designates a single UTXO.
- the indication comprised by D i could comprise a combination of TxID and the number of the particular UTXO 203 within the identified transaction 152 (e.g. output 0 or output 1).
- each leaf node 302 could correspond to all the UTXOs in a certain specified group of transactions 152 (e.g. range of TxIDs).
- the Merkle tree 301 (of which the instance illustrated in Figure 3 is just one example), allows a party to attest to or commit to the membership of the set of unspent UTXOs. This is because the tree 300 allows another party to verify that a candidate data item D i is a member of the attested-to set. The principle is illustrated by way of example in Figure 4, where Do happens to be the candidate data item.
- an attesting party wishes to commit to the membership of a UTXO set, e.g. current UTXOs on chain and/or current UTXOs in their mempool, and that the attestation or commitment is being made for the benefit of at least one other party (the "attester")
- the attesting party could be a third-party service provider who provides a service of attesting to the UTXO set for the benefit of one or more miners (who in this example would be the attestees).
- the attesting party could be a miner who attests to their view of the UTXO set.
- the attestee party (or parties) could be one or more other miners so as to promote consensus among miners, or could one or more end-users 102 of the blockchain 150.
- the attesting party makes the Merkle root 304 available to the attestee party, such as by publishing it (e.g. on the blockchain 150), or sending it to them via an off-chain side channel (not shown).
- the attestee wishes to check that some candidate data item D i - in this an indication of a candidate UTXO - is indeed a member of the set attested to by the Merkle root 304.
- the attestee can do this given only the candidate data item D i , the Merkle root 304, and a further portion of information called the "Merkle
- the "Merkle path" is the subset of nodes 401 (which will include a leaf node 302 and one or more interior nodes 303) that are immediate siblings of each node lying along the path 402 between the candidate leaf node 450 and the Merkle root 302 (including the sibling of the candidate leaf node 450). In other words, consider a path 402 from the candidate leaf node 450 to the Merkle root 304.
- each layer there will be a node 302/303 that lies on that path 402, and that node will have one or more siblings 401 (exactly one in the case of a binary tree) which is/are the other node(s) 302/303 that are is/are part of the same subset at that layer - that is, the subset of nodes that are combined and hashed to form the node 303/304 at the next layer up along the path 402.
- the total subset of siblings 401 that lie along the path 402 are referred to as the "Merkle path" (even though they are not the path
- the attested to party knows the candidate data item D i they which to check, and has been given the Merkle root 304 and Merkle path 401, then they can demonstrate that the candidate data item D i was part of the set attested to by the attesting party, by recomputing the Merkle root from the candidate data item D i Merkle path 401.
- the Merkle path may be obtained by the attestee from, for example, either a miner/node who provides this as a service, or some non-node service provider. In embodiments it may be provided along with the Merkle root 304 by the party the attesting who supplies the
- Table 0 a list of notations used in the description of certain embodiments disclosed herein.
- a Merkle tree is typically interpreted as a binary hash tree (though this is not essential).
- each node in the tree may be given an index pair (i ⁇ , i ⁇ ) and is represented as N(i ⁇ , i ⁇ ).
- the indices i ⁇ , i ⁇ are simply numerical labels that are related to a specific position in the tree.
- the i ⁇ ⁇ i ⁇ case corresponds to an internal or root node, which is generated by recursively hashing and concatenating child nodes in the tree until the specific node or the root is reached.
- the node jV(0,3) is constructed from the four data blocks D 0 , ... , D 3 as:
- a Merkle tree in most applications is to facilitate a proof that some data block D i is a member of a list or set of N data blocks . Given a Merkle root and a candidate data block D i , this can be treated as a 'proof-of-existence' of the block within the set.
- the mechanism for such a proof is known as a Merkle proof and consists of obtaining a set of hashes known as the Merkle path for a given data block D i and Merkle root R.
- Merkle path for a data block is simply the minimum list of hashes required to reconstruct the root R by way of repeated hashing and concatenation, often referred to as the
- N(0,0) H (D 0 ).
- e. Compare the calculated root R' with the root R obtained in step 1: i. If R' R, the existence of D 0 in the tree, and therefore the data set , is confirmed. ii. If R' + R, the proof has failed and D 0 is not confirmed to be a member of .
- Figure 4 shows a Merkle proof-of-existence of a data block D 0 , in the tree represented by a root R (304), using a Merkle path 402. This demonstrates that performing the Merkle proof for a given block D 0 and root R is effectively traversing the Merkle tree
- Figure 5 shows an example of a Merkle tree, with indices i ⁇ within each layer ⁇ . Each row is indexed from 0 to the right, and the rows themselves are indexed from 0 up from the leaf layer. A node with a higher value of index i ⁇ within a given layer may be describes as to the
- index i ⁇ may be abbreviated as just I on the understanding of which layer ⁇ is in question.
- Table 1 the layers, node numbers, and arrays containing layer indices of the Merkle tree shown in Figure 5.
- a partial Merkle tree is a collection of indexed nodes of a Merkle tree which can be used to prove that a proper subset of leaf nodes L' are members of the complete set of leaves L, which can be expressed mathematically as L' ⁇ L. It should be noted that the partial Merkle tree for a single leaf is simply its Merkle path.
- n L 2 k , for some integer k.
- the value k can also be used to determine the number of layers in a binary Merkle tree, which is simply given by k + 1.
- the index i of a node situated in the layer ⁇ is denoted by i ⁇ .
- i ⁇ The index i of a node situated in the layer ⁇ .
- the first equation (1) allows us to calculate the index of the parent of the node of interest.
- the second equation (2) which is also used in (1), allows us to calculate the parity of the index of the node (i.e. whether it is an odd or even index).
- the third equation (3) allows us to determine the index of a node's partner (i.e. the node which the node of interest is concatenated and hashed with in the tree), which we call a complementary index c ⁇ .
- the output of the generatePMT( ) algorithm is a partial Merkle tree of the form: where is the set of node indices in the ⁇ th layer of the PMT, which is a proper subset of the indices of the nodes A ⁇ in the ⁇ th layer of the full Merkle tree and satisfies the relation .
- An example algorithm generatePMT( ): for determining a partial Merkle tree may be described as follows.
- Step 1 initialises an array corresponding to the nodes of the PMT in the leaf layer, which only contains the leaves provided to the algorithm by L' at this point. Note that is denoted with a " ' " to indicate it is a subset of the full array A 0 of layer 0 nodes.
- Step 2 populates the rest of by calculating the complementary indices c 0 for all of the leaves already in the array and adds them to the array.
- the complementary indices are added, they are added in numerical order, meaning each complementary index is placed next to (either immediately left or right of) the corresponding original leaf provided in L'.
- Step 3 initialises a branch array B 0 , which allows step 4 to be written as a loop.
- This step introduces an array U ⁇ _ 1 which is the ordered union of the PMT nodes of the layer below and the branch nodes B ⁇ _ 1 of the layer below.
- the branch nodes of a given layer are all the nodes in that layer that can be calculated from other information (i.e. child nodes) that are already somewhere lower down in the PMT.
- the array U ⁇ _ 1 includes all the nodes of the lower layer that we have access to for calculation (whether they are stored as part of the PMT or can be calculated 'on-the- fly' from other parts), and therefore can be used as the starting point for determining the relevant arrays in the layer above.
- step 3 comprises two further subroutines.
- the first calculates the parent index i ⁇ for ever other entry in U ⁇ _ 1 and adds them to the branch array B ⁇ .
- the second calculates the complement partner indices for all the entries in B ⁇ and adds these complement indices to C ⁇ if they are not already in B ⁇ , which avoids double-counting anything we need to store in that we know we can already calculate based on other information in the
- step 3 involves setting each respective to the array C ⁇ we have just populated and deduplicated. There is also a break condition to halt the loop of step 3 if is empty, meaning no further processing is required to generate the PMT.
- Step 5 of the algorithm simply combines all the arrays in order to create the final partial Merkle tree 4.
- the present disclosure provides a novel scheme for maintaining a Merkle tree (or hash tree), whereby at least some of the leaf nodes can each either: A) designate a corresponding subset of one or more of the unconsumed outputs (e.g. by comprising a hash of a preimage that compromised an indication of the corresponding subset); or B) comprise a placeholder value, in other words a dummy value, which may also be referred to herein as a "hole".
- every leaf node has the ability to become either type of node, and may be changed back and forth between the two from one update of the tree to the next.
- leaf nodes 302 each designate a respective corresponding subset of the UTXOs 203, as discussed previously.
- each comprises a hash H i of an indication of its corresponding subset.
- the subset designated by each leaf could be one or more UTXOs, e.g. the subset of each leaf being an individual
- each leaf comprises a hash H i of a respective preimage where the respective preimage comprises a TxID of a respective transaction 152 and an identifier of each UTXO 203 within the transaction (e.g. output 0, output 1, etc.).
- One or more others of the leaf nodes may comprise "holes", represented herein by the empty sign " ⁇ ". These are dummy or placeholder values that represent no UTXOs. E.g. they could be zero or a string of zeros, or any other predetermined value that is understood to represent a hole in the leaf layer of the tree where no UTXOs are designated.
- a "hole” as referred to herein could be any representation of a null value.
- the following describes a method of attesting to a current state of a set of UTXOs (or more generally unconsumed outputs of blockchain transactions in any output-based model). That is, computing a Merkle tree cumulating in a Merkle root which can later be used to verify the membership of the set.
- An example flow chart is shown in Figure 7.
- the method may be used to publicly commit to the membership of the set by publishing the Merkle root, e.g. on the blockchain 150.
- the method could instead be used to keep a private record, e.g. internally within an organization.
- the method may be performed by a third-party service provider who makes available the attestation to one or more nodes 104 (or "miners") of the blockchain network 106 in order to confirm the miner's view of the blockchain.
- the method may be performed by one or more miners who make the attestation available to other miners and/or users 102 of the blockchain network in order to promote confidence in the state of the chain.
- the attested-to set could be, for example, only the set of UTXOs actually recorded in blocks
- the method begins by determining an initial Merkle tree based on the current UTXO set at the set-up stage. This may include one or more holes ⁇ , or it could begin fully occupied only with leaves 302 that designate UTXOs.
- the tree may be formed so as to be "balanced". That is to say, each layer contains a full set of nodes 303/303 (i.e. the maximum number of nodes at each layer given the branching ratio of the tree), with the leaf nodes all at the same layer. E.g. in a binary tree this means there are 2 k leaf nodes all at the same, lowest layer where k is the number of layers. Depending on the number of UTXOs and the mapping of UTXO subsets to leaves 302, this may require including one or more holes ⁇ at the leaf layer. E.g. in a binary tree, if there are not exactly
- the method comprises determining an update to the set of UTXOs. For example this could be done the next time that a new block 151 is included on the blockchain 150 (in other words the block height has increased by one). Alternatively it could be in response to some other event, or after some periodic or random time interval has elapsed. E.g. if the tree is being maintained by a node 104 of the blockchain network and includes pending transactions, then the update could be performed after the node 104 has received a predetermined number of new pending transactions into its pool of pending transactions ("mempool").
- the method at step 520 comprises determining a "delta set" representing the update.
- the delta set is the total set of new UTXOs being added and
- the delta set will comprise an addition of at least one new UTXO and/or removal of one or more UTXOs which have now been consumed.
- the update will very likely comprise both the removal of at least one now-spent
- the party performing the method may determine the delta set by monitoring the blockchain 150 and/or mempool themself. Alternatively, they may determine the delta set by receiving it from another party who monitors the blockchain 150 on their behalf.
- the party performing the method may be a node 104 of the blockchain network 106, or a party operating one or more nodes 104 of the blockchain network 106 - a "miner" for short - and the delta set may be determined by receiving a subscription to the delta set from a third party service provider who monitors the blockchain 150 for new blocks and regularly provides the delta set to one or more miners as a subscription service (e.g. each time the block height increases).
- the miner could determine the delta set as the union of the delta of on-chain UTXOs received in the subscription combined with the delta to the miner's mempool. Alternatively the miner may monitor the blockchain
- the party performing the method may be the third-party service provider, and the determination of the delta set may be performed by the service provider monitoring the blockchain 150.
- the service provider may both use the delta set both to determine the update to the tree for the purpose of their own attestation, and to provide to one or more miners as a subscription service to inform them of updates to the blockchain 150.
- the method comprises recomputing the hash tree to reflect the update.
- the idea of the holey Merkle tree is that when there is an update to the UTXO set, sometimes entries will be removed and sometimes entries will be added. Using a holey Merkle tree, it is possible to add new entries in the tree in places where others have been removed, either in the current update round or from one round of update to the next. This will make recomputing the tree simpler.
- UTXO(s) can replace an existing hole or holes ⁇ that was already present from a previous round of update (previous occasion). Also if the tree begins at step S10 with some holes already present, then these may be filled in subsequent rounds of update.
- only one of a subset of multiple UTXOs designated by a given leaf may have been spent, still leaving one or more other unspent UTXOs covered by the same leaf 302.
- the corresponding leaf will be updated but not replaced with a hole ⁇ . It may be replaced with an updated leaf that designates at least the remaining UTXO(s), and which could potentially also designate one or more new UTXOs.
- an old leaf designating a first subset of UTXOs is replaced with an updated leaf designating a second, different subset of UTXOs, instead of a hole ⁇ , wherein the second subset could overlap with the first subset but is not identical.
- the tree may need to be expanded to the right. If the tree is to remain balanced, this will mean added a whole new side to the tree (a whole extra half in the case of a binary tree) plus new root node 304.
- the tree is kept balanced at each update, whether the update involves replacing holes or other previous leaves, or expanding the tree, padding, or any combination of these. It is not essential that the tree is kept balanced by the updates. However, it may be preferable as it minimises the number of layers in the tree, such that the extra computation is also minimised (e.g. in a binary tree, it is only padded up to 2 ⁇ k not 2 ⁇ (k+1)).
- the process of recomputing the tree may be summarised as follows.
- the leaf node designating the removed output is removed and replaced, at the same position in the leaf layer, with a new leaf node which either: A) designates an updated subset of one or more unconsumed outputs not including the removed output, or B) comprises a placeholder value (a "hole" ⁇ ).
- a new leaf node is formed designating a subset of one or more unconsumed outputs including at least the new output, wherein the new leaf node is inserted in the tree in place of a replaceable leaf node when available, at the same position in the leaf layer.
- a replaceable leaf node is one that either: A) designates an output being removed, or B) comprises a placeholder value. But otherwise, if no replaceable leaf node is available, the tree is expanded to accommodate the new leaf node.
- the recomputing of the tree comprises recomputing the hashes of only those nodes affected by the update, i.e. only the part of the tree affected.
- the only hashes that need to be recomputed are those that are themselves an updated leaf node 302 or that are internal nodes 303 at any level of parent (parent, grandparent, great- grandparent etc) of an updated leaf node 302.
- the recomputing of the hash tree may be performed by a "remove then add” procedure; i.e. first removing any and all leaf nodes designating consumed outputs from the set, then inserting any and all leaf nodes designating new unconsumed outputs.
- This approach helps reduce the overall size (i.e. number of leaves) of the tree at any given time. This is because updating the leaf set transaction-wise ensures that UTXOs are removed from the Merkle tree at the earliest possible opportunity in the algorithm, which in-turn ensures that the holes in the leaf set are positioned as far left in the ordered set at possible. This means that holes are always filled from as far left as possible, thus minimising the possible number of entries in the leaf set.
- an "add then remove” procedure is also possible.
- the method at the re-computation stage S30 may also provide for shrinking the tree by a layer if, after the update, the tree would otherwise now have a redundant number of layers given its degree of branching and the number of leaves that designate actual UTXOs compared to those that have been removed and would thus otherwise comprise holes ⁇ .
- the tree can be shrunk by one layer.
- the Merkle root 304 (R) is published as a public commitment to the membership of the attested-to UTXO set. This could be done by including it in a transaction
- the commitment may be included in an output 203 (e.g. unspendable output) of a transaction recorded on the blockchain 152, e.g. by means of an OP_DROP opcode, OP_RETURN opcode, or combination of OP_RETURN and OP_FALSE, depending on the locking script protocol being used.
- step 540 may loop back to step 520 to determine another update and recompute the tree again. For example this may be done each time the block height of the blockchain 150 increases (i.e. a new block has been
- the update comprises the removal of at least one output
- the update comprises the addition of at least one new output.
- the addition could happen on the same occasion (i.e. same update) as the removal, or a different occasion (i.e. different update).
- an update may comprise both the removal of at least one output and the addition of at least one new output.
- the update may comprise only addition or only removal.
- holes can be added in place of an actual content-carrying leaf node that has been removed from a dynamically updated tree. Preferably they can be created in any place in the list of leaves, while padding is only appended at the end. Furthermore, holes act as placeholders which can subsequently be replaced by new content-carrying leaves in further updates to the dynamic tree.
- An optional additional feature relates to "generation transactions", also known as
- a generation transaction is a transaction generated when a node 104 of the blockchain network 106 successfully wins the proof-of-work race to have a new block 151 generated and incorporated onto the blockchain 150 - sometimes described as a new block being "mined”.
- the generation transaction contains an output that rewards the successful miner with a new portion of a digital asset (e.g. some new Satoshi).
- this is not essential.
- each generation transaction may have an associated maturity condition associated with it, which must be met before its one or more outputs can be consumed.
- the maturity condition may be that a certain block height threshold (e.g.
- the miner or service provider may avoid this by including the outputs of unmatured generation transactions in the UTXO set being attested to by the Merkle tree.
- the method comprises maintaining a list indicating whether the associated maturity condition has been met for each generation transaction (e.g. the respective block height at the time they were generated). This gives a small efficiency increase as it involves querying a smaller data structure.
- the list of unmatured transactions and their maturity status may be included in the preimage D of one or more of the leaves 302, so that the maturity status of the unmatured transactions is also attested to.
- the list may simply be kept for internal reference by the party in question (e.g. miner or service provider).
- HMT Holey Merkle Tree'
- the goal with elements (1) and (2) is to prescribe a deterministic process for determining and updating the state of the UTXO set on a block-by-block basis, such that these updates are efficient to perform.
- the aim of introducing element (3) is to provide a way for UTXO set snapshots to be produced, shared, and updated by blockchain nodes 104 in a way that requires minimal trust on the behalf of the user.
- a UTXO snapshot S n is defined as the complete set of spendable outpoints on the blockchain that are unspent at a block of height n, denoted as B n .
- n the leftmost outpoints in the snapshot are reserved for coinbase outpoints and ordered in descending block height. If n ⁇ 100, then only the outpoints corresponding to the most recent 100 coinbase transactions are reserved and ordered in descending block height. For example,
- the first 100 transaction IDs does not necessarily imply the first 100 outpoints as one coinbase transaction can have multiple outputs. They are ordered in descending block height for convenience. When a new coinbase transaction is added, it is added to the beginning of the list, it naturally pushes the matured coinbase transaction txid 1 out of the coinbase list.
- the coinbase list can be part of the UTXO set when creating a commitment.
- they can be represented by a single leaf or multiple leaves.
- leaves or some of the leaves will be updated by every block.
- a delta set is a collection of outpoints that are either
- the second type of outpoint is included in so that we can add them to S n .
- An intermediate set is a collection of outpoints that are created between B n+1 and
- step 1 We can generalise this to multiple blocks. That is, if we have a snapshot S n and we want to create a later snapshot S n+t , we can gather the blocks B n+1 , B n+2 , ... , B n+t , and consider it as a larger set of transactions . We can then apply the same algorithm to to obtain and S n+t . The only difference is the following modification to step 1:
- the second component for generating a deterministic commitment to a UTXO at a point in time is to introduce a holey Merkle tree (HMT).
- HMT holey Merkle tree
- the idea here is to represent the UTXO set S n at a given block B n of height n as a Merkle tree T n , whose root R n can be attested to on the blockchain. See again Figure 6.
- the Merkle tree is a balanced, binary Merkle tree.
- the leaves of the Merkle tree may consist of either: a. UTXOs; or b. Holes iii. UTXOs may be represented as either: a. TxID
- Holes may be represented as a zero element (e.g. a 0 bit, or Boolean 'False').
- Option b) may in some cases generate a larger tree than a) because each leaf can represent multiple UTXOs, i.e., less likely to generate a hole, but has the drawback that leaves may remain in the tree while only a single UTXO of a transaction is unspent, meaning that the spend-state of all of the transaction outputs must be kept until all have been spent, whereas a) allows each UTXO to be tracked independently. For example, if a transaction generates two outputs including a 'change' output, the change output may not be spent until a long time after the primary output, meaning we have to store the spend-state for both until the later time when the change output is also consumed.
- STXO spent UTXO
- Option c) is identical to option b), except the objects stored for each UTXO include the full output information, rather than just the Boolean spend-state of each output.
- An HMT for a block of height n can be stored as a nested array, where each inner array represents the ordered set of hashes stored at a particular level of the tree, which are indexed from 0. This can be written as where each inner array represents the set of hashes at the ⁇ th layer in the tree and the final inner array is simply the root node.
- a deterministic algorithm updateTree( ) may be specified to allow a particular HMT state, representing a UTXO set S n at block height n, to be updated when a subsequent block B n+1 is obtained.
- Figure 10 shows an example of a process of updating the HMT state T n — > T n+1 , where changes to leaf nodes are highlighted in bold.
- updateTree( ) can be used to update the tree from one state T n to another state T n+1 based on a set of changed leaves that are determined by a blockchain block. This algorithm may be defined as follows. updateTree( ):
- the algorithm operates by generating the updated set of leaves L n+1 , using the previous set
- the algorithm uses the updated set of leaves, in conjunction with the previous tree T n , to generate the new tree T n+1 by invoking another sub-algorithm updateHashes( ). It should be noted here that the output T n+1 also includes both L n+1 and R n+1 , by definition.
- a sub-algorithm which may be specified is is the updateLeaves( ) algorithm, which is responsible for taking the leaf set of a current Merkle tree state L n and updating its state according to the effect of a new block B n+1 .
- This sub-algorithm updates the set of leaves from a previous state L n , representing the
- Step 1 initialises a leaf set L that we will manipulate in the algorithm by removing and adding entries corresponding to UTXOs consumed and created respectively in B n+1 .
- Step 2 initialises an array ⁇ which will store the indices at which changes (i.e. removals and additions) to L n are made. We call this the 'changelog array'. This array is necessary to update node hashes later in the updateHashes( ) algorithm.
- Step 3 is a transaction-wise loop that implements a 'remove-then-add' process for each transaction individually, before moving on to the next transaction in the block. The transactions are processed in the order they appear in the block.
- Step 3.1 takes the current transaction and removes from L all outpoints consumed by it.
- the index in L at which each outpoint was previously recorded is inserted into the changelog ⁇ .
- Step 3.2 takes the current transaction and adds each of its outpoints to L at the left-most empty ( ⁇ ) entry position. If there is no empty entry in L, the outpoint is appended to the end of the list. The index in L at which a new outpoint is inserted/appended is recorded in ⁇ .
- Step 4 handles redundant or missing indices in L following step 3, to ensure the tree is balanced and of the correct depth. If L is a power of two, and its HMT will be a perfectly balanced binary tree, then any remaining indices larger than the length of L are removed, which handles the case where the HMT shrinks by one level following step 3. Otherwise, the minimum number of empty elements are appended to L that are required for the number of leaves to reach a power of 2. Once again any indices larger than the new size of the balanced tree are removed. The changelog array A is updated accordingly.
- Step 5 the temporary leaf set L becomes the new leaf set L n+1 and both L n+1 and the changelog A are output by the algorithm.
- updateLeaves( ) algorithm could be written; namely using a remove-then-add paradigm as shown above, or alternatively using an add- then-remove paradigm.
- the remove-then-add option parses a block transaction-wise. This means that the UTXOs consumed by the outputs of one transaction are removed from the leaf set, and then the
- TTOR topological transaction ordering rule
- remove-then-add option it is preferable to use the remove-then-add option specifically because this approach minimises the overall size (i.e. number of leaves) of the HMT at any given frame in time. This is because updating the leaf set transaction-wise ensures that UTXOs are removed from the
- Merkle tree at the earliest possible opportunity in the algorithm ensures that the holes in the leaf set are positioned as far left in the ordered set at possible. This means that holes are always filled from as far left as possible, thus minimising the possible number of entries in the leaf set.
- a second sub-algorithm that may be specified is the updateHashes( ) algorithm. This is responsible for updating the hashes of the previous HMT state T n to form the new HMT state T n+1 based on the changes to the UTXO set caused by the new block B n+1 .
- the main steps are as follows:
- Step 1 of the updateHashes( ) algorithm initialises a new tree T n+1 using the previous state T n as the basis. Note that in the case where the new state has a different size (i.e. different k) then step 1 should accommodate this, either by adding additional empty arrays for new layers or removing arrays from higher layers.
- Step 3 updates the hashes in the leaf layer 0 , by replacing elements in with the new elements in at the corresponding index and saves the resulting .
- Step 4 generates a partial Merkle tree using generatePMT( ) algorithm described in section 2.3, taking the changelog indices ⁇ as input. Note that the output is another set of arrays of indices , which will help to identify nodes that are required to update the tree.
- Step 5 is a loop, containing two further loops, which ascends through the remaining layers of the new HMT state T n+1 up to and including the new root node at layer k. For each layer, this step is to identify hash values that are required to update the next layer above. It combines the hashes of the PMT in the ⁇ — 1 th layer with the updated hashes just calculated in the ⁇ — 1 th layer to create a set of hashes which is the subset of required to calculate the new hashes in in the ⁇ th layer.
- the first of the smaller loops in step 5 iterates through pairs of elements of to calculate the changed elements in layer k.
- the second smaller loop then updates the values in with the changed elements we have just calculated and saves them.
- Step 6 finally returns the new tree state T n+1 as an array of the arrays just updated in the previous step.
- the changelog array ⁇ contains all of the indices of elements in L n+1 which represent changes
- FIG. 11 shows the relationship between the changelog A, the new set of leaves L n+1 and the sub-set of leaves which cause changes to the internal nodes and root hash of the new HMT T n+1 .
- the goal is to update the HMT state T n+1 ⁇ T n by recomputing the HMT root R n+1 .
- the first option is simply to recompute the entire Merkle tree using the complete set of new leaves L n+1 .
- the second, and far more desirable option is to recompute only the internal nodes required to propagate the changes from L n+1 ⁇ L n to the new root hash R n+1 .
- This second option is more computationally efficient than the first, and so we have chosen to implement it in the updateHashes( ) algorithm.
- the hashes required to propagate the changes caused by the new values of leaves L’ to the new root R n+1 are identical to the partial Merkle tree of L' .
- PMT nodes in the layer below to create a set that contains everything required to propagate a given change to the next level of the HMT.
- a method of incentivizing a party to publicly commit to the membership of a set of data items D may be to commit to a set of UTXOs, as discussed previously, such as to commit to the current state of a blockchain 150 or the UTXOs on chain plus those pending in a mempool.
- the method could be performed for example by a third party service provider to incentivize miners (operators of nodes 104) to publicly commit to their view of the UTXO set, or the method could be performed by a miner themselves in order to incentivize other miners.
- the method could be used to incentivize parties to commit to the membership of a set of any other kind of data items.
- the scheme could be used to represent anything where the set has elements that may be created and destroyed/consumed.
- inventory logs may be used to track a set of inventory items that can be either in either a
- the data items D could represent the inventory items.
- Another example would be a transparent ticketing system where the ticket-provider wishes to attest to the set of remaining tickets (e.g. seats in a football stadium) as and when they are individually sold. This may help reduce fraud and re-selling in secondary markets by providing a record of which seats were sold at which time, the state of the entire 'stadium' of seats now being mapped to the HMT.
- the ticket-provider wishes to attest to the set of remaining tickets (e.g. seats in a football stadium) as and when they are individually sold. This may help reduce fraud and re-selling in secondary markets by providing a record of which seats were sold at which time, the state of the entire 'stadium' of seats now being mapped to the HMT.
- the challenging party e.g. service provider
- the set of data items D to be attested to comprises a UTXO set
- the blockchain used to publish the hash puzzle could be the same blockchain 150 as the UTXO set relates to, or a different blockchain.
- a hash puzzle is a challenge, also called a hash challenge, in the form of a short program placed in a transaction recorded on a blockchain - call this the challenge transaction.
- the program may take the form of a locking script in an output 203 of a transaction in a UTXO-based (or output-based) model.
- the program could take the form of a smart contract in a transaction of an account-based model.
- the program comprises a reference hash value, being the hash of a preimage wherein the preimage comprises a reference piece of information which the challenger wishes to challenge a challengee party (e.g. a miner) to prove that they know.
- the program of the hash puzzle also comprises some code (e.g.
- the method comprises the challengee sending a candidate transaction to be recorded on the same blockchain as the challenge transaction.
- This may comprise the challengee sending or propagating the candidate transaction to one or more nodes 104 of the blockchain network 106.
- the candidate transaction comprises a pointer to the challenge transaction, along with the candidate piece of information, or the preimage that comprises the candidate piece of information (optionally the candidate piece of information could be combined, e.g. concatenated, with another element such as a salt in order to form the preimage).
- the candidate piece of information may be included in the unlocking script of an input 202 that points to the output of the challenge transaction that contains the hash puzzle.
- the candidate transaction may comprise a smart contract that comprises the candidate piece of information and references the smart contract of the challenge transaction.
- the blockchain network 106 attempts to validate the candidate transaction at one or more of the nodes 104 of the blockchain network 106.
- This comprises executing the hash puzzle, e.g. by running the locking script together with the unlocking script in the case of a UTXO-based (or output-based) model, or by executing the smart contracts in the case of an account-based model.
- the node 104 executing the puzzle will thus take the candidate piece of information from the candidate transaction, and hash the candidate preimage that comprises the candidate piece of information. If the candidate preimage comprises more data than just the candidate piece of information (e.g. another piece of data concatenated with it), then the additional data may either be received in the candidate transaction or added from the challenge transaction before the candidate preimage is hashed to generate the candidate hash.
- the node 104 in question checks whether the resulting candidate hash equals the reference hash from the challenge transaction. If so, then at step TSO the candidate transaction is validated and recorded on chain, thus rewarding the challengee for proving knowledge (and publicly attesting to that knowledge) of the candidate piece of information.
- step T60 the candidate transaction is not validated and instead is rejected by the node 104, and so the challengee does not receive their reward.
- a hash puzzle such as described above can be used to incentivize one or more challengee parties to publicly commit to a view of a set of data items D, such as a UTXO set.
- the reference piece of information tested-for by the challenge transaction comprises the Merkle tree root 304 of the set as determined by the challenging party (e.g. service provider).
- the challenging party e.g. service provider
- Such a scheme can be used to promote confidence in the state of the chain.
- the challenger and challengee(s) all use the same algorithm for computing the Merkle tree 300, so this is completely deterministic.
- the challenge transaction may additionally require a signature of a specific challengee or challenegees to unlock, such as by means of a pay-to-public-key (P2PK) puzzle or pay-to-public-key-hash (P2PKH) puzzle included in the locking script along with the main hash puzzle as an additional condition for redeeming the output of the challenge transaction.
- P2PK pay-to-public-key
- P2PKH pay-to-public-key-hash
- the challenegee may publish multiple instances of the challenge transaction on chain, one for each of the potential challengees, each requiring a signature of the respective challengee to unlock.
- the challenger could publish a single challenge transaction on chain that will accept the signature of any of multiple different challengees as alternative conditions for unlocking.
- the hash puzzle should in fact test for two pieces of information: the Merkle root 304 of the attested-to set, and additional piece of information that is specific to a particular challengee.
- the additional piece of information may be allocated randomly to the challengee.
- the additional piece of information may be another one of the nodes 302/303 (e.g. internal note 303) other than the root node 304.
- this may be a randomly allocated one of the nodes (e.g. a random internal node 303).
- each of a plurality of potential challenges e.g. miners
- each of a plurality of potential challenges may be allocated different such pieces of additional information, each specific to the respective challengee - for example each may be allocated a different and/or random one of the nodes (e.g. internal node302) in the tree 300 as their respective piece of additional information.
- the piece of additional information could be a secret password or piece of personal information known only to the challenger and the particular challengee.
- the challenger arranges to have recorded on a blockchain, e.g. 150, a challenge transaction. If the challenger is a party other than a miner such as a third party service provider, this comprises sending the challenge transaction (directly or via an intermediate party) to one or more of the blockchain nodes 104 to be propagated through the network
- the challenger is themselves a miner, they could validate the challenge transaction for recordal themselves, and/or propagate to one or more nodes 104 of one or more other miners to validate.
- the blockchain on which the challenge transaction is recorded could be the same or a different blockchain as that on which the transactions of the previously discussed UTXO set are recorded. For ease of reference it may be assumed in the following that they are the same blockchain, but this is not limiting.
- the challengee submits to be recorded on chain a candidate transaction which points to the challenge transaction. If the challengee is a party other than a miner, this comprises sending the candidate transaction (directly or via an intermediate party) to one or more of the blockchain nodes 104 to be propagated through the network 106 and thereby validated and incorporated into a block 151 on chain. If the challengee is themselves a miner, they could validate the candidate transaction for recordal themselves, and/or propagate to one or more nodes 104 of one or more other miners to validate.
- the challenge transaction comprises code, e.g. a locking script in a UTXO based model or a smart contract in an account-based model, which (steps T30-T40) is run at a node 104 of the blockchain network 106 when a candidate transaction pointing to the challenge transaction is received at the node 104.
- the code tests for three things in the candidate transaction (e.g. in an unlocking script or smart contract of the candidate transaction): a valid signature of the challengee, the Merkle root 304 attesting to the set of data items D, and the additional piece of information.
- Figure 9 schematically illustrates the challenge transaction 152Ch (which is recorded on the blockchain 150 already) and the candidate transaction 152Can (which is to be validated for recordal on the blockchain 150).
- the candidate transaction 152Can comprises: (e.g. in an input 202) a pointer 951 to the challenge transaction 152Ch (e.g. its transaction ID TXID_Ch); and (e.g. in an unlocking script in the input 202) a signature 952 of the challengee party, a candidate instance 953 of the Merkle root 304 being attested to, and a candidate instance
- the candidate transaction 152Can may be said to comprise candidate preimage data that comprises at least the candidate instance 953 of the root 304 and the candidate instance 954 of the additional information, wherein the preimage data could optionally comprise one or both of these elements combined with (e.g. concatenated with) some further data.
- the challenge transaction 152Ch comprises (e.g. in a locking script in an output 203 of the challenge transaction 152Ch) a short program (e.g. script) 900 is run as part of the process of validating the candidate transaction 152Can.
- This program or code 900 comprises a first element (e.g.
- a Checksig 901 that verifies the signature 952 of the challengee from the candidate transaction 152Can, and a second element (hash puzzle) which verifies the candidate instance 953 of the Merkle root and the candidate instance 954 of the additional piece of information from the candidate transaction 152.
- the hash puzzle 902 comprises reference hash result data.
- the hash puzzle comprises reference hash result data.
- the reference hash result data comprises two separate hash values: a first hash value hl, which was determined by taking a hash of a reference instance of the Merkle root 304 (or more generally preimage data that comprises at least the reference instance of the root); and a second hash value h2 which was determined by taking a hash of a reference instance of the piece of additional information (or more generally preimage data that comprises at least the reference instance of the additional information).
- a first one of the constituent hash puzzles comprises the first hash value hl, along with code which will hash the candidate instance 953 of the Merkle root 304 from the candidate transaction 152 (or more generally the candidate preimage data that comprises the candidate instance 953 of the Merkle root 304), and check whether this equals hl.
- a second one of the constituent hash puzzles comprises the second hash value h2, along with code which will hash the candidate instance 954 of the piece of additional information from the candidate transaction 152Can (or more generally the candidate preimage data that comprises the candidate instance 954 of the additional information), and check whether this equals h2.
- the candidate transaction 152Can is validated for recordal in a block 151 on the blockchain 150 (step T50), and the challengee is assigned the reward defined in the challenge transaction 152Ch.
- the hash puzzle 902 comprises a single combined hash puzzle.
- the reference hash result data in the hash puzzle in the challenge transaction 152Ch comprises a combined hash value h, having been determined by taking a hash of reference preimage data that comprises a combination (e.g. concatenation) of the reference instance of the Merkle root 304 and the reference instance of the piece of additional information (and optionally further data).
- the hash puzzle 902 will hash candidate preimage data that comprises the reference instance 953 of the Merkle root
- the candidate transaction 152Can is validated for recordal in a block 151 on the blockchain 150, and the challengee is assigned the reward defined in the challenge transaction 152Ch.
- the challenger may publish multiple challenges on the blockchain 150, each along the lines discussed above, but each requiring the signature of a different potential challengee and a different respective piece of additional information 954 specific to the respective challengee. For example, this could be done by including multiple different challenge transactions!52Ch on chain, each with a different puzzle 902 requiring a different piece of additional information 954 specific to the respective challengee; or by including the different hash puzzles 902 in different outputs
- This model has significant utility when applied to a commitment scheme for the state of the
- the bootstrapping node will have to perform a full blockchain synchronisation, often referred to as an initial block download (IBD), whereby the node must obtain the entire history of the chain and replay it in sequence to re-derive the current UTXO state independently.
- IBD initial block download
- UTXO commitment schemes that solve (or at least improve) the bootstrapping problem.
- the scheme in section 7.1 provides a simple method for miners to attest to the UTXO state at a given block height as an additional service and can be implemented by either an individual or collective of nodes.
- section 7.2 we separately introduce a bounty-based scheme.
- a third party UTXO set service provider can offer a bounty for anybody to redeem by successfully attesting to the UTXO set snapshot of a previous block.
- section 7.3 we combine these two mechanisms into a hybrid scheme that collectively enables incentives for all miners to continuously calculate, verify and attest UTXO snapshots as the blockchain grows over time.
- UTXO snapshots may be modelled using the HMT defined earlier, due to its efficient-update property.
- the miners that secure the blockchain network can attest to the UTXO set state of any block that they produce.
- the attestation can simply be in the form of the
- Merkle root for the HMT of the previous block which can be included in the coinbase (or another) transaction in the block being produced by the miner.
- B n _ 1 represented by the HMT root R n-1 , is as follows.
- M 1 independently obtains its copy of the previous block's HMT root R n-1 at the start of a new block interval (i.e., once B n _ 1 has been mined).
- M 1 builds a candidate block B n on top of B n _ 1 based on the transactions they have seen during the interval, which includes CTx n .
- CTx n becomes the on- chain attestation of B n _ 1 , containing the commitment h n-1 . Note that this process only allows for the snapshot of a given block to be committed in a subsequent block i.e. the UTXO snapshot for the (n — 1) th block can only be committed in the n th block at the earliest. In fact, it is not possible to commit to R n in block B n because
- R n is effectively an accumulator of all of the other transaction IDs in B n , and if any of these transactions (including the coinbase) were to contain R n then we would have introduced a circular hash reference, which is not possible.
- This process can be performed by a single miner for each block they successfully mine and can be extended such that the miner includes the commitments of all blocks since they last successfully mined a block. It would also be feasible to allow a delay in publishing block hashes such that all network nodes are likely to have been able to calculate the commitment; for example, if the UTXO state of B n were to be included in B n+ 10 , this gives an interval of 10 blocks in which miners can compute the required commitment H(R n ).
- CTx n would still need to be accounted for somewhere in this 100-block window in order to ensure that the UTXO set state is accurate after CTx n+99 .
- Another variation of this method might involve adding the UTXO snapshot commitment to a transaction in the relevant block other than the coinbase.
- the transaction would be signed by a well-known public key, and possibly linked to a
- MinerlD MinerlD.
- a node attempting to bootstrap from B n can simply do the following: 1) Obtain the list of block headers B 0 , B 1 , ..., B n to verify the proof-of-work and integrity of the current chain tip B n .
- the protocol has two phases, (i) a set-up by Charlie, followed by (ii) a fulfilment phase carried out by one or more miners.
- a set-up phase carried out by one or more miners.
- Each bounty transaction should be bound to a particular miner.
- One way to achieve this is to make sure that the spendable bounty output also requires a signature from a key-pair belonging to the Miner ID associated with that miner, e.g. a signature that can be verified by PK Alice for a miner Alice, where PK Alice is a public key that is linked to Alice's Miner ID in some way.
- each of the miners in the scheme can perform the following steps to redeem the bounty:
- This scheme essentially allows all the participating miners to be able to earn a bounty as reward for successfully committing to the correct UTXO snapshot.
- a node attempting to bootstrap from B n can do the following:
- the bootstrapping node has the UTXO set snapshot of the chaintip, and trusts it is correct because it is consistent with the hash puzzle provided by the trusted UTXO set provider Charlie, which contains H(R n ). 7.3. Competitive scheme
- the bounty scheme of section 7.2 is useful in providing some financial incentive for miners to commit to UTXO snapshots, making it an improvement over the scheme in section 7.1.
- an alpha token i.e. unique info known only to a given miner
- a more secure use of an alpha token may be achieved by, e.g., requiring that the signing key is a combined key using alpha; i.e , where s alpha is another private key derived from alpha, such as s alpha alpha, or s alpha alpha mod n, or s alpha
- the script could require both the miner signature for and a second R-puzzle signature, where the 'r' in the puzzle is derived from the miner's alpha.
- the bootstrapping process for a node joining the network may also be identical to section
- the UTXO set provider operates multiple bounty 'rounds' per UTXO snapshot that requires commitments.
- bitcoin blockchain 150 is one particular example of a blockchain 150 and the above description may apply generally to any blockchain. That is, the present invention is in by no way limited to the bitcoin blockchain. More generally, any reference above to bitcoin network 106, bitcoin blockchain 150 and bitcoin nodes 104 may be replaced with reference to a blockchain network 106, blockchain 150 and blockchain node 104 respectively.
- the blockchain, blockchain network and/or blockchain nodes may share some or all of the described properties of the bitcoin blockchain 150, bitcoin network 106 and bitcoin nodes
- the blockchain network 106 is the bitcoin network and bitcoin nodes 104 perform at least all of the described functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150. It is not excluded that there may be other network entities (or network elements) that only perform one or some but not all of these functions. That is, a network entity may perform the function of propagating and/or storing blocks without creating and publishing blocks (recall that these entities are not considered nodes of the preferred Bitcoin network 106).
- the blockchain network 106 may not be the bitcoin network.
- a node may perform at least one or some but not all of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150.
- a "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but not store and/or propagate those blocks 151 to other nodes.
- any reference to the term “bitcoin node” 104 above may be replaced with the term “network entity” or “network element”, wherein such an entity/element is configured to perform some or all of the roles of creating, publishing, propagating and storing blocks.
- the functions of such a network entity/element may be implemented in hardware in the same way described above with reference to a blockchain node 104.
- a method comprising: determining a set of unconsumed outputs of blockchain transactions recorded on and/or submitted for recordal on a blockchain; and forming a hash tree comprising a plurality of layers arranged in a hierarchy from a leaf layer up to a root layer with one or more internal layers in between, wherein the root layer comprises a root node, and each internal layer and the leaf layer each comprise a respective plurality of nodes with each node having an indexed position within its respective layer, and wherein at each layer but the leaf layer, each node within the layer comprises a hash of a combination of a different corresponding subset of at least two of the nodes at the next layer down in the hierarchy; wherein at least some of the leaf nodes can each either A) designate a corresponding subset of one or more of the unconsumed outputs or B) comprise a placeholder value; and the method further comprises, on each of one or more occasions: I) determining an update to the set of unconsumed outputs, each update comprising an addition of
- the recomputing of the hash tree comprises: when any output is removed, removing the leaf node designating the removed output and replacing the removed leaf node, at the same position in the leaf layer, with a new leaf node which either: A) designates an updated subset of one or more unconsumed outputs not including the removed output, or B) comprises a placeholder value; and when any new output is added, forming a new leaf node designating a subset of one or more unconsumed outputs including at least the new output, wherein the new leaf node is inserted in the tree in place of a replaceable leaf node when available, at the same position in the leaf layer, a replaceable leaf node being a leaf node that either: A) designates an output being removed, or B) comprises a placeholder value; but otherwise if no replaceable leaf node is available, the tree is expanded to accommodate the new leaf node.
- Statement 2 The method of statement 1, wherein each node designating a corresponding subset of one or more unconsumed outputs designates its corresponding subset by comprising a hash of a corresponding leaf preimage, the leaf preimage comprising an indication of the corresponding subset of one or more unconsumed outputs.
- Statement 3 The method of statement 1 or 2, wherein on at least one occasion the recomputing of the hash tree on at least one occasion comprises only recomputing the hashes of subtree of the hash tree affected by the update.
- Statement 4 The method of statement 1, 2 or 3, wherein the unconsumed outputs include one or more outputs of one or more generation transactions generated when a new block is mined onto the blockchain, wherein each generation transaction has an associated maturity condition which must be met before its one or more outputs can be consumed, and wherein the method comprises maintaining a list indicating whether the associated maturity condition has been met for each generation transaction.
- Statement 5 The method of any preceding statement wherein on each occasion the recomputing of the hash tree comprises: first removing any and all leaf nodes designating consumed outputs from the set, then inserting of any and all leaf nodes designating new unconsumed outputs.
- Statement 6 The method of any preceding statement, wherein on at least one occasion, the recomputing of the hash tree comprises shrinking the tree by removing a layer if, after the update, the tree would otherwise contain a redundant number of layers for the number of leaf nodes that actually designate UTXOs.
- Statement 7 The method of any preceding statement, comprising having recorded on said blockchain or another blockchain a challenge transaction which comprises code configured to: receive and verify a signature of a challengee party from a candidate transaction submitted for recordal on the same blockchain as the challenge transaction; also receive from the candidate transaction candidate preimage data comprising a candidate instance of the root node and a candidate instance of an additional piece of information specific to the challengee party; perform a hash operation on the candidate preimage data, thereby producing a candidate hash result; verify whether the candidate hash result matches a reference hash result included in the challenge transaction, the reference hash result being a result of applying the same hash operation to reference preimage data comprising a reference instance of the root node and a reference instance of the additional piece of information; and allow the candidate transaction to be validated for recordal on the same blockchain as the challenge transaction and thereby redeem a reward specified in the challenge transaction on condition that the signature and the candidate hash result are verified by said verifying steps.
- Statement 8 The method of statement 7, wherein the other piece of information comprises an identified one of the nodes in one of the internal layers.
- Statement 9 The method of any preceding statement, comprising, by a publishing party following the re-computation on at least one of the occasions, publishing the root node or an attestation of the root node as a public commitment to the set of unconsumed outputs.
- Statement 10 The method of statement 9, wherein the publishing comprises including the root node or attestation in a commitment transaction recorded on the blockchain.
- Statement 11 The method of statement 9 or 10, wherein the publishing comprises publishing the attestation wherein the attestation comprises a hash of a commitment preimage, the commitment preimage comprising the root node.
- Statement 12 The method of any of statements 9 to 11, wherein the publishing party is a service provider providing a commitment service to miners of the blockchain transactions and/or other parties.
- Statement 13 The method of statement 12, further comprising, on each occasion: determining a delta set comprising an indication of only the outputs being removed or added in the update, not other outputs that are not being removed or added; and making the delta set available to one or more of the miners as part of a subscription to the updates.
- Statement 14 The method of any of statements 7 to 11, wherein the method is performed by a miner of the blockchain transactions to commit to the miner's view of the set of unconsumed outputs.
- Statement 15 The method of any preceding statement, wherein the set of unconsumed outputs is the set of unconsumed outputs of only the blockchain transactions recorded in blocks on the blockchain, not blockchain transactions merely submitted for recordal but not yet validated.
- Statement 16 The method of statement 15, wherein each of said occasions is when a new block is mined onto the blockchain.
- Statement 17 The method of any of statements 1 to 14, wherein the method is performed by a miner and the set of unconsumed outputs comprises transactions in a pool of transactions submitted for recordal on the blockchain but not yet validated.
- Statement 18 The method of statement 17, wherein said occasions are in response to one or more new blockchain transactions being submitted into the pool, or are periodic.
- a method comprising the actions of Computer equipment comprising: memory comprising one or more memory units; and processing apparatus comprising one or more processing units, wherein the memory stores code arranged to run on the processing apparatus, the code being configured so as when on the processing apparatus to perform the method of any preceding statement.
- a computer program embodied on computer-readable storage and configured so as, when run on one or more processors, to perform the method of any of statements 1 to 18.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Un procédé consiste à : déterminer un ensemble de sorties non consommées de transactions de chaîne de blocs, et former un arbre de hachage pour attester l'ensemble ; un nœud feuille pouvant chacun soit A) désigner un sous-ensemble correspondant d'une ou plusieurs des sorties non consommées ou B) comprendre une valeur de paramètre de substitution. Le procédé consiste en outre à déterminer une mise à jour de l'ensemble et à recalculer l'arbre de hachage pour refléter la mise à jour. Lorsqu'une sortie est supprimée, le nœud feuille désignant la sortie retirée peut être remplacé par un nouveau nœud feuille qui : A) désigne un sous-ensemble mis à jour d'une ou de plusieurs sorties non consommées comprenant la sortie retirée, ou B) comprend une valeur de paramètre de substitution. Lorsqu'une nouvelle sortie est ajoutée, un nouveau nœud feuille peut être inséré dans l'arbre à la place d'un nœud feuille remplaçable qui : A) désigne une sortie qui est retirée, ou B) comprend une valeur de paramètre de substitution.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB2201967.3A GB2615598A (en) | 2022-02-15 | 2022-02-15 | Attesting to a set of unconsumed transaction outputs |
GB2201967.3 | 2022-02-15 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023156102A1 true WO2023156102A1 (fr) | 2023-08-24 |
Family
ID=80820858
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2023/050839 WO2023156102A1 (fr) | 2022-02-15 | 2023-01-16 | Attestation à un ensemble de sorties de transaction non consommées |
Country Status (2)
Country | Link |
---|---|
GB (1) | GB2615598A (fr) |
WO (1) | WO2023156102A1 (fr) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117479235A (zh) * | 2023-12-28 | 2024-01-30 | 中通信息服务有限公司 | 一种末梢网络设施调度管理方法及*** |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11316696B2 (en) * | 2017-09-29 | 2022-04-26 | R3 Ltd. | Hash subtrees for grouping components by component type |
CA3055108C (fr) * | 2019-03-28 | 2021-10-05 | Alibaba Group Holding Limited | Systeme et procede pour le traitement parallele de transactions de chaines de blocs |
GB2592338A (en) * | 2019-07-25 | 2021-09-01 | Nchain Holdings Ltd | Digital contracts using blockchain transactions |
-
2022
- 2022-02-15 GB GB2201967.3A patent/GB2615598A/en active Pending
-
2023
- 2023-01-16 WO PCT/EP2023/050839 patent/WO2023156102A1/fr unknown
Non-Patent Citations (3)
Title |
---|
ALEXANDER CHEPURNOY ET AL: "Edrax: A Cryptocurrency with Stateless Transaction Validation", vol. 20181014:152508, 14 October 2018 (2018-10-14), pages 1 - 25, XP061026538, Retrieved from the Internet <URL:http://eprint.iacr.org/2018/968.pdf> [retrieved on 20181014] * |
DAVIDE FREY ET AL: "Dietcoin: shortcutting the Bitcoin verification process for your smartphone", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 28 March 2018 (2018-03-28), XP080859904 * |
NAGAYAMA RYUNOSUKE ET AL: "Trail: A Blockchain Architecture for Light Nodes", 2020 IEEE SYMPOSIUM ON COMPUTERS AND COMMUNICATIONS (ISCC), IEEE, 7 July 2020 (2020-07-07), pages 1 - 7, XP033840339, DOI: 10.1109/ISCC50000.2020.9219673 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117479235A (zh) * | 2023-12-28 | 2024-01-30 | 中通信息服务有限公司 | 一种末梢网络设施调度管理方法及*** |
CN117479235B (zh) * | 2023-12-28 | 2024-03-19 | 中通信息服务有限公司 | 一种末梢网络设施调度管理方法及*** |
Also Published As
Publication number | Publication date |
---|---|
GB202201967D0 (en) | 2022-03-30 |
GB2615598A (en) | 2023-08-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20220278859A1 (en) | Digital contracts using blockchain transactions | |
CN113924747A (zh) | 区块链交易数据字段验证 | |
US20220269810A1 (en) | Using Blockchain Transactions to Provide Off-Chain Functionality | |
US20220300257A1 (en) | In-Script Functions Within a Blockchain Transaction | |
US20230275770A1 (en) | Pseudo-random selection on the blockchain | |
US20230388136A1 (en) | Merkle proof entity | |
JP2023515368A (ja) | ブロックチェーンネットワークと共に使用される証明サービス | |
WO2023156102A1 (fr) | Attestation à un ensemble de sorties de transaction non consommées | |
US20230308292A1 (en) | Digital signatures | |
US20220309504A1 (en) | Multi-criteria blockchain protocol | |
US20230394063A1 (en) | Merkle proof entity | |
KR20240100373A (ko) | 분산된 블록체인 기능들을 위한 방법들 및 시스템들 | |
EP4248609A1 (fr) | Versionnage de noeuds | |
WO2023156104A1 (fr) | Attestation d'appartenance d'un ensemble | |
WO2023160921A1 (fr) | Procédé d'attestation d'échange de données | |
KR20240093494A (ko) | 샤딩된 머클 트리 | |
WO2024099693A1 (fr) | Transaction de chaîne de blocs | |
WO2024061546A1 (fr) | Application de contraintes sur des transactions de chaîne de blocs | |
WO2024041866A1 (fr) | Transaction de chaîne de blocs | |
WO2024061617A1 (fr) | Transactions de jetons de permutation atomique | |
WO2023208832A1 (fr) | Transaction de chaîne de blocs | |
WO2024041862A1 (fr) | Transaction de chaîne de blocs | |
GB2621405A (en) | Attesting to knowledge of blockchain transaction outputs | |
WO2023057151A1 (fr) | Mise en œuvre d'un protocole de jeton de couche 2 à l'aide d'une chaîne de blocs de couche 1 | |
WO2023057149A1 (fr) | Rédaction de contenu à partir de transactions de chaîne de blocs |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 23700857 Country of ref document: EP Kind code of ref document: A1 |