Blockchain Database Management System

Abstract

To provide a blockchain database management system.SOLUTION: In one aspect, the present disclosure proposes methods, devices and systems for providing new structured data pertaining to blockchain transactions to implement a new data structure. The new data structure is provided for a distributed database. In another aspect, a new distributed data management system (DBMS) is provided that can manage data associated with the new data structure. Unlike conventional DBMSs, the present disclosure provides a blockchain DBMS that is configured to managed data associated with blockchain transactions, the data being stored in the new data structure. In another aspect, the present disclosure provides a method for generating or providing blockchain transactions for implementing standard database commands that are received for accessing or manipulating a database, the data being stored on the new data structure.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present disclosure generally relates to methods and systems for implementing a database and / or database management system for data related to transactions associated with a distributed ledger. More particularly, but not limited to, the present disclosure is suitable for applications where an existing database is to be migrated to or implemented in relation to a distributed ledger, i.e., after such a migration, data for the database is associated with transactions related to the distributed ledger.

Background Art

[0002] In this specification, the term “blockchain” is used to include all forms of electronic computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, public and private blockchains, and their variations. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. While Bitcoin may be referenced here for convenience and illustrative purposes, this disclosure is not limited to use with the Bitcoin blockchain, and it should be noted that alternative blockchain implementations and protocols relating to any kind of digital asset or representation of a digital asset fall within the scope of this disclosure. The terms “user,” “sender,” and “receiver” may refer here to computing or processor-based resources. The term “Bitcoin” is used here to include any version or variation derived from or based on the Bitcoin protocol. The term “digital asset” may refer to any transferable asset such as cryptocurrency, tokens representing at least part of property, smart contracts, licenses i.e., software licenses, or DRM contracts for media content. It will be understood that the term "digital asset" is used throughout this specification to represent products that may be transferred for payment in a transaction from one entity to another, or that may be associated with value that may be offered as such payment.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based, decentralized system consisting of blocks, each block comprising a transaction. Each transaction is a data structure that encodes the transfer of control of a digital asset among participants in the blockchain system, and includes at least one input and at least one output. Each block contains the hash of the previous block to that block, and together they are chained to create a permanent, immutable record of all transactions written to the blockchain from its beginning. A transaction contains a small program called a script embedded within the transaction's input and output, which specifies how and by whom the transaction's output can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be "validated." Network nodes (miners) perform the work to ensure that invalid transactions are rejected from the network and that each transaction is valid. Software clients installed on the nodes perform this validation work on unconsumed transactions (UTXOs) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE, the transaction is valid and is then written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must i) be validated by the first node receiving the transaction - if the transaction is validated, the node relays it to other nodes in the network, ii) be added to a new block built by miners, and iii) be added to the mining, i.e., the public ledger of past transactions.

[0005] Once stored in the blockchain as a UTXO, a user can transfer control of the associated resources to another address associated with the input in another transaction. This transfer is typically done using a digital wallet. This digital wallet may be a remotely hosted service associated with a domain of operation such as a device, physical media, program, application (app) on a computing device such as a desktop, laptop, or mobile terminal, or the internet. A digital wallet can store public and private keys, track ownership of resources, tokens, and assets associated with a user, receive or consume digital assets, and be used to transfer cryptocurrencies or tokens that may be associated with digital assets such as licenses, property, or other types of resources.

[0006] While blockchain technology is most widely known for its use in relation to digital assets, i.e., cryptocurrency implementations or tokens, digital entrepreneurs are beginning to explore the use of both the cryptographic security system on which digital assets are based and other types of data that can be stored on the blockchain to implement new systems. It would be extremely advantageous if blockchain could be used for automated tasks and processes that are not limited to the scope of digital assets. Such solutions would be more versatile in their application examples while still leveraging the advantages of blockchain (e.g., permanent, tamper-proof event records, distributed processing, etc.). Thus, a public blockchain would function as an immutable, distributed data storage system that leverages both cryptography for security and economic incentives.

[0007] However, such security elements are not always present in databases such as distributed databases and / or private and / or corporate databases. A database in which parts of the data are stored in several different physical locations and computing power is distributed among the relevant nodes is called a distributed database. This, therefore, leaves such distributed databases vulnerable to attacks. Security features are important for many companies that use distributed databases, and this can be managed by a distributed database management system (distributed DBMS, or DDBMS). A DDBMS is a computer software system that integrates distributed data, so that it can be managed as if the distributed data were stored in a single server or computing resource, and it provides a systematic means for updating and querying data in a distributed database.

[0008] There are many parallel lines that can be drawn between blockchain and distributed databases, such as having a decentralized storage of information across a network to avoid having a single point of failure. The advantages of blockchain stem from its underlying data structure, where cryptographic hash functions are used to link data, leading to an immutable record of all valid actions from its inception. This is a crucial feature for transparency and auditing that private or existing databases cannot provide. However, even so, there is no simple technique for migrating current distributed databases and DDBMS systems to a distributed ledger, i.e., to be incorporated into a blockchain. Many proposed blockchain solutions that claim to manage data do not provide interoperability with current distributed databases, which is a technical obstacle for companies that should change to a more secure blockchain-based implementation form to manage and store data. From a commercial standpoint, such interoperability would require greater investment from companies, which may lead to opposition from companies to such a change.

[0009] This disclosure addresses these technical issues by proposing techniques that enable the implementation of a distributed database on a distributed ledger, i.e., a blockchain, or by utilizing existing and general database functions, such as those already used in existing (distributed) databases, for the purpose of using a distributed ledger, i.e., a blockchain. Accordingly, this disclosure provides existing databases and their functions, as well as embodiments and implementations for a new data structure compatible with the blockchain, thereby ensuring interoperability and scalability and contributing to the additional security provided by the blockchain implementation. This disclosure also provides a blockchain-related DBMS for managing this new data structure. In this way, this disclosure enables a means to achieve interoperability with existing non-blockchain databases, which is important for the gradual transition of current (private enterprise or other) database systems to a more secure and robust equivalent blockchain system. [Overview of the project] [Means for solving the problem]

[0010] In one aspect, the Disclosure proposes a method, device, and system for providing a novel structured data storage technique related to blockchain transactions in order to implement a new data structure. This new data structure is provided for implementing a distributed database. In another aspect, a novel distributed data management system (DBMS) is provided that can manage data associated with the new data structure. However, unlike conventional DBMSs for conventional databases, the Disclosure provides a blockchain DBMS configured to manage data associated with one or more blockchain transactions.

[0011] In another aspect, the disclosure provides a method for generating or providing one or more blockchain transactions for executing one or more standard database commands received to access or manipulate a database, wherein the data is stored on a new data structure.

[0012] Accordingly, aspects and embodiments of this disclosure propose a system in which existing and known (general) database functions can be provided by structuring data in a distributed ledger, i.e., a blockchain, using the proposed data structure, and the proposed DBMS provided for managing the proposed data structure is configured to interpret and process standard database commands (such as standard Structured Query Language (SQL) commands) using the blockchain in order to access and manage the data associated with the data structure.

[0013] Throughout this specification, the word “comprise,” or variations such as “includes,” “comprises,” or “comprising,” shall be understood to imply the inclusion of the element, integer, or step, or group of elements, integers, or steps, but not the exclusion of any other element, integer, or step, or group of elements, integers, or steps.

[0014] Hereinafter, aspects and embodiments of the present disclosure will be described merely as examples and with reference to the attached drawings. [Brief explanation of the drawing]

[0015] [Figure 1] This flowchart illustrates a method, according to a first aspect, for providing a data structure for storing and / or managing data associated with transactions related to a distributed ledger, the method being implemented by one or more processors related to a data management system (DBMS). [Figure 2]This is a schematic diagram illustrating a data structure according to a first aspect for storing and / or managing data associated with transactions related to a distributed ledger. [Figure 3a-1] This is a schematic diagram illustrating a transaction for managing data using a data structure according to the first embodiment. [Figure 3a-2] This is a schematic diagram illustrating a transaction for managing data using a data structure according to the first embodiment. [Figure 3b] This is a schematic diagram illustrating a transaction for managing data using a data structure according to the first embodiment. [Figure 3c] This is a schematic diagram illustrating a transaction for managing data using a data structure according to the first embodiment. [Figure 4a] This flowchart illustrates an identification and access verification method for a DBMS for processing transactions associated with a distributed ledger, according to a second aspect of the present disclosure, in which the method is implemented by one or more processors associated with the DBMS. [Figure 4b] This flowchart illustrates an identification and access verification method for a DBMS for processing transactions associated with a distributed ledger, according to a second aspect of the present disclosure, in which the method is implemented by one or more processors associated with a client entity. [Figure 5] A flowchart illustrating a method for implementing a DBMS for managing data associated with a transaction, according to a third aspect of the present disclosure, wherein the transaction is associated with a distributed ledger and is implemented by one or more processors associated with the DBMS. [Figure 6] This is a schematic diagram illustrating a DBMS for use with transactions associated with a distributed ledger, according to a second and / or third embodiment. [Figure 7] This is a schematic diagram illustrating a computing environment in which various aspects and embodiments of this disclosure can be implemented.

Best Mode for Carrying Out the Invention

[0016] According to a first aspect, the present disclosure provides a computer-implemented method for providing a data structure for storing and / or managing data associated with one or more transactions related to a distributed ledger. The method is implemented by one or more processors associated with a database management system (DBMS) for a distributed ledger, an identifier for a database D to be used to obtain data for one or more transactions related to a distributed ledger, and creating a database transaction type comprising one or more table transaction identifiers (TTxID), wherein a given TTxID among the one or more TTxID is unique to a given table among one or more tables related to the identified database D, and the given TTxID is related to a transaction related to the distributed ledger for the given table.

[0017] The method also includes creating a table transaction type comprising an identifier for a table T, wherein the table is among one or more tables related to the identified database D, and one or more entries related to the identified table T.

[0018] There are many parallel lines that can be drawn between distributed ledgers, or blockchains, and distributed databases, which have decentralized storage of information across a network to avoid having a single point of failure. The advantages of blockchains stem from the data structure beneath them, where each block contains the hash of the previous block to that block and is chained together, for example, where a cryptographic hash function is used to link the data, leading to an immutable record of all valid actions from its beginning. This structure for data in a blockchain is a crucial feature for the advantages of transparency and auditing that existing databases cannot provide. Advantageously, the method according to the first aspect provides a technique for providing a data structure based on data types associated with one or more transactions associated with a distributed ledger, i.e., database data types and table data types as presented above, while identifying transactions representing tables with their associated entries. The data structure according to the first aspect is a data structure that enables general database functions to be provided and implemented through the structuring and management of data within the blockchain, and therefore, from here on, for ease of reference, will be referred to as a blockchain (based) data structure. For example, common database functions used in an existing database may be based on an array of data in a table having entries that can be identified by rows in a given table, and the given table is then operated by common database commands, such as using Structured Query Language (SQL) commands. By implementing a data structure for cases where data associated with one or more blockchain transactions can also be stored and manipulated using these same common functions, a first aspect of this disclosure enables interoperability with existing databases and / or distributed databases, making the process of converting or transitioning thereto to using blockchain instead of existing databases easy, scalable, seamless, simple, fully transparent, traceable, and efficient.Therefore, the blockchain data structure proposed in the first embodiment can provide structured storage throughout the database based on a blockchain transaction identifier (TTxID) associated with a given transaction.

[0019] In some embodiments, a table transaction type of the first embodiment includes one or more entry transaction identifiers (ETxIDs), where a given ETxID is specific to a given entry E among one or more entries relating to an identified table T, and the given ETxID relates to a transaction relating to a distributed ledger for a given entry E. The method also includes creating an entry transaction type comprising one or more data pairs, each data pair relating to an entry in the identified table T, and each data pair comprising a reference R that identifies a location in the identified table, and a value VL for the identified location.

[0020] In addition to the above advantages of the first aspect, the above embodiment defines an entry data type for storing the transaction identifier of a blockchain transaction related to entry E, and entry E is associated with a table T of a given database D. Therefore, any change to an entry can be implemented by a transaction that consumes the latest transaction (identified by ETxID in the entry data type), where the new transaction accommodates the updated data. To be consistent, each dependent transaction must also be updated to reflect the latest transaction identifier TxID, which can be either ETxID referring to the entry transaction or TTxID referring to the table transaction. That is, when the value of entry E is updated, the entry transaction identifier ETxID in the table transaction must also be updated, and as a result, the table transaction identifier TTXID in the database transaction referring to the updated entry E must be updated.

[0021] Advantageously, this provides a nested data structure according to the first aspect, where any change to entry E requires an update of the entry data type with a new ETxID, an update of the table such that the TTxID associated with entry E includes the new ETxID, and an update of database D with the updated TTxID, and the data from the data structure cannot be easily removed or modified (without modifying the entire chain of transactions associated with a given entry E), enabling a robust immutable and fully auditable record of changes to the database and its current state. Further advantageously, using such a nested data structure, it suffices to monitor only the transactions related to the database (identified by database name D or table T) so that the data can be reconfigured or queried. This is similar to storing a compressed form of the database instead of a complete record of the database.

[0022] In some embodiments, data references and / or values ​​can be stored directly in table T, rather than in the entry data type, i.e., they can be included within the table transaction type itself. This means that data can be identified based on the table transaction (TTxID) within the database transaction data type. However, for ease of referencing and consistency, nested data structures in which both ETxID and TTxID are stored are referenced below, but the disclosure is not limited thereto.

[0023] In some embodiments, a transaction associated with one or more TTxIDs or ETxIDs is associated with one or more unconsumed transaction outputs (UTXOs). In some embodiments, the UTXO for a given transaction includes an output script that can be consumed by subsequent transactions associated with the identified database D and / or table T. In some embodiments, the UTXO for a given transaction includes unconsumable outputs associated with the consumable output script for a given transaction.

[0024] Advantageously, including non-consumable output, such as an OP_RETURN script, can be used to indicate a valid transaction involved in performing one or more database operations. This allows an operable or consumable UTXO related to an OP-RETURN, including the latest update of database D or table T or entry E, to be easily and readily identified by one or more processors associated with a client entity for a user interacting with the database, while it resides in the distributed ledger, i.e., the blockchain. A further advantage is that the supply of non-consumable output identifies the transaction identifier (TTxID or ETxID) used for the latest database operation or update. The client entity can simply query the blockchain, i.e., the distributed ledger, to identify the non-consumable OP_RETURN transaction associated with database D from which a consumable payload or UTXO can be retrieved. Once identified, the UTXO for the recipient can then be processed by executing the consumable output script.

[0025] A first aspect of the present disclosure also relates to a data structure, i.e., a nested data structure for storing and / or managing data associated with one or more transactions relating to a distributed ledger, wherein the data structure is managed by one or more processors associated with a data management system (DBMS) for the distributed ledger, and the data structure includes data transaction types, table transaction types, and entry transaction types, as presented above with respect to the first aspect. In some embodiments, the data structure is a nested transaction storage structure configured to store the entire identified database D, based on storing TTxIDs and, in some embodiments, ETxIDs related to the identified database D, as described above.

[0026] Some embodiments of this disclosure relate to a method for executing one or more database requests by executing transactions associated with a distributed ledger, wherein the transactions use blockchain-based data structures as presented above. The method is executed by one or more processors associated with a database management system (DBMS) and relates to generating one or more transactions associated with a distributed ledger to perform one or more actions of creating, updating, or modifying / deleting one or more of the following: database transaction types, table transaction types, or entry transaction types. The method also includes providing one or more outputs based on the created transactions associated with the distributed ledger. In some embodiments, the outputs are consumable output scripts and / or non-consumable output scripts as described above. In some embodiments, the generation of one or more transactions is based on processing or consuming previous transactions associated with a database or table or entry. The method also includes updating one or more of the data types presented above based on the output of previous transactions. A sequence of steps for generating transactions to execute one or more database requests, providing outputs, and updating data types is described in detail with respect to the following diagram.

[0027] With respect to the embodiments described above, and in conjunction therewith, the embodiments relating to the embodiments include the steps of sending a request relating to one or more of creating, updating, modifying, or deleting one or more of a database transaction type, a table transaction type, or an entry transaction type, when performed by one or more processors relating to a client entity for performing one or more requests relating to a database, and monitoring a distributed ledger for at least one transaction output associated with a transaction being generated by a DBMS relating to each request.

[0028] Advantageously, the embodiments described above provide a method for using standard or known database commands and functions, such as standard Structured Query Language (SQL), to manipulate data structures of the first embodiment, which are associated with a distributed ledger and include transaction identifiers associated with them in the distributed ledger. Advantageously, by enabling the use of standard SQL commands for use with blockchain-implemented data structures, users, or client entities associated with a given user, will not detect changes before, during, and after the migration of an existing database to a blockchain-based implementation of the database. This seamlessness is important for the gradual transition of enterprise systems to a more secure and robust equivalent blockchain system for the database. For easier adoption and interoperability with current database systems, the embodiments described above enable the application of standard SQL commands to blockchain-based data structures of the first embodiment using one or more consecutive blockchain transactions. While the selection of SQL commands is described herein, similar methods can be applied to map the entire standard SQL library to blockchain-based data structures of the first embodiment.

[0029] A second aspect of this disclosure relates to a computer implementation method for managing access to a data management system (DBMS), where the DBMS manages data relating to transactions associated with a distributed ledger, and the data is provided in a database. In some embodiments, the database is implemented using the data structures described above. The method includes the step of creating a record relating to a given user in response to a request to register with the DBMS, when performed by one or more processors relating to the database, the record containing an identifier for the given user among a plurality of users. The method includes obtaining a public key P relating to the given user, where the public key is part of a cryptographic key pair relating to the given user, the cryptographic key pair containing a private key V for the given user. The method then includes obtaining or assigning one or more attributes relating to the given user, each attribute being associated with a setting relating to access to a database managed by the DBMS. In some embodiments, the setting for a given attribute checks whether the given attribute is associated with permission to perform one or more of the read, write / update, modify, or delete operations relating to the database. This is sometimes referred to as permission settings. The method also includes the steps of updating a record based on an acquired public key P and one or more attributes associated with a given user, and storing or providing the updated record related to the DBMS.

[0030] Accordingly, a second aspect of this disclosure relates to a management system for facilitating requests relating to the blockchain-based data structure of the first aspect. For example, a data management system (DBMS) may be required to help access data in the data structure, configure transactions and / or submit them to a distributed ledger for the data structure, and maintain records of associated transaction IDs (which may be TxIDs or ETxIDs). This data management is similar to a standard database management system (DBMS) or distributed DBMS (DDMS) of conventional distributed databases that work to integrate a distributed data system, and may be a third-party service that can be implemented by a remote server or by one or more distributed processors that implement single-server functionality, or even a client-side implementation, i.e., a computing entity for a client entity or organization that has sufficient resources to manage its own DBMS.

[0031] Advantageously, the method for managing access to the data management system of the second aspect protects the integrity of the blockchain implementation database of the first aspect and provides security by acting as an identity verification resource. The second aspect implements multi-level permission control, such as read-only, write-only (to update, modify, or delete data), or both read and write privileges, based on attributes associated with each user registered in the DBMS. The use of cryptographic keys associated with the client entity for a given user in the created user record enhances the security of the DBMS, which can be implemented off-chain as presented above. This is described herein as an off-chain implementation, i.e., not implemented in the distributed ledger itself, or not using the distributed ledger itself, but this disclosure also relates to on-chain implementations that use known methods, including a certificate authority for a public key infrastructure (PKI), a session key derived from an initial shared secret, or a standard username / password authentication system encrypted within a transaction. In some embodiments, the method of the second embodiment may be carried out by a system administrator component or resource responsible for DBMS registration and key distribution, along with a record of access attributes that can be used to write to or read from the database. In some embodiments, user records may be stored off-chain as local files in the form of objects (which should be used as such when manipulated using, for example, an object-oriented programming language), or they may be encrypted on the blockchain with respect to a TTxID or ETxID.

[0032] In some embodiments, an attribute may refer to a team or category to which a user is associated; for example, within an organizational structure, an attribute may be the name of a department. Therefore, a user with the department attribute "Human Resources" (HR) in a registered user record may have settings with valid permissions (permission settings or access attribute settings) to access databases or tables related to "Human Resources Management," but not valid settings to access databases or tables related to the accounting department. Subcategories of attributes for different users may also have different settings. For example, a user record with HR Director status in the HR department may have full access (read and write) to the HR database, but only "read" access to some accounting databases, such as payroll ledgers. Another user in the same HR department with HR Assistant status may not have any valid permission settings for the payroll ledger database, and similarly only have read access to the HR database.

[0033] In some embodiments, the per-attribute settings may also be provided in a registration request received from a given user (or a client entity associated with a given user), or the settings may be retrieved from computing resources associated with the DBMS, or the settings may be predetermined per attribute by a system administrator or equal computing resources for a database managed by the DBMS.

[0034] In some embodiments relating to the second aspect, the disclosure also provides a computer implementation method for implementing a DBMS for accessing a database, the method comprising the step of obtaining a request from a client entity for an action relating to the database, the client entity relating to a given user among a plurality of users, and the request including a digital signature associated with the given user. In some embodiments, the request is a request to read, write, modify, or delete data in the database. In some embodiments, the database is implemented using the data structures of the first aspect and embodiments described above. The method also includes determining that a given user is authorized to access the database. In response to a successful determination, the method includes verifying that the digital signature is associated with a given user based on a user record relating to the DBMS. In some embodiments, the user record is created when registering with the DBMS as described above. In response to a successful verification, the method includes generating a message based on the current instance of the user record and the request.

[0035] Advantageously, once a user is registered as described above, based on the information in the user record created during registration, a second aspect of this disclosure provides a method for implementing a DBMS for processing user requests relating to the blockchain data structure of the first aspect, so as to provide a single-point reference to distributed data and to verify that a given user has permission, i.e., valid settings, to perform the request.

[0036] In some embodiments, the step of determining whether a user is authorized includes determining whether a user record associated with a given user exists in the DBMS at the time of registration with the DBMS. In some embodiments, the step of verifying the digital signature is based on determining whether a private key V, or a signing key K used to sign the request, is associated with a public key P associated with a given user in the user record. This is advantageous because two checks are performed before a given user or a client entity associated with a given user is allowed to have arbitrary access to data in the database, thus enhancing the security of the DBMS at the time a request for database access is made. Firstly, if the request is from an unregistered user, the request is immediately rejected because there is no associated user record for the requesting user to verify permission for access. Secondly, the identity of the requesting user is checked by verifying that the digital signature in the request is indeed associated with a public key P linked to the user record, and as a result, the signature can be verified using this public key P. If a malicious user submits a request, the public key P held with the user record cannot verify the digital signature (the digital signature is based on the same user's private key V).

[0037] In some embodiments, in response to an authorization failure, the method includes generating an error notification specifying that a given user is not authorized to access the database or is not registered to access the database. Also, in response to a digital signature verification failure, the method generates an error notification specifying that the signature applied to the request is not valid for a given user.

[0038] A second aspect of the Disclosure, when implemented by one or more processors associated with a client entity, also provides a method for registering with a DBMS, comprising the steps of: generating a request for registration with the DBMS, wherein the request relates to a given user; and providing or accessing one or more attributes associated with the given user, wherein each attribute is associated with a database-related setting managed by the DBMS. The method also includes generating a private key V related to a given user, wherein the private key is part of an encryption key pair, which includes a public key P for a given user; and computing a public key P based on the private key V. In some embodiments, the private key may be generated using one or more known means, i.e., based on a secret seed or random number generator as a starting point, or based on a network identifier of a client entity related to a given user. The key V is kept secret, but is used to generate the public key P in such a manner that any message encrypted or signed using the private key V can only be activated, read, or decrypted using the public key P. The method also includes sending the public key P and one or more attributes to the DBMS. Advantageously, this enhances the security of the DBMS and improves the privacy of all requests to perform one or more actions related to the blockchain-implemented database.

[0039] A second aspect of this disclosure also includes a method for accessing data related to a database when performed by one or more processors related to a client entity. In this case, the method comprises the step of generating the above-described request relating to database operations, the request relating to a given user, and the database being managed by a DBMS. The method includes generating a digital signature based on a private key V for a given user, the private key being part of a cryptographic key pair including a public key P for a given user, where the public key P is provided to the DBMS. The method then includes applying the digital signature to the request and sending the signed request to the DBMS. In some embodiments, the method includes a method of registering with the DBMS as presented above.

[0040] In some embodiments, the method includes generating a signing key K based on a private key V, where the signing key is a short-term key. In some embodiments, the cryptographic key, i.e., the public key and / or private key and / or session key for a given client entity, is a stable elliptic curve digital signature algorithm (ECDSA) key. The ECDSA public key is, for example, a compressed and hex-encoded valid point on the secp256k1 curve. In some embodiments, a secure hash of a secret seed or generator G associated with the client entity may be used to generate the private key V. G is typically a known constant, which may be known or shared with one or more entities associated with the client entity, for one or more blockchain transactions in some embodiments. In some embodiments, the public key P may be based on a network identifier associated with a public (network) address for the client entity, and may include a secure hash value, i.e., may be based on a secure hash algorithm (SHA).

[0041] A digital signature associated with a given user's private key V also conveniently provides an auditable record of the request submission, which can be verified using the user record without the given user needing to directly interact with the blockchain. In some embodiments, the system administrator, i.e., the computing resources providing this functionality to the DBMS, may batch requests into a single blockchain transaction. Including the signed requests within OP_RETURN still provides a clear audit trail, thereby increasing transparency and accountability while maintaining an immutable record on the blockchain and ensuring interoperability with conventional systems. In some embodiments, the OP_RETURN payload can be encrypted using a deterministically derived key before the transaction is configured (if the request is a write request). In some embodiments, attributes can also be attached along with data references or hashes of references for easier retrieval, if necessary.

[0042] In a third aspect, the disclosure relates to a computer implementation method for implementing a database management system (DBMS) for managing a database relating to transactions associated with a distributed ledger, the method comprising the step of receiving a message relating to a current instance of a user record for a given user of one or more users, the request relating to a database, and the request being made by a given user. The method includes the step of parsing the request relating to the database, the parsing step comprising the step of retrieving one or more attributes associated with a given user from the current instance, and the step of verifying that a setting for each of the retrieved attributes is valid for a request made by a given user. In some embodiments, the verification includes checking whether a setting for a given attribute of one or more attributes indicates that a given user has permission to access the database for the request made. In response to successful verification, the method includes performing one or more actions relating to the database based on the request, the database relating to a data structure provided as described in the first aspect. If the request relates to a read operation, the steps to be performed include obtaining one or more transaction identifiers (TTxID, ETxID) related to the request, wherein each obtained transaction identifier relates to a transaction, thereby associating the data for the transaction with a data structure, and further including accessing the data related to the obtained transaction identifiers (TTxID, ETxID) from the data structure. If the request relates to a write, modify, or delete operation, in addition to the steps to obtain, the method further includes, based on the operation, generating one or more transactions to consume or process the transactions associated with the obtained transaction identifiers (TTxID, ETxID), and updating the data structure with the identifiers related to the generated transactions.

[0043] In addition to the advantages already described above for improving security, reliability, and privacy when registering and / or accessing data in the blockchain-based data structure of the first aspect, the method according to the third aspect advantageously provides means for interpreting and processing standard database commands related to the database, i.e., the blockchain-based data structure. Thus, advantageously, the method according to the third aspect acts as an SQL compiler, but implements the functionality of interpreting, verifying, and executing one or more SQL commands on the blockchain, i.e., using TTxID or ETxID related to the blockchain. In addition, the method according to the third aspect also performs attribute verification on user records. Thus, assuming that a user record exists for a given user, it is checked whether the settings for attributes for that user are valid for the request subsequently made. In some embodiments, such verification is based on the method and embodiments described with respect to the second aspect. For example, continuing from the above example of an organization where the attribute is department or team, if a registered user with the HR assistant attribute makes a write request to the HR or payroll database, this will be rejected. On the other hand, if a registered user with the HR Director attribute makes a read request to the payroll database, this request is permitted to proceed further. If the appropriate settings are in place, i.e., the access permissions associated with one or more attributes are enabled, the request is performed by either obtaining the relevant transaction identifier (based on consuming the output of previous transactions by authorized or registered users with the necessary permissions) or generating one or more blockchain transactions, and providing an output script with a transaction identifier TxID (which may be a new TTxID or ETxID) for the generated transactions, and as a result, the database data type or table transaction type or entry transaction type may be updated with the new TxID.

[0044] When the request relates to read functionality, i.e., data access rather than operation, in some embodiments this may be performed off-chain by the DDMS, as there is no need to generate a transaction, and the standard SQL protocol can be used for data access (following registration and / or access verification in a second embodiment). This also advantageously allows the system to leverage standard efficiency optimization and scaling methods for easy interface with existing enterprise data management solutions.

[0045] In some embodiments, if the request relates to a write, modify, or delete operation, the steps to be performed further include a method for executing one or more transactions as described above with respect to the first embodiment, for the purpose of executing a standard database SQL command. In the embodiments concerned, the steps to be generated further include obtaining an output script associated with the obtained transaction identifier (TTxID, ETxID), and constructing further transactions based on the output script. The further transactions may be based on, or signed with, a private key V associated with a client entity of a given user, the private key being part of a cryptographic key pair including a public key P for a given user. The method then includes providing the further transactions to a distributed ledger, the further transactions being associated with a new transaction identifier (TTxID, ETxID).

[0046] Conveniently, the generation of further transactions is only possible by users who possess the necessary attribute permission settings and who can be verified using the public key P within their respective user records. Therefore, previous transactions, referenced by transactions identified within the most recent version of the data type in the blockchain implementation database, can only be consumed or accessed by registered and verified users, and consequently, their identification information is recorded or linked at each stage using keys P and V. This ensures that there is a user record associated with the most recent transaction (even if it is encrypted) using these public cryptographic keys.

[0047] In embodiments where the request relates to a write, modify, or delete operation, the steps that constitute a further transaction are performed by a Simplified Payment Verification (SPV) client associated with the DBMS, which connects the DBMS to the distributed ledger via a communication network.

[0048] An SPV client is a computing resource associated with a DBMS, ensuring that the second and third forms of DBMS connect to the blockchain (distributed ledger) via peer-to-peer connections to all nodes. However, an SPV does not mine or store copies of the blockchain, and therefore such transactions can be verified and executed efficiently and with less complexity.

[0049] In embodiments where the request relates to a write, modify, or delete operation, each transaction identifier (TTxID, ETxID) obtained is associated with a transaction containing a non-consumable UTXO, the non-consumable UTXO being associated with or containing a consumable payload, and the consumable payload being a consumable UTXO. In some embodiments, each consumable and non-consumable UTXO is stored in a UTXO set or memory associated with the DBMS, the non-consumable UTXO is an OP_RETURN output script, and one or more consumable UTXOs in the UTXO set or memory are used to constitute further transactions.

[0050] Advantageously, to facilitate quick and easy access to the data, an indexed copy of a UTXO set or subset containing the most recent relevant transactions in the database may be provided in relation to the DBMS of the third embodiment. In some embodiments, this UTXO set may be integrated with an SPV wallet or node that tracks cryptographic keys for registered users associated with the DBMS to record updates (consumption) of UTXO transactions. In some embodiments, a separate record of the index is stored as a register of all transaction identifiers (TxIDs including TTxID and ETxID in the data types of the data structure of the first embodiment), either additionally or as a replacement. Advantageously, this allows OP_RETURN data to be retrieved more easily for querying. In some embodiments, the index associated with these registers may be a simple integer count in operation, or more detailed data such as names, function output values, or hash values.

[0051] Embodiments of the present disclosure include a computing device comprising a processor and memory, the memory including executable instructions that cause the device to execute the computer implementation embodiments of the first and second embodiments described above, which are to be performed by a client entity as a result of execution by the processor.

[0052] Embodiments of the present disclosure include a DBMS system for managing access to data associated with one or more transactions relating to a distributed ledger, wherein the data managed by the DBMS is stored in a data structure such as that provided by a blockchain-based data structure of the first embodiment. The DBMS includes a registration and access management system having one or more processors configured to execute instructions for performing the method of the second embodiment described above, and a transaction execution system having one or more processors configured to execute instructions for performing the method of the third embodiment described above. The DBMS also includes one or more registers for storing a plurality of transaction identifiers relating to the database, and a UTXO set or memory for storing copies of a plurality of UTXOs relating to the database.

[0053] Embodiments of the present disclosure include a system comprising one or more computing devices, each comprising a client entity as described above, a DBMS as described above, and a communication network for communicatingly connecting each client entity to the DBMS.

[0054] In some embodiments, a computer-readable storage medium is provided, which stores executable instructions that, as a result of being executed by the processor of the computer system, cause the computer system to perform the methods of the embodiments and / or embodiments described above.

[0055] Several specific embodiments are described herein by reference with reference to the accompanying drawings, and similar reference numerals refer to similar features.

[0056] First aspect - Blockchain implementation data structure Figure 1 is a flowchart illustrating a method relating to providing a blockchain-based data structure. In other words, the figure illustrates a method for providing a data structure associated with one or more transactions associated with a distributed ledger, i.e., a blockchain, according to a first aspect. In the embodiment shown in Figure 1, a nested data structure including a database transaction data type, a table transaction data type, and an entry data type is provided according to one embodiment of the first aspect. However, it will be understood that the entry transaction identifier (ETxID) and entry data transaction type are not necessarily required for all embodiments of the first aspect, as in some embodiments the end data or value and / or reference can be provided within the table transaction data type itself. However, for ease of understanding and consistency, nested data types will be described below throughout the description and accompanying figures.

[0057] To facilitate database functionality, the data being stored must be consistently structured so that it can be managed and accessed in the expected manner as traditional databases do. The best-known example in traditional databases is Structured Query Language (SQL), which uses a standard library of functions for recording, updating, and querying data in relational databases. To provide SQL integration to blockchain data, this disclosure proposes a similar structure for data contained within blockchain transactions, and Figure 1 illustrates how to provide or implement such a data structure, also referred to herein as a blockchain database or blockchain implementation data structure. The steps in Figure 1 are performed by one or more processors associated with a database management system for creating and / or managing blockchain-related data structures.

[0058] Step 102 indicates the creation of a database transaction type, which includes an identifier for a database. This could be the name of the database to be used to store or retrieve data for one or more transactions relating to the distributed ledger, i.e., D or the first database. Database D, as indicated in the database transaction type, includes one or more tables associated with database D. The data transaction type to be created is configured to store an identifier (TTxID) for transactions relating to one or more tables.

[0059] Step 104 describes the step of creating a table transaction type, which includes an identifier for a table. This could be the name of the table, i.e., T or the first table. In step 102, table T is one of one or more tables associated with the identified database D. Table T, as shown in the table transaction type, contains one or more entries associated with table T. The table transaction type to be created is configured to store an identifier (ETxID) for the transaction associated with one or more entries.

[0060] Step 106 describes the step of creating an entry transaction type, which relates to one or more entries in table T in step 104, and in some embodiments comprises an identifier for the entry, i.e., a reference or entry name such as E or the first entry. In some embodiments, each entry relates to a row in table T. The data transaction type created is configured to store the data associated with each of the one or more entries.

[0061] Step 108 represents the step of providing one or more data pairs within the entry transaction type of Step 106. Each data pair relates to an entry E in an identified table T, and each data pair comprises a reference R that identifies the location in the identified table, and a value VL for the identified location. In some embodiments, R may represent a row number, which is the location indicated in table T, i.e., the 1st row or the 9th row, etc. The remaining elements within each row may then include the value, i.e., VL, for the indicated row.

[0062] Step 110 represents the step of providing one or more entry transaction identifiers (ETxIDs) within the table transaction type of Step 104. A given ETxID is one or more ETxIDs that are unique to a given entry among one or more entries associated with table T. A given ETxID relates to a transaction related to a distributed ledger for a given entry E in a given table T in Step 104, and table T is in database D in Step 102. In other words, an ETxID is called an entry transaction identifier because it relates to data associated with a given entry E in table T.

[0063] Step 112 involves providing one or more table transaction identifiers (TTxIDs) within the database transaction type of Step 102. A given TTxID is one or more TTxIDs unique to a given table within one or more tables associated with database D in Step 102. This given TTxID is called a table transaction identifier because it relates to transactions related to the distributed ledger for a given table T, or in other words, to data related to the table in database D.

[0064] Figure 2 shows a nested blockchain-based data structure in a first aspect, illustrating transaction data types related to the blockchain and their interrelationships. The database transaction data type contains the name of the database (D) which can be used to search or query the data structure. It also contains the TTxIDs of all the tables that are its components. Hereinafter, a TTxID is stored for each table T1, T2, T3, etc. The table transaction data type begins with the name of the table (T1, T2, T3) and is filled with ETxIDs that refer to entry data E1, E2, E3, etc. for each table. This is illustrated for T3 in the figure. The entry transaction data type contains reference and associated data values, each representing a row in table T1, T2, or T3. A reference and value pair for entry E3 in table T3 is shown in Figure 2.

[0065] First aspect - SQL commands for use in blockchain data structures Structured query language (commonly abbreviated as SQL) is a common programming language that enables users to efficiently manage and query relational databases, where there are structured relationships between data elements. The code is communicated to a database management system (DBMS), which compiles and processes requests locally or, in the case of distributed databases, remotely. Generally, there are four main categories of SQL code. 1. Data querying using the SELECT function and conditional statements (FROM, WHERE). 2. Data manipulation using INSERT, DELETE, and UPDATE. 3. Data definition using CREATE. 4. Data control for permissioned access, such as GRANT or REVOKE.

[0066] Having structured data, such as that found in SQL relational databases, makes data retrieval more efficient. A considerable amount of work has been invested by developers in the past to optimize the process of querying data based on its underlying structure. Most commercial database systems have a dedicated query optimizer and query execution engine. The execution engine determines the actions (such as sorting, scanning, and merging) that should be applied to the data. The query optimizer then creates an execution plan (logical flow) to perform the search most efficiently, taking into account the data structure and computational cost. Finally, the query is executed by the query execution engine according to that plan.

[0067] Given that SQL and its functions and commands are typically used in existing databases, including distributed databases, embodiments of this disclosure provide a method for executing standard SQL commands to perform one or more standard database operations on a blockchain implementation data structure, such as that shown in Figure 2. For easier adoption and interoperability with current database systems, Figures 3a–3c illustrate a method for demonstrating how standard SQL commands can be applied to a blockchain database using one or more consecutive transactions associated with the blockchain. While select or write SQL commands (update / insert, modify, or delete) are illustrated in Figures 3a–3b, similar methods can be applied to map the entire SQL library.

[0068] Figure 3a is a schematic diagram showing the following SQL database commands that manage the data structure in Figure 2 when executed by one or more processors associated with the DBMS. In some embodiments, one or more processors associated with a SQL server, which is either associated with the DBMS or communicatively coupled to the DBMS, may also be used to execute one or more of the following commands.

[0069] The command CREATE DATABASE can be executed by following these steps:

[0070] TxID1 - A step of generating a first transaction to create a first database, wherein the first transaction provides output for the first transaction based on the database transaction type of the data structure and the created first database (database_name).

[0071] Next, in response to a request or transaction related to the first database, subsequent SQL commands are executed by the following transaction.

[0072] CREATE TABLE, including the following steps.

[0073] TxID2 - A step of generating a second transaction to create a first table, wherein the second transaction provides output to the second transaction based on the table transaction type of the data structure, and the first table created, and includes an identifier (TTxID) for the second transaction.

[0074] TxID3 - A step of generating a third transaction based on the output of a second transaction, comprising the steps of updating the database transaction type of a first database using an identifier (TTxID) associated with the second transaction, and providing output for the third transaction based on the updated first database.

[0075] Next, in response to requests or transactions related to the first table, subsequent SQL commands are executed based on the following transaction.

[0076] The following INSERT INTO TABLE statement is included in the next step.

[0077] TxID4 - A step of generating a fourth transaction to create a first entry in a first table, wherein the fourth transaction provides output to the fourth transaction based on the entry transaction type of the data structure and the created entry, and includes an identifier (ETxID) for the fourth transaction.

[0078] TxID5 - A step of generating a fifth transaction based on the output of the fourth transaction, A step of updating the table transaction type of a first table using an identifier (ETxID) associated with a fourth transaction, and a step of providing output for a fifth transaction, wherein the output is based on the updated first table and the identifier (TTxID) of the fifth transaction.

[0079] TxID6 - A step of generating a sixth transaction based on the output of the fifth transaction, A step comprising updating the database transaction type of the first database using the identifier (TTxID) associated with the fifth transaction, and providing output for the sixth transaction based on the updated first database.

[0080] Figure 3b is a schematic diagram showing the following SQL UPDATE database commands that create and / or manage the data structures in Figure 2 when executed by one or more processors associated with the DBMS.

[0081] Modifying a first table in response to a request or transaction related to the first table using UPDATE / MODIFY commands performed using blockchain transactions, comprising the following steps:

[0082] TxID7 - A step of generating a seventh transaction to modify the reference and / or value of a data pair associated with the first entry in the first table. Following this, based on the seventh transaction, the entry transaction type of the first entry is updated with the modified entry, and output for the seventh transaction is provided based on the modified entry, including the identifier (ETxID) of the seventh transaction.

[0083] TxID8 - A step of generating an eighth transaction based on the output of the seventh transaction, A step comprising updating the table transaction type of a first table using the identifier (ETxID) associated with a seventh transaction, and providing output for an eighth transaction based on the updated first table, including the identifier (TTxID) of the eighth transaction.

[0084] TxID9 - A step of generating a ninth transaction based on the output of the eighth transaction, A step comprising updating the database transaction type of the first database using the identifier (TTxID) associated with the eighth transaction, and providing output for the sixth transaction based on the updated first database.

[0085] Figure 3c is a schematic diagram showing the following SQL DELETE database command, which creates and / or manages the data structure in Figure 2 when executed by one or more processors associated with the DBMS.

[0086] Modifying a first table using a DELETE FROM command executed using a blockchain transaction in response to a request or transaction related to the first table, comprising the following steps:

[0087] TxID10 - A step of generating a 10th transaction to delete the first entry in the first table, A step comprising updating the table transaction type of a first table to remove the identifier (ETxID) associated with a fourth transaction, and providing output for a tenth transaction based on the updated first table, and including the identifier (TTxID) of the tenth transaction.

[0088] TxID11 - A step of generating an eleventh transaction based on the output of the tenth transaction, A step of updating the database transaction type of a first database using an identifier (TTxID) associated with a tenth transaction, and a step of providing output for an eleventh transaction, wherein the output includes the updated identifier of the first database.

[0089] The above example illustrates how several SQL commands may be executed using a blockchain-based data structure of the first aspect. Several modifications from the above transaction flow are presented below, and they are also within the scope of this disclosure.

[0090] For many enterprise applications and existing databases, data is constantly being added, removed, and modified. For these high-volume scenarios, submitting individual requests or per-request database commands, each requiring a separate blockchain transaction, can be impractical and economically inefficient.

[0091] Accordingly, in some embodiments of this disclosure, requests can be batched to the advantage of enabling more efficient resource management at both the entry and table levels. To insert multiple entries (rows) into a single table, data in a blockchain data structure can be indexed and concatenated within a single transaction. To update entry information, a non-consumable transaction (i.e., an OP_RETURN transaction) can be copied across relevant consumption transactions by modifying only one or more relevant entries. For relevant tables that share common entries, in some embodiments, it may be possible to include the common entries within the same transaction to limit the number of update transactions required when data is modified.

[0092] SQL Server may store records of all requests (transactions for blockchain-based data structures, as proposed) in a database file commonly called a transaction log. This typically serves as a backup of the database file in case of file corruption or data deletion. The transaction log can be loaded to recreate the latest state of the database. However, in large systems, this file can reach terabytes in size, making it difficult and expensive to store. To address this problem, some embodiments of this disclosure provide a similar logging system for a database implemented using a distributed ledger, i.e., a blockchain-based data structure, as shown in Figure 2, using a series of transactions. A series of request transactions can be stored within a single transaction, using only the transaction identifier TxID of the most recent transaction as a reference. This advantageously dramatically reduces the size of the backup log. Furthermore, storing this backup log of a series of transactions on the blockchain also advantageously means that an entity or company does not need to store the backup itself and only needs to retain records of the most recent transactions. Advantageously, this log also provides a permanent and immutable record of all updates to the database and can therefore be used for auditing or regulatory requirements.

[0093] Second aspect - Registration and access management for a DBMS associated with data related to blockchain transactions A data management system (DBMS) facilitates SQL requests and functions to structure data relating to one or more databases. In the case of blockchain-based databases, this is particularly important for constructing and submitting transactions (see Figures 3a-3c), as well as for maintaining records of associated transaction IDs (TxIDs) (see the data structures described in Figures 1 and 2). This data management system for blockchain-based data structures is similar to a distributed database management system (DDMS) for traditional distributed databases, working to integrate distributed databases. This DBMS can manifest itself in several ways, namely, it can represent a client application that can be configured for client entities, which may have, or be associated with, one or more computing resources for remote third-party services, or computing resources or processing / networking capabilities and availability to manage their own DBMS.

[0094] A second aspect of this disclosure describes identification information and access verification techniques for client entities that wish to access data managed by a DBMS and associated with one or more blockchain transactions. In some embodiments, the methods relating to the second aspect are implemented by one or more processors associated with the DBMS. In some embodiments, the methods relating to the second aspect are implemented by a registration and access management system that is part of or associated with the DBMS to protect the integrity of the database and provide sufficient security. The database managed by the DBMS in the second aspect is the blockchain-based data structure of the first aspect. Advantageously, the methods relating to the second aspect enable multi-level access or permission control, such as read-only, write-only, or both read and write privileges, for client entities that wish to perform database operations.

[0095] Figure 4a is a flowchart illustrating a method related to an off-chain attribute-based access technique that can be used to validate access to a database via a DBMS and can be favorably adapted to any type of data or organization. Access to the database or its components is restricted unless the user submitting the request possesses one or more attributes associated with a configuration that allows the requested action. Figure 4a illustrates a method implemented by one or more processors associated with the DBMS.

[0096] In step 402a, a request to register with the DBMS is received by one or more processors associated with the DBMS. In some embodiments, a request to register is a request received from one or more processors associated with a client entity for a given user who wishes to use, view, or manipulate data in the blockchain implementation database, such as the data structure in Figure 2.

[0097] Step 404a describes the step of creating a record associated with a given user. The record may be stored in one or more memory or storage modules associated with the DBMS, or in a remote server or storage structure, so that it can be retrieved as needed and when required. The record contains an identifier for a given user among several users. This may be the user's name and other details that can be used to identify the user.

[0098] In step 406a, a public key P associated with a given user is obtained from the client entity. The public key is part of a cryptographic key pair associated with the given user, and the cryptographic key pair also includes a private key V for the given user. The public and / or private keys for a given user can be generated by known methods, such as based on random numbers or a secret seed, as described above with respect to the second aspect.

[0099] Step 408a indicates retrieving or assigning one or more attributes associated with a given user, each attribute associated with a setting related to access to a database managed by the DBMS. For example, the setting may be a permission setting for an attribute, and the attribute may be the name of a team or department, such as HR or accounting, as described above. In some examples, the setting may be a flag or binary toggle (0 or 1) or state indicating whether read / write permission to access database components is enabled for a given user having a particular attribute. The attribute setting may be retrieved from the client entity, or in some embodiments, the attribute may be pre-assigned by the DBMS in accordance with the identification information of a given user. The setting may be retrieved from the client entity in relation to an attribute, or it may be pre-assigned for several attributes received by the DBMS's system administrator module.

[0100] Step 410a indicates updating the record based on the acquired public key P and one or more attributes, and, if received, the permission settings associated with a given user. In some embodiments, the user record is stored in one or more storage areas, either in or in relation to the DBMS, from which the user record may later be accessed, as described in the following steps. Such storage may also be in a remote computing resource.

[0101] Step 412a involves obtaining a request from a client entity that seeks to perform an action related to the database, the client entity relating to a given user among several users. The request includes a digital signature associated with the given user submitting the request in this step.

[0102] In step 414a, it is first determined whether the given user who made the request in the previous step is authorized to access the database by checking whether a user record exists for that user. In other words, as explained in steps 402a to 410a above, it is checked whether the user who made the request in the previous step is actually registered in the database.

[0103] If the user is not registered or no user record is found for the user, in step 416a, the request received in step 412a is rejected or denied. In some embodiments, an error notification of the consequences may be generated.

[0104] If a user record is found, the given user making the request in step 412a is authorized. The method then proceeds to step 418a, where it is verified whether a digital signature is correctly associated with the given user who submitted the request. This can be done by ensuring that the request can be validated or decrypted using the public key P present in the record for the given user. A digital signature can only be successfully validated or decrypted using its paired public key P if it is based on a private key V. This ensures that the request actually originated from the given user identified in the user request and not from a malicious party impersonating the given user.

[0105] If it is not possible to verify the digital signature using the public key P in the record, the request in step 412a is rejected in step 420a. In some embodiments, an error message may be generated to communicate this rejection.

[0106] In response to the successful verification of the digital signature, in step 422a, the DBMS generates a message based on the current instance and request of the user record. This message is generated in a format that may be machine-readable and parsable by one or more DBMS components (as described below in relation to the third embodiment). In some embodiments, the message includes details that reflect attributes, settings (if received), and a representation of the database action requested by the user.

[0107] Figure 4b, relating to the second aspect, is complementary to the method described in Figure 4a above, but is implemented by one or more processors of a client entity associated with a given user that makes requests for registration and / or operations related to a database, such as a blockchain implementation data structure as shown in Figure 2.

[0108] Step 402b involves generating a request for registration in the DBMS, the request relating to a given user related to the client entity sending the request.

[0109] Step 404b indicates providing or accessing one or more attributes associated with a given user, each attribute associated with a database-related setting managed by the DBMS. If the attributes are available in the client entity, they are included as part of the registration request. Otherwise, these attributes (and settings, if available) are retrieved from a different system or memory for the given user.

[0110] Step 406b represents generating a private key V associated with a given user, the private key being part of a cryptographic key pair that includes a public key P for the given user. This private key is not shared with any other entity or DBMS. It may be generated by any known means, such as using a common secret or generator, and this method of generation is outside the scope of this disclosure. In some embodiments, to enhance the security of the system, the public and private keys may be short-term keys that are generated periodically or at arbitrary intervals.

[0111] Step 408b shows that a public key P is computed based on a private key V. Since no message signed with the private key V can be validated without the public key P of the cryptographic key pair, this key is related to the private key V, and vice versa.

[0112] Step 410b shows sending the public key P and one or more attributes to the DBMS using one or more known data transmission protocols over a communication network such as the Internet.

[0113] Step 412b represents generating a request for database-related actions, the request relating to a given user. For simplicity of reference, in this diagram, this is understood to be the same user who submitted the registration request in step 402b. In other embodiments, this step and subsequent steps may be performed by different client entities for different users, who are also registered in the DBMS.

[0114] Step 414b indicates generating a digital signature based on a private key V for a given user, where the private key is part of a cryptographic key pair that includes a public key P for a given user, the public key P being provided to the DBMS during the registration process as described in steps 402b-410b.

[0115] Step 416b describes applying a digital signature to the request and sending the signed request to the DBMS. In some embodiments, if the DBMS rejects the request (due to failed authorization or unsuccessful verification of the digital signature), the client entity may receive an error message from the DBMS in response to the request.

[0116] Third aspect - Command interpretation and transaction configuration for a DBMS associated with data related to blockchain transactions As described in the second aspect, the data management system facilitates SQL requests and processes requests to databases, such as the blockchain-based database in Figure 2. A third aspect of this disclosure relates to a method for interpreting and processing database requests to perform operations with respect to a blockchain database. In some embodiments, the method of the third aspect, when implemented by one or more processors of the DBMS, effectively acts as an SQL compiler and performs attribute verification (following authorization and identity verification of the second aspect).

[0117] Figure 5 is a flowchart illustrating the process of interpreting and processing one or more SQL commands or requests to the operation of the database, where the database is a blockchain implementation data structure as seen in Figure 2.

[0118] Step 502 indicates receiving a message relating to the current instance of a user record for a given user among one or more users, the message also including a request relating to the database. In some embodiments, this message is as described in step 422a of Figure 4a, and the request is a request for an action provided by the given user. The request may be a read request, or a request to write data into the database, i.e., to update / insert, modify, or delete.

[0119] In step 504, attributes associated with a given user are retrieved from the message in step 502. If settings are provided in the user record, these are also retrieved. In some embodiments, these settings are permissions associated with attributes that may be pre-configured and stored in memory associated with the DBMS. In any case, both attributes for one or more types of database behavior and their associated permissions (settings) are retrieved in this step.

[0120] In step 506, the permission settings for each of the retrieved attributes are then verified to be valid for the request made by a given user. In other words, the SQL request is parsed and the required database attributes are checked against the settings associated with each attribute for a given user. In some embodiments, if the user and attributes are considered as objects, this check may be performed on the basis of using a simple Boolean check as follows: (object instance).(database attribute)==true

[0121] If there are two or more attributes to be validated based on their respective permission settings, the attributes can be combined or chained using AND and OR operators. Failure of the access conditions for an attribute will, in some embodiments, trigger a PERMISSION ERROR message displayed to the user, and the request will be rejected without proceeding further, as seen in step 508.

[0122] If the access conditions are met, in some embodiments, the SQL request is compared against the SQL command library. If no such command is found in the library, or if it is not recognized by the DBMS, a REQUEST ERROR message may be returned to the user. If it is a valid function, the method then proceeds to step 510.

[0123] Step 510 involves obtaining one or more transaction identifiers (TTxID, ETxID) related to the request, each transaction identifier obtained relating to a transaction, thereby associating the data for that transaction with a data structure. This step also involves accessing the data related to the obtained transaction identifiers (TTxID, ETxID) from the data structure.

[0124] If the data is accessible, then in step 512, it is determined whether the request is a READ operation or a WRITE operation that should be performed using the data to be accessed.

[0125] If the request is a READ operation in which the data is not updated in any way, in step 514 an operation is performed to retrieve the accessed data for supply to one or more processors or display devices associated with the DBMS, or to an interface on a client entity. In some embodiments, for a READ operation (database query), the associated TxIDs are collected and configured in the system's memory. The query is executed, a summary table is constructed and returned to the user.

[0126] If the request relates to a WRITE operation, i.e., an update / insert, modify, or delete operation, as shown in Figures 3a-3b and described above with respect to the first embodiment, in addition to obtaining the data in step 512, the method further includes, in step 516, a process to generate one or more transactions to consume or process the transactions associated with one or more obtained transaction identifiers (TTxID, ETxID) based on the operation. In some embodiments, for a WRITE operation, the appropriate TxID(s) (or TxIDs) that need to be updated are collected and communicated to a transaction constructor, which may be one or more processors associated with the DBMS. This transaction constructor may be associated with an SPV wallet for communication with the distributed ledger, as described above.

[0127] Simultaneously, the OP_RETURN payload may be constructed when a new transaction is generated for the blockchain. This is similar to the generation of a transaction for a command, as shown in Figures 3a-3c, in addition to including, for example, the user's digital signature. The digital signature advantageously provides an auditable record of the request submission that can be verified using the user record without the user needing to directly interact with the blockchain, and can be used to verify the submission for a given user at the time of submission or at any point in the future. This advantageously provides interoperability with conventional systems while still maintaining an immutable record on the blockchain. In some embodiments, the OP_RETURN payload may be encrypted using a deterministically derived key before being passed to the transaction constructor.

[0128] Transaction configuration can be carried out in several ways in step 516. For example, a transaction can be configured using a local simplified payment verification (SPV) client (for the DBMS), or a wallet for the DBMS, which, having received the necessary TxID and OP_RETURN payload, then connects to the blockchain network via peer-to-peer connections to all nodes. The SPV client or wallet itself does not mine or store a copy of the blockchain.

[0129] As an example, an example of pseudocode for transaction configuration is provided below.

[0130] The transaction object is instantiated using the constructor. tx = Transaction(NetworkParameters params)

[0131] The consuming output is first appended and linked to an address (address_i) held by the system for the DBMS's SPV client. The address can be generated using a hash of the public key, which is derived using a known deterministic derivation scheme. tx.addOutput(Coin.MIN_NONDUST_OUTPUT, Address address_i)

[0132] The OP_RETURN payload is stored in the variable OPR_DATA, and then added to the transaction using the addOutput function as follows: tx.addOutput(Coin.MIN_NONDUST_OUTPUT,newScriptBuilder().op(ScriptOpCodes.OP_RETURN).data(OPR_DATA.getBytes).build())

[0133] The corresponding UTXO reference is stored in a variable called prevOut. After this, the required private key V for consuming this output is retrieved, and the corresponding public key P is stored in the variable sigKey.

[0134] Finally, the private key V is used to sign the transaction using ECDSA (without using TxID and an unlocking script). The signature data (sig) and public key are stored as follows: scriptPubKey = OP_PUSH sig OP_PUSH sigKey

[0135] The input data is then added to the transaction object using the addSignedInput function. tx.addSignedInput(TransactionOutPoint prevOut, Script scriptPubKey, ECKey sigKey)

[0136] Transactions can then be submitted to the network via SPV wallets to all nodes for verification and inclusion in a block. tx.broadcastComplete.get()

[0137] In step 518, one or more of the entry transaction data type, table transaction data type, and / or database transaction data type related to the blockchain-based data structure in Figure 2 are then updated with the TxID of the newly configured or generated transaction.

[0138] Figure 6 is a schematic diagram showing a data management system or data or database management system (DBMS) 600, as described in relation to the second or third aspects of this disclosure, for managing the storage, access, and manipulation of data in a blockchain-based data structure as shown in Figure 2.

[0139] This is similar to a traditional distributed database management system (DDMS) for distributed databases, which works to integrate distributed data systems. This DBMS600 system may be a remote or third-party service run by one or more remote servers, or it may be associated with a client application.

[0140] Regardless of the implementation, DBMS600 includes the following components: A registration and access management system 604, based on the method described in relation to the second aspect above, for providing access control to read / write privileges for users associated with client entity 602. A transaction execution system 606 for interpreting and executing standard SQL commands to create transactions or queries on data associated with a blockchain data structure, as described in the third aspect. This component may include a command interpreter 606a acting as an SQL compiler, a transaction constructor 606b constituting a set of transactions to be submitted, and an SPV wallet 606c for output execution management, transaction submission, network monitoring, etc., when interacting with or communicating with the blockchain 612. In relation to DBMS600, UTXO set 610 and TxID register 608 for recording all TxIDs and the latest data in the UTXO set.

[0141] To facilitate quick and easy access to the data, an indexed copy of a UTXO set 610 or a subset thereof, containing the most recent relevant transactions in the database, may be provided to the DBMS 600. This is integrated with an SPV wallet 606c that tracks keys associated with the user (i.e., client entities, which are all nodes that request to register with or access the database / DBMS) to record UTXO updates (consumption). A separate record of the index is stored as a TxID register 608, so that OP_RETURN data can be retrieved for querying.

[0142] An index can be a simple integer count in operation, or more detailed data such as a name, function output value, or hash value. The transaction identifier TxID of a database transaction is all that is needed when accommodating the relevant TTxID or ETxID to reconstruct the entire database or data structure. However, in some embodiments, to reduce the number of update transactions required, it is also possible to store the TTxID or ETxID and organize them off-chain within the relevant database structure. Access attributes can be stored along with the TxID register 608, which can be checked during the setup / authorization verification step performed by the registration and access management system in a second embodiment of this disclosure.

[0143] The components of DBMS600 provide a sequence for processing user requests to provide a single-point reference to distributed data associated with blockchain 612. The functions and components of DBMS600 can be executed or implemented on-chain or off-chain using the same methods presented with respect to the second and third embodiments described above.

[0144] Referring next to Figure 7, a simplified exemplary block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure is provided. In various embodiments, the computing device 2600 may be used to implement any of the systems illustrated and described above. For example, the computing device 2600 may be configured to be used as one or more components of the DBMS in the figure, or the computing device 2600 may be configured to be a client entity associated with a given user, a client entity that makes database requests to a database managed by the DBMS in Figure 6. Thus, the computing device 2600 may be a portable computing device, a personal computer, or any electronic computing device. As shown in Figure 7, the computing device 2600 may include one or more processors (collectively labeled 2602) having one or more levels of cache memory and memory controllers, which can be configured to communicate with a storage subsystem 2606 including a main memory 2608 and a persistent memory 2610. The main memory 2608 may include a dynamic random access memory (DRAM) 2618 and a read-only memory (ROM) 2620, as shown in the figure. The storage subsystem 2606 and cache memory 2602 may be used for storing information such as transaction and block-related details as described in this disclosure. The processor 2602 may be used to provide any step or functionality of any embodiment as described in this disclosure.

[0145] The processor 2602 can also communicate with one or more user interface input devices 2612, one or more user interface output devices 2614, and a network interface subsystem 2616.

[0146] The bus subsystem 2604 may provide a mechanism to enable various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is schematically illustrated as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0147] The network interface subsystem 2616 may provide interfaces to other computing devices and networks. The network interface subsystem 2616 may act as an interface for receiving data from and sending data to other systems from the computing device 2600. For example, the network interface subsystem 2616 may enable data engineers to connect the device to a network, so that they can send data to and receive data from the device while in a remote location such as a data center.

[0148] The user interface input device 2612 may include one or more user input devices such as a keyboard, integrated mouse, trackball, touchpad, or pointing device such as a graphics tablet, scanner, barcode scanner, touchscreen embedded in a display, voice recognition system, microphone or other audio input devices, and other types of input devices. In general, the use of the term “input device” is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0149] One or more user interface output devices 2614 may include non-visual display devices such as a display subsystem, a printer, or an audio output device. The display subsystem may be a flat panel device such as a cathode ray tube (CRT), liquid crystal display (LCD), light-emitting diode (LED) display, or a projection or other display device. In general, the use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. One or more user interface output devices 2614 may be used to present a user interface and facilitate user interaction when, for example, user interaction with an application performing the processes described and their variations is appropriate.

[0150] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data configurations that may provide the functionality of at least one embodiment of the Disclosure. Applications (programs, code modules, instructions), when executed by one or more processors, may provide the functionality of one or more embodiments of the Disclosure and may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 may additionally provide a repository for storing data used in accordance with the Disclosure. For example, main memory 2608 and cache memory 2602 may provide volatile storage for programs and data. Persistent storage 2610 may provide persistent (non-volatile) storage for programs and data and may include flash memory, one or more solid-state drives, one or more magnetic hard disk drives, one or more floppy disk drives with associated removable media, one or more optical drives (e.g., CD-ROM or DVD or Blu-ray) with associated removable media, and other similar storage media. Such programs and data may include programs for performing steps of one or more embodiments as described in this disclosure, as well as data related to transactions and blocks as described in this disclosure.

[0151] The computing device 2600 may be of various types, including portable computer devices, tablet computers, workstations, or any other devices described below. Additionally, the computing device 2600 may include other devices that may be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). A device that may be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. Thus, this device may be configured to convert optical signals into electrical signals that may be transmitted through the ports connecting the device to the computing device 2600 for processing. Due to the constantly changing nature of computers and networks, the description of the computing device 2600 shown in Figure 7 is intended only as a specific example to illustrate a preferred embodiment of the device. Many other configurations with more or fewer components than the system shown in Figure 7 are possible.

[0152] Exemplary embodiments listed below This disclosure is described herein based on the following sections relating to the above-described aspects, which are provided herein as exemplary embodiments for better describing, explaining and understanding the claimed aspects and embodiments.

[0153] 1. A computer implementation method that provides a data structure for storing and / or managing data associated with one or more transactions relating to a distributed ledger, wherein the method is implemented by one or more processors relating to a data management system (DBMS) for a distributed ledger, A step of creating a database transaction type, wherein the database transaction type is An identifier for database D, which should be used to retrieve data for one or more transactions related to the distributed ledger, and A step comprising one or more table transaction identifiers (TTxIDs), wherein a given TTxID among the one or more TTxIDs is unique to a given table among the one or more tables associated with the identified database D, and the given TTxID relates to a transaction relating to a distributed ledger for a given table, A step of creating a table transaction type, wherein the table transaction type is An identifier for table T, wherein the table is among one or more tables related to the identified database D, and Step and It is equipped with.

[0154] 2. The method presented in Section 1, where the table transaction type is: The system further comprises one or more entry transaction identifiers (ETxIDs), where a given ETxID is unique to a given entry among one or more entries associated with an identified table T, and the given ETxID is related to a transaction relating to a distributed ledger for a given entry. The method is, Further, it is possible to create an entry transaction type, and the entry transaction type is: It comprises one or more data pairs, each data pair relating to an entry in an identified table T, and each data pair comprises a reference R that identifies a location in the identified table, and a value VL for the identified location.

[0155] 3. Transactions relating to one or more TTxIDs or ETxIDs, as described in Section 1 or 2, are associated with one or more unspent transaction outputs (UTXOs).

[0156] 4. The method presented in Section 3, wherein the UTXO for a given transaction includes an output script that can be consumed by subsequent transactions associated with the identified database D and / or table T.

[0157] 5. A method as presented in either Section 3 or 4, wherein the UTXO for a given transaction includes non-consumable output associated with a consumable output script for a given transaction.

[0158] 6. A data structure for storing and / or managing data associated with one or more transactions relating to a distributed ledger, the data structure being managed by one or more processors associated with a database management system (DBMS) for the distributed ledger, and the data structure including data transaction types and table transaction types created according to any one of the methods in Sections 1 to 5.

[0159] 7. A data structure as presented in Section 6, wherein the data structure is a nested transaction storage structure, further comprising an entry data type created according to any one of the methods in Sections 2 to 5, and the data structure is configured to store the identified database D on the basis of storing the TTxID and ETxID associated with the identified database D.

[0160] 8. A computer implementation method for performing one or more transactions associated with a distributed ledger, wherein the transactions use a data structure provided by one of the preceding claims, and the method is performed by one or more processors associated with a data management system (DBMS). The step of creating a database, A step of generating a first transaction to create a first database, wherein the first transaction is based on the database transaction type of the data structure, and A step including providing output for a first transaction based on a first database that has been created, A step of updating a first database in response to a request or transaction related to the first database, A step of generating a second transaction to create a first table, wherein the second transaction is based on the table transaction type of the data structure, and A step that includes providing output for a second transaction based on the first table created and including the identifier (TTxID) of the second transaction, A step of generating a third transaction based on the output of a second transaction, The steps include updating the database transaction type of the first database using the identifier (TTxID) associated with the second transaction, and A step including providing output for a third transaction based on the updated first database, It is equipped with.

[0161] 9. The method presented in Section 7, A step of populating the first table in response to a request or transaction related to the first table, A step of generating a fourth transaction to create a first entry in a first table, wherein the fourth transaction is based on the entry transaction type of the data structure, and A step that includes providing output for a fourth transaction based on the created entries and including the identifier (ETxID) of the fourth transaction, A step of generating a fifth transaction based on the output of a fourth transaction, The steps include updating the table transaction type of the first table using the identifier (ETxID) associated with the fourth transaction, and A step of providing output for a fifth transaction, the output being based on the updated first table and the identifier (TTxID) of the fifth transaction, the step of providing output for a first table, and the step of providing an identifier (TTxID) of the fifth transaction, the step of providing output for a fifth transaction, the step of providing output for a first table, and the step of providing an identifier (TTxID) of the fifth transaction, the step of providing output for a fifth transaction, the step of providing output for a first table, and the step of providing output for a fifth transaction, the step of providing output for a fifth transaction, the step of providing output for a first table, and the step of providing an identifier ( A step of generating a sixth transaction based on the output of a fifth transaction, A step of updating the database transaction type of the first database using the identifier (TTxID) associated with the fifth transaction, and A step including providing output for a sixth transaction based on the updated first database, To further prepare.

[0162] 10. The method presented in Section 9, A step of modifying a first table in response to a request or transaction related to the first table, The step of generating a seventh transaction to modify the reference and / or value of a data pair related to the first entry in the first table, The steps include updating the entry transaction type of the first entry using the modified entry based on the seventh transaction, and A step which includes providing output for the seventh transaction based on the modified entry and including the identifier (ETxID) of the seventh transaction, A step of generating an eighth transaction based on the output of the seventh transaction, The steps include updating the table transaction type of the first table using the identifier (ETxID) associated with the seventh transaction, and A step that includes providing output for the eighth transaction based on the updated first table and including the identifier (TTxID) of the eighth transaction, A step of generating a ninth transaction based on the output of the eighth transaction, The steps include updating the database transaction type of the first database using the identifier (TTxID) associated with the eighth transaction, and A step including providing output for a sixth transaction based on the updated first database, It is equipped with.

[0163] 11. A method as presented in either Section 9 or 10, A step of modifying a first table in response to a request or transaction related to the first table, A step of generating a tenth transaction to delete the first entry in the first table, The steps include updating the table transaction type of the first table to remove the identifier (ETxID) associated with the fourth transaction, and A step that includes providing output for the 10th transaction based on the updated 1st table and including the identifier (TTxID) of the 10th transaction, A step of generating an eleventh transaction based on the output of the tenth transaction, A step of updating the database transaction type of the first database using the identifier (TTxID) associated with the tenth transaction, and A step of providing output for an eleventh transaction, the step of which the output includes an updated identifier for a first database, and The procedure includes steps that include the following:

[0164] 12. A computer implementation method for performing one or more transactions associated with a distributed ledger, wherein the transactions use a data structure provided by any one of claims 1 to 7, and the method is performed by one or more processors associated with a client entity. The steps include sending a request to one or more processors associated with the DBMS to create a first database, The steps include monitoring the distributed ledger to obtain at least one transaction output related to the first database D that was created, The steps include sending a request to one or more processors associated with the DBMS to create a first table for a first database, The steps include monitoring the distributed ledger to obtain at least one transaction output related to the first table (TTxID), The process includes the step of sending a request to one or more processors associated with the DBMS to update a first table using a first entry, wherein the first entry includes a data pair comprising a reference that identifies a location in the first table and a value for the identified location.

[0165] 13. A computer implementation method for performing one or more transactions associated with a distributed ledger, wherein the transactions use a data structure provided by any one of claims 1 to 7, and the method is performed by one or more processors associated with a client entity. A step of monitoring a distributed ledger to obtain at least one transaction output related to a first entry (ETxID) in a first table of a first database, A step of sending a request to one or more processors associated with the DBMS to modify a first entry, wherein the request includes a request to modify a reference and / or value of a data pair associated with the first entry. The steps include monitoring the distributed ledger to obtain at least one transaction output associated with an identifier for the updated first table (TTxID) and / or the updated first database D, which incorporates the modified first entry, and It is equipped with.

[0166] 14. A computer implementation method for performing one or more transactions associated with a distributed ledger, wherein the transactions use a data structure provided by any one of claims 1 to 7, and the method is performed by one or more processors associated with a client entity. A step of monitoring a distributed ledger to obtain at least one transaction output related to an identifier (TTxID) for a first table in a first database, The steps include sending a request to one or more processors associated with the DBMS to delete the first entry of the first table, The steps include monitoring the distributed ledger for at least one transaction output associated with an identifier for the updated first table (TTxID) and / or the updated first database, and It is equipped with.

[0167] 15. A computer implementation method for managing access to a data management system (DBMS), wherein the DBMS manages data relating to transactions associated with a distributed ledger, and the data is provided in the database, and the method is A step of creating a record related to a given user in response to a request to register with a DBMS, wherein the record includes an identifier for the given user among a group of users; A step of obtaining a public key P associated with a given user, wherein the public key is part of a cryptographic key pair associated with the given user, and the cryptographic key pair includes a private key V for the given user. A step of retrieving or assigning one or more attributes associated with a given user, wherein each attribute is associated with a setting relating to access to a database managed by a DBMS, A step of updating a record based on the obtained public key P and one or more attributes associated with a given user, The steps of storing or providing updated records related to the DBMS and It is equipped with.

[0168] 16. The setting for a given attribute, as presented in Section 15, checks whether the given attribute is associated with permission to perform one or more of the read, write, modify, or delete operations related to the database.

[0169] 17. In any of the manner presented in either Section 15 or 16, the settings for each attribute are provided in the request, or the settings are obtained from computing resources associated with the DBMS, or the settings are predetermined for each attribute to the database managed by the DBMS.

[0170] 18. A computer implementation method for implementing a data management system (DBMS) for managing databases related to transactions associated with a distributed ledger, the method being: A step of obtaining a request from a client entity for an action related to a database, wherein the client entity relates to a given user among a group of users, and the request includes a digital signature associated with the given user. The steps include determining whether a given user is authorized to access the database, In response to a successful decision, the steps include verifying that the digital signature is associated with a given user based on the user record associated with the DBMS, The steps include generating a message based on the current instance and request of the user record in response to successful validation, and It is equipped with.

[0171] 19. The method is as described in Section 18, and the request is a request to read, write, modify, or delete data in the database.

[0172] 20. The database is implemented using a data structure as provided in any one of sections 15-19, with the method described in any one of sections 1-7.

[0173] 21. The user record is created when a given user is registered in the DBMS using one of the methods described in any one of Sections 16-18, and the user record is created using one of the methods described in Sections 15-17.

[0174] 22. The step of determining whether a user is authorized, as presented in Section 21, includes determining that a user record associated with the DBMS exists for a given user at the time the given user was registered in the DBMS.

[0175] 23. A method, such as those presented in either Section 22 or 22, in which the step of verifying the digital signature is based on determining that the private key V or the signing key K used to sign the request is associated with a public key P associated with a given user in the user record.

[0176] 24. A method, such as those presented in any one of Sections 18-23, comprising generating an error notification in response to a decision failure, specifying that a given user is not authorized to access the database or is not registered to access the database.

[0177] 25. A method, such as those presented in any one of Sections 18-23, comprising generating an error notification in response to a failure in verifying a digital signature, specifying that the signature applied to the request is not valid for a given user.

[0178] 26. A computer implementation method for registering in a database management system (DBMS), wherein the DBMS relates to data relating to transactions associated with a distributed ledger, the method is performed by one or more processors relating to a client entity, the client entity relates to a given user among a plurality of users, and the method is A step of generating a request to register in a DBMS, wherein the request relates to a given user, A step of providing or accessing one or more attributes associated with a given user, wherein each attribute is associated with a setting relating to a database managed by a DBMS, A step of generating a private key V associated with a given user, wherein the private key is part of a cryptographic key pair that includes a public key P for a given user, The steps include: calculating the public key P based on the private key V, The steps include sending the public key P and one or more attributes to the DBMS. It is equipped with.

[0179] 27. A computer implementation method for accessing data related to a data management system (DBMS), wherein the DBMS relates to data related to transactions associated with a distributed ledger, the method is implemented by one or more processors related to a client entity, the client entity relates to a given user among a plurality of users, and the method A step of generating a request related to a database, wherein the request is related to a given user and the database is managed by a DBMS. A step of generating a digital signature based on a private key V for a given user, wherein the private key is part of a cryptographic key pair including a public key P for a given user, and the public key P is provided to a DBMS. Steps to apply a digital signature to the request, The steps include sending the signed request to the DBMS and It is equipped with.

[0180] 28. A method as presented in Section 27, comprising generating a signing key K based on a private key V, wherein the signing key is a short-term key.

[0181] 29. A method claimed in Section 27 or 28, which includes a method of registering data in a DBMS as presented in Section 26.

[0182] 30. A computer implementation method for implementing a data management system (DBMS) for managing databases related to transactions associated with a distributed ledger, the method being: A step of receiving a message and a database-related request relating to the current instance of a user record for a given user among one or more users, wherein the request is provided by the given user, A step of parsing a request related to a database, Retrieving one or more attributes associated with a given user from the current instance. A step that includes verifying that the settings for each of the extracted attributes are valid for the request made by a given user, In response to successful validation, a step of performing one or more database-related operations on a request, wherein the database performs the steps based on a data structure provided in accordance with any one of sections 1 to 6, If the request relates to a read operation, obtain one or more transaction identifiers (TTxID, ETxID) related to the request, wherein each obtained transaction identifier relates to a transaction, and thereby the data for the transaction is associated with a data structure, and This further includes accessing data related to transaction identifiers (TTxID, ETxID) obtained from the data structure, If the request relates to a write, modify, or delete operation, in addition to the acquisition step, the method generates one or more transactions to consume or process the transactions associated with one or more acquired transaction identifiers (TTxID, ETxID), and The steps further include updating the data structure using identifiers related to the generated transaction, and It is equipped with.

[0183] 31. A method as presented in Section 30, wherein the verification step includes checking whether a setting for a given attribute among one or more attributes indicates that a given user has permission to access the database for the request made.

[0184] 32. In any case where the request relates to a write, modify, or delete operation, the steps to be performed include any of the methods presented in any of the sections 7-9.

[0185] 33. In any of the methods presented in any one of Sections 30-32, where the request relates to a write, modify, or delete operation, the steps to generate are: Obtain the output script associated with each acquired transaction identifier (TTxID, ETxID), The process involves constructing further transactions based on an output script, wherein the further transactions are based on a private key V associated with a given user, and the private key is part of a cryptographic key pair that includes a public key P for the given user. This involves providing further transactions to the distributed ledger, where each further transaction is associated with a further transaction identifier (TTxID, ETxID). It also includes.

[0186] 34. The steps for further transactions, as presented in Section 33, are performed by a simplified payment verification (SPV) client associated with the DBMS, which connects the DBMS to the distributed ledger via a communication network.

[0187] 35. A method as presented in any one of Sections 30-34, wherein each acquired transaction identifier (TTxID, ETxID) is associated with a transaction containing a non-consumable UTXO, the non-consumable UTXO is associated with or contains a consumable payload, and the consumable payload is a consumable UTXO.

[0188] 36. The method presented in Section 35, where each storable and non-storable UTXO is stored in a UTXO set or memory associated with the DBMS, and the non-storable UTXO is the OP_RETURN output script.

[0189] 37. In the manner presented in Section 36, one or more disposable UTXOs in a UTXO set or memory are used to constitute further transactions.

[0190] 38. A computing device, Processor and The device comprises memory containing executable instructions that cause the device to execute one of the computer implementation methods from sections 12-14 or 26-29 as a result of execution by the processor, Computing devices are client entities.

[0191] 39. A DBMS system for managing access to data associated with one or more transactions relating to a distributed ledger, wherein the data managed by the DBMS is stored in a data structure as provided by any one of Sections 1 to 7, and the DBMS is: A registration and access management system having one or more processors configured to execute instructions for performing one of the computer implementation methods in Sections 15 to 25, A transaction execution system having one or more processors configured to execute instructions for executing one of the computer implementation methods in Sections 30 to 37, One or more registers for storing multiple transaction identifiers related to the database, A UTXO set or memory for storing multiple copies of UTXOs related to the database It is equipped with.

[0192] 40. It is a system, One or more computing devices, as presented in Section 38, each of which is a client entity, DBMS as presented in Section 39, A communication network to connect each client entity to the DBMS in a communicative manner. It is equipped with.

[0193] It should be noted that the embodiments described above are illustrative rather than limiting of the disclosure, and that many alternative embodiments can be designed by those skilled in the art without departing from the scope of the disclosure as defined by the appended claims. No reference numerals enclosed in parentheses in the claims should be construed as limiting the claims. Words such as “equipped with” and “equipped with” do not exclude the existence of any element or step other than those enumerated in any claim or specification. In this specification, “equipped with” means “to include or consist of,” and “equipped with” means “to include or consist of.” A singular reference to an element does not exclude a plural reference to such element, and vice versa. The disclosure may be implemented using hardware comprising several different elements and using a suitably programmed computer. In device claims enumerating several means, some of these means may be embodied by one identical component of hardware. The mere fact that several strategies are described in different dependent claims does not imply that combinations of these strategies cannot be used to benefit.

[0194] Exemplary use cases and scenarios Exemplary READ processing The capability of relational databases stems from their ability to aggregate related data across multiple tables. This is typically done using the JOIN SQL command between two tables. There are four subtypes of JOIN. 1. INNER JOIN - Returns values ​​that are common to both tables. 2. LEFT JOIN - Returns all values ​​from the left table and common values ​​from the right table. 3. RIGHT JOIN - Returns all values ​​from the right table and common values ​​from the left table. 4. OUTER JOIN - Returns all values ​​from both tables.

[0195] The INNER JOIN command will have the following format. SELECT table_name.column_name, table_name.column_name,... FROM lefttable_name INNER JOIN righttable_name ON [Matching Condition];

[0196] In this command, the first line selects the column values ​​to be reported in the query response, and these can be freely selected from both tables. The relevant table and entry data will be read from the UTXO set from the TxID reference and stored in system memory. Then, conditions will be applied and matched for analysis and assembly.

[0197] The next line selects the "left" table, which can be freely chosen by the user.

[0198] The next line sets the join condition (in this case, internal join) and specifies the table to the right that the join should be directed to.

[0199] Finally, a matching condition is specified, which is used to search the two tables for common elements. For example, to search the buyer's table and the seller's table by name, the condition would look like this: buyers.name=sellers.name

[0200] Because this is performed entirely off-chain by the DBMS, equivalent transactions are not required, and the standard SQL protocol can be incorporated. This also allows the system to leverage standard efficiency optimization and scaling methods that have been extensively explored over the past several decades. This approach enables easy interfacing with existing enterprise data management solutions (e.g., Oracle, SAP, etc.). [Explanation of Symbols]

[0201] 600 Database Management Systems (DBMS) 602 Client Entity 604 Registration and Access Management System 606 Transaction Execution System 606a Command Interpreter 606b Transaction constructor 606c SPV Wallet 608 TxID register 610 UTXO Set 612 Blockchain 2600 Computing Devices 2602 Processor 2602 cache memory 2604 Bus Subsystem 2606 Memory subsystem 2608 Main storage 2610 Persistent storage 2612 User Interface Input Devices 2614 User Interface Output Device 2616 Network Interface Subsystem 2618 Dynamic Random Access Memory (DRAM) 2620 Read-only memory (ROM)

Claims

1. A computer implementation method that provides a blockchain-implemented data structure for storing and / or managing data associated with one or more transactions relating to a distributed ledger, wherein the method is performed by one or more processors relating to a data management system (DBMS) for the distributed ledger. A step of creating a database transaction type, wherein the database transaction type is An identifier for database D which should be used to retrieve data for one or more transactions related to the distributed ledger, A step comprising one or more table transaction identifiers (TTxIDs), wherein a given TTxID among the one or more TTxIDs is unique to a given table among the one or more tables associated with the database D, and the given TTxID relates to a transaction relating to a distributed ledger for the given table, A step of creating a table transaction type, wherein the table transaction type is An identifier for table T, wherein the table is among the one or more tables related to database D, A step comprising one or more entries related to the table T A method that includes [a certain feature].

2. The aforementioned table transaction type is The system further comprises one or more entry transaction identifiers (ETxIDs), wherein a given ETxID among the one or more ETxIDs is unique to a given entry among the one or more entries related to the table T, and the given ETxID is related to a transaction relating to the distributed ledger for the given entry. The method described above is The further step is to create an entry transaction type, wherein the entry transaction type is A data set comprising one or more data pairs, each data pair relating to an entry in the table T, each data pair comprising a reference R that identifies a location in the table T, and a value VL for the identified location, The method according to claim 1.

3. The method according to claim 1 or 2, wherein the transaction relating to one or more TTxIDs or ETxIDs is associated with one or more unspent transaction outputs (UTXOs).

4. The method according to claim 3, wherein the UTXO for the transaction includes an output script that can be consumed by subsequent transactions related to the database D and / or table T.

5. The method according to any one of claims 3 or 4, wherein the UTXO for the transaction includes non-consumable output associated with a consumable output script for the transaction.

6. A computer implementation method for performing one or more transactions associated with a distributed ledger, wherein the transactions use a data structure implemented by a blockchain, provided by the method of claim 1 or 2, and the method is performed by one or more processors associated with a data management system (DBMS). The step of creating a database, A step of generating a first transaction to create a first database, wherein the first transaction is based on the database transaction type of the data structure, The steps include providing output for the first transaction based on the first database created above, and Steps including, A step of updating the first database in response to a request or transaction related to the first database, A step of generating a second transaction to create a first table, wherein the second transaction is based on the table transaction type of the data structure, The steps include providing output for the second transaction based on the first table created, and including the identifier (TTxID) of the second transaction, and Steps including, A step of generating a third transaction based on the output of the second transaction, A step of updating the database transaction type of the first database using the identifier (TTxID) associated with the second transaction, The steps include providing output for the third transaction based on the updated first database, and Steps and A computer implementation method comprising the above.

7. A step of populating the first table in response to a request or transaction related to the first table, A step of generating a fourth transaction to create a first entry in the first table, wherein the fourth transaction is based on the entry transaction type of the data structure, The steps include providing output for the fourth transaction based on the created entry and including the identifier (ETxID) of the fourth transaction, and Steps including, A step of generating a fifth transaction based on the output of the fourth transaction, The steps include updating the table transaction type of the first table using the identifier (ETxID) associated with the fourth transaction, A step of providing output for the fifth transaction, wherein the output is based on the updated first table and the identifier (TTxID) of the fifth transaction. Steps including, A step of generating a sixth transaction based on the output of the fifth transaction, The steps include updating the database transaction type of the first database using the identifier (TTxID) associated with the fifth transaction, The steps include providing output for the sixth transaction based on the updated first database, and Steps including and The method according to claim 6, further comprising:

8. A step of modifying the first table in response to a request or transaction related to the first table, The steps include generating a seventh transaction to modify the reference and / or value of a data pair associated with the first entry in the first table, A step of updating the entry transaction type of the first entry using the modified entry based on the seventh transaction, The steps include providing output for the seventh transaction based on the modified entry and including the identifier (ETxID) of the seventh transaction, and Steps including, A step of generating an eighth transaction based on the output of the seventh transaction, The steps include updating the table transaction type of the first table using the identifier (ETxID) associated with the seventh transaction, A step of providing output for the eighth transaction based on the updated first table, and including the identifier (TTxID) of the eighth transaction. Steps including, A step of generating a ninth transaction based on the output of the eighth transaction, The steps include updating the database transaction type of the first database using the identifier (TTxID) associated with the eighth transaction, The steps include providing output for the sixth transaction based on the updated first database, and Steps and The method according to claim 7, comprising:

9. A step of modifying the first table in response to a request or transaction related to the first table, A step of generating a tenth transaction to delete the first entry in the first table, The steps include updating the table transaction type of the first table in order to remove the identifier (ETxID) associated with the fourth transaction, The steps include providing output for the 10th transaction based on the updated first table, and including the identifier (TTxID) of the 10th transaction, and Steps including, A step of generating an eleventh transaction based on the output of the tenth transaction, A step of updating the database transaction type of the first database using the identifier (TTxID) associated with the 10th transaction, A step of providing output for the 11th transaction, wherein the output includes the identifier of the updated first database. Steps and The method according to any one of claims 7 or 8, comprising the step of including the step.

10. A computer implementation method for performing one or more transactions associated with a distributed ledger, wherein the transactions use a data structure implemented by a blockchain, provided by the method of claim 1 or 2, and the method is performed by one or more processors associated with a client entity. The steps include sending a request to one or more processors associated with the DBMS to create a first database, The steps include monitoring a distributed ledger to obtain at least one transaction output related to the first database D created, The steps include sending a request to one or more processors associated with the DBMS to create a first table for the first database, The steps include monitoring the distributed ledger to obtain at least one transaction output related to the first table (TTxID), A step of sending a request to one or more processors associated with the DBMS to update the first table using the first entry, wherein the first entry includes a data pair comprising a reference that identifies a location in the first table and a value for the identified location. A method that includes [a certain feature].

11. A computer implementation method for performing one or more transactions associated with a distributed ledger, wherein the transactions use a data structure implemented by a blockchain, provided by the method of claim 1 or 2, and the method is performed by one or more processors associated with a client entity. A step of monitoring the distributed ledger to obtain at least one transaction output related to a first entry (ETxID) in a first table of a first database, A step of sending a request to one or more processors associated with the DBMS to modify the first entry, wherein the request includes a request to modify a reference and / or value of a data pair associated with the first entry. The steps include monitoring the distributed ledger to obtain at least one transaction output associated with an identifier for the updated first table (TTxID) and / or the updated first database D, which incorporates the aforementioned modified first entry, and A method that includes [a certain feature].

12. A computer implementation method for performing one or more transactions associated with a distributed ledger, wherein the transactions use a data structure implemented by a blockchain, provided by the method of claim 1 or 2, and the method is performed by one or more processors associated with a client entity. The steps include monitoring the distributed ledger to obtain at least one transaction output associated with an identifier (TTxID) for a first table in the first database, The steps include sending a request to delete the first entry of the first table to one or more processors associated with the DBMS, The steps include monitoring the distributed ledger for at least one transaction output associated with an identifier for the updated first table (TTxID) and / or the updated first database, and A computer implementation method comprising the above.

13. A computing device, Processor and A memory including an executable instruction that causes the computing device to execute the computer implementation method according to any one of claims 10 to 12 as a result of execution by the processor, Equipped with, A computing device in which the computing device is a client entity.

Images