Blockchain-implemented database overlay, verification, and indexing system

Abstract

An embodiment provides a database overlay and indexing mechanism implemented on a blockchain. In one embodiment, records in the database are associated with each unspent output in a transaction on the blockchain via an overlay. Each output is provided with a lock script that specifies which key can be used to consume the output for further transactions. When a user desires to access a given record in the database, a further (consuming) transaction is generated and sent to the blockchain network. The further transaction is provided with an unlock script that provides the key needed to satisfy the conditions of the lock script; otherwise, the blockchain's consensus mechanism will not allow consumption of the output, and access to the record is denied. However, if the requirements are met, the output is consumed, and the access request is considered authorized. In this way, the consensus mechanism provides improved permission control and a user authorization mechanism for the database. When an output is consumed by a further transaction, the overlay is updated to associate the record with the consuming transaction. A transaction log may also be provided to enable fast and efficient replay of the database, if needed.

Description

[Technical Field]

[0001] Embodiments of the present disclosure provide mechanisms for improving data storage, retrieval, search, and reindexing. Specifically, blockchain is used to implement a database overlay that maps records in a database to transactions in a ledger, thereby providing a flexible yet efficient indexing strategy. Advantageously, a consensus mechanism specified by the blockchain protocol and implemented by the blockchain network may be used to implement a permissioning facility, where access to database records is granted only if the consensus mechanism is satisfied. Thus, the present disclosure is particularly suitable for use in relation to database technology and data storage / access, and for providing security, management, and authorization strategies therefor. [Background technology]

[0002] Blockchain Embodiments of the present disclosure may be implemented with respect to any suitable blockchain and its associated network and protocol. A blockchain refers to a form of distributed data structure, and duplicate copies of the blockchain are maintained and publicly available at each of multiple nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network"). A blockchain comprises a chain of blocks of data, each block comprising one or more transactions. Each transaction, other than so-called "coinbase transactions," points to a preceding transaction in a sequence, which may span one or more blocks and go back to one or more coinbase transactions. Coinbase transactions are discussed further below. Transactions submitted to the blockchain network are included in new blocks. New blocks are created by a process often referred to as "mining," which involves multiple nodes competing to perform "proof of work," i.e., solving a cryptographic puzzle based on a representation of a defined set of ordered, validated, outstanding transactions awaiting inclusion in a new block of the blockchain. Note that the blockchain may be pruned at some nodes, and publication of blocks may be achieved through publication of only the block headers.

[0003] Transactions in a blockchain may be used for one or more of the following purposes: moving digital assets (i.e., a number of digital tokens), ordering a set of entries in a virtualized ledger or registry, receiving and processing timestamp entries, and / or temporally ordering index pointers. Blockchains may also be leveraged to layer additional functionality on top of the blockchain. For example, blockchain protocols may allow for the storage of additional user data or indexes for data within transactions. Because there is no pre-specified limit on the maximum amount of data that can be stored in a single transaction, increasingly more complex data can be incorporated. For example, this could be used to store electronic documents or audio or video data on the blockchain.

[0004] Nodes (often called "miners") in a blockchain network perform a distributed transaction registration and validation process, which is described in more detail below. Briefly, during this process, nodes validate transactions and insert them into a target block template in an attempt to identify a valid proof-of-work solution for the transaction. Once a valid solution is found, the new block is disseminated to other nodes in the network, allowing each node to record the new block in the blockchain. To have a transaction recorded in the blockchain, a user (e.g., a blockchain client application) submits the transaction to one of the nodes in the network to be disseminated. Nodes receiving the transaction may compete to find a proof-of-work solution that will incorporate the validated transaction into the new block. Each node is configured to enforce the same node protocol, which includes one or more conditions for a transaction to be valid. Invalid transactions are not disseminated and are not included in blocks. Assuming the transaction is validated and thereby accepted on the blockchain, the transaction (including any user data) remains registered and indexed at each of the nodes in the blockchain network as an immutable public record.

[0005] Nodes that successfully solve the proof-of-work puzzle and create the latest block are rewarded with a new transaction, usually called a "coinbase transaction," that distributes an amount of digital assets, i.e., a number of tokens. Detection and rejection of fraudulent transactions is performed by the actions of competing nodes that are incentivized to act on behalf of the network and report and prevent fraud. Widespread publication of information allows users to continuously audit node behavior. The simple publication of block headers allows participants to guarantee the ongoing integrity of the blockchain.

[0006] In an “output-based” model (sometimes called a UTXO-based model), the data structure of a given transaction comprises one or more inputs and one or more outputs. Every consumable output comprises an element specifying the amount of a digital asset derivable from the preceding sequence of transactions. A consumable output is sometimes called a UTXO (unspent transaction output). An output may further comprise a locking script that specifies the conditions for future redemption of the output. A locking script is a predicate that defines the conditions necessary to validate and transmit a digital token or asset. Each input of a transaction (other than a coinbase transaction) comprises a pointer (i.e., a reference) to such output in a preceding transaction and may further comprise an unlocking script for unlocking the locking script of the pointed-to output. Thus, consider a pair of transactions, referred to as a first transaction and a second transaction (or “target” transaction). The first transaction comprises at least one output specifying the amount of a digital asset and a locking script that defines one or more conditions for unlocking the output. The second target transaction comprises at least one input, which comprises a pointer to the output of the first transaction and an unlock script for unlocking the output of the first transaction.

[0007] In such a model, when a second target transaction is sent to the blockchain network to be disseminated and recorded in the blockchain, one of the validity criteria applied at each node is that the unlocking script meets all of one or more conditions defined in the locking script of the first transaction. Another criterion is that the output of the first transaction has not yet been redeemed by another, earlier, valid transaction. Any node that finds the target transaction to be fraudulent according to any of these conditions will not disseminate the target transaction (not as a valid transaction, but possibly disseminate it to register a fraudulent transaction) and will not include the target transaction in a new block to be recorded in the blockchain.

[0008] An alternative type of transaction model is the account-based model, where each transaction defines the amount to be transferred not by referencing back to the UTXO of a previous transaction in a sequence of past transactions, but by referencing an absolute account balance. The current state of every account is stored in the blockchain and constantly updated by multiple nodes separately.

[0009] term Although some terms are common in various fields, they are understood to have different meanings by those skilled in the art in each field. Hereinafter, unless otherwise specified, the following terms will be used with the meanings given below. Database: hereinafter means any “traditional” non-blockchain-based data collection, such as database technologies that may or may not be accessed via a DBMS, as known in the art of computing and information science, including but not limited to document stores, relational databases, file storage systems, data warehouses, array DBMSs, unstructured data DBs, etc. Transaction: This term may be used in the field of traditional databases and in relation to financial operations. Here, unless otherwise specified, the term "transaction" means a blockchain transaction, i.e., a data structure formed according to and in compliance with the blockchain protocol. Mapped: This term may be used interchangeably with "linked," "indexed," "associated," "represented by," and / or "correlated with / to." Mapping: May be used interchangeably with linking, indexing, correlating with / to, referencing, representing, and / or associating with. Blockchain: The term "blockchain" is used to include all forms of electronic, computer-based distributed ledgers, including, but not limited to, consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. Bitcoin: The term "Bitcoin" is used to include the original Bitcoin protocol and implementations, as well as any and all protocols derived therefrom or variations thereof. While reference to Bitcoin may be made herein purely for convenience and illustrative purposes, as it is the most well-known, it should be noted that the present invention is not limited to use with the Bitcoin blockchain and related protocols, and alternative blockchain implementations and their associated protocols / networks are within the scope of the present invention. The term "Bitcoin" may be used interchangeably with "blockchain" herein. Consensus mechanism: A term known in the field of blockchain technology. According to the known definition, a consensus mechanism comprises a protocol that allows nodes of a distributed blockchain network to reach agreement on the state of the ledger and sets out the validation requirements that each blockchain transaction must meet to be accepted for inclusion in the ledger. In this specification, this term is used to include any type of blockchain-related consensus mechanism, including but not limited to Proof of Work (PoW), Proof of Stake (PoS), or Delegated Proof of Stake (DPoS). The term "consensus algorithm" may be used interchangeably with "consensus mechanism."

[0010] Background to the disclosure Blockchains are sometimes described as databases because, like databases, electronic ledgers can store data. However, there are significant differences between blockchains and databases. Some examples of technical differences and relative advantages / disadvantages are given below, without limitation: Databases have a centralized administrator. In contrast, blockchains are decentralized and have no centralized governing body. Instead, validation is performed through a consensus mechanism that is written into the blockchain protocol and enforced by nodes (miners) on the network. · Governing authorities set access permissions in databases (at the system and record levels), so that data can only be accessed from records if authorized by a centralized administrator. In contrast, outputs (e.g., UTXOs) in blockchain transactions (TX) can only be consumed if the requesting party provides the necessary information to comply with the conditions of the locking script. Thus, in the context of blockchain, access permissions are specified according to an associated protocol and enforced via cryptographic controls. Thus, rather than being specified and enforced by a centralized governing authority associated with a particular organization, blockchains operate as decentralized policies, specified by protocols adhered to by network nodes but not specified by them. In a database, records are mutable unless write operations are individually locked by a central authority. However, in a blockchain, all transactions are immutable as a result of the protocol design. Databases maintain a separate transaction log to provide a historical record of which actions were performed, when, and by whom. Transaction logs are crucial for the regeneration of traditional databases, for example, in the event of a system failure, to return the database to a stable state. In contrast, each blockchain transaction (the equivalent of a record in a database) stores a unique history of who did what in specific data via inputs and outputs and a time-stamping mechanism, and once written to the ledger, this log is immutable. Databases can be corrupted and vulnerable to exploitation, so they need to be backed up regularly, which requires storage and processing resources. In contrast, blockchains are immutable, so data cannot be corrupted or changed after it has been confirmed on the chain, and data integrity is cryptographically guaranteed and enforced. Databases are easy and simple to implement and maintain as the technology is well known and widely used, whereas blockchain-based technologies can be more complex to implement and require more specialized skills and time. · In terms of scalability, databases may offer advantages over blockchains, depending on the protocols involved. In a database, data-level operations such as create, search, write, and read can be performed very quickly. However, create and write operations to a blockchain are slowed down by the protocol's integral validation and consensus mechanisms. Reading / searching a blockchain for a specific data item can be time and resource intensive due to the sequential nature of the ledger and the need to iterate over individual blocks to identify the specific transaction containing the target data.

[0011] Therefore, significant technical challenges must be overcome to find ways to deliver the benefits of two very different data storage technologies with contrasting software and hardware architectures while avoiding or at least mitigating their respective drawbacks. Summary of the Invention [Problem to be solved by the invention]

[0012] The present disclosure provides a methodology whereby traditional databases and / or database structures are associated with a blockchain, which can provide an overlay that facilitates or enables data storage, access, security, and / or processing. Embodiments provide a methodology whereby permission control for traditional databases is implemented and / or enforced by nodes on the blockchain network through the execution of tasks and functions specified by the blockchain's protocol. [Means for solving the problem]

[0013] From one perspective, embodiments utilize the strengths and benefits of both blockchain and traditional databases while eliminating or at least reducing their respective drawbacks when used as large-scale data storage mechanisms. From another perspective, the present disclosure combines advantageous aspects of separate and distinct technology platforms and architectures. According to one possible embodiment, a traditional database is associated with a blockchain such that the association enables, provides, or functions as a blockchain-implemented overlay for the database.

[0014] The database may be implemented on-chain or off-chain, i.e., on or off the blockchain. In other words, individual data items may be stored in transactions within the blockchain or stored off-chain in any suitable storage mechanism. In one or more embodiments, this storage mechanism may be a traditional database. Examples include, but are not limited to, a relational database, an SQL, New-SQL or no-SQL database, a graph database, or any mixture or alternative of these listed examples.

[0015] A database may comprise one, some, or all of the components typically associated with a traditional database, including a DBMS, associated storage resources, such as hardware and software for storing and retrieving data, an API, a language for manipulating and using the database, etc. (see, e.g., https: / / en.wikipedia.org / wiki / Database).

[0016] In a preferred embodiment, an overlay is provided that associates at least one record in a database with at least one transaction (Tx) on a blockchain. Specifically, it may associate a record with a respective output (UTXO) in one or more transactions. From one perspective, the database record may thus be represented as an unspent output of a blockchain transaction.

[0017] In a preferred embodiment, the output comprises a lock script. In some but not all embodiments, the lock script, which may also be known as a scriptPubKey or PubKey Script, may be a portion of code associated with the transaction output that specifies some conditions that must be met for another (further) transaction to consume the output. These conditions may include the further transaction comprising an unlock script (which may also be known as a scriptPubKey or Signature script, according to some embodiments) that provides proof of signature by one or more specified public keys.

[0018] Preferably, when access is requested for a particular record in the database, a further transaction is generated and submitted to the blockchain network. The blockchain-related consensus mechanism verifies, according to conventional functionality, whether the required signature and public key are present in the lock script via the unlock script. If present, access to the database record is considered authorized, and the record can be accessed. If not, access is denied. In this way, the blockchain network implementing the blockchain protocol can be used as the sole verification and authorization mechanism for the database. No pre- or post-verification of user authorization is required beyond verification by the nodes forming the consensus mechanism.

[0019] This offers the significant technical advantage that traditional database permission enforcement (e.g., privilege and user permissions) can be implemented and enforced by existing blockchain consensus mechanisms. This not only means that processing resources such as hardware, software, and energy need not be transferred from the database owner to the blockchain network, but it also means that permissions can be cryptographically enforced via the blockchain protocol, providing an immutable on-chain record of who has access to what and when. See https: / / en.wikipedia.org / wiki / Database_security

[0020] The overlay may be updated to reflect any event or processing operation that occurs with respect to a given record. This may be an access event, such as a read, write, or copy operation. When a particular record is accessed in the database, the overlay entry for that record is updated to reflect the change.

[0021] In some embodiments, a transaction log may be provided that records all events and changes related to the state of the overlay. While this information may be extracted from the blockchain from important transactions related to the record, a separate transaction log may provide efficiencies in terms of the time, energy, and processing resources required to find and gather the necessary information when it is required. Thus, some embodiments may provide advantages related to database activity monitoring (DAM) (https: / / en.wikipedia.org / wiki / Databaase_activity_monitoring) and / or "backup and restore" requirements (https: / / en.wikipedia.org / wiki / Backup) in case the database needs to be rebuilt.

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

[0023] [Figure 1] FIG. 1 is a schematic block diagram of a system for implementing a blockchain. [Figure 2] FIG. 1 illustrates schematically some examples of transactions that may be recorded on a blockchain. [Figure 3A] FIG. 2 is a schematic block diagram of a client application. [Figure 3B] 3B is a schematic mockup of an exemplary user interface that may be presented by the client application of FIG. 3A. [Figure 4] FIG. 1 is a schematic block diagram of some node software for processing transactions. [Figure 5] FIG. 1 is a diagram of an overview of an embodiment according to one or more embodiments of the present disclosure. [Figure 6] FIG. 6 shows the embodiment of FIG. 5 in more detail. [Figure 7] 1 is a flowchart illustrating steps that may be taken in accordance with one or more embodiments of the present disclosure. [Figure 8] FIG. 6 is an alternative diagram of the embodiment of FIG. 5, showing the relationship between database records and their associated transactions with dotted lines. DETAILED DESCRIPTION OF THE INVENTION

[0024] Databases and Data In one illustrative implementation, and with particular reference to Figures 5, 6, and 8, the contents of a database are mapped to a blockchain in such a way that the blockchain acts as an overlay mechanism. Among other benefits, this facilitates improved indexing and reindexing of the database and its data items, provides improved security and authorization techniques that are advantageously implemented via traditional features and functionality of the blockchain, and enables improved database backup and restore strategies.

[0025] Data stored in a database may take any form and may be organized or suitable for any purpose. In our example, the database is a graph-based database, but the disclosure is not limited in this respect and may be configured for use with any alternative form of database model or data store. However, graph databases are known to be particularly well-suited for storing and representing many-to-many relationships between data items, such as those used by social media and other applications that store, manipulate, generate, reindex, and process large numbers of data items that are interrelated through complex relationships and connections. Accordingly, embodiments are particularly well-suited for use with graph databases, giving rise to many promising and powerful applications.

[0026] We use the term "data item" to include one or more pieces of data that are recorded in a database as an entity. This may be, for example, a single data item such as a file, or it may be multiple data items that are related in some way within the database and therefore may be viewed as an entity even if the data items are not stored in the same location or on the same device.

[0027] Although the term "node" is typically used in reference to data items stored in a graph database, the term "record" is used to avoid confusion with "nodes" 104 in a computing network 106, as embodiments may be used with other types of database models that comprise "records" akin to nodes in a graph database. A record may comprise one or more data items, each of which may be stored in a distributed manner but logically associated as part of the same record. Each record has a unique record identifier (record_ID) that allows the record to be referenced and accessed as known in the art.

[0028] According to some embodiments, data items may be stored on-chain (i.e., on the blockchain), off-chain, or a combination thereof. In our illustrative embodiment, all individual data items are stored off-chain in records in a traditional (graph) database. However, other database and data storage implementations are equally suitable for use with the embodiments disclosed herein. For example, one or more data items may be stored in a transaction on the blockchain using any suitable known technique. For example, in a Bitcoin-related blockchain, a data item may be provided in a transaction by providing the data item after an OP_RETURN statement in a script, by including it as metadata, or by including a reference, pointer, or other reference that allows identification of the data in an off-chain location. Multiple data items may be stored in separate outputs of the same transaction. In other cases, data for a given record in a database is stored across separate locations, such that multiple transactions in the same block may comprise one or more data items. Alternatively, multiple transactions, each containing at least one data item, may be provided across multiple blocks on the blockchain. There is no restriction or constraint requiring database-containing transactions to be in the same block.

[0029] Overlay Components With reference to Figures 5, 6, and 8, the present disclosure provides an overlay mechanism that maps one, some, or all records in a database to transactions on a blockchain. The overlay ("map") associates one or more records in the database with at least one transaction (TX) on the blockchain. Any form of known transaction may be used. In our Bitcoin illustration, non-limiting examples may include pay-to-public-key-hash (P2PKH), Pay to Public Key (P2PK), pay to multi-signature (P2MS), and pay-to-script-hash (P2SH).

[0030] An overlay comprises a list of entries, each entry relating to a record in a database to be mapped to a blockchain. In some implementations, the overlay is stored on-chain for one or more transactions, but off-chain for other transactions. It may be stored digitally in any format or form. In our illustrative embodiments of Figures 5, 6, and 8, the overlay is stored off-chain.

[0031] In some instances, multiple records may be associated with the same transaction, while in other instances, records may be distributed across multiple transactions. In particular, each record listed in the overlay corresponds to a respective output in an on-chain transaction.

[0032] For each record entry in the overlay, there is (at least) an identifier that associates that record with a particular output 203 in a particular transaction 152i on the blockchain 150. For convenience, we refer to this identifier as the "on-chain index" or simply "index." The output (UTXO) is unspent and has a lock script that can only be consumed by providing an unlock script that satisfies the conditions specified in the lock script. As known in the art, the lock script specifies which cryptographic key must be used to prove authorization to receive the output's associated cryptocurrency. The intended recipient provides this proof by including the required public key and signature via the unlock script in a new transaction 152j. When the new transaction 152j is submitted to the blockchain network, it is verified by the nodes. This verification verifies the public key provided by the recipient against the key hash provided by the lock script, and also uses the public key to verify the signature. If the script verification returns true, the cryptocurrency is unlocked and spent to the specified address.

[0033] Thus, traditional consensus mechanisms of blockchain protocols and networks enforce a cryptographic authorization process whenever outputs are consumed from one transaction to another via the ledger. Advantageously, embodiments of the present disclosure utilize this inherent authorization functionality to facilitate cryptographically enforced authorization for databases, as described below.

[0034] In addition to the record index, an entry / entries may comprise additional information about the data item / record. For example, at least one entry may comprise data relating to or referencing other records / entries with which the at least one entry has a relationship or correlation. For example, a record index may comprise a field that identifies other records / entries related to it. This field may comprise parameters that add additional information about the relationship, such as parameters indicating a hierarchical relationship with other records in the database, or references / addresses indicating where the data item related to the record can be accessed, or any other metadata related to the record.

[0035] The record index specified in the overlay can take any suitable form. In our example, it comprises the transaction ID (TXID) of the transaction for which the output is provided, concatenated with the identifier of the output within the transaction. This means that TXID||UTXO_ID and are shown in Figures 5 and 7.

[0036] So if database record i corresponds to output y in transaction x on the blockchain, then this is RECi→TXxID||UTXOy_ID can be written as:

[0037] As is known in the art, each Bitcoin transaction that is successfully validated and written to the ledger has a unique ID (TXID) that never changes. Within each transaction, the outputs are enumerated in a vector (VOUT), so that each output in a transaction can be identified by its position / index in the VOUT vector, starting with VOUT[0]. Thus, in the above expression, UTXO_IDy can be replaced with VOUT[y], where y is the position of the associated output in the list of outputs of Tx, RECi→TXxID||VOUT[y] Give.

[0038] As described above, in some examples, multiple records may be associated with the same transaction instead of, or in addition to, an overlay that may be maintained off-chain. In such embodiments, all records in a database may initially be associated with their respective outputs in a single blockchain transaction, so that the single transaction effectively becomes the online schema or index listing for the entire database. This initial transaction 152i may be referred to as the root or genesis transaction for the overlay. The individual outputs of the genesis transaction may subsequently be consumed whenever their associated records are accessed, leaving an immutable, auditable trail for each record of time-stamped events and details of the users who executed them. Each of these output trails may be traced back to the initial root / genesis transaction for the database.

[0039] Transaction Log In some embodiments, a transaction log may be maintained to facilitate database restoration and recovery in the event of hardware / software failure, content corruption, etc. The transaction log provides a historical record of all events that have occurred with respect to the database and maintains details of all state changes in the overlay. While this data can be extracted from the blockchain in the event of a system failure, it may be more efficient to maintain a log and restore the database from the log. The transaction log may comprise one or more components of the overlay system disclosed herein.

[0040] Access to Records When a user desires to access a record in the database, the access request is passed to an overlay component of the system. The overlay component identifies the associated entry for the record and retrieves all necessary data from the entry to enable the creation of a transaction that consumes the output of the associated transaction 152i. This data may include one or more of a transaction identifier (TXID), an output identifier (VOUT[y]), an address against which the cryptocurrency associated with the output should be consumed, and a public key associated with the record. The address may be a cryptocurrency address generated by and / or stored in a wallet. The wallet may be a component of the overlay system.

[0041] Once the necessary data is obtained, a new transaction 152j is generated and broadcast to the network 106 of nodes 104. The nodes 104 validate the transaction, and if successful, the transaction is mined into block 151 and added to the ledger 150. This causes the outputs 203 of the previous transaction to be spent against the new transaction. The entry details for the record are updated to reflect that the record is now associated with the specific unspent outputs in the new transaction. The transaction log may also be updated with the event details. A new cryptographic (sub)key may be generated to replace the key used to spend the output during the access request, and the new key may be associated with the record and / or the user in an overlay. The cryptocurrency associated with the spent output is spent against the specified address. The new transaction includes the output with a lock script, specifying the key that must be used to unlock it and the address against which the cryptocurrency is to be spent. Unless an administrator changes the authorization details in the overlay entry for the record (e.g., an employee leaves the organization so their authorization data / keys are removed from the entry), new transactions will require keys provided by the same authorized party / parties (i.e., users).

[0042] During validation by a node, the protocol requires that the lock and unlock scripts be evaluated. This involves verifying that the required public keys and signatures are provided in the unlock script. Thus, the consensus mechanism built into the blockchain protocol performs the authorization function traditionally performed as part of a database application.

[0043] Usage example With reference to the figures (and specifically to FIG. 7), we now provide examples of how the illustrative embodiments may be used. Steps may actually be performed in a different order than shown in FIG. 7, some may be omitted, and / or other steps not shown may be inserted.

[0044] In step 1, a database 506 is created. As explained above, the database can take any known form suitable for the needs of the use case.

[0045] In step 2, using a user interface 501, a component of the control system 500 disclosed herein, an administrator or user associates each authorized user with one or more cryptographic key pairs, each consisting of a public key and a corresponding private key. The user / administrator may generate the keys using a digital wallet or other key generation component known in the art, and wallets 502a, 502b, and 502c are associated with the user / administrator, hereafter simply “user.” Each user may have a unique digital wallet 502a, 502b, and 502c for generating and storing keys that can be used to verify authorization to access records and for generating cryptocurrency addresses. The wallets 502a, 502b, and 502c may contain some cryptocurrency that allows for the consumption of output during an access event. Users may maintain and / or use the control system 500 through interaction with the user interface 501. The user interface 501 may facilitate operations such as creating a new record entry, creating a new authorized user for one or more records, and deleting one or more records or authorized users.

[0046] A record of which keys are associated with each user may be stored and maintained, for example, by an administrator. Each key pair provides an authorization mechanism that users can use to unlock specific records. The database 506 may be configured such that at least some of the records 505 form a hierarchical structure. In such cases, subkeys may be generated for records at different levels within the hierarchy. Techniques such as those disclosed in International Application Publication No. 2017 / 145016 (PCT Application No. PCT / IB2017 / 0500856) may be used to deterministically generate subkeys from a master key, thereby enabling the generation of a hierarchy of cryptographic keys that reflects the hierarchical structure of the records.

[0047] In step 3, a database overlay 503 is created to map records 505 in the database 506 to respective outputs 203 in one or more transactions in the blockchain ledger 150. This step may comprise the act of creating one or more blockchain transactions 152 that represent each record 505 in the database 506 and have outputs 203 associated therewith. The transactions are submitted to the blockchain 150. Thus, for each record 505 in the database, there is a genesis transaction to which subsequent transfers (output consumption / access events) can be traced for a given database record 505. That trace provides an auditable, time-stamped, and irrefutable record of who did what for each record 505.

[0048] Each user and their associated public key and corresponding record_ID may be recorded within the overlay component 503 so that the overlay can be queried or queried to determine which users have permission to access particular records 505 or which records a particular user has permission to access. Users may perform such queries to generate reports and may interact with the authorization control system 500 using the interface 501.

[0049] At least one blockchain transaction 152 is generated, comprising a UTXO 203 representing a respective record 505. Each UTXO 203 comprises a lock script that specifies at least one key that can be used to unlock the output and spend its associated cryptocurrency. Thus, the UTXO 203 can only be unlocked if at least one key and corresponding signature are provided. In some cases, as is known in the art of blockchain transactions, the script may allow one or more of a group of authorized keys to be used to unlock the output (i.e., an "n-of-m" or "multisig" transaction). The script may comprise an "OR" or select function to allow any authorized party in the set of authorized parties to access the record.

[0050] In practice, keys may be generated as subkeys of a master key. For example, an initial key associated with a given user and / or record may be used as a master key for the generation of subkeys associated with partial records derived from that record. This is advantageous when a database comprises a hierarchy of records and the associated key structure needs to reflect the record structure. Subkeys may be generated using techniques substantially as disclosed in International Application Publication No. 2017 / 145016 (which is incorporated herein in its entirety) or any other suitable subkey generation technique. In some embodiments, a new key and / or subkey may be used for each new output associated with a given record. This may increase security by making it more difficult to distinguish the recipient for whom an output is spent.

[0051] In step 4, a transaction log 504 is generated (optional). This is updated every time an output is consumed. Any new keys associated with each record 505 are recorded.

[0052] In step 5, suppose a user desires to access a specific record in database 506. When such a demand arises, an access request can be generated by the user and sent to the overlay. The overlay component 503 may be queried to obtain an on-chain ID for that record 505. In other words, an ID for the output is associated with the target record. In our example, this identifier is the transaction ID (TXID) combined with the UTXO identifier, which together specify the location of the record's index (the output) on the blockchain. An authorization check needs to be performed to ensure that the access requestor has permission to access the target record and is legitimately authorized to do so.

[0053] In step 6, in response to the access request, a new (further) blockchain transaction (Tx) is generated to consume the UTXO currently associated with the record. This may be generated by the user's (or administrator's) wallet. Tx comprises an input 202 with an unlocking script that provides a public key and a signature generated by that public key to satisfy requirements specified by a locking script 203 of the UTXO in the Tx currently associated with the target database record. In some cases, more than one public key and corresponding signature are provided in the unlocking script, depending on conditions set in the locking script. The unlocking script provides an address against which cryptocurrency is to be consumed. The further transaction is submitted to the blockchain network 106 for validation by the mining node 104 and, if successful, for addition to the ledger 150. (Note that Figures 5, 6, and 8 only show transactions, not the blocks in which they are provided on the ledger 150; however, blocks are shown in Figure 1.)

[0054] In step 7, the node validates the new transaction according to the consensus rules specified in the blockchain protocol, which involves the node 104 verifying that the correct keys and minimum number of keys were provided by the unlock script and that those keys were used to generate the provided signature.

[0055] In step 8.2.1, if the verification is successful, the user's access request is considered authorized. The output of the record is consumed and the cryptocurrency is transferred to the recipient's address according to the protocol rules. The record is now transferred to a further transaction, TX j The database record becomes associated with the new UTXO in the overlay. The database record is locked on a first-come, first-served basis until the current access ends. The overlay entry for the record is updated to associate the record with the new UTXO in a further transaction. If needed, a new (sub)key is generated for the new UTXO and associated with the record in the overlay. If a transaction log is implemented, the transaction log is updated to reflect this event.

[0056] If, in step 8.2.2, the consensus mechanism fails to verify the attempted consumption of the UTXO, access to record 505 is denied.

[0057] An advantage of the present disclosure is that by enabling the mapping of the database 506 to the blockchain 150, lookups and other operations can be performed using Simplified Payment Verification (SPV) techniques. SPV is known in the art and was introduced in Section 8 of Satoshi Nakamoto's white paper, "Bitcoin: A Peer-to-Peer Electronic Cash System" (2008). SPV takes advantage of the inherent design of the blockchain protocol, which incorporates Merkle proofs, to provide an efficient way to verify the existence of a target transaction (and therefore its inputs) in the blockchain without needing to access the entire blockchain. Rather than searching for individual transactions on the chain as in traditional approaches, in accordance with the present disclosure, records are directly indexed in a manner similar to a hash database. Thus, edges between nodes (records) in the overlay correspond to paths in a Merkle tree. The advantage of this is that paths are dynamically stored in the blockchain over time.

[0058] As a result, data reindexing can be performed more quickly, requiring less processing and resources because sequential searches do not need to be repeatedly performed across the entire blockchain each time a particular record and / or data item of interest needs to be accessed. In contrast, using embodiments of the present disclosure, a user can look up a given TX, see its associated correspondences, and understand that TXa corresponds to TXb, TXb corresponds to TXc, TXc corresponds to TXd, etc. Transactions may be in different blocks on the chain, but are all connected via correspondences. This provides a faster and more efficient approach to searching than having to iterate across the ledger block by block until the target transaction is found.

[0059] Additionally, the above embodiments utilize existing consensus mechanisms for blockchains to implement the authorization and authorization components of the system. Access requests are granted or denied substantially based on the outcome of the consensus mechanism's work. In a preferred embodiment, validation work is not required by the overlay / DBMS, as it is instead handled by the blockchain network.

[0060] This is in contrast to prior art arrangements such as PCT / IB2020 / 057762 (published as International Application Publication No. WO2021 / 033134), which use a DBMS to verify the access permissions of a requesting user and, if the user is deemed authorized, write a record of the event in the transaction's non-consumable output to a ledger. The contents of applicant's co-pending application No. PCT / IB2020 / 057762 (published as International Application Publication No. WO2021 / 033134) are incorporated herein in their entirety. The contents of International Application Publication No. WO2017 / 145016 (PCT Application No. PCT / IB2017 / 0500856) are also incorporated herein in their entirety.

[0061] Example of a blockchain system overview FIG. 1 illustrates an exemplary system 100 for implementing an illustrative blockchain 150 that may be used in connection with embodiments of the present disclosure. This example is not intended to be limiting or exclusive, but rather is provided as one possible implementation form among many possibilities. 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 multiple blockchain nodes 104 that may be configured to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be configured as a near-complete graph. Thus, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0062] Each blockchain node 104 comprises a peer computing device, with different nodes 104 belonging to different peers. Each blockchain node 104 comprises one or more processors, e.g., processing devices comprising one or more central processing units (CPUs), accelerator processors, application-specific processors, and / or field-programmable gate arrays (FPGAs), as well as other devices such as application-specific integrated circuits (ASICs). Each node also comprises memory, i.e., computer-readable storage in the form of a non-transitory computer-readable medium. The memory may comprise one or more memory units utilizing one or more memory media, e.g., magnetic media such as a hard disk, electronic media such as a solid-state drive (SSD), flash memory, or EEPROM, and / or optical media such as an optical disk drive.

[0063] A blockchain 150 comprises a chain of blocks of data 151, and a respective copy of the blockchain 150 is maintained at each of multiple blockchain nodes 104 in a distributed network or blockchain network 106. As mentioned above, maintaining a copy of the blockchain 150 does not necessarily mean storing the blockchain 150 in its entirety. Instead, the blockchain 150 can 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, where a transaction in this context refers to a certain data structure. The nature of the data structure depends on the type of transaction protocol used as part of the transaction model or scheme. A given blockchain uses one particular transaction protocol throughout. In one common type of transaction protocol, the data structure for each transaction 152 comprises at least one input and at least one output. Each output specifies as a property an amount representing an amount of digital assets, such as a user 103 to which the output is cryptographically locked (requiring that user's signature or other solution to be unlocked and thereby redeemed or spent). Each input points to the output of a preceding transaction 152, thereby chaining transactions together.

[0064] Each block 151 also has a block pointer 155 that points to a previously created block 151 in the chain to define a sequential order for the blocks 151. Each transaction 152 (other than a coinbase transaction) has a pointer to a previous transaction to define an order for the sequence of transactions (note that the sequence of transactions 152 is allowed to diverge). The chain of blocks 151 goes back to a genesis block (Gb) 153, which was the first block in the chain. One or more original transactions 152 early in the chain 150 pointed to the genesis block 153, not to a preceding transaction.

[0065] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, thereby allowing the transactions 152 to be disseminated throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store respective copies of the same blockchain 150 in its memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into a block 151. The ordered pool 154 is often referred to as a "mempool." As used herein, this term is not limited to a particular blockchain, protocol, or model. It refers to an ordered set of transactions that the node 104 has accepted as valid and for which the node 104 is not obligated to accept other transactions that attempt to consume the same output.

[0066] For a given current transaction 152j, its (or each) input comprises a pointer that references the output of a preceding transaction 152i in the sequence of transactions, specifying that this output should be redeemed or “spent” in the current transaction 152j. In general, a preceding transaction can be any transaction in the ordered set 154 or any block 151. A preceding transaction 152i need not necessarily exist at the time the current transaction 152j is created or even transmitted to the network 106, but for the current transaction to be valid, the preceding transaction 152i must exist and be validated. Thus, as used herein, “preceding” refers to something that precedes in the logical sequence connected by pointers, not necessarily to the time of creation or transmission in the chronological order, and does not necessarily preclude transactions 152i, 152j from being created or transmitted in a different order (see the discussion of orphan transactions below). A preceding transaction 152i may be equivalently referred to as an ancestor transaction or a predecessor transaction.

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

[0068] According to an output-based transaction protocol such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to institute a new transaction 152j (either manually or through an automated process utilized by the party), the instituting party transmits the new transaction from its computer terminal 102 to a recipient. The instituting party or recipient ultimately transmits this transaction to one or more of the blockchain nodes 104 of the network 106 (which today are typically servers or data centers, but could in principle be other user terminals). It is not excluded that the party 103 instituting the new transaction 152j may transmit the transaction directly to one or more of the blockchain nodes 104, and in some instances may not transmit it to a recipient. The blockchain nodes 104 receiving the transaction verify whether the transaction is legitimate according to a blockchain node protocol applied at each of the blockchain nodes 104. The blockchain node protocol typically requires the blockchain nodes 104 to verify that the cryptographic signature in the new transaction 152j matches an expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such output-based transaction protocols, this may comprise verifying that the cryptographic signature or other authorization of a party 103 included in the input of the new transaction 152j matches a condition defined in the output of the preceding transaction 152i that the new transaction assigns, which condition typically comprises at least verifying that the cryptographic signature or other authorization 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. This condition may be defined at least in part by a script included in the output of the preceding transaction 152i.Alternatively, it may be determined solely by the blockchain node protocol, or by a combination of these. In either case, if the new transaction 152j is valid, 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 tests according to the same blockchain node protocol and forward the new transaction 152j to one or more further nodes 104, and so on. In this way, the new transaction is disseminated throughout the network of blockchain nodes 104.

[0069] In an output-based model, the definition of whether a given output (e.g., UTXO) is allocated (e.g., "spent") is whether it has not yet been validly redeemed by the input of another, earlier transaction 152j according to the blockchain node protocol. Another condition for a transaction to be valid is that the output of the preceding transaction 152i that it attempts to redeem has not yet been redeemed by another transaction. Again, if it is not valid, the transaction 152j is not disseminated (unless flagged as fraudulent and disseminated as a warning) or recorded in the blockchain 150. This protects against double spending, where a transactor attempts to allocate the same transaction output more than once. On the other hand, an account-based model protects against double spending by maintaining an account balance. Again, because there is no defined order to transactions, an account balance has a single defined state at any given time.

[0070] In addition to validating transactions, blockchain nodes 104 also compete to be the first to create a block of transactions in a process commonly referred to as mining, which is aided by "proof of work." At blockchain nodes 104, new transactions that have not yet appeared in a block 151 recorded in the blockchain 150 are added to an ordered pool 154 of legitimate transactions. Blockchain nodes then compete to assemble a new legitimate block 151 of transactions 152 from the ordered set of transactions 154 by attempting to solve a cryptographic puzzle. Typically, this involves looking for a nonce value such that when the "nonce" is concatenated with a representation of the ordered pool of outstanding transactions 154 and hashed, the hash output satisfies a predetermined condition. For example, the predetermined condition might be that the hash output has a defined number of leading zeros. Note that this is just one particular type of proof-of-work puzzle; other types are not excluded. The nature of a hash function is that it has an unpredictable output given its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 attempting to solve the puzzle.

[0071] The first blockchain node 104 that solves the puzzle announces this to the network 106 and provides the solution as a proof, which can then be easily verified by other blockchain nodes 104 in the network (given the solution to the hash, it is easy to verify that the solution causes the hash output to satisfy a condition). The first blockchain node 104 disseminates the block to a threshold consensus of other nodes, which accept the block and enforce the protocol rules. The ordered set of transactions 154 is then recorded by each of the blockchain nodes 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n, which points to the previously created block 151n-1 in the chain. The large amount of effort required to produce the proof-of-work solution, e.g., in the form of a hash, indicates the first node 104's willingness to follow the rules of the blockchain protocol. Such rules include not accepting a transaction as valid if it allocates the same output as a previously validated transaction (also known as double-spend). Once created, blocks 151 cannot be altered because they are recognized and maintained at each of the blockchain nodes 104 in the blockchain network 106. Block pointers 155 also impose a sequential order on blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, this becomes an immutable public ledger of transactions.

[0072] Note that different blockchain nodes 104 competing to solve the puzzle at any given time may do so based on different snapshots of the pool of unpublished transactions 154 at any given time, depending on when they began searching for a solution or the order in which transactions were received. The first to solve each puzzle defines which transactions 152 will be included in the next new block 151n and in what order, and the current pool of unpublished transactions 154 is updated. Blockchain nodes 104 then continue competing to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. There are also protocols for resolving any possible "forks," which are situations in which two blockchain nodes 104 solve the puzzle within a very short time of each other, causing conflicting views of the blockchain to spread between the nodes 104. That is, the fork with the longest branch becomes the final blockchain 150. Note that this should not affect users or agents of the network, since the same transactions appear in both forks.

[0073] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to allocate an additional acceptable amount of digital assets in a new, special type of transaction (as opposed to an agent-to-agent or user-to-user transaction that transfers an amount of digital assets from one agent or user to another) that distributes an additional specified amount of digital assets. This special type of transaction is typically called a "coinbase transaction," but may also be named an "initial transaction" or "generation transaction." It typically forms the first transaction in a new block 151n. The proof of work indicates the node constructing the new block's willingness to follow protocol rules that allow this special transaction to be redeemed later. Blockchain protocol rules may require a maturation period, e.g., 100 blocks, before this special transaction can be redeemed. Often, an ordinary (non-generation) transaction 152 also specifies an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction is published. This fee is typically called a "transaction fee" and is discussed below.

[0074] Depending on the resources involved in validating and publishing transactions, at least each of the blockchain nodes 104 typically takes the form of a server with one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 could take the form of a user terminal or a group of user terminals networked together.

[0075] The memory of each blockchain node 104 stores software configured to execute on the processing unit of the blockchain node 104 to perform its respective role and handle transactions 152 in accordance with the blockchain node protocol. It will be understood that any actions attributed to a blockchain node 104 herein may be performed by software executing on the processing unit of the respective computing device. The node software may be implemented in one or more applications at the application layer, or at a lower layer, such as the operating system layer or protocol layer, or any combination thereof.

[0076] Also connected to the network 101 are computing devices 102 of each of a number of participants 103 who act as consuming users. These users may interact with the blockchain network 106 but do not participate in validating transactions or constructing blocks. Some of these users or agents 103 may act as senders and receivers in transactions. Other users may interact with the blockchain 150 without necessarily acting as senders or receivers. For example, some participants may act as storage entities that store a copy of the blockchain 150 (e.g., have obtained a copy of the blockchain from a blockchain node 104).

[0077] Some or all of the participants 103 may be connected as part of a different network, for example, a network superimposed on the blockchain network 106. Users of the blockchain network (often referred to as “clients”) are sometimes said to be part of a system that includes the blockchain network 106, but these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each participant 103 interacts with the blockchain network 106 and thereby utilizes the blockchain 150 by connecting to (i.e., communicating with) a blockchain node 106. Two participants 103 and their respective devices 102 are shown for illustrative purposes: a first participant 103a and its respective computer device 102a, and a second participant 103b and its respective computer device 102b. It will be understood that more such participants 103 and their respective computer devices 102 may be present and participate in the system 100 but are not shown for convenience. Each participant 103 may be an individual or an organization. By way of example only, the first party 103a is referred to herein as Alice and the second party 103b is referred to as Bob, but it will be understood that this is not intended to be limiting and that any reference herein to Alice or Bob may be replaced with "first party" and "second party," respectively.

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

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

[0080] The client application 105 comprises at least a "wallet" functionality. It has two main functions. One of these is to enable each party 103 to create, authorize (e.g., sign), and submit transactions 152 to one or more Bitcoin nodes 104 so that the transactions 152 are disseminated throughout the network of blockchain nodes 104 and thereby included in the blockchain 150. The other is to report to each party the amount of digital assets that it currently owns. In an output-based system, the second function comprises reconciling the amounts defined in the outputs of various transactions 152 scattered throughout the blockchain 150 that belong to that party.

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

[0082] An instance of client application or software 105 on each computing device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This enables the wallet functionality of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain nodes 104 to inquire about any transactions of which the respective party 103 is the recipient (or, in embodiments, to actually investigate other party transactions in the blockchain 150, since the blockchain 150 is a public institution that lends credibility to transactions in part by being publicly visible). The wallet functionality of each computing device 102 is configured to organize and send transactions 152 according to a transaction protocol. As discussed above, each blockchain node 104 executes software configured to validate transactions 152 according to the blockchain node protocol and forward transactions 152 to disseminate them throughout the blockchain network 106. The transaction protocol and the node protocol correspond to each other; a given transaction protocol is attached to a given node protocol, and together they implement 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 nodes 104 in the network 106.

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

[0084] Provided that the newly received transaction 152j passes the tests to be considered valid (i.e., for it to be "validated"), every blockchain node 104 that receives the transaction 152j adds the newly validated transaction 152 to the ordered set of transactions 154 maintained at that blockchain node 104. Additionally, every blockchain node 104 that receives the transaction 152j propagates the validated transaction 152 onward to one or more other blockchain nodes 104 in the network 106. Because each blockchain node 104 applies the same protocol, this means that, assuming the transaction 152j is valid, the transaction 152j will soon be propagated throughout the network 106.

[0085] Once admitted to the ordered pool of outstanding transactions 154 maintained at a given blockchain node 104, that blockchain node 104 begins competing to solve a proof-of-work puzzle for the latest version of each pool 154 that includes the new transaction 152. (Recall that other blockchain nodes 104 may be attempting to solve the puzzle based on different pools of transactions 154, but whoever solves first defines the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 solves the puzzle for the portion of the ordered pool 154 that includes Alice's transaction 152j.) Once the proof-of-work has been done for the pool 154 that includes the new transaction 152j, it becomes immutably part of one of the blocks 151 in the blockchain 150. Because each transaction 152 includes a pointer to an earlier transaction, the order of the transactions is also immutably recorded.

[0086] Because different blockchain nodes 104 initially receive different instances of a given transaction, they may have conflicting views about which instance is "valid" before an 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 an instance as valid and discovers that a second instance has been recorded in the blockchain 150, it must accept it and discard (i.e., treat as fraudulent) the instance it originally accepted (i.e., the one not published in block 151).

[0087] An alternative type of transaction protocol operated by some blockchain networks may be called an "account-based" protocol, as part of an account-based transaction model. In the account-based case, each transaction defines the amount to be transferred by referencing the absolute account balance, rather than by referencing the UTXO of a preceding transaction in the sequence of past transactions. The current state of every account is stored separately on the blockchain and constantly updated by the network's nodes. In such a system, transactions are ordered using the account's transaction execution record (also called "position"). This value is signed by the sender as part of the sender's cryptographic signature and hashed as part of the transaction reference calculation. Additionally, an optional data field may be the signed transaction. This data field may point to a previous transaction, for example, if a previous transaction ID is included in this data field.

[0088] UTXO-based model FIG. 2 illustrates an exemplary transaction protocol. This is an example of a UTXO-based protocol. Transactions 152 (abbreviated as "Tx") are the fundamental data structure of a blockchain 150 (each block 151 comprises one or more transactions 152). The following is described with reference to an output-based or "UTXO"-based protocol. However, this is not a limitation on all possible embodiments. Note that while the exemplary UTXO-based protocol is described with reference to Bitcoin, it may equally be implemented on other exemplary blockchain networks.

[0089] In a UTXO-based model, 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 may be used as a source for an input 202 of another new transaction (if the UTXO has not yet been redeemed). A UTXO contains a value specifying an amount of a digital asset, which represents a set number of tokens on the distributed ledger. A UTXO may also contain, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also comprise a header 201, which may include an indication of the sizes of the input fields 202 and output fields 203. The header 201 may also include the transaction's ID. In embodiments, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to node 104.

[0090] Suppose Alice 103a wishes to create transaction 152j that transfers an amount of a target digital asset to Bob 103b. In FIG. 2, Alice's new transaction 152j is labeled "Tx1." It has the amount of digital asset locked to Alice in the output 203 of the previous transaction 152i in the sequence and transfers at least a portion of this to Bob. The previous transaction 152i is labeled "Tx0" in FIG. 2. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily imply that Tx0 is the first transaction in the blockchain 151 or that Tx1 is the immediately following transaction in the pool 154. Tx1 may refer to any previous (i.e., ancestor) transaction that still has unspent outputs 203 locked to Alice.

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

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

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

[0094] So, in the example shown, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A ], which means that Alice's signature Sig P must exist in order for UTXO0 to be redeemed (or, more precisely, for any subsequent transaction attempting to redeem UTXO0 to be valid). A [Checksig P A] is the public key P from Alice's public-private key pair. A The Tx1 input 202 comprises a pointer to Tx1 (e.g., pointed to by transaction ID TxID0, where in an embodiment TxID0 is a hash of the entire transaction Tx0). The Tx1 input 202 comprises an index that identifies UTXO0 within Tx0, in order to identify UTXO0 among all other possible outputs of Tx0. The Tx1 input 202 further comprises an unlock script <Sig P A >, which comprises Alice's cryptographic signature, created by Alice applying her private key from her key pair to a predetermined piece of data (sometimes called a "message" in cryptography). The data (or "message") that needs to be signed by Alice to provide a valid signature may be defined by a lock script, or by a node protocol, or a combination of these.

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

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

[0097] If the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (thus, in the illustrated example, Alice's signature is provided and authenticated in Tx1), the blockchain node 104 considers Tx1 valid. This means that the blockchain node 104 adds Tx1 to its ordered pool of outstanding transactions 154. The blockchain node 104 also forwards transaction Tx1 to one or more other blockchain nodes 104 in the network 106, so that transaction Tx1 is disseminated throughout the network 106. Once Tx1 is validated and included in the blockchain 150, this defines the UTXO0 from Tx0 as having been spent. Note that Tx1 can only be valid if it consumes an unspent transaction output 203. If Tx1 attempts to consume an output that has already been consumed by another transaction 152, Tx1 is fraudulent, even if all other conditions are met. Therefore, blockchain node 104 also needs to verify whether the referenced UTXO in the preceding transaction Tx0 has already been spent (i.e., whether it already formed a valid input to another valid transaction). This is one reason why imposing a prescribed ordering on transactions 152 is important for blockchain 150. In practice, a given blockchain node 104 may maintain a separate database that marks which UTXOs 203 a transaction 152 has spent, but what ultimately defines whether a UTXO is spent is whether it already forms a valid input to another valid transaction in blockchain 150.

[0098] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount indicated by all its inputs 202, this is another ground of invalidity in most transaction models. Therefore, such a transaction is not propagated or included in block 151.

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

[0100] In practice, Alice is typically also required to include a fee for Bitcoin nodes 104 that successfully include her transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by blockchain nodes 104 and therefore may not be propagated or included in the blockchain 150, even if technically valid (the node protocol does not force blockchain nodes 104 to accept a transaction 152 if they do not want to). In some protocols, the transaction fee does not require a unique, separate output 203 (i.e., does not require a separate UTXO). Instead, any difference between the total amount pointed to by inputs 202 of a given transaction 152 and the total amount specified in outputs 203 is automatically given to the blockchain node 104 that issues the transaction. For example, suppose a pointer to UTXO0 is the only input to Tx1, and Tx1 has only one output, UTXO1. If the amount of digital assets specified in UTXO0 is greater than the amount specified in UTXO1, the difference may be allocated by the node 104 that wins the proof-of-work competition to create the block containing UTXO1. However, it is not necessarily excluded that a transaction fee may alternatively or additionally be explicitly specified in a unique one of the UTXOs 203 of transaction 152.

[0101] Alice and Bob's digital assets consist of the UTXOs locked to them in any transaction 152 anywhere in the blockchain 150. Thus, typically, a given party 103's assets are scattered across the UTXOs of various transactions 152 throughout the blockchain 150. There is no single number stored anywhere in the blockchain 150 that defines a given party's 103's entire balance. It is the role of the wallet function of the client application 105 to reconcile together the values of all the various UTXOs locked to each party that have not yet been spent in another forward transaction. The wallet function can do this by querying a copy of the blockchain 150, such as that stored in one of the Bitcoin nodes 104.

[0102] Note that script code is often represented generally (i.e., without using a strict language). For example, operation codes (opcodes) may be used to represent specific functions. "OP_..." refers to a specific opcode in the Script language. As an example, OP_RETURN is an opcode in the Script language that, when preceded by OP_FALSE at the beginning of the lock script, creates a non-consumable output of the transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may comprise a document that is desired to be stored in the blockchain.

[0103] Typically, the input for a transaction is a public key P AIn embodiments, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs specific data. In some embodiments, for a given transaction, the signature signs some of the transaction inputs and some or all of the transaction outputs. The specific portions of the outputs that the digital signature signs depend on the SIGHASH flag. The SIGHASH flag is typically a four-byte code included at the end of the signature that selects which outputs are signed (and is therefore fixed at the time of signing).

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

[0105] Side Channels As shown in FIG. 1, the client applications on each of Alice's computing device 102a and Bob's computing device 102b may include additional communication capabilities. This additional functionality allows Alice 103a to establish a separate side channel 107 with Bob 103b (either at the instigation of a related party or a third party). The side channel 107 allows for the exchange of data separately from the blockchain network. Such communication may be referred to as "off-chain" communication. For example, this may be used to exchange transactions 152 without the transactions 152 being registered on the blockchain network 106 or entering the chain 150 until either Alice or Bob chooses to broadcast the transaction 152 between Alice and Bob to the network 106. Sharing transactions in this manner may be referred to as sharing a "transaction template." The transaction template may lack one or more inputs and / or outputs required to form a complete transaction. Alternatively or additionally, the side channel 107 may be used to exchange any other transaction-related data, such as keys, negotiated amounts or terms, data content, etc.

[0106] The side channel 107 may be established over the same packet-switched network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established over a different network, such as a mobile cellular network, or a local area network, such as a local wireless network, or even a direct wired or wireless link between Alice's device 102a and Bob's device 102b. In general, the side channel 107 referred to anywhere herein may comprise any one or more links over one or more networking technologies or communication media for exchanging data “off-chain,” i.e., separately from the blockchain network 106. When more than one link is used, the bundle or collection of off-chain links may collectively be referred to as the side channel 107. Thus, it should be noted that when Alice and Bob are said to exchange certain information or data, etc., over the side channel 107, this does not necessarily imply that all such data must be transmitted over exactly the same links, or even the same type of network.

[0107] Client Software 3A shows an example implementation of a client application 105 for implementing embodiments of the presently disclosed techniques. The client application 105 comprises a transaction engine 401 and a user interface (UI) layer 402. The transaction engine 401 is configured to implement the underlying transaction-related functionality of the client 105, such as orchestrating transactions 152, receiving and / or sending transactions and / or other data via side channels 301, and / or sending transactions to one or more nodes 104 for dissemination through the blockchain network 106, in accordance with the techniques discussed above and as will be discussed in more detail shortly. In accordance with embodiments disclosed herein, the transaction engine 401 of each client 105 comprises functionality 403.

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

[0109] Note: While various functions herein may be described as being integrated into the same client application 105, this is not necessarily limiting; instead, they may be implemented as a suite of two or more separate applications, e.g., one plugging into the other or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 401 may be implemented in a separate application from the UI layer 402, or the functionality of a given module, such as the transaction engine 401, may be split among more than one application. It is not excluded that some or all of the described functionality may be implemented, for example, in the operating system layer. Where reference is made anywhere in this specification to a single or given application 105, etc., it will be understood that this is by way of example only, and more generally, the described functionality may be implemented in any form of software.

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

[0111] 3B illustrates UI 500 from Alice's perspective. UI 500 may comprise one or more UI elements 501, 502, 503 that are rendered as separate UI elements via user output means.

[0112] For example, the UI elements may comprise one or more user-selectable elements 501, which may be different on-screen buttons, or different options in a menu, etc. User input means are adapted to allow the user 103 (in this case Alice 103a) to select or otherwise act on one of the options, such as by clicking or touching the UI element on the screen or by speaking the name of the desired option (note that the term "manual" as used herein is intended only to contrast with automatic and is not necessarily limited to the use of hands). This option allows the user (Alice) to...

[0113] Alternatively or additionally, the UI element may include one or more data entry fields 502 through which a user can... These data entry fields may be rendered via a user output means, e.g., on a screen, and data may be entered into the fields via a user input means, e.g., a keyboard or touch screen. Alternatively, data may be received orally, e.g., based on speech recognition.

[0114] Alternatively or additionally, the UI element may comprise one or more output information elements 503 to output information to the user, which may for example be rendered on a screen or audibly.

[0115] It will be understood that the specific means of rendering the various UI elements, selecting options, and inputting data are not essential. The functionality of these UI elements will be discussed in more detail shortly. It will also be understood that the UI 500 shown in Figure 3 is only a schematic mockup and may in fact comprise one or more additional UI elements that are not shown for the sake of brevity.

[0116] Node Software FIG. 4 illustrates an example of node software 450 running on each blockchain node 104 of the network 106 in the example UTXO-based model or output-based model. Note that another entity may run the node software 450 without being classified as a node 104 on the network 106, i.e., without performing the actions required of a node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a script engine 452, a stack 453, an application-level decision engine 454, and a set of one or more blockchain-related function modules 455. Each node 104 may run node software including, but not limited to, all three of the following: an agreement module 455C (e.g., proof-of-work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 451 is typically configured to recognize different fields of a transaction 152 and process them according to the node protocol. Another preceding transaction 152i (Tx m-1 ) output (e.g., UTXO) j ) is received, the protocol engine 451 j and passes it to the script engine 452. The protocol engine 451 also j Based on the pointer at the input of Tx i Identify and extract Tx i may be published on the blockchain 150, in which case the protocol engine may generate Tx from a copy of block 151 of the blockchain 150 stored on the node 104. i Alternatively, Tx i may not yet be published on the blockchain 150. In that case, the protocol engine 451 selects Tx from the ordered set of unpublished transactions 154 maintained by the node 104. i In any case, the script engine 451 may extract Txi locates the lock script in the referenced output of and passes it to the script engine 452.

[0117] Therefore, the script engine 452 executes the Tx i Lock script and Tx j , and the corresponding inputs of the transaction. For example, transactions labeled Tx0 and Tx1 are shown in FIG. 2, but the same can apply to any pair of transactions. The script engine 452 executes the two scripts together as previously discussed, which includes putting data on and retrieving data from the stack 453 according to the stack-based scripting language being used (e.g., Script).

[0118] By executing the scripts together, script engine 452 determines whether the unlock script satisfies one or more criteria defined in the lock script, i.e., whether the lock script "unlocks" the included output. Script engine 452 returns the result of this determination to protocol engine 451. If script engine 452 determines that the unlock script satisfies one or more criteria specified in the corresponding lock script, script engine 452 returns the result "true." Otherwise, it returns the result "false."

[0119] In the output-based model, a "true" result from the script engine 452 is one of the conditions for the validity of the transaction. There are usually also one or more further protocol-level conditions evaluated by the protocol engine 451 that must also be satisfied, such as Tx j the total value of the Digital Assets specified in the output of Tx does not exceed the total value indicated by its input; jThe protocol engine 451 evaluates the result from the script engine 452 along with one or more protocol-level conditions, and executes transaction Tx only if they are all true. j The protocol engine 451 outputs an indication of whether the transaction is valid to the application level decision engine 454. Tx j is actually validated, the decision engine 454 will j , which may choose to control both the consensus module 455C and the propagation module 455P to perform their respective blockchain-related functions with respect to the nodes' respective ordered sets of transactions 154 for incorporation into block 151. j and a consensus module 455C that adds Tx to another blockchain node 104 in the network 106. j and a propagation module 455P that forwards the transaction. Optionally, in embodiments, the application-level decision engine 454 may apply one or more additional conditions before triggering either or both of these functions. For example, the decision engine may choose to publish a transaction only under the condition that the transaction is legitimate and leaves sufficient transaction fees.

[0120] It should also be noted that the terms "true" and "false" herein are not necessarily limited to returning a result expressed solely in the form of a single binary digit (bit), although that is certainly one possible implementation. More generally, "true" can refer to any state that indicates a successful or positive outcome, and "false" can refer to any state that indicates a failed or negative outcome. For example, in an account-based model, a "true" outcome may be indicated by a combination of an implicit protocol-level validation of a signature and an additional positive output of a smart contract (if both individual outcomes are true, the overall result is considered to indicate true).

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

[0122] For example, some embodiments above are described with respect to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104. However, it will be understood that the Bitcoin blockchain 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 no way limited to the Bitcoin blockchain. More generally, any references above to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin nodes 104 may be replaced with references to the blockchain network 106, the blockchain 150, and the blockchain nodes 104, respectively. The blockchains, blockchain networks, and / or blockchain nodes may share some or all of the described characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin nodes 104, as described above.

[0123] In a preferred embodiment of the present invention, the blockchain network 106 is the Bitcoin network, and the Bitcoin nodes 104 perform at least all of the described functions of creating, publishing, disseminating, and storing blocks 151 in the blockchain 150. It is not excluded that there may be other network entities (or network elements) that perform only one or some, but not all, of these functions. That is, a network entity may perform the functions of disseminating and / or storing blocks without creating and publishing them (recall that these entities are not considered to be nodes of the preferred Bitcoin network 106).

[0124] In other embodiments of the present invention, the blockchain network 106 may not be the Bitcoin network. In these embodiments, it is not excluded that a node may perform at least one or some, but not all, of the functions of creating, publishing, disseminating, and storing blocks 151 of the blockchain 150. For example, on these other blockchain networks, 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 disseminate those blocks 151 to other nodes.

[0125] Even more generally, any reference above to the term "Bitcoin node" 104 may be replaced with the term "network entity" or "network element," with such entity / element configured to perform some or all of the roles of creating, publishing, disseminating, and storing blocks. The functionality of such network entity / element may be implemented in hardware in the same manner as described above with reference to blockchain node 104.

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

[0127] Enumerated statements The present disclosure may be described as providing a computer-implemented method and / or computer program embodied on a computer-readable storage and configured to perform any of the methods of the embodiments claimed or disclosed herein when executed on one or more processors. One or more of the method steps disclosed herein may be performed by a computer-based resource comprising at least one processor. Embodiments of the present disclosure may comprise a method and a computer-based system operable to perform the method.

[0128] The term "mapping" may be used interchangeably with the terms "overlay" or "resource indexing." The systems disclosed herein may be referred to as "database control systems" and / or "database authorization systems," "database overlay systems" and / or "database security systems," and / or "database indexing systems" and / or "database query systems."

[0129] The corresponding methods may be called "database security / control / authorization / overlay / indexing / query methods."

[0130] According to some forms of expression, the embodiments disclosed herein include: Use of a [public or private] blockchain to provide an overlay authority or resource via a database, preferably where the overlay authority or resource implements, facilitates or enables indexing of one or more records of the database; and / or Verifying or implementing at least one authorization control for the database (which may be referred to as "at least one authorization condition"); and / or Enabling or using a blockchain consensus mechanism to act as an authorization mechanism for the database, preferably the consensus mechanism being the only authorization mechanism for granting / denying access to records in the database; and / or Using multiple (mining) nodes on a blockchain network to implement, perform and / or enforce at least one authorization control for a traditional database through the execution by the multiple nodes of tasks and functions specified as part of the blockchain's protocol, where "authorization control" may be used interchangeably with "access control" and / or "user privileges" and / or "user verification"; Providing an overlay / indexing / mapping authority and / or resources to associate records of or within database records with transactions of or within a blockchain; and / or Providing resources that are a mix or collection of [traditional] databases and blockchains; and / or A search or indexing process for a database, preferably a search or indexing process that includes using a Merkle tree or Merkle path to validate that a given transaction is traceable to one or more genesis transactions that are associated with one or more database records, wherein preferably each output in the transaction is associated with a record in the database, and the association of records with outputs is preferably stored in an overlay component of the system. may be described as including a method for performing or facilitating any one or more of the above.

[0131] In one, some, or all embodiments, access to one or more records in the database may be granted or denied by a consensus mechanism for the blockchain based on successful or unsuccessful validation of the consuming transaction. The record may be associated with at least one output of a blockchain transaction that is consumed by an input of the consuming transaction.

[0132] Additionally or alternatively, it may: It may be described as providing a method for using or maintaining a mapping to associate at least one record in / of a database with at least one (respective) (unspent) transaction on a blockchain. Preferably, - the overlay is provided / stored separately from the database, and / or - The overlay is stored off-blockchain, but in other embodiments may be stored on-chain; and / or - access to the at least one record is controlled by or via a consensus mechanism associated with the blockchain, preferably access to the at least one record is granted / denied based on the success / failure of consumption of the transaction output after processing of the (further / consuming) blockchain transaction by the consensus mechanism of the blockchain; The processing may comprise further validation of the transaction by a node operating or implementing a consensus mechanism; and / or - The association (or "association") of at least one record with at least one output provides or facilitates a blockchain-based or blockchain-implemented overlay for the database.

[0133] In additional or alternative form, the present disclosure provides: using a (public) cryptographic key and / or a digital signature generated using the cryptographic key to consume an output in a first transaction on the blockchain, the key and / or signature being provided in an unlocking script for a further transaction on the blockchain; granting access to at least one database record upon consumption of the output; and preferably a method comprising: At least one database record is associated with the output and / or the first transaction in the stored association. The method may further include updating the association to associate at least one database record with the further transaction and / or output in the further transaction.

[0134] In additional or alternative form, the present disclosure provides: Associating at least one record in a database with an unspent output of the first blockchain transaction, the unspent output comprising at least one authorization condition for verifying whether at least one party is authorized to access the at least one database record. The present invention may provide a computer-implemented method comprising:

[0135] The database may be an off-chain (traditional) database or may be implemented in conjunction with a blockchain ledger.

[0136] The method is: i) granting access to the record upon successful validation by the blockchain network's consensus mechanism of a further blockchain transaction whose input satisfies the authorization condition of the unspent output; and / or ii) interpreting successful validation of the further blockchain transaction by the blockchain network's consensus mechanism as successful validation of the at least one authorized party and granting access to the at least one record by the authorized user; and The further transaction comprises an input and / or unlock script adapted to consume the output of the first transaction; and / or Successful validation of further blockchain transactions by the consensus mechanism may result in unspent outputs being spent and / or further transactions being written to the blockchain.

[0137] In feature i), granting access to the record may be based on or dependent on the successful validation of the further blockchain transaction by the blockchain network's consensus mechanism. In other words, the blockchain consensus mechanism may provide the (preferably only) validation / authorization mechanism for the database. If the network nodes forming the consensus mechanism validate the transaction, the user's access request is granted; otherwise, it is denied.

[0138] The authorized party may be an administrator, an end user, or any other user of the database 506 and / or the overlay system 500. The authorized party may be a human user or a computing resource. The method may further include storing the association (record entry) in the storage resource 503.

[0139] In an additional or alternative expression, the overlay provides a mechanism for indexing one or more database records (in the database), with each record associated in the overlay with a respective index. The indexes may be blockchain-based or implemented on a blockchain. Preferably, each index is associated with, is a representation of, or is indicative of, an unspent output in one or more blockchain transactions. The one or more indexes may comprise an identifier, which may comprise an identifier of an unspent output (UTXO) and / or a blockchain transaction. The unspent output may be provided as an element in a collection 154 of unspent transaction outputs associated with the blockchain (e.g., a Bitcoin mempool).

[0140] In additional or alternative definitions, the present disclosure provides: associating a record in a database with an output of a blockchain transaction, the output comprising a lock script that specifies at least one cryptographic key that must be provided / used to consume the output; receiving a request to access the at least one record and generating a further blockchain transaction in response to the request, the transaction comprising an unlock script that provides / uses the at least one cryptographic key; submitting the further transaction to one or more computer-based resources for validation in accordance with a protocol associated with the blockchain; and viewing the request as authorized if verification of the further transaction by one or more computer-based resources is successful, or viewing the request as unauthorized if verification is not successful. The present invention may be described as providing a method comprising one or more of:

[0141] Preferably, the validation is performed by one or more computer-based resources, which may be (mining) nodes on or within a blockchain network, the nodes adapted to implement the protocol and / or consensus mechanism associated with the blockchain according to which transactions are generated.

[0142] An overlay may comprise a portion of an overall system that is adapted to and operable to interact with a blockchain, a blockchain network, a database, and / or a DBMS.

[0143] In additional or alternative definitions, the present disclosure provides: Providing, generating, or using a mapping comprising one or more entries relating to, indicating, or representing a record in the database. wherein the one or more entries comprise an association of a record of a blockchain transaction with an output.

[0144] Preferably, i) the mapping acts as or provides a blockchain-related overlay on the database; ii) The association and / or one or more entries comprise machine-readable code for associating the record with an output of a blockchain transaction, preferably where a) the transaction has been written to the blockchain and / or b) the output is unspent.

[0145] Any embodiment described herein may comprise the following steps: Generating at least one blockchain transaction with multiple outputs, each output representing or associated with at least one record, or at least one group of records, or all records in a database, where the at least one transaction may be referred to as a "genesis transaction" or "root transaction" for the overlay disclosed herein. Consuming an output associated with a record (or group of records), where consumption of the output can be interpreted by a system implementing the overlay as meaning that an event, such as an access operation or other processing event, has occurred with respect to the record associated with the output and / or has been authorized by a blockchain consensus mechanism. Searching for a target (unspent) output in a transaction on a blockchain ledger, the target output being associated with a record or group of records in a database, the search may include using a Merkle path or a Merkle proof to find the transaction, the search may include using a Merkle proof or a Merkle path having a root transaction disclosed herein at the root of the Merkle path, for example, the search may include an SPV (SPV-style or SPV-like) search that does not require downloading the entire blockchain. It may include one, some, or all of the following:

[0146] The present disclosure may also provide a computer-implemented system adapted and operable to perform the method of any embodiment disclosed herein. The system comprises: a blockchain formed in accordance with the protocol; and / or a network of nodes adapted to implement a consensus mechanism specified and / or required by the protocol; and / or databases, and / or Digital wallets, and / or DBMS related to databases The device may include an overlay component operable to interact with the

[0147] The system may comprise one or more of at least one digital (cryptocurrency) wallet, an overlay component substantially as disclosed herein, a transaction log substantially as disclosed herein, a data storage component for storing entries for database records, hardware and / or software adapted to facilitate the performance of any function or method step disclosed herein.

[0148] The overlay component is generating blockchain transactions formed in accordance with or in compliance with the protocol; communication with databases and / or DBMS, Submitting transactions to the network for validation and / or mining; Finding the target transaction on the blockchain and / or the outputs provided in the target transaction The device may be operable to perform one, some, or all of the following:

[0149] Any or all of the following listed clauses may be used in conjunction with the wording and definitions given above. The following clauses should not be construed as limiting or exclusive with respect to the scope of protection that may be claimed for embodiments of the present disclosure.

[0150] Enumerated Clauses 1: Article 1. A computer-implemented method comprising associating at least one database record with a blockchain transaction (Tx), the blockchain transaction comprising an authorization mechanism for specifying and / or verifying at least one authorized party (AP) that is authorized to process the at least one database record. The processes may include "receiving," "storing," "reading," "modifying," and / or "deleting."

[0151] "Access" may include a read, copy, delete, or write operation, or any other operation or process, that may be performed on at least one recording.

[0152] The term "authorization mechanism" may alternatively be used with "at least one authorization condition." The term "characteristic" may be used instead of "mechanism."

[0153] Clause 2. The method of clause 1, wherein the authorization mechanism comprises a script and / or at least one cryptographic key associated with or controlled by at least one authorized party.

[0154] Article 3. i) the authorization mechanism is operable to use a consensus mechanism related to the blockchain to validate access operation requests; and / or ii) the script includes or implements control operations that enable or facilitate selective access of the at least one database record by one or more of the at least one authorized party; Preferably, the method of clause 1 or 2, wherein the control operations may comprise selection operations such as IF or CASE, and / or Boolean operators such as OR, AND, XOR, or NOT.

[0155] Article 4. 10. The method of any preceding clause, comprising repeating the associating step to provide multiple associations, each associating step associating at least one database record with the blockchain transaction.

[0156] Article 5. i) the mapping is stored on the blockchain or in an off-chain resource; and / or ii) The method of any preceding clause, wherein the association comprises a database record identifier (REC ID) and / or a blockchain transaction identifier (TxID) and / or a blockchain transaction output.

[0157] Article 6. providing an event record that implements, enables, or facilitates the functionality of a database transaction log, preferably comprising: i) the event record comprises a list of all or some of the blockchain transactions that have previously been associated with the record in the database; and / or ii) A method according to any preceding clause, wherein the event records are stored on or off the blockchain.

[0158] Since individual blockchain transactions can provide historical information, i.e., a transaction log of a database record, a master index of all blockchain transactions representing records in the database provides a complete transaction log of the entire database.

[0159] Article 7. i) processing at least one database record includes at least one of reading from the database record, deleting the database record, modifying the database record, or writing to the database record; and / or ii) each database record relates to, stores, and / or represents at least a portion of data, and at least a portion of the data is Stored on or off the blockchain, or directed to or referenced from a blockchain transaction; and / or iii) The method of any preceding clause, wherein the database is a graph database, a relational database, or an SQL database.

[0160] Article 8. Blockchain transactions: i) Data relating to or associated with a database record; ii) a pointer to, reference to, or identifier of a database record or its storage location; iii) Data relating to one or more further database records associated with the database record; The method of any preceding clause, comprising one or more of:

[0161] Article 9. At least one authorization condition is provided to facilitate requests or attempts to unlock / satisfy / redeem a locking script associated with an unspent output (UTXO) of a blockchain transaction; i) UTXOs are associated with records and / or parties in an index or overlay; ii) UTXOs can only be unlocked / satisfied / redeemable if the transaction is successfully validated by the blockchain network's consensus mechanism; iii) unlocking / satisfying / redeeming the lock script includes providing at least one required encryption key; iv) Unlocking / satisfying / redeeming the lock script results in updates or changes being made in the Master Index; v) unlocking / satisfying / redeeming the locking script results in the UTXO being spent to the address specified in the input of a further blockchain transaction; vi) The method of any preceding clause, wherein updating the mapping associates a further blockchain transaction with the database record.

[0162] Any incorporation by reference of the above documents is limited so that no subject matter inconsistent with the explicit disclosure provided herein is incorporated. Any incorporation by reference of the above documents is further limited so that no claims contained in those documents are incorporated herein by reference. Any incorporation by reference of the above documents is still further limited so that any definitions provided in those documents are not incorporated herein by reference unless expressly included herein. In the event of inconsistent usage between this document and those documents so incorporated by reference, the usage in the incorporated references should be considered as supporting the usage in this document, with the usage in this document taking precedence over any irreconcilable inconsistencies. [Explanation of symbols]

[0163] 101 Internet, packet-switched networks 102 Computer terminals and equipment 103 users 104 blockchain nodes 105 Client Applications 106 P2P networks 107 Side Channel 150 Blockchain 151 blocks 152 transactions 153 Genesis Block 154 Pool 155 Block Pointer 201 Header 202 Input 203 Output 301 Side Channel 401 Transaction Engine 402 UI Layer 451 Protocol Engine 452 Script Engine 454 Application Level Decision Engine 455 Blockchain-related functional modules 500 UI 501 UI Elements, User Selectable Elements, User Interface 502 UI elements, cryptocurrency wallet 503 UI Elements, Information Elements, and Overlay Components 504 Transaction Log 505 records 506 Database

Claims

1. The record (505) in the database (506) is then transferred to the first blockchain transaction (152 i ) with unspent output (203), said unspent output including at least one authorization condition for verifying whether at least one party is authorized to access said database record (505); a further blockchain transaction (152) comprising an input (202) made to satisfy the at least one authorization condition of the unspent output by a consensus mechanism of the blockchain network; j granting access to said record upon successful verification of A computer-implemented method comprising:

2. the at least one authorization condition comprises at least a portion of a script and / or at least one cryptographic key associated with or controlled by the at least one party; and / or the at least one authorization condition specifies and / or verifies the at least one party; and / or 2. The method of claim 1, wherein the at least one authorization condition is a required feature of the script as specified by a protocol associated with the blockchain and / or as implemented by a network of nodes operating in accordance with a protocol associated with the blockchain.

3. i) the at least one authorization condition is operable to use the consensus mechanism associated with the blockchain protocol to validate the request to process the record; and / or ii) the unconsumed output comprises a script that includes or implements control operations that enable or facilitate selective access of the at least one recording by one or more of the at least one participant; 3. The method of claim 1 or 2, wherein the control operations may preferably comprise selection operations such as IF or CASE and / or Boolean operators such as OR, AND, XOR or NOT.

4. 4. The method of claim 1, further comprising repeating the associating step to provide multiple associations, each associating step associating at least one record with an unspent output of the same or another blockchain transaction.

5. associating the record with the unconsumed output, i) stored on said blockchain and / or in an off-chain resource; and / or ii) comprising an identifier of said record and / or an identifier of said blockchain transaction and / or an unspent output of said blockchain transaction; 5. The method of claim 1, wherein the method provides a correspondence.

6. providing an event history that implements, enables or facilitates the functionality of a database transaction log, preferably wherein said event history comprises a list of all or some of the blockchains that have been previously associated with one or more records in said database; and / or 6. The method of claim 1, wherein the event history is stored on the blockchain or off the blockchain.

7. i) accessing the record comprises at least one of processing the record, reading from the record, deleting the record, modifying the record, or writing to the record; and / or ii) the record relates to, stores, and / or represents at least a portion of data, and at least a portion of the data is stored on or off the blockchain, or directed to or referenced by said blockchain transaction; and / or iii) The method of any one of claims 1 to 6, wherein the database is a graph database, a relational database or an SQL database and / or comprises a database management system (DBMS).

8. The blockchain transaction is: iv) data relating to or associated with said record; v) a pointer to, reference to, or identifier for said record or its storage location; vi) data relating to one or more further records associated with said record; 8. The method of claim 1, comprising one or more of:

9. the at least one authorization condition is adapted to facilitate a request or attempt to unlock / satisfy / redeem a locking script associated with an unspent output (UTXO) of the blockchain transaction; vii) the UTXO is associated with the record; vii) the UTXO can be unlocked / satisfied / redeemable only if the blockchain transaction is successfully validated by the consensus mechanism of the blockchain network; ix) unlocking / satisfying / redeeming said lock script includes providing at least one required encryption key; x) unlocking / satisfying / redeeming said lock script causes updates or changes to be made in the index or overlay; 10. The method of claim 1, wherein unlocking / satisfying / redeeming the locking script results in the unspent output being spent to an address specified in an input of the further blockchain transaction.

10. generating at least one blockchain transaction comprising at least one output representing or associated with at least one record, at least one group of records, or all records in the database; searching for a target output for a target transaction on a blockchain ledger, the target output being associated with a record or group of records in a database that has the at least one blockchain transaction in its on-chain history; Including, A computer-implemented method, wherein the searching includes using a Merkle path or a Merkle proof to find the target transaction.

11. 11. A computer-implemented system adapted to implement an overlay configured according to one or more of claims 1 to 10.

12. a blockchain formed in accordance with the protocol; and / or a network of nodes adapted to implement the consensus mechanisms specified and / or required by said protocol; and / or databases, and / or Digital wallets (502a, 502b, 502c), and / or DBMS related to said database 1. A computer-implemented system comprising: a blockchain-implemented database overlay component operable to communicate with

13. the database overlay component comprises: generating blockchain transactions formed in accordance with or pursuant to said protocol; communication with said database and / or DBMS; generating a cryptocurrency address; submitting the transaction to the network for validation and / or mining; Searching for a target transaction on the blockchain and / or an output provided in the target transaction. The system of claim 12 may be operable to perform one, some, or all of the following:

14. A computer device comprising: a memory comprising one or more memory units; a processing device comprising one or more processing units; 11. A computing device comprising: a processor; a memory for storing code adapted to execute on the processor; and a processor configured to execute the method of claim 1.

15. A computer program embodied on a computer readable storage and configured to, when executed on one or more processors, perform the method of any one of claims 1 to 10.

Images