Database coverage, verification and indexing system implemented by block chain

Abstract

The embodiment of the invention provides a database covering and indexing mechanism implemented by a block chain. In one embodiment, records in a database are associated with respective unconsumed outputs in one or more transactions on a blockchain by overlay. Each output includes a lock script that specifies which keys can be used to consume the output to other transactions. When a user wishes to access a given record in the database, the other (expending) transactions are generated and sent to a blockchain network. The other transactions include an unlock script that provides one or more keys required to meet the conditions of the lock script, otherwise a consensus mechanism of the blockchain will not allow expenditure of the output and access to the record will be denied. However, if a requirement is met, the output is consumed, and an access request is considered to be authorized. In this way, the consensus mechanism provides an improved authority control and user authorization scheme for a database. When the output is consumed by the other transactions, the overlay is updated to associate the record with the consumed transaction. Transaction logs can also be provided to quickly and efficiently regenerate the database when needed.

Description

Technical Field

[0001] Embodiments of the present disclosure provide mechanisms for improving data storage, retrieval, search, and re-indexing. Specifically, a blockchain is used to implement a database overlay that maps records in a database to transactions in a ledger, thereby providing a flexible but efficient indexing scheme. Advantageously, a consensus mechanism specified by the blockchain's protocol and implemented by the blockchain network can be used to implement a licensing facility, where access to database records is allowed only when the consensus mechanism is met. Therefore, the present disclosure is particularly suitable for use with database technology and data storage / access, and is also suitable for providing security, control, and authorization schemes therefor.

[0002] Technical Background—Blockchain

[0003] Embodiments of the present disclosure may be implemented for any suitable blockchain and its associated networks and protocols. A blockchain refers to a distributed data structure in which a copy of the blockchain is maintained at each of a plurality of nodes in a distributed peer-to-peer (P2P) network (hereinafter referred to as a "blockchain network") and the copy is widely disclosed. A blockchain includes a series of data blocks, each of which includes one or more transactions. In addition to the so-called "coinbase transaction", each transaction points to a previous transaction in a sequence, which may span one or more blocks and go back to one or more coinbase transactions. The coinbase transaction will be discussed further below. Transactions submitted to the blockchain network are included in new blocks. The process of creating a new block is generally referred to as "mining", which involves each of a plurality of nodes competing to perform "proof of work", i.e., solving cryptographic puzzles based on a set of defined ordered and verified valid pending transactions waiting to be included in a new block of the blockchain. It should be noted that the blockchain can be pruned at some nodes, and the publication of blocks can be achieved by publishing only block headers.

[0004] Transactions in a blockchain can be used for one or more of the following purposes: transferring digital assets (i.e., a certain number of digital tokens); sorting a set of entries in a virtualized ledger or registry; receiving and processing time-stamped entries; and / or sorting index pointers by time. Blockchains can also be used to implement hierarchical additional functions on blockchains. For example, a blockchain protocol may allow additional user data or data indexes to be stored in a transaction. There is no pre-specified limit on the maximum data capacity that can be stored in a single transaction, so increasingly complex data can be incorporated. For example, this can be used to store electronic documents, audio, or video data in a blockchain.

[0005] The nodes of the blockchain network (commonly referred to as "miners") perform a distributed transaction registration and verification process, which will be described in more detail later. In summary, in this process, nodes verify transactions and insert them into block templates, which attempt to identify a valid proof-of-work solution for the block template. Once a valid solution is found, the new block is propagated to other nodes of the network, so that each node can record the new block on the blockchain. In order to record a transaction in the blockchain, a user (e.g., a blockchain client application) sends the transaction to one of the nodes in the network for propagation. The nodes receiving the transaction can compete to find a proof-of-work solution that incorporates the verified valid transaction into the new block. Each node is configured to execute the same node protocol, which will include one or more conditions for confirming that the transaction is valid. Invalid transactions will not be propagated or incorporated into the block. Assuming that the transaction has been verified to be valid and thus accepted on the blockchain, the transaction (including any user data) will therefore be registered and indexed as an immutable public record on each node in the blockchain network.

[0006] The node that successfully solves the proof-of-work puzzle to create the latest block is usually rewarded with a new transaction called a "coinbase transaction" that distributes the amount of digital assets, i.e. the number of tokens. The detection and rejection of invalid transactions is performed by the actions of competing nodes, which act as agents of the network and are incentivized to report and prevent improper behavior. The widespread publication of information allows users to continuously audit the performance of nodes. Publishing only block headers allows participants to ensure the continued integrity of the blockchain.

[0007] In the "output-based" model (sometimes referred to as the UTXO-based model), the data structure of a given transaction includes one or more inputs and one or more outputs. Any spendable output includes an element that specifies the amount of a digital asset, which can be derived from the ongoing transaction sequence. Spendable outputs are sometimes called UTXOs ("unspent transaction outputs"). Outputs may also include a locking script that specifies future redemption conditions for the output. A locking script is a predicate that defines the conditions necessary to verify and transfer a digital token or asset. Each input of a transaction (except for a coinbase transaction) includes a pointer (i.e., a reference) to such an output in a previous transaction, and may also include an unlocking script for unlocking the locking script pointing to the output. Thus, consider a pair of transactions, referred to as a first transaction and a second transaction (or "target" transaction). The first transaction includes at least one output that specifies the amount of a digital asset, and includes a locking script that defines one or more conditions for unlocking the output. The second (target) transaction includes at least one input and an unlocking script, the at least one input including a pointer to the output of the first transaction; the unlocking script is used to unlock the output of the first transaction.

[0008] In such a model, when the second (target) transaction is sent to the blockchain network to be propagated and recorded in the blockchain, one of the validity conditions applied at each node will be that the unlocking script satisfies all of the one or more conditions defined in the locking script of the first transaction. Another condition will be that the output of the first transaction has not been redeemed by another earlier valid transaction. Any node that finds the target transaction invalid according to any of these conditions will not propagate the transaction (as a valid transaction, but may register an invalid transaction) nor include the transaction in a new block to be recorded in the blockchain.

[0009] Another transaction model is the account-based model. In this case, each transaction is defined not by reference to the UTXO of the previous transaction in the past transaction sequence, but by reference to the absolute account balance. The current state of all accounts is stored individually by the node in the blockchain and is constantly updated.

[0010] the term

[0011] Although some terms are common in various fields, the relevant technicians in these corresponding fields understand them to have different meanings. In the following, unless otherwise specified, the following terms will be used to represent the following meanings:

[0012] ●Database: hereinafter refers to any “traditional”, non-blockchain-based data collection, such as database technologies known in the fields of computing and information science and technology that may or may not be accessible through a DBMS, including but not limited to document storage, relational databases, file storage systems, data warehouses, array DBMS, unstructured data DB, etc.

[0013] ●Transaction: This term can be used in the field of traditional databases as well as in financial operations. In this article, unless otherwise specified, the term "transaction" refers to blockchain transactions, i.e., data structures formed and compatible with the blockchain protocol;

[0014] ● mapped: this term may be used interchangeably with “linked,” “indexed,” “associated,” “represented by,” and / or “related to”;

[0015] ●Map: can be used interchangeably with “link”, “index”, “related to…”, “reference”, “represent” and / or “associated with…”.

[0016] ● Blockchain: The term “blockchain” is used to cover all forms of computer-based electronic distributed ledgers. These ledgers include, but are not limited to, consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and their variations.

[0017] ● Bitcoin: The term "Bitcoin" is used to cover the original Bitcoin protocol and implementations, as well as any and all protocols derived therefrom or its variants. Although Bitcoin is referred to herein for convenience and illustration purposes only, since Bitcoin is the most widely known, it should be noted that the present invention is not limited to use with the Bitcoin blockchain and associated protocols, and alternative blockchain implementations and their associated protocols / networks fall within the scope of the present invention. In this document, the term "Bitcoin" may be used interchangeably with "blockchain".

[0018] ● Consensus Mechanism: A term known in the field of blockchain technology; according to known definitions, a consensus mechanism includes a protocol that enables the nodes of a distributed blockchain network to reach an agreement on the state of a ledger and sets verification requirements that each blockchain transaction must meet in order to be accepted for inclusion in the ledger. As used herein, the term is used to cover 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" can be used interchangeably with "consensus mechanism." Background Art

[0019] Sometimes, blockchains are 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 provided below, but are not limited to:

[0020] ● Databases have centralized control administrators; in contrast, blockchains are decentralized and have no central control authority. Instead, validation is performed through a consensus mechanism that is written into the blockchain protocol and implemented by nodes (caretakers) on the network;

[0021] ● The control authority sets access rights in the database (system-level and record-level), so that data can only be accessed from the record if authorized by the centralized controller; in contrast, outputs (e.g., UTXO) in blockchain transactions (TX) can only be spent if the requester provides the necessary information to meet the conditions of the locking script; therefore, in the blockchain environment, access rights are specified according to the relevant protocol and implemented through cryptographic control; therefore, blockchain is not specified and implemented by a centralized control authority associated with a specific organization, but rather operates as a decentralized scheme specified by a protocol that the network nodes follow but do not specify;

[0022] ● In a database, records are mutable unless a central controller specifically locks write operations; however, in a blockchain, all transactions are immutable due to the protocol design;

[0023] ● Maintain a separate transaction log for the database to provide a historical record of what actions were performed, when they were performed, and by whom. Transaction logs are critical for regenerating traditional databases in the event of a system failure, for example, to restore the database to a consistent state; in contrast, each blockchain transaction (equivalent to a database of records) stores its own history of who performed what actions on a specific block of data through its inputs and outputs and a timestamp mechanism, and once written to the ledger, this log becomes immutable.

[0024] ● Databases can become corrupted and vulnerable to attack, so they need to be backed up regularly. This requires storage and processing resources. In contrast, blockchains are immutable, so data cannot be corrupted or altered after it is confirmed on the chain, and data integrity is cryptographically ensured and enforced;

[0025] ● Databases are easy to implement and maintain because database technology is well known and widely used; on the other hand, blockchain-based technologies may be more complex to implement and require more specialized expertise and time;

[0026] Databases can offer advantages over blockchains in terms of scalability, depending on the protocol in question.

[0027] ●In a database, data-level operations such as create, search, write, and read can be performed very quickly. However, create and write operations to the blockchain are slowed down by the protocol’s overall validation and consensus mechanisms. Reading / searching for a specific data item in the blockchain 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.

[0028] Therefore, significant technical challenges need to be overcome to find a solution that offers the advantages of two very different data storage technologies, which include contrasting software and hardware architectures, while avoiding or at least mitigating their respective disadvantages. Summary of the invention

[0029] The present disclosure includes a scheme for mapping traditional databases and / or database structures to blockchains. This can provide an overlay that facilitates or enables the storage, access, security, and / or processing of data. An embodiment provides a scheme in which permission control over traditional databases is implemented and / or enforced by nodes on a blockchain network by performing tasks and functions specified by the protocol of the blockchain.

[0030] From one perspective, embodiments leverage the strengths and advantages of both blockchain and traditional databases while eliminating or at least reducing their respective disadvantages as large-scale data storage mechanisms. From another perspective, the present disclosure combines the advantageous aspects of distinct technology platforms and architectures. According to one possible embodiment, a traditional database is mapped to a blockchain such that the mapping enables, provides, or acts as an overlay of a blockchain implementation of the database.

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

[0032] The database may include one, some or all of the components typically associated with a traditional database, including a DBMS, associated storage resources (e.g., hardware and software for storing and retrieving the data), APIs, languages ​​for database manipulation and use, etc. (e.g., see: https: / / en.wikipedia.org / wiki / Database).

[0033] In a preferred embodiment, an overlay is provided that maps at least one record in the database to at least one transaction (Tx) on the blockchain. Specifically, the overlay can map the one or more records to corresponding outputs (UTXO) in the one or more transactions. Therefore, from one perspective, the database record can be represented as an unspent output of a blockchain transaction.

[0034] In a preferred embodiment, the output includes a locking script. In some but not all embodiments, the locking script may also be referred to as a scriptPubKey or PubKey script, and may be part of the code associated with a transaction output and specifies certain conditions that must be met in order for another (other) transaction to consume the output. These conditions may include that the other transaction includes an unlocking script (which may also be referred to as a scriptPubKey or Signature script, according to some embodiments), which provides a signature proof via one or more specified public keys.

[0035] Preferably, when access is requested for a particular record in the database, the other transaction is generated and submitted to the blockchain network. The consensus mechanism associated with the blockchain will verify whether the unlocking script has presented the required signature and public key to the locking script according to traditional functions. If so, 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 only verification and permission mechanism for the database. No pre-verification or post-verification of the user's authorization is required, except for verification by the nodes forming the consensus mechanism.

[0036] This provides significant technical advantages, as the enforcement of traditional database permissions (e.g., privileges and user rights) can be achieved and enforced through existing blockchain consensus mechanisms. This means that not only do processing resources such as hardware, software, and energy need to be transferred from the database owner to the blockchain network, it also means that the permissions can be cryptographically enforced through the blockchain protocol, and an immutable record of who accessed what at what time can be provided on the chain. See https: / / en.wikipedia.org / wiki / Database_security.

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

[0038] In some embodiments, a transaction log may be provided that keeps a record of all events and changes related to the state of the overlay. While this information may be extracted from the blockchain from the relevant transactions associated with the record, a separate transaction log may provide efficiencies in terms of the time, energy, and processing resources required to find and compile the necessary information when needed. Thus, some embodiments may provide advantages in terms of database activity monitoring (DAM) (https: / / en.wikipedia.org / wiki / Database_activity_monitoring) and / or "backup and restore" requirements https: / / en.wikipedia.org / wiki / Backup in the event that the database needs to be rebuilt. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0040] Figure 1A schematic block diagram of a system for implementing a blockchain.

[0041] Figure 2 Some examples of transactions that may be recorded in a blockchain are schematically shown.

[0042] Figure 3A A schematic block diagram of a client application is shown.

[0043] Figure 3B It shows that Figure 3A A schematic mockup of an exemplary user interface represented by a client application.

[0044] Figure 4 A schematic block diagram of some node software for processing transactions is shown.

[0045] Figure 5 is an overview of an embodiment according to one or more embodiments of the present disclosure.

[0046] Figure 6 Shown in more detail Figure 5 Embodiment of the invention.

[0047] Figure 7 A flow chart is provided that illustrates steps that may be taken in accordance with one or more embodiments of the present disclosure.

[0048] Figure 8 Provided Figure 5 An alternative view of an embodiment of the invention illustrates the relationship between database records and their associated transactions with dashed lines. DETAILED DESCRIPTION

[0049] Databases and Data

[0050] In one illustrative implementation, and with particular reference to Figure 5 , Figure 6 and Figure 8 , mapping the contents of the database to the blockchain so that the blockchain acts as an overlay mechanism. This helps improve indexing and re-indexing of the database and its data items, provides improved security and authorization techniques that are advantageously enabled by the traditional features and functions of the blockchain, and enables improved database backup and recovery schemes, among other advantages.

[0051] The data stored in the database may take any form and may be configured for or suitable for any one or more purposes. Although in the examples of the present disclosure the database is a graph-based database, the present disclosure is not limited thereto and may be configured for any alternative form of database model or data storage. However, it is well known that graph databases are particularly suitable for storing and representing many-to-many relationships between data items, such as those used in social media and other application areas that store, manipulate, generate, re-index, and process large numbers of data items that are interconnected through complex relationships and connections. Therefore, embodiments are particularly suitable for use with graph databases, resulting in many potential, powerful applications.

[0052] The term "data item" is used to cover one or more parts of data recorded as an entity in a database. This could be, for example, a single data item (e.g., a file), or it could be multiple data items that are related in some way within a database and therefore can be considered entities even if they are not stored in the same location or on the same device.

[0053] Although the term "node" is often used for data items stored in a graph database, the term "record" will be used to avoid confusion with the "node" 104 in the computing network 106, and because embodiments can be used with other types of database models that include "records" similar to nodes in a graph database. A record may include 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 enables each record to be referenced and accessed as known in the art.

[0054] According to some embodiments, data items may be stored on-chain (i.e., on a blockchain) or off-chain, or a combination thereof. In the illustrative embodiments of the present disclosure, each data item is stored off-chain in a record 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 one or more transactions on a blockchain using any suitable known technology. For example, in a Bitcoin-related blockchain, one or more data items may be provided in a transaction by providing the one or more data items after an OP_RETURN statement in a script; or by including the one or more data items as metadata; or by including a reference, pointer, or other reference that can identify data in or at an off-chain location. Multiple data items may be stored in separate outputs of the same transaction. In other cases, multiple transactions within the same block may include one or more data items, so that data associated with a given record in the database is stored in different locations. Alternatively, multiple transactions may be provided across multiple blocks on a blockchain, each transaction containing at least one data item. There is no restriction or constraint requiring transactions containing data to be located in the same block.

[0055] Overlay Components

[0056] refer to Figure 5 , Figure 6 and Figure 8 , the present disclosure provides an overlay mechanism that maps some or all records in a database with transactions on a blockchain. The overlay ("mapping") associates one or more records in a database with at least one transaction (TX) on a blockchain. Any form of known transactions can be used. In the Bitcoin example of the present disclosure, non-limiting examples may include pay to public key hash (P2PKH), pay to public key (P2PK), pay to multi-signature (P2MS), pay to script hash (P2SH).

[0057] An overlay includes a list of entries, each of which is associated with a record in the database to be mapped to the blockchain. In some implementations, the overlay is stored on-chain in one or more transactions; but in other implementations, the overlay is stored off-chain. The overlay can be stored digitally in any format or form. Figure 5 , Figure 6 and Figure 8 In the illustrative embodiment of , overlays are stored off-chain.

[0058] In some examples, multiple records may be mapped to the same transaction; in other examples, records may be distributed across multiple transactions. Specifically, each record listed in the overlay maps to a corresponding output in the on-chain transaction.

[0059] For each record entry in the overlay, there is (at least) an identifier that associates the record with a specific output 203 in a specific transaction 152i on the blockchain 150. For convenience, this identifier is called an "on-chain index" or simply an "index". The output (UTXO) is not spent and includes a locking script that can only be spent by providing an unlocking script that satisfies the conditions specified in the locking script. As is known in the prior art, the locking script specifies which one or more cryptographic keys must be used to prove the authorization to receive the associated cryptocurrency of the output. The potential recipient provides this proof by including the required public key and signature in the unlocking script of the new transaction 152j. When the new transaction 152j is sent to the blockchain network, the new transaction will be verified by the node. The verification checks the public key provided by the recipient against the key hash provided in the locking script and uses the public key to check the signature. If the script verification returns TRUE, the cryptocurrency will be unlocked and spent to the specified address.

[0060] Therefore, every time an output is spent from one transaction to another through the ledger, the blockchain protocol and the network's traditional consensus mechanism enforces a cryptographic authorization process. Advantageously, embodiments of the present disclosure utilize this inherent authorization feature to facilitate cryptographically enforced authorization of the database, as described below.

[0061] In addition to the record index, one or more entries may also include additional information related to the data item / record. For example, at least one entry may include data relating to or referencing other records / entries that have a relationship or association with the at least one entry. For example, a record index may include one or more fields that identify other records / entries related to it. The field may include parameters that add additional information about the relationship—for example, parameters indicating a hierarchical relationship to other records in the database, or indicating a reference / address at which one or more data items related to the record may be accessed, or any other metadata related to the record.

[0062] The record index specified in the overlay layer can take any suitable form. In an example of the present disclosure, the record index includes the transaction ID (TXID) of the transaction in which the output is provided, concatenated with the identifier of the output within the transaction. Figure 5 and Figure 7 The ID is shown as:

[0063] TXID||UTXO_ID

[0064] Therefore, if database record i maps to output y in transaction x on the blockchain, then we can write

[0065]

[0066] 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 listed in a vector (VOUT) such that each output in the transaction can be identified by its position / index in the VOUT vector starting at VOUT[0]. Therefore, in the above expression, UTXO_IDy can be replaced by VOUT[y], where y is the TX x The position of the relevant output in the output list of is given by:

[0067]

[0068] As described above, in some examples, instead of or in addition to an overlay that may be maintained off-chain, multiple records may be mapped to the same transaction. In such embodiments, all records in the database may initially be mapped to corresponding outputs in a single blockchain transaction, such that the single transaction effectively becomes an online schema or index list for the entire database. This initial transaction 152i may be referred to as the root transaction or genesis transaction of the overlay. Each time the associated records of the various outputs of the genesis transaction are accessed, these outputs may subsequently be spent, leaving an immutable, auditable, time-stamped trail of events and detailed information about the users who performed these events for each record. Each of these output trails may be traced back to the original root transaction / genesis transaction of the database.

[0069] Transaction log

[0070] In some embodiments, a transaction log may be maintained to aid in recovering and restoring the database in the event of hardware / software failures or content corruption, etc. The transaction log provides a history of all events related to the database that have occurred and maintains details of all state changes in the overlay. Although 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 recover the database from the log. The transaction log may include one or more components of the overlay system disclosed herein.

[0071] Access log

[0072] When a user wishes to access a record in the database, the access request is passed to an overlay component of the system. The overlay component identifies the relevant entry for the record and obtains all necessary data from the entry to enable the generation of a transaction that consumes the output of the associated transaction 152i. The data may include one or more of the following: a transaction identifier (TXID), an output identifier (VOUT[y]), an address to which the cryptocurrency associated with the output should be consumed, one or more public keys 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.

[0073] Once the necessary data has been acquired, a new transaction 152j is generated and broadcast to the network 106 of nodes 104. Node 104 verifies the transaction and, if successful, mines the transaction into block 151 and adds it to the ledger 150. This results in the output 203 of the previous transaction being spent to the new transaction. The entry details of the record are updated to reflect that the record is now associated with a specific unspent output in the new transaction. In addition, the transaction log may be updated with the event details. A new encryption (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 user in the overlay. The cryptocurrency associated with the spent output will be spent to the specified address. The new transaction will include an output with a locking script (specifying one or more keys that must be used to unlock the new transaction) and the address to which the cryptocurrency will be spent. Unless the administrator has changed the authorization details in the overlay entry of the record (for example, because the employee has left the organization, their one or more authorization data / keys will be removed from the entry), the new transaction will require a key provided by the same one or more authorized parties (i.e., one or more users).

[0074] During node verification, the protocol requires the evaluation of locking and unlocking scripts. This involves checking whether the required public key or keys and signature or signatures are present in the unlocking script. Thus, the consensus mechanism built into the blockchain protocol performs a permissioning function that is traditionally performed as part of a database application.

[0075] Examples in use

[0076] With reference to the accompanying drawings (especially Figure 7 ), now provide examples of how to use the illustrative embodiments. In fact, you can follow the same Figure 7 The steps may be performed in an order different from that shown, and some steps may be omitted and / or other steps not shown may be inserted.

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

[0078] In step 2, using the user interface 501 as a component of the control system 500 disclosed herein, the administrator or user associates each authorized user with one or more encryption key pairs, each encryption key pair consisting of a public key and a corresponding private key. The user / administrator can use a digital wallet or other key generation components known in the art to generate one or more keys, wherein wallets 502a, 502b, 502c are associated with the user / administrator (hereinafter referred to as "user"). Each user can have his own digital wallet 502a, 502b, 502c, for generating and storing keys (these keys can be used to verify their authorization to access records) and generating cryptocurrency addresses. Wallets 502a, 502b, 502c may include certain cryptocurrencies so that outputs can be consumed during access events. Users can maintain and / or use the control system 500 by interacting with the user interface 501. The user interface 501 can facilitate the execution of operations such as creating new record entries, creating new authorized users for one or more records, deleting one or more records or authorized users, etc.

[0079] Records of which keys are associated with each user can be stored and maintained, for example, by an administrator. Each key pair provides a permission mechanism that a user can use to unlock a particular record. Database 506 can be arranged so that at least some of records 505 form a hierarchical structure. In such cases, subkeys can be generated for records at different levels within the hierarchy. Techniques such as those disclosed in WO2017 / 145016 (PCT application PCT / IB2017 / 0500856) can be used to deterministically generate subkeys from a master key, thereby enabling the generation of an encryption key hierarchy that reflects the hierarchical structure of the records.

[0080] In step 3, a database overlay 503 is generated to map the records 505 in the database 506 to the corresponding outputs 203 in one or more transactions in the blockchain ledger 150. This step may include the actions of generating one or more blockchain transactions 152 that include the outputs 203 representing and associated with the corresponding records 505 in the database 506. The one or more 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 spending / access events) for a given database record 505 can be traced. This trace will provide an auditable, time-stamped, irrefutable record of who performed what actions on each record 505.

[0081] Each user and its associated one or more public keys and corresponding record_ID can be recorded within the overlay component 503, so that the overlay can be interrogated or queried to determine which user or users have access to a particular record 505, or which record or records a particular user has access to. Users can perform such queries to generate reports, and can use the interface 501 to interact with the authority control system 500.

[0082] At least one blockchain transaction 152 is generated, the at least one blockchain transaction including a UTXO 203 representing a corresponding record 505. Each UTXO 203 includes a locking script that specifies at least one key that can be used to unlock the output and spend its associated cryptocurrency. Therefore, the UTXO 203 can only be unlocked when the at least one key and the corresponding signature are provided. In some cases, the script may allow one or more authorized keys from a set of authorized keys to be used to unlock the output, as is known in the art of blockchain transactions (i.e., "n / m" or "multi-signature" transactions). The script may include an "OR" or selection function so that any authorized party from a set of authorized parties can access one or more records.

[0083] In fact, the key can be generated as a subkey of the master key. For example, the initial key associated with a given user and / or record can be used as a master key to generate subkeys associated with subrecords derived from the record. This is advantageous when the database includes a record hierarchy and the associated key structure needs to reflect the record structure. The subkeys can be generated using techniques substantially as disclosed in WO2017 / 145016 (which is incorporated herein in its entirety) or any other suitable subkey generation technique. In some embodiments, a new key and / or subkey can be used for each new output associated with a given record. This can enhance security by making it more difficult to identify the recipient to whom the output is spent.

[0084] In step 4, a transaction log 504 is generated (optional). Each time an output is consumed, the transaction log is updated. Any new key or keys associated with the corresponding record 505 are recorded.

[0085] In step 5, assume that a user wishes to access a specific record in database 506. When such a need arises, the user may generate an access request and send it to the overlay. The overlay component 503 may be queried to obtain the on-chain ID of the record 505. In other words, obtain the ID of the output associated with the target record. In the example of the present disclosure, this identifier is a combination of a transaction ID (TXID) and a UTXO identifier, which together specify the location of the index (output) of the record on the blockchain. An authorization check will need to be performed to ensure that the source of the access request has the right to access the target record and is legally allowed to do so.

[0086] In step 6, in response to the access request, a new (other) blockchain transaction (Tx) is generated and set to consume the UTXO currently associated with the record. This can be generated by the wallet of the user (or administrator). Tx includes an input 202 with an unlocking script that provides a public key and a signature generated by the public key to satisfy the requirements specified by the locking script 203 of the UTXO in TX currently associated with the target database record. In some cases, multiple public keys and corresponding signatures will be provided in the unlocking script, depending on the conditions set in the locking script. The unlocking script provides the address to which the cryptocurrency will be consumed. The other transaction is submitted to the blockchain network 106 for verification by the mining node 104 and, if successful, is added to the ledger 150. (It should be noted that Figure 5 , Figure 6 and Figure 8 Only transactions are shown, not blocks, in which transactions are provided on the ledger 150. However, these blocks are Figure 1 shown).

[0087] In step 7, the node verifies the new transaction according to the consensus rules specified in the blockchain protocol. This involves the node 104 checking whether the unlocking script has provided the correct key and the minimum number of keys, and whether these keys have been used to generate the provided signature.

[0088] At 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 linked to the other transaction TX j The database record is locked on a first-come, first-served basis until the current access terminates. The record's overwrite entry is updated to associate the record with the new UTXO from the other transaction. If necessary, a new (child) key is generated for the new UTXO and associated with the record in the overlay. If a transaction log has been implemented, it is updated to reflect the event.

[0089] At step 8.2.2, if the consensus mechanism fails to validate the attempted spending of the UTXO, access to record 505 is denied.

[0090] An advantage of the present disclosure is that the database 506 can be mapped to the blockchain 150 so that searches and other operations can be performed using a simple payment verification (SPV) style approach. SPV is known in the art (having been introduced in Section 8 of the Satoshi Nakamoto white paper "Bitcoin: A Peer-to-Peer Electronic Cash System" (2008)) and takes advantage of the inherent design of the blockchain protocol (incorporating Merkle proofs) to provide an efficient method for verifying whether a target transaction (and its inputs) exists on the blockchain without accessing the entire blockchain. According to the present disclosure, records are indexed directly in a manner similar to a hash database, rather than looking up a single transaction on the chain in the traditional way. Therefore, the edges between nodes (records) in the overlay correspond to paths in the Merkle tree. The advantage of this is that the paths are dynamically stored in the blockchain over time.

[0091] As a result, data can be re-indexed faster, which requires less processing and resources because a sequential search does not need to be repeatedly performed across the entire blockchain each time a specific record / data item of interest needs to be accessed. In contrast, using embodiments of the present disclosure, a user can inspect a given TX, view the mapping associated with it, and see that TXa maps to TXb, TXb maps to TXc, TXc maps to TXd, etc. Even though the transactions may be located in different blocks on the chain, the transactions are linked by the mapping. This provides a faster and more efficient solution for searching than iterating the ledger block by block until the target transaction is found.

[0092] Furthermore, the above embodiments utilize the existing consensus mechanism of the blockchain in order to implement the permission and authorization components of the system. Access requests are effectively granted or denied based on the results of the consensus mechanism. In a preferred embodiment, the overlay / DBMS does not need to perform any verification work because this is handled by the blockchain network.

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

[0094] Overview of blockchain system examples

[0095] Figure 1An exemplary system 100 for implementing an illustrative blockchain 150 that can be used for embodiments of the present disclosure is shown. This example is not limiting or exclusive, but is provided as one possible implementation among multiple possibilities. The system 100 may include a packet-switched network 101, typically a wide-area internet such as the Internet. The packet-switched network 101 includes a plurality of blockchain nodes 104, which may be arranged to form a peer-to-peer (P2P) network 106 within the packet-switched network 101. Although not shown, the blockchain nodes 104 may be arranged as a nearly complete graph. Therefore, each blockchain node 104 is highly connected to other blockchain nodes 104.

[0096] Each blockchain node 104 includes a computer device of a peer, and different nodes 104 belong to different peers. Each blockchain node 104 includes a processing device, which includes one or more processors, such as one or more central processing units (CPUs), accelerator processors, special processors and / or field programmable gate arrays (FPGAs), and other devices, such as application-specific integrated circuits (ASICs). Each node also includes a memory, that is, a computer-readable memory in the form of a non-transitory computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as magnetic media such as hard disks, electronic media such as solid-state drives (SSDs), flash memory, or electrically erasable programmable read-only memories (EEPROMs), and / or optical media such as optical disk drives.

[0097] The blockchain 150 includes a series of data blocks 151, wherein a respective copy of the blockchain 150 is maintained at each of the plurality of blockchain nodes 104 in the distributed or blockchain network 106. As described 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 as long as each blockchain node 150 stores the block headers (discussed below) of each block 151. Each block 151 in the blockchain includes one or more transactions 152, wherein a transaction in this context refers to a data structure. The nature of the data structure will depend on the type of transaction protocol used as part of the transaction model or plan. A given blockchain uses a particular transaction protocol throughout. In a common transaction protocol, the data structure of each transaction 152 includes at least one input and at least one output. Each output specifies an amount of a digital asset represented as a property, an example of which is an output locked to a user 103 by a cryptographic key (requiring the user's signature or other solution to unlock, thereby redeeming or spending). Each input points to the output of a previous transaction 152, thereby linking these transactions.

[0098] Each block 151 also includes a block pointer 155, which points to a previously created block 151 in the blockchain to define the order of blocks 151. Each transaction 152 (except for the coinbase transaction) includes a pointer to a previous transaction to define the order of the transaction sequence (Note: the sequence of transactions 152 can branch). The blockchain of blocks 151 is traced back to the genesis block (Gb) 153, which is the first block in the blockchain. One or more original transactions 152 earlier in the blockchain 150 point to the genesis block 153, not to the previous transaction.

[0099] Each blockchain node 104 is configured to forward transactions 152 to other blockchain nodes 104, so that transactions 152 propagate throughout the network 106. Each blockchain node 104 is configured to create blocks 151 and store corresponding copies of the same blockchain 150 in its corresponding memory. Each blockchain node 104 also maintains an ordered set (or "pool") 154 of transactions 152 waiting to be incorporated into block 151. Ordered pools 154 are often referred to as "memory pools". In this article, the term is not intended to be limited to any particular blockchain, protocol, or model. The term refers to a set of ordered transactions that a node 104 has accepted as valid, and for which the node 104 is forced to not accept any other transaction that attempts to consume the same output.

[0100] In a given current transaction 152j, an input (or each input) includes a pointer that references an output of a previous transaction 152i in the transaction sequence, specifying that the output is to be redeemed or "spent" in the current transaction 152j. In general, the previous transaction can be any transaction in the ordered set 154 or any block 151. Although the previous transaction 152i will need to exist and be verified to be valid in order to ensure that the current transaction is valid, the previous transaction 152i does not have to exist when the current transaction 152j is created or even sent to the network 106. Therefore, in this article, "previous" refers to the predecessor in the logical sequence linked by the pointer, and not necessarily the creation time or sending time in the time sequence, and therefore, does not necessarily exclude the situation where transactions 152i, 152j are created or sent out of order (see the discussion of orphan transactions below). The previous transaction 152i can also be called a predecessor transaction or a predecessor transaction.

[0101] The inputs of the current transaction 152j also include input authorizations, such as the signature of the user 103a to whom the outputs of the previous transaction 152i are locked. In turn, the outputs of the current transaction 152j may be cryptographically locked to the new user or entity 103b. Thus, the current transaction 152j may transfer the amounts defined in the inputs of the previous transaction 152i to the new user or entity 103b defined in the outputs of the current transaction 152j. In some cases, a transaction 152 may have multiple outputs to split the input amounts among multiple users or entities (one of which may be the original user or entity 103a for changes). In some cases, a transaction may also have multiple inputs to aggregate the amounts from multiple outputs of one or more previous transactions and reallocate them to one or more outputs of the current transaction.

[0102] According to an output-based transaction protocol, such as Bitcoin, when a party 103, such as an individual user or an organization, wishes to issue a new transaction 152j (either by an automated program employed by the party or manually), the issuing party sends the new transaction from its computer terminal 102 to a recipient. The issuing party or recipient will ultimately send the transaction to one or more blockchain nodes 104 of the network 106 (now typically a server or data center, but in principle it can also be other user terminals). It is also not excluded that the party 103 issuing the new transaction 152j can send the transaction directly to one or more blockchain nodes 104, and in some examples, the transaction may not be sent to the recipient. The blockchain node 104 receiving the transaction checks whether the transaction is valid according to the blockchain node protocol applied at each blockchain node 104. The blockchain node protocol typically requires the blockchain node 104 to check whether the cryptographic signature in the new transaction 152j matches the expected signature, which depends on the previous transaction 152i in the ordered sequence of transactions 152. In such an output-based transaction protocol, this may include checking whether the cryptographic signature or other authorization of the party 103 included in the input of the new transaction 152j matches the condition defined in the output of the previous transaction 152i assigned by the new transaction, wherein the condition typically includes at least checking whether 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. The condition may be defined at least in part by a script included in the output of the previous transaction 152i. Alternatively, this may be determined solely by the blockchain node protocol, or may be determined by a combination thereof. 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 test according to the same blockchain node protocol, and therefore forward the new transaction 152j to one or more other nodes 104, and so on. In this way, the new transaction is propagated throughout the network of blockchain nodes 104.

[0103] In the output-based model, the definition of whether a given output (e.g., UTXO) is allocated (e.g., spent) is whether it is validly redeemed by the input of another subsequent transaction 152j according to the blockchain node protocol. Another condition for the transaction to be valid is that the output of the previous transaction 152i that it attempts to redeem has not been redeemed by another transaction. Similarly, if invalid, the transaction 152j will not be propagated (unless marked as invalid and propagated for reminder) or recorded in the blockchain 150. This prevents duplicate spending, that is, the transaction processor allocates the output of the same transaction more than once. On the other hand, the account-based model prevents duplicate spending by maintaining account balances. Because there is also a defined transaction order, the account balance has a single defined state at all times.

[0104] In addition to verifying that transactions are valid, blockchain nodes 104 compete to be the first node to create a block of transactions in a process generally referred to as mining, which is supported by "proof of work". At a blockchain node 104, a new transaction is added to an ordered pool 154 of valid transactions that have not yet appeared in a block 151 recorded on the blockchain 150. The blockchain nodes then compete to assemble a new valid transaction block 151 of transactions 152 in the ordered transaction set 154 by attempting to solve a cryptographic puzzle. Typically, this involves searching for a "nonce" value such that when the nonce is juxtaposed with a representation of the ordered pool 154 of pending transactions and hashed, the output of the hash value satisfies a predetermined condition. For example, the predetermined condition may be that the output of the hash value has a certain predefined number of leading zeros. Note that this is only one specific type of proof of work puzzle, and other types are not excluded. A property of a hash function is that it has an unpredictable output relative to its input. Therefore, this search can only be performed by brute force, consuming a large amount of processing resources at each blockchain node 104 that attempts to solve the puzzle.

[0105] The first blockchain node 104 that solves the puzzle announces the puzzle solution on the network 106, providing the solution as proof, which can then be easily checked by other blockchain nodes 104 in the network (once a solution to the hash value is given, it is directly possible to check whether the solution satisfies the output of the hash value). The first blockchain node 104 propagates a block to other nodes that accept the block to reach a threshold consensus, thereby enforcing the protocol rules. The ordered transaction set 154 is then recorded by each blockchain node 104 as a new block 151 in the blockchain 150. A block pointer 155 is also assigned to the new block 151n pointing to the previously created block 151n-1 in the blockchain. The large amount of work required to create a proof-of-work solution (e.g., in the form of a hash) signals the intention of the first node 104 to follow the blockchain protocol. These rules include not accepting a transaction as valid if it assigns the same output as a previously verified valid transaction, otherwise it is called a duplicate spend. Once created, the block 151 cannot be modified because it is identified and maintained at each blockchain node 104 in the blockchain network 106. The block pointers 155 also impose an order on the blocks 151. Because transactions 152 are recorded in ordered blocks at each blockchain node 104 in the network 106, an immutable public ledger of transactions is provided.

[0106] It should be noted that the different blockchain nodes 104 competing to solve a puzzle at any given time may do so based on different snapshots of the pool 154 of transactions that have not yet been published at any given time, depending on when they began searching for a solution or the order in which they received the transactions. The person solving the corresponding puzzle first defines the transactions 152 included in the new block 151n and their order, and updates the current pool of unpublished transactions 154. The blockchain nodes 104 then continue to compete to create blocks from the newly defined ordered pool of unpublished transactions 154, and so on. In addition, there is a protocol to resolve any "forks" that may occur, where two blockchain nodes 104 solve puzzles within a short time of each other, thereby propagating conflicting views of the blockchain between the nodes 104. In short, the fork direction that is the longest becomes the final blockchain 150. It should be noted that this does not affect users or agents of the network, as the same transaction will appear in both forks.

[0107] According to the Bitcoin blockchain (and most other blockchains), a node that successfully constructs a new block 104 is granted the ability to newly allocate an additional, accepted amount of digital assets in a new special type of transaction that allocates an additional limited amount of digital assets (as opposed to an inter-agent or inter-user transaction, which transfers a certain amount of digital assets from one agent or user to another). This special type of transaction is often called a "coinbase transaction", but may also be called a "starting transaction" or "generating transaction". It usually forms the first transaction of a new block 151n. The proof of work signals the intention of the node that constructs the new block to follow the protocol rules, thereby allowing the particular transaction to be redeemed later. The blockchain protocol rules may require a maturation period, such as 100 blocks, before the special transaction can be redeemed. Typically, a regular (non-generating) transaction 152 will also specify an additional transaction fee in one of its outputs to further reward the blockchain node 104 that created the block 151n in which the transaction was published. This fee is often called a "transaction fee" and is discussed below.

[0108] Due to the resources involved in transaction verification and publication, typically at least each blockchain node 104 takes the form of a server comprising one or more physical server units, or even an entire data center. However, in principle, any given blockchain node 104 may take the form of a user terminal or a group of user terminals networked together.

[0109] The memory of each blockchain node 104 stores software configured to run on the processing device of the blockchain node 104 to perform its corresponding role according to the blockchain node protocol and process transactions 152. It should be understood that any action attributed to the blockchain node 104 herein can be performed by software running on the processing device of the corresponding computer device. The node software can be implemented in one or more applications at the application layer or a lower layer such as an operating system layer or a protocol layer, or any combination of these layers.

[0110] Computer devices 102 of each of the parties 103 acting as consuming users are also connected to the network 101. These users can interact with the blockchain network 106 but do not participate in verifying transactions or constructing blocks. Some of these users or agents 103 can act as senders and receivers in transactions. Other users can interact with the blockchain 150 without acting as senders or receivers. For example, some parties can act as storage entities that store a copy of the blockchain 150 (e.g., having obtained a copy of the blockchain from the blockchain node 104).

[0111] Some or all of the parties 103 may be connected as part of a different network, such as a network overlaid on the blockchain network 106. Users of the blockchain network (often referred to as "clients") may be referred to as being part of a system that includes the blockchain network 106; however, these users are not blockchain nodes 104 because they do not perform the roles required of blockchain nodes. Instead, each party 103 may interact with the blockchain network 106, thereby utilizing the blockchain 150 by connecting to (i.e., communicating with) the blockchain node 106. For illustrative purposes, two parties 103 and their corresponding devices 102 are shown: a first party 103a and its corresponding computer device 102a, and a second party 103b and its corresponding computer device 102b. It should be understood that more such parties 103 and their corresponding computer devices 102 may exist and participate in the system 100, but for convenience, they are not illustrated. Each party 103 may be an individual or an organization. For illustrative purposes only, in this document, the first party 103a is referred to as Alice and the second party 103b is referred to as Bob, but it should be understood that this is not limited to Alice or Bob, and any reference to Alice or Bob in this document can be replaced with "first party" and "second party" respectively.

[0112] The computer device 102 of each party 103 includes a corresponding processing device, which includes one or more processors, such as one or more CPUs, graphics processing units (GPUs), other accelerator processors, specific application processors and / or FPGAs. The computer device 102 of each party 103 also includes a memory, that is, a computer-readable memory in the form of a non-temporary computer-readable medium. The memory may include one or more memory units, which use one or more memory media, such as 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 on the computer device 102 of each party 103 stores software, which includes a corresponding instance of at least one client application 105 that is set to run on the processing device. It should be understood that any action attributed to a given party 103 in this article can be executed by software running on the processing device of the corresponding computer device 102. The computer device 102 of each party 103 includes at least one user terminal, such as a desktop or laptop computer, a tablet computer, a smart phone, or a wearable device such as a smart watch. The computer device 102 of a given party 103 may also include one or more other network resources, such as cloud computing resources accessed through a user terminal.

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

[0114] The client application 105 includes at least a "wallet" function. This has two main functions. One of the functions is to enable the corresponding party 103 to create, authorize (e.g., sign) and send transactions 152 to one or more Bitcoin nodes 104, which are then propagated in the network of blockchain nodes 104 and included in the blockchain 150. Another function is to report to the corresponding party the amount of digital assets it currently owns. In an output-based system, this second function includes collating the amounts defined in the outputs of various transactions 152 belonging to the relevant parties scattered in the blockchain 150.

[0115] Note: While various client functions may be described as being integrated into a given client application 105, this is not necessarily limiting, and rather, any client function described herein may be implemented in a suite consisting of two or more different applications, such as interfacing via an API or one application as a plug-in to another application. More generally, the client functions may be implemented at the application layer or at a lower layer such as an operating system, or any combination of these layers. The following description will be based on the client application 105, but it should be understood that this is not limiting.

[0116] An instance of a client application or software 105 on each computer device 102 is operably coupled to at least one of the blockchain nodes 104 of the network 106. This can enable a wallet function of the client 105 to send transactions 152 to the network 106. The client 105 can also contact the blockchain node 104 to query the blockchain 150 for any transactions to which the corresponding party 103 is a recipient (or indeed to check other parties' transactions in the blockchain 150, because in an embodiment, the blockchain 150 is a public facility that provides transaction trust to some extent through its public visibility). The wallet function on each computer device 102 is configured to formulate and send transactions 152 according to a transaction protocol. As described above, each blockchain node 104 runs software that is configured to verify transactions 152 according to the blockchain node protocol and forward transactions 152 for propagation in the blockchain network 106. The transaction protocol and the node protocol correspond to each other, and a given transaction protocol and a given node protocol together implement a given transaction model. The same transaction protocol is used for all transactions 152 in the blockchain 150. All nodes 104 in the network 106 use the same node protocol.

[0117] When a given party 103 (say Alice) wishes to send a new transaction 152j to be included in the blockchain 150, she will formulate the new transaction according to the relevant transaction protocol (using the wallet function in her client application 105). She will then send the transaction 152 from the client application 105 to one or more blockchain nodes 104 to which she is connected. For example, this may be the blockchain node 104 that Alice's computer 102 is best connected to. When any given blockchain node 104 receives the new transaction 152j, it will process it according to the blockchain node protocol and its corresponding role. This includes first checking whether the newly received transaction 152j meets certain conditions for becoming "valid", specific examples of which will be discussed in detail later. In some transaction protocols, the validity conditions may be configurable on a per-transaction basis through a script included in the transaction 152. Alternatively, the conditions may simply be a built-in function of the node protocol, or defined by a combination of script and node protocol.

[0118] If the newly received transaction 152j passes the validity test (i.e., under the “valid” condition), any blockchain node 104 that receives the transaction 152j will add the new verified valid transaction 152 to the ordered transaction set 154 maintained at the blockchain node 104. Further, any blockchain node 104 that receives the transaction 152j will then propagate the verified valid transaction 152 to one or more other blockchain nodes 104 in the network 106. Since each blockchain node 104 applies the same protocol, it is assumed that the transaction 152j is valid, which means that the transaction will soon be propagated throughout the network 106.

[0119] Once in the ordered pool 154 of pending transactions maintained at a given blockchain node 104, that blockchain node 104 will begin racing to solve the proof-of-work puzzle on the latest version of its respective pool 154 containing the new transaction 152 (keep in mind that other blockchain nodes 104 can attempt to solve the puzzle based on different transaction pools 154. However, whoever solves the puzzle first will define the set of transactions included in the latest block 151. Ultimately, the blockchain node 104 will solve the puzzle for a portion of the ordered pool 154, which includes Alice's transaction 152j). Once the pool 154 including the new transaction 152j completes the proof-of-work, it will immutably become part of one of the blocks 151 in the blockchain 150. Each transaction 152 includes a pointer to an earlier transaction, so the order of transactions is also immutably recorded.

[0120] Different blockchain nodes 104 may initially receive different instances of a given transaction and therefore have conflicting views about which instance is “valid” before one instance is published in a new block 151, at which point all blockchain nodes 104 agree that the published instance is the only valid instance. If a blockchain node 104 accepts one instance as valid and then discovers that a second instance has been recorded in the blockchain 150, the blockchain node 104 must accept this and will discard (i.e., treat as invalid) the instance it originally accepted (i.e., the instance that has not yet been published in block 151).

[0121] Another type of transaction protocol operated by some blockchain networks as part of the account-based transaction model can be called an "account-based" protocol. In the account-based case, each transaction is defined not by reference to the UTXO of a previous transaction in the past sequence of transactions, but by reference to an absolute account balance. The current state of all accounts is stored individually in the blockchain by the nodes of the network and is continuously updated. In such systems, transactions are ordered using an account's running transaction record (also called a "position"). This value is signed by the sender as part of their cryptographic signature and hashed as part of the transaction reference calculation. In addition, optional data fields can also be signed in the transaction. For example, a data field can point to a previous transaction if it contains the ID of the previous transaction.

[0122] UTXO-based model

[0123] Figure 2 An exemplary transaction protocol is shown. This is an example of a UTXO-based protocol. A transaction 152 ("Tx" for short) is the basic data structure of the blockchain 150 (each block 151 includes one or more transactions 152). The following will be described with reference to an output-based or "UTXO"-based protocol. However, this is not limited to all possible embodiments. It should be noted that although the exemplary UTXO-based protocol is described with reference to Bitcoin, it can also be implemented on other exemplary blockchain networks.

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

[0125] Let's say Alice 103a wishes to create a transaction 152j that transfers the relevant amount of digital assets to Bob 103b. Figure 2 In , Alice's new transaction 152j is labeled "Tx1". This new transaction takes the amount of digital assets locked to Alice in output 203 of the previous transaction 152i in the sequence and transfers at least a portion of such amount to Bob. Figure 2 , the previous transaction 152i is labeled "Tx0". Tx0 and Tx1 are just arbitrary labels that do not necessarily mean that Tx0 refers to the first transaction in blockchain 151 and Tx1 refers to a subsequent transaction in pool 154. Tx1 can point to any previous (i.e., preceding) transaction that still has unspent output 203 locked to Alice.

[0126] When Alice creates her new transaction Tx1, or at least when she sends it to the network 106, the previous transaction Tx0 may already be valid and included in block 151 of the blockchain 150. The transaction may have been included in one of the blocks 151 at this time, or it may still be waiting in the ordered set 154, in which case it will be included in the new block 151 soon. Alternatively, Tx0 and Tx1 may be created and sent to the network 106 together; or, if the node protocol allows buffering of "orphan" transactions, Tx0 may even be sent after Tx1. The terms "previous" and "successor" as used herein in the context of transaction sequences refer to the order of transactions in the sequence defined by the transaction pointers specified in the transactions (which transaction points to which other transaction, etc.). They may equally be replaced by "predecessors" and "successors", "predecessors" and "descendants", or "parents" and "children", etc. This does not necessarily refer to the order in which they are created, sent to the network 106, or arrive at any given blockchain node 104. However, subsequent transactions (descendant transactions or "child transactions") pointing to a previous transaction (predecessor transaction or "parent transaction") will not be valid unless the parent transaction is valid. A child transaction that arrives at the blockchain node 104 before the parent transaction is considered an orphan transaction. Depending on the node protocol and / or node behavior, it may be discarded or buffered for a period of time to wait for the parent transaction.

[0127] One of the one or more outputs 203 of the previous transaction Tx0 includes a specific UTXO, labeled UTXO0. Each UTXO includes a value specifying the amount of digital assets represented by the UTXO and a locking script that defines the conditions that the unlocking script in the input 202 of the subsequent transaction must satisfy in order for the subsequent transaction to be valid and thus successfully redeem the UTXO. Typically, the locking script locks the amount to a specific party (the beneficiary of the transaction for that amount). That is, the locking script defines the unlocking condition, which typically includes the following conditions: the unlocking script in the input of the subsequent transaction includes the cryptographic signature of the party to which the previous transaction was locked.

[0128] The locking script (also known as scriptPubKey) is a piece of code written in a domain-specific language recognized by the node protocol. A specific example of such a language is called a "Script" (with a capital S), which can be used by the blockchain network. The locking script specifies the information required to consume the transaction output 203, such as the requirement for Alice's signature. The unlocking script appears in the output of the transaction. The unlocking script (also known as scriptSig) is a piece of code written in a domain-specific language that provides the information required to meet the locking script criteria. For example, it can contain Bob's signature. The unlocking script appears in the input 202 of the transaction.

[0129] Thus in the example shown, UTXO0 in output 203 of Tx0 includes a locking script [Checksig P A], the locking script requires Alice’s signature Sig P A , in order to redeem UTXO0 (strictly speaking, to make subsequent transactions that attempt to redeem UTXO0 valid). A ] contains Alice's public key P from her public-private key pair A The input 202 of Tx1 includes a pointer to Tx1 (e.g., by its transaction ID (TxID0), which in the embodiment is the hash value of the entire transaction Tx0). The input 202 of Tx1 includes an index identifying UTXO0 in Tx0 to identify it among any other possible outputs of Tx0. The input 202 of Tx1 further includes an unlocking script <Sig P A >, the unlocking script includes Alice's cryptographic signature, which is created by Alice by applying the private key of her key pair to a predetermined portion of data (sometimes called a "message" in cryptography). The data (or "message") that Alice needs to sign to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0130] When a new transaction Tx1 arrives at a blockchain node 104, the node applies the node protocol. This includes running the locking script and the unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (where the conditions may include one or more criteria). In an embodiment, this involves juxtaposing two scripts:

[0131] <Sig PA> <pa>||[Checksig PA]

[0132] Where "||" means concatenation, "<…>" means putting data on the stack, and "[…]" means a function consisting of locked scripts (in this case, a stack-based language). Similarly, scripts can be run one after another using a common stack instead of concatenating the scripts. In either case, when run together, the scripts use Alice's public key P A (included in the locking script of the output of Tx0) to verify that the unlocking script in the input of Tx1 contains Alice's signature when signing the expected portion of the data. The expected partial data itself (the "message") also needs to be included in order to perform this verification. In an embodiment, the signed data includes the entire Tx1 (so there is no need to include a separate element to plaintext specify the signed partial data, as it is already present).

[0133] Those skilled in the art will be familiar with the details of authentication via public-private cryptography. Basically, if Alice has signed a message using her private key cryptographically, then given Alice's public key and the message in plain text, other entities such as node 104 can authenticate that the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash value, and marking this to the message as a signature, thereby enabling any holder of the public key to authenticate the signature. Therefore, it should be noted that in embodiments, any reference herein to signing a particular data fragment or transaction portion, etc., may mean signing the hash value of that data fragment or transaction portion.

[0134] If the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (thus, in the example shown, if Alice's signature is provided and authenticated in Tx1), then the blockchain node 104 considers Tx1 to be valid. This means that the blockchain node 104 will add Tx1 to the pending transaction ordered pool 154. The blockchain node 104 will also forward the transaction Tx1 to one or more other blockchain nodes 104 in the network 106 so that it will propagate throughout the network 106. Once Tx1 is valid and included in the blockchain 150, this will define UTXO0 from Tx0 as consumed. It should be noted that Tx1 is only valid if it consumes an unspent transaction output 203. If it attempts to consume an output that has already been consumed by another transaction 152, then Tx1 will be invalid even if all other conditions are met. Therefore, the blockchain node 104 also needs to check whether the UTXO referenced in the previous transaction Tx0 has been consumed (that is, whether it has formed a valid input for another valid transaction). This is one of the reasons why it is important for the blockchain 150 to impose a defined order on transactions 152. In practice, a given blockchain node 104 may maintain a separate database marking the UTXO 203 of a transaction 152 as having been spent, but ultimately defining whether a UTXO has been spent depends on whether it has formed a valid input to another valid transaction in the blockchain 150.

[0135] If the total amount specified in all outputs 203 of a given transaction 152 is greater than the total amount pointed to by all its inputs 202, this is another basis for failure in most transaction models. Therefore, such a transaction will not be propagated or included in block 151.

[0136] Note that in a UTXO-based transaction model, a given UTXO needs to be spent as a whole. You cannot "leave behind" a portion of the amount defined in a UTXO as spent while spending another portion. However, the amount of a UTXO can be split between multiple outputs of subsequent transactions. For example, the amount defined in UTXO0 of Tx0 can be split between multiple UTXOs in Tx1. Therefore, if Alice does not want to give all of the amount defined in UTXO0 to Bob, she can use the remaining portion to make change for herself in the second output of Tx1, or to pay another party.

[0137] In practice, Alice will also typically need to include a fee for the Bitcoin node 104 that successfully includes Alice's transaction 104 in block 151. If Alice does not include such a fee, Tx0 may be rejected by the blockchain node 104, and therefore, although technically valid, may not be propagated and included in the blockchain 150 (if the blockchain node 104 does not want to accept transaction 152, the node protocol does not force the blockchain node 104 to accept). In some protocols, the transaction fee does not require its own separate output 203 (i.e., no separate UTXO is required). Instead, any difference between the total amount pointed to by input 202 and the total amount specified by output 203 of a given transaction 152 will be automatically provided to the blockchain node 104 that issued the transaction. For example, assume that a pointer to UTXO0 is the only input of Tx1, and Tx1 has only one output UTXO1. If the amount of the digital asset specified in UTXO0 is greater than the amount specified in UTXO1, the difference can be distributed by the node 104 that wins the proof-of-work competition to create a block containing UTXO1. Alternatively or additionally, this does not necessarily preclude that a transaction fee may be explicitly specified in one of the UTXOs 203 in the transaction 152 itself.

[0138] Alice and Bob's digital assets consist of the UTXO locked to them in any transaction 152 anywhere in the blockchain 150. Therefore, in general, the assets of a given party 103 are scattered among the UTXOs of various transactions 152 throughout the blockchain 150. No single number defining the total balance of a given party 103 is stored anywhere in the blockchain 150. The role of the wallet function of the client application 105 is to collate the various UTXO values ​​locked to the respective parties and not yet spent in other subsequent transactions. To achieve this, it can query a copy of the blockchain 150 stored at any one Bitcoin node 104.

[0139] It should be noted that script code is often represented schematically (i.e., using an imprecise language). For example, an opcode (opcode) may be used to represent a specific function. "OP_..." refers to a specific opcode of the scripting language. For example, OP_RETURN is a scripting language opcode that, when preceded by OP_FALSE at the beginning of a locking script, creates a non-consumable output of a transaction that can store data within the transaction, thereby immutably recording the data in the blockchain 150. For example, the data may include a file to be stored in the blockchain.

[0140] Typically, the inputs to a transaction contain a digital signature corresponding to the public key PA. In an embodiment, this is based on ECDSA using the elliptic curve secp256k1. The digital signature signs a specific piece of data. In an embodiment, for a given transaction, the signature will sign part of the transaction input and part or all of the transaction output. Signing a specific part of the output depends on the SIGHASH flag. The SIGHASH flag is typically a 4-byte code included at the end of the signature that selects the output to be signed (and is therefore fixed at the time of signing).

[0141] The locking script is sometimes referred to as "scriptPubKey", which means that it usually includes the public key of the party to which the corresponding transaction is locked. The unlocking script is sometimes referred to as "scriptSig", which means that it usually provides the corresponding signature. However, more generally speaking, in all applications of blockchain 150, the conditions for UTXO redemption do not necessarily include verification of the signature. More generally speaking, the scripting language can be used to define any one or more conditions. Therefore, the more general terms "locking script" and "unlocking script" may be preferred.

[0142] Side Channel

[0143] like Figure 1 As shown, the client application on each of Alice and Bob's computer devices 102a, 120b can include additional communication functionality. This additional functionality enables Alice 103a to establish a separate side channel 107 with Bob 103b (at the instigation of any party or third party). The side channel 107 enables data to be exchanged away from the blockchain network. Such communications are sometimes referred to as "off-chain" communications. For example, this can be used to exchange transactions 152 between Alice and Bob without registering the transaction (yet) on the blockchain network 106 or publishing it on the chain 150 until one of the parties chooses to broadcast it to the network 106. Sharing transactions in this way is sometimes referred to as sharing "transaction templates". 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 can be used to exchange any other transaction-related data, such as keys, negotiation amounts or terms, data content, etc.

[0144] The side channel 107 may be established via the same packet switching network 101 as the blockchain network 106. Alternatively or additionally, the side channel 301 may be established via a different network such as a mobile cellular network or a local area network such as a wireless local area network, or even via a direct wired or wireless link between Alice's and Bob's devices 102a, 102b. In general, a side channel 107 referred to anywhere in this document may include any one or more links via one or more networking technologies or communication media that are used to exchange data "off-chain", i.e., off-chain. The bundle or collection of off-chain links may be referred to as a side channel 107 as a whole. Therefore, it should be noted that if Alice and Bob are said to exchange certain information or data, etc., via a side channel 107, this does not necessarily mean that all of this data must be sent over exactly the same link or even the same type of network.

[0145] Client Software

[0146] Figure 3A An exemplary implementation of a client application 105 for implementing an embodiment of the disclosed solution is shown. The client application 105 includes a transaction engine 401 and a user interface (UI) layer 402. According to the solution discussed above and discussed in further detail later, the transaction engine 401 is configured to implement basic transaction-related functions of the client 105, such as formulating transactions 152, receiving and / or sending transactions and / or other data through the side channel 301, and / or sending transactions to one or more nodes 104 for propagation through the blockchain network 106. According to the embodiments disclosed herein, the transaction engine 401 of each client 105 includes functions 403...

[0147] The UI layer 402 is configured to present a user interface through a user input / output (I / O) mode of the corresponding user's computer device 102, including outputting information to the corresponding user 103 through the user output mode of the device 102, and receiving input from the corresponding user 103 through the user input mode of the device 102. For example, the user output mode may include one or more screens (touch or non-touch screen) that provide visual output, one or more speakers that provide audio output, and / or one or more tactile output devices that provide tactile output, etc. The user input mode may include, for example, an input array of one or more touch screens (which may be the same or different from that / those used for the output mode); one or more cursor-based devices such as a mouse, trackpad, or trackball; one or more microphones and voice or sound recognition algorithms for receiving voice or sound input; one or more gesture-based input devices for receiving input in the form of manual or physical gestures; or one or more mechanical buttons, switches, or joysticks, etc.

[0148] Note: Although various functions in this document may be described as being integrated into the same client application 105, this does not necessarily constitute a limitation. Instead, they can be implemented in a suite of two or more different applications, such as one application as a plug-in to another application or interfacing via an API (application programming interface). For example, the functionality of the transaction engine 401 can be implemented in a separate application rather than in the UI layer 402, or the functionality of a given module such as the transaction engine 401 can be split between multiple applications. At the same time, it is not excluded that some or all of the described functions can be implemented, for example, at the operating system level. Where a single or given application 105 or the like is referenced anywhere in this document, it should be understood that this is only by way of example, and more generally, the described functions can be implemented in any form of software.

[0149] Figure 3B A model is given of an example of a user interface (UI) 500 that may be presented by the UI layer 402 of the client application 105a on Alice's device 102a. It should be understood that a similar UI may be presented by the client 105b on Bob's device 102b or any other party's device.

[0150] By means of diagrams, Figure 3B The UI 500 is shown from Alice's perspective. The UI 500 may include one or more UI elements 501, 502, 503, which are presented as different UI elements through user output.

[0151] For example, the UI elements may include one or more user-selectable elements 501, which may be different buttons on a screen, different options in a menu, or the like. The user input method is configured to enable the user 103 (in this case, Alice 103a) to select or otherwise operate one of the options, such as by clicking or touching the UI element on the screen, or speaking the name of the desired option (Note: the term "manual" is used herein only to contrast with automatic, and is not necessarily limited to performing operations by hand). These options enable the user (Alice) to...

[0152] Alternatively or additionally, the UI element may include one or more data input fields 502 through which a user may input data. These data input fields are presented via a user output means, such as on a screen, and data may be entered into the fields via a user input means, such as a keyboard or a touch screen. Alternatively, data may be received verbally based on speech recognition or the like.

[0153] Alternatively or additionally, the UI element may include one or more information elements 503 that output information to the user. For example, this / these may be presented on a screen or audibly.

[0154] It should be understood that the specific manner in which various UI elements, selection options, and input data are presented is not important. The functions of these UI elements will be discussed in more detail later. It should also be understood that the UI 500 shown in Figure 3 is only a diagram model, and in practice, it may include one or more further UI elements, which are not described for the sake of brevity.

[0155] Node software

[0156] Figure 4 An example of node software 450 running on each blockchain node 104 of the network 106 in an example of a UTXO-based or output-based model is shown. It should be noted that another entity may run the node software 450 without being classified as a node 104 on the network 106, i.e., not performing the actions required of the node 104. The node software 450 may include, but is not limited to, a protocol engine 451, a scripting engine 452, a stack 453, an application-level decision engine 454, and a collection of one or more blockchain-related functional modules 455. Each node 104 may run node software that includes, but is not limited to, all three of the following: a consensus module 455C (e.g., proof of work), a propagation module 455P, and a storage module 455S (e.g., a database). The protocol engine 401 is typically configured to identify different fields of a transaction 152 and process such fields according to the node protocol. When a transaction 152i (Tx m-1 )’s output (e.g., UTXO) is an input transaction 152j (Tx j ), the protocol engine 451 identifies Tx j The unlocking script in and passes it to the script engine 452. The protocol engine 451 also j The pointer in the input to identify and retrieve Tx i .Tx i may be published on blockchain 150, in which case the protocol engine may retrieve Tx from the copy of block 151 of blockchain 150 stored at node 104 i . Or, Tx i It can also be published on blockchain 150. In this case, protocol engine 451 can retrieve Tx from unpublished ordered transaction set 154 maintained by node 104. i Regardless of the method used, the script engine 451 will identify Tx i The locked script in the reference output is passed to the script engine 452.

[0157] Therefore, the script engine 452 has Tx i The locking script and the j The unlocking script for the corresponding input. For example, Figure 2 Transaction labels Tx0 and Tx1 are shown in FIG, but the same transaction can also be applied to any transaction pair. As previously described, the script engine 452 runs two scripts together, which will include placing data on and retrieving data from the stack 453 according to the stack-based scripting language used (e.g., script).

[0158] By running the scripts simultaneously, the script engine 452 determines whether the unlocking script satisfies one or more criteria defined in the locking script, i.e., whether the unlocking script unlocks the output including the locking script? The script engine 452 returns the result of the determination to the protocol engine 451. If the script engine 452 determines that the unlocking script does meet one or more criteria specified in the corresponding locking script, the result "TRUE" is returned. Otherwise, the result "FALSE" is returned.

[0159] In the output-based model, the result "TRUE" from the script engine 452 is one of the conditions for the validity of the transaction. Typically, one or more further protocol-level conditions evaluated by the protocol engine 451 must also be satisfied; for example, Tx j The total amount of digital assets specified in the inputs of tx does not exceed the total amount pointed to in its outputs, and tx i The pointed output of has not been consumed by another valid transaction. The protocol engine 451 evaluates the result from the script engine 452 and one or more protocol-level conditions, and only if they are all TRUE, the protocol engine verifies the transaction Tx j The protocol engine 451 outputs an indication of whether the transaction is valid to the application-level decision engine 454. j Only when the conditions are really valid, the decision engine 454 can choose to control the consensus module 455C and the propagation module 455P at the same time to execute its Tx j· This includes the consensus module 455C, adding Tx to the corresponding ordered transaction set 154 of the node. j , for incorporation into block 151; and propagation module 455P, Tx j Forwarded to another blockchain node 104 in the network 106. Optionally, in an embodiment, the application-level decision engine 454 may apply one or more additional conditions before triggering one or both of these functions. For example, the decision engine may choose to publish a transaction only if the transaction is valid and sufficient transaction fees are reserved.

[0160] In addition, it should be noted that in this article, the terms "TRUE" and "FALSE" are not necessarily limited to returning results that are expressed only in the form of a single binary number (bit), although this is indeed a possible implementation. More generally, "TRUE" can refer to any state indicating a successful or positive result, while "FALSE" can refer to any state indicating an unsuccessful or non-positive result. For example, in an account-based model, the combination of implicit protocol-level verification of signatures and additional positive outputs of smart contracts can be used to indicate that the result is "TRUE" (if both individual results are TRUE, the overall result is considered to be TRUE).

[0161] in conclusion

[0162] Other variations or uses of the disclosed technology may become apparent to those skilled in the art once given the disclosure herein.The scope of the present disclosure is not limited by the described embodiments but only by the appended claims.

[0163] For example, some of the embodiments above have been described in terms of the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104. However, it should be understood that the Bitcoin blockchain is a specific example of a blockchain 150, and the above description can generally be applied to any blockchain. That is, the present invention is in no way limited to the Bitcoin blockchain. More generally, any references to the Bitcoin network 106, the Bitcoin blockchain 150, and the Bitcoin node 104 above can be replaced with reference to the blockchain network 106, the blockchain 150, and the blockchain node 104, respectively. Blockchains, blockchain networks, and / or blockchain nodes can share some or all of the characteristics of the Bitcoin blockchain 150, the Bitcoin network 106, and the Bitcoin node 104 described above.

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

[0165] In other embodiments of the present invention, the blockchain network 106 may not be a Bitcoin network. In these embodiments, it is not excluded that the node can perform at least one or part of the functions of creating, publishing, propagating and storing blocks 151 of the blockchain 150, but not all of the functions. For example, on these other blockchain networks, "node" may be used to refer to a network entity that is configured to create and publish blocks 151 but does not store and / or propagate these blocks 151 to other nodes.

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

[0167] It should be understood that the above embodiments are described by way of example only. In more general terms, a method, apparatus or program may be provided according to any one or more of the following statements.

[0168] Enumeration Statement

[0169] The present disclosure may be described as providing a computer-implemented method and / or computer program, the computer program being contained on a computer-readable memory and being configured to, when run on one or more processors, perform the method according to any of the embodiments claimed or disclosed herein. One or more of the method steps disclosed herein may be performed by a computer-based resource, the computer-based resource comprising at least one processor. Embodiments of the present disclosure may include methods and computer-based systems for implementing the methods.

[0170] The term "mapping" can be used interchangeably with the term "coverage" or "index resource". The system disclosed herein can be referred to as a "database control system" and / or a "database permission system", a "database coverage system" and / or a "database security system" and / or a "database indexing system" and / or a "database query system". The corresponding method can be referred to as a "database security / control / permission / coverage / indexing / query method".

[0171] According to certain forms of wording, embodiments disclosed herein may be described as comprising a method for performing / implementing or facilitating any one or more of the following:

[0172] ● Use a [public or private] blockchain to provide an overlay facility or resource on a database;

[0173] Preferably, wherein said overlay facility or resource implements, facilitates or enables indexing of one or more records of said database; and / or

[0174] ● verify or implement at least one permission control (which may be referred to as "at least one authorization condition") of the database; and / or

[0175] ● enabling or using a blockchain consensus mechanism as a permission mechanism for a database, preferably wherein the consensus mechanism is the only permission mechanism used to allow / deny access to one or more records in the database; and / or

[0176] ● using a plurality of (mining) nodes in a blockchain network to implement, perform and / or enforce at least one permission control on a traditional database by the plurality of nodes performing one or more tasks and functions specified as part of a protocol of the blockchain; "permission control" may be used interchangeably with "access control" and / or "user privileges" and / or "user authentication";

[0177] ● providing overlay / indexing / mapping facilities and / or resources for associating one or more records of a database record or one or more records in a database record with one or more transactions of a blockchain or one or more transactions in a database; and / or

[0178] ● Provide a resource that acts as a hybrid or aggregate of a [traditional] database and a blockchain; and / or

[0179] ● A database search or indexing process; preferably, wherein the search or indexing process comprises:

[0180] - Using a Merkle tree or Merkle path to verify that a given transaction is traceable to >= 1 genesis transaction associated with one or more database records; preferably, wherein corresponding outputs in said one or more transactions are associated with records in said database; preferably, wherein said associations between said records and said outputs are stored in an overlay component of the system.

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

[0182] Additionally or alternatively, it may be described as providing a method for:

[0183] A mapping is used or maintained to associate at least one record in a database / at least one record of a database with at least one (corresponding) (unspent) transaction output on a blockchain. Preferably, wherein:

[0184] - coverage is provided / stored separately from said database; and / or

[0185] - the overlay is stored off-chain, but in other embodiments may be stored on-chain; and / or

[0186] - access to the at least one record is controlled by or through a consensus mechanism associated with the blockchain; preferably, wherein access to the at least one record is allowed / denied based on a successful / unsuccessful cost of the transaction output after processing a (other / cost) blockchain transaction through the consensus mechanism of the blockchain;

[0187] The processing may include validating the other transactions by a node operating or implementing the consensus mechanism; and / or

[0188] - A mapping (or "association") between the at least one record and the at least one output provides or facilitates a blockchain-based or blockchain-enabled overlay for the database.

[0189] In additional or alternative wording, the present disclosure may provide a method comprising the steps of:

[0190] ● spending an output in a first transaction on the blockchain using a (public) cryptographic key and / or a digital signature generated using the cryptographic key, wherein the key and / or the signature are provided in unlocking scripts of other transactions on the blockchain;

[0191] ● granting access to at least one database record upon consuming said output;

[0192] Preferably, wherein:

[0193] The at least one database record is associated with the output in the stored mapping and / or the first transaction.

[0194] The method may further comprise the step of updating the mapping to associate the at least one database record with the other transaction and / or an output in the other transaction.

[0195] In additional or alternative wording, the present disclosure may provide a computer-implemented method comprising:

[0196] Associating at least one record in a database with an unspent output of the first blockchain transaction, wherein the unspent output includes at least one authorization condition for verifying whether at least one party is authorized to access the at least one database record.

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

[0198] The method may also include one or more of the following:

[0199] i) granting access to the record upon successful verification of other blockchain transactions through a consensus mechanism of the blockchain network, wherein the other blockchain transactions include inputs that are set to satisfy the authorization condition for the unspent output; and / or

[0200] ii) interpreting the successful verification of other blockchain transactions as successful verification of at least one authorized party through a consensus mechanism of the blockchain network, and allowing the authorized user to access the at least one record, wherein:

[0201] The other transaction includes an input and / or an unlocking script, wherein the input and / or the unlocking script are arranged to consume the output of the first transaction; and / or

[0202] Successful verification of the other blockchain transactions by the consensus mechanism results in: the unspent output being spent and / or the other transactions being written to the blockchain.

[0203] In feature i), granting access to the record may be based on or dependent on successful verification of the other blockchain transactions by the consensus mechanism of the blockchain network. In other words, the blockchain consensus mechanism may provide a (preferably unique) verification / permission mechanism for the database. If the network nodes forming the consensus mechanism verify the transaction, the user's access request will be granted, otherwise it will be denied.

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

[0205] In additional or alternative wording, the overlay provides a mechanism for indexing one or more database records (in a database), each record being associated with a corresponding index in the overlay. The index may be based on a blockchain or may be implemented on the blockchain. Preferably, the corresponding index is associated with, represents, or indicates an unspent output in one or more blockchain transactions. One or more indexes may include an identifier, which may include an unspent output (UTXO) and / or an identifier of a blockchain transaction. The unspent output may be provided as an element in a set 154 of unspent transaction outputs associated with a blockchain (e.g., a Bitcoin memory pool).

[0206] In additional or alternative definitions, the present disclosure may be described as providing a method comprising one or more of the following steps:

[0207] associating a record in a database with an output of a blockchain transaction, wherein the output includes a locking script that specifies at least one cryptographic key that must be provided / used in order to spend the output;

[0208] receiving a request to access the at least one record, and in response to the request, generating another blockchain transaction, the other blockchain transaction including an unlocking script that provides / uses the at least one cryptographic key;

[0209] submitting the other transactions to one or more computer-based resources for verification in accordance with a protocol associated with the blockchain;

[0210] The request is deemed authorized if verification of the other transaction by the one or more computer-based resources is successful, or unsuccessful, then the request is deemed unauthorized.

[0211] Preferably, the verification is performed by one or more computer-based resources; the computer-based resources may be (mining) nodes on or in a blockchain network, the nodes being configured to implement the protocol and / or the consensus mechanism associated with the blockchain, the transactions being generated according to the protocol.

[0212] The overlay may include a portion of an overall system configured to interact with the blockchain, the blockchain network, the database and / or the DBMS.

[0213] In additional or alternative definitions, the present disclosure may be described as providing a method comprising one or more of the following steps:

[0214] Providing, generating or using a map comprising one or more entries that relate to, indicate or represent a record in a database;

[0215] The one or more entries include an association between the record and an output of the blockchain transaction.

[0216] Preferably, wherein:

[0217] i) the mapping serves as, or provides, a blockchain-related overlay on the database;

[0218] ii) the mapping and / or the one or more entries include machine-readable code for associating the record with an output of a blockchain transaction, preferably wherein a) the transaction has been written to the blockchain; and / or b) the output has not been spent.

[0219] Any of the embodiments described herein may include one, some, or all of the following steps:

[0220] ● generating at least one blockchain transaction, the at least one blockchain transaction comprising a plurality of outputs, each output representing or associated with at least one record, at least one record group (a set of records), or all records in a database. The at least one transaction may be referred to as a "genesis transaction" or "root transaction" of the overlay disclosed herein;

[0221] ● Consume an output associated with a record (or a group of records); the consumption of the output can be interpreted by the system implementing the overlay to mean that an event (e.g., an access operation or other processing event) has occurred for one or more records associated with the output, and / or has been authorized through the consensus mechanism of the blockchain.

[0222] ● Searching for a target (unspent) output in a transaction on the blockchain ledger, the target output being associated with a record or group of records in the database;

[0223] The search may include using a Merkle path or proof to locate the transaction; the search may include using a Merkle proof or path having a root transaction disclosed herein at the root of the Merkle path; for example, the search may include an SPV (style or similar) search that does not require downloading the entire blockchain.

[0224] The present disclosure may also provide a computer-implemented system configured to perform the method of any embodiment disclosed herein. The system may include an overlay component configured to interact with the following items:

[0225] The blockchain formed in accordance with the Agreement; and / or

[0226] a network of nodes arranged to implement a consensus mechanism specified and / or required by the protocol; and / or

[0227] databases; and / or

[0228] Digital wallet; and / or

[0229] The DBMS associated with the database.

[0230] The system may include one or more of the following: 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 related to database records; hardware and / or software configured to facilitate performance of any function or method step disclosed herein.

[0231] The overlay component may be used to perform one, some, or all of the following:

[0232] ● Generate blockchain transactions formed according to or in compliance with the protocol;

[0233] ●Communicate with the database and / or the DBMS;

[0234] ● submitting the transaction to the network for verification and / or mining;

[0235] ●Searching for a target transaction and / or outputs provided in the target transaction on the blockchain.

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

[0237] Enumeration clause set 1:

[0238] Clause 1. A computer-implemented method, the method comprising:

[0239] Associating at least one database record with a blockchain transaction (Tx), wherein the blockchain transaction includes a permission mechanism for specifying and / or verifying at least one authorized party (AP) that is authorized to process the at least one database record. The process may include "receive", "store", "read", "modify" and / or "delete".

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

[0241] The term "authorization mechanism" can be used interchangeably with "at least one authorization condition". The term "attribute" can be used in place of "mechanism".

[0242] Clause 2. The method according to clause 1, wherein:

[0243] The permission mechanism includes a script and / or at least one encryption key associated with or controlled by the at least one authorized party.

[0244] Clause 3. A method according to clause 1 or 2, wherein:

[0245] i) the permission mechanism is used to verify access operation requests using a consensus mechanism associated with the blockchain [protocol]; and / or

[0246] ii) the script includes or implements a control operation that enables or facilitates one or more of the at least one authorized party to selectively access the at least one database record;

[0247] Preferably, the control operation may include a selection operation (such as IF or CASE, etc.), and / or a Boolean operator (such as OR, AND, XOR or NOT, etc.).

[0248] Clause 4. A method according to any of the preceding clauses, comprising the following steps:

[0249] The associating step is repeated to provide a plurality of associations, each association associating at least one database record with a blockchain transaction.

[0250] Clause 5. A method according to any of the preceding clauses, wherein:

[0251] i) the mapping is stored on the blockchain or in an off-chain resource; and / or

[0252] ii) The mapping includes an identifier of a database record (REC ID) and / or an identifier of a blockchain transaction (TxID) and / or an output of a blockchain transaction.

[0253] Clause 6. A method according to any of the preceding clauses, comprising the following steps:

[0254] An event log is provided, the event log implementing, enabling or facilitating the functionality of a database transaction log; preferably, wherein:

[0255] i) the event record includes a list of all or some of the blockchain transactions historically associated with the record in the database; and / or

[0256] ii) The event record is stored on or off the blockchain.

[0257] A single blockchain transaction may provide historical information, i.e., a transaction log of the database records; thus, a master index representing all of the blockchain transactions recorded in the database provides a complete transaction log of the entire database.

[0258] Clause 7. A method according to any of the preceding clauses, wherein:

[0259] i) processing the at least one database record comprises at least one of: accessing the database record, reading from the database record, deleting the database record, modifying the database record, or writing to the database record; and / or

[0260] ii) each database record relates to, stores and / or represents at least a portion of data, and said data:

[0261] is stored on or off the blockchain, or

[0262] is pointed to or referenced from the blockchain transaction; and / or

[0263] iii) The database is a graph database, a relational database or a SQL database.

[0264] Clause 8. A method according to any preceding clause, wherein the blockchain transaction comprises one or more of the following:

[0265] i) data relating to or associated with the database record;

[0266] ii) a pointer, reference or identifier to the database record or its storage location;

[0267] iii) data related to one or more other database records to which the database record is associated.

[0268] Clause 9. A method according to any of the preceding clauses, wherein:

[0269] The at least one authorization condition is configured to facilitate a request or attempt to unlock / satisfy / redeem a locking script associated with an unspent output (UTXO) of the blockchain transaction, wherein:

[0270] i) the UTXO is associated with a party in an index or overlay and / or the record;

[0271] ii) the UTXO can only be unlocked / satisfied / redeemed after the consensus mechanism of the blockchain network successfully verifies the transaction;

[0272] iii) unlocking / satisfying / redeeming the locking script includes providing at least one required cryptographic key;

[0273] iv) unlocking / satisfying / redeeming the locking script results in an update or change to the master index;

[0274] v) Unlocking / satisfying / redeeming the locking script causes the UTXO to be spent to the address specified in the input of other blockchain transactions;

[0275] vi) updating the mapping to associate the other blockchain transaction with the database record.

[0276] Any incorporation by reference of the above-mentioned documents is limited so that no subject matter is incorporated that is inconsistent with the explicit disclosure provided herein. Any incorporation by reference of the above-mentioned documents is further limited so that no claims included in these documents are incorporated herein by reference. Any incorporation by reference of the above-mentioned documents is further limited so that no definitions provided in these documents are incorporated herein by reference unless expressly included herein. In the event of an inconsistency between the usages of this document and a document incorporated by reference, the usage in the incorporated reference or references shall be deemed supplementary to that of this document; for irreconcilable inconsistencies, the usage in this document controls.< / pa>

Claims

1. A computer-implemented method, the method comprising: The record (505) in the database (506) is associated with the first blockchain transaction (152 i ), wherein the unconsumed output (203) comprises at least one authorization condition for verifying whether at least one party is authorized to access the database record (505); After successfully verifying other blockchain transactions through the consensus mechanism of the blockchain network (152 j ), granting access to the record, the other blockchain transaction including an input that is set to satisfy the at least one authorization condition of the unspent output (202).

2. The method according to claim 1, wherein: The at least one authorization condition comprises at least a portion of at least one encryption key and / or script associated with or controlled by the at least one party; and / or The at least one authorization condition is configured to specify and / or authenticate the at least one party; and / or The at least one authorization condition is a required characteristic of the script specified by a protocol associated with the blockchain and / or implemented by a network of nodes operating according to the protocol associated with the blockchain.

3. The method according to claim 1 or 2, wherein: i) the at least one authorization condition is for validating a request to process the record using the consensus mechanism associated with the blockchain [protocol]; and / or ii) the unconsumed output comprises a script, the script comprising or implementing a control operation, the control operation enabling or facilitating selective access to at least one record by one or more of the at least one party; Preferably, the control operation may include selection operations such as IF or CASE, and / or Boolean operators such as OR, AND, XOR or NOT.

4. A method according to any preceding claim, comprising the steps of: The associating step is repeated to provide a plurality of associations, each association associating at least one record with an unspent output of the same or another blockchain transaction.

5. A method according to any preceding claim, wherein associating the record with the unconsumed output provides a mapping, the mapping: i) stored on the blockchain and / or in off-chain resources; and / or ii) including an identifier of the record and / or an identifier of the blockchain transaction and / or an unspent output of the blockchain transaction.

6. A method according to any preceding claim, comprising the steps of: An event history record is provided, the event history record implements, enables or facilitates the functionality of a database transaction log; preferably, wherein: iii) the event history includes a list of all or some of the blockchain transactions historically associated with one or more records in the database; and / or iv) The event history record is stored on or off the blockchain.

7. A method according to any preceding claim, wherein: 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 the data: is stored on or off the blockchain, or is pointed to or referenced from the blockchain transaction; and / or iii) the database is a graph database, a relational database or a SQL database; and / or comprises a database management system (DBMS).

8. A method according to any preceding claim, wherein the blockchain transaction comprises one or more of the following: iv) data related to or associated with the record; v) a pointer, reference or identifier to the record or its storage location; vi) data relating to one or more other records to which the record is associated.

9. A method according to any preceding claim, wherein: The at least one authorization condition is configured to facilitate a request or attempt to unlock / satisfy / redeem a locking script associated with an unspent output (UTXO) of the blockchain transaction, wherein: vii) the UTXO is associated with the record; viii) the UTXO can only be unlocked / satisfied / redeemed after the consensus mechanism of the blockchain network successfully verifies the transaction; ix) unlocking / satisfying / redeeming the locking script includes providing at least one required cryptographic key; x) unlocking / satisfying / redeeming the locking script results in an update or change to the index or overlay; xi) Unlocking / satisfying / redeeming the locking script causes the unspent output to be spent to the address specified in the input of the other blockchain transaction.

10. A computer-implemented method comprising the steps of: generating at least one blockchain transaction, the at least one blockchain transaction comprising at least one output, the at least one output representing or associated with at least one record, at least one group of records, or all records in a database; Searching a target transaction on a blockchain ledger for a target output, the target output being associated with a record or a group of records in a database and having the at least one blockchain transaction in its on-chain history; The searching includes using a Merkle path or proof to locate the target transaction.

11. A computer implemented system arranged to implement coverage according to one or more of the preceding claims.

12. A computer-implemented system comprising a blockchain-implemented database overlay component, the overlay component being configured to communicate with: The blockchain formed in accordance with the Agreement; and / or a network of nodes arranged to implement a consensus mechanism specified and / or required by the protocol; and / or databases; and / or Digital wallet (502a, 502b, 502c); and / or The DBMS associated with the database.

13. The system of claim 12, wherein the overlay component is operable to perform one, some, or all of the following operations: Generate blockchain transactions formed according to or in compliance with the protocol; Communicating with the database and / or the DBMS; Generate cryptocurrency addresses; submitting the transaction to the network for verification and / or mining; Searching the blockchain for a target transaction and / or an output provided in the target transaction.

14. A computer device, comprising: a memory, the memory comprising one or more memory units; as well as A processing device, comprising one or more processing units, wherein the memory stores codes arranged to be executed on the processing device, the codes being configured to execute the method according to any one of claims 1 to 10 when executed on the processing device.

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

Images