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 a database management system for data related to transactions associated with a distributed ledger. The present disclosure more particularly relates, without limitation, to applications where an existing database is to be migrated to or implemented in relation to a distributed ledger, i.e., after such 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 variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Although Bitcoin may be referenced herein for purposes of convenience and illustration, it should be noted that the present disclosure is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols related to any type of digital asset or representation of a digital asset fall within the scope of the present disclosure. The terms "user", "sender", and "recipient" may refer to computing or processor-based resources herein. The term "Bitcoin" is used herein 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 a cryptocurrency, a token representing at least a portion of a property, a smart contract, a license or software license, or a DRM contract for media content. It will be understood that the term "digital asset" is used throughout this specification to represent a product that may be transferred in payment for a transaction from one entity to another or associated with a value that may be provided as such payment.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system consisting of blocks, where each block consists of transactions. Each transaction is a data structure that encodes the transfer of control rights of digital assets 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 leading to that block and is chained together to create a permanent and immutable record of all the transactions written to the blockchain from its beginning. Transactions contain a small program called a script embedded within the inputs and outputs of the transaction that specifies how and by whom the output of the transaction 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, the transaction 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. The software client installed on the node performs this validation work on unspent transaction outputs (UTXOs) by executing their locking scripts and unlocking scripts. If the execution of the locking script and unlocking script evaluates to TRUE, the transaction is valid and the transaction is then written to the blockchain. Thus, for a transaction to be written to the blockchain, the transaction must i) be validated by the first node that receives the transaction, - if the transaction is validated, the node relays it to other nodes in the network, ii) be added to a new block constructed by the miner, and iii) be mined, i.e., added to the public ledger of past transactions.

[0005] When stored in the blockchain as UTXO, a user can transfer the control right of the relevant resources to another address associated with the input in another transaction. This transfer is usually done using a digital wallet. This digital wallet can be an application (app) on a computing device such as a device, physical medium, program, desktop, laptop, or mobile terminal, or a remotely hosted service related to a domain on a network operation such as the Internet. The digital wallet stores the public key and private key, tracks the ownership of resources, tokens, and assets related to the user, receives or consumes digital assets, and can be used to transfer tokens related to digital assets such as cryptocurrencies, or licenses, or property, or other types of resources.

[0006] Blockchain technology is best known for its use in digital assets, i.e., cryptocurrency implementations or tokens, but digital entrepreneurs are beginning to explore the use of both digital asset-based cryptographic security systems and other types of data that can be stored on the blockchain to implement new systems. If the blockchain can be used for automated tasks and processes not limited to the scope of digital assets, it would be extremely advantageous. Such solutions would be more versatile in their applications while still being able to utilize the advantages of the blockchain, such as permanent, tamper-proof records of events, distributed processing, etc. Thus, the public blockchain serves as an immutable distributed data storage system that utilizes both cryptography and economic incentives for security.

[0007] However, such security elements do not always exist within databases such as distributed databases and / or private databases and / or corporate databases. A database in which portions of data are stored at several different physical locations and computing power is distributed among associated nodes is called a distributed database. Thus, this leaves such distributed databases vulnerable to attack. Security features are important to many enterprises that use distributed databases, and these may 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 within a single server or computing resource, and provides systematic means for updating and querying data within the distributed database.

[0008] There are many parallels that can be drawn between blockchain and distributed databases such as having a decentralized storage area for information across a network to avoid having a single point of failure. The advantages of blockchain stem from the underlying data structure where cryptographic hash functions are used to link data to derive an immutable record of all valid actions from its inception. This is a very important feature for transparency and auditing that private or existing databases cannot provide. However, even so, there is no easy technique for migrating current distributed database and DDBMS systems to be associated with a distributed ledger, i.e., incorporated within a blockchain. Many proposed blockchain solutions that claim to manage data do not provide interoperability with current distributed databases, which is a technical impediment to enterprises that should change to a more secure blockchain-based implementation for managing and storing data. From a commercial perspective, such interoperability requires greater investment from enterprises and may cause enterprises to oppose such changes.

[0009] The present disclosure addresses these technical problems by proposing a technique by which existing and common database functions, such as those already used in existing (distributed) databases, can be used to implement a distributed database on a distributed ledger, i.e., a blockchain, or to use a distributed ledger, i.e., a blockchain. Accordingly, the present disclosure provides aspects and embodiments for implementing a new data structure that is compatible with existing databases and their functions, as well as with blockchains, thereby ensuring interoperability and scalability and contributing to the additional security provided by blockchain implementation. The present disclosure also provides a blockchain-related DBMS for managing this new data structure. Thereby, the present disclosure enables means for achieving interoperability with existing non-blockchain databases, which is important for the gradual conversion of current (private or other) database systems to more secure and robust equivalent blockchain systems.

SUMMARY OF THE INVENTION

MEANS FOR SOLVING THE PROBLEMS

[0010] In one aspect, the present disclosure proposes a method, device, and system for providing a new structured data storage technique related to blockchain transactions for implementing a new data structure. This new data structure is provided for implementing 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. However, unlike a conventional DBMS for a conventional database, the present disclosure provides a blockchain DBMS configured to manage data associated with one or more blockchain transactions.

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

[0012] Accordingly, aspects and embodiments of the present disclosure propose a system in which existing and known (general) database functions can be provided by structuring data within 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 to access and manage data associated with the data structure.

[0013] Throughout this specification, the word "comprise", or variations such as "includes", "comprises", or "comprising", are to be understood to imply the inclusion of the stated 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] Here, by way of example only and with reference to the accompanying drawings, aspects and embodiments of the present disclosure are described.

Brief Description of the Drawings

[0015]

Figure 1

Figure 2

Figure 3a-1

Figure 3a-2

Figure 3b

Figure 3c

Figure 4a

Figure 4b

Figure 5

Figure 6

Figure 7

DETAILED DESCRIPTION OF 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 the distributed ledger, and an identifier for a database D to be used to obtain data for one or more transactions related to the distributed ledger, and creating a database transaction type 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 one or more tables associated with 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 that is an identifier for a table T, where the table is among one or more tables associated with the identified database D, and comprising one or more entries associated with the identified table T.

[0018] There are many parallels that can be drawn between a distributed ledger, i.e., a blockchain, and a distributed database, such that in order to avoid having a single point of failure, an information non-centralized storage area is traversed across the network. The advantages of a blockchain stem from the data structure underlying it, i.e., here, each block contains the hash of the previous block leading up to that block and becomes chained together, such that, for example, a cryptographic hash function is used to link the data here to lead to an immutable record of all valid actions from its inception. This structure for the data within a blockchain is a very important 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 the data types associated with one or more transactions associated with a distributed ledger while identifying a transaction representing a table having its associated entries, i.e., database data types and table data types as presented above. Since the data structure of 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 a blockchain, hereinafter it will be referred to as a blockchain (based) data structure for simplicity of reference. For example, general database functions used within an existing database often rely on the arrangement of data within a table having entries that can be identified by rows within a given table, where the given table is then manipulated by general database commands such as using Structured Query Language (SQL) commands. By implementing a data structure for the case where data associated with one or more blockchain transactions can likewise be stored and manipulated using these same general functions, the first aspect of the present disclosure enables interoperability with existing databases and / or distributed databases, thereby making the conversion or transition process to using a blockchain instead of an existing database simple, scalable, seamless, straightforward, completely transparent, traceable, and efficient.Thus, the blockchain data structure proposed in the first aspect can provide a structured storage area across the database based on a blockchain transaction identifier (TTxID) associated with a given transaction.

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

[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 the blockchain transaction related to entry E, and entry E is associated with table T of a given database D. Thus, any change to an entry can be effected by a transaction that consumes the latest transaction (identified by ETxID within the entry data type), where the new transaction accommodates the updated data. Consistently, each dependent transaction must also be updated to reflect the latest transaction identifier TxID (which can be 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 data from the data structure cannot be easily removed or modified (without amending 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, instead of entry data types, data references and / or values can be immediately stored into table T, i.e., 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 simplicity of reference and consistency, a nested data structure in which both ETxID and TTxID are stored is referred to below, but the present disclosure is not so limited.

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

[0024] Advantageously, including unspendable outputs, such as OP_RETURN scripts, is used to indicate a valid transaction related to performing one or more database operations. This enables an unspendable OP-RETURN related UTXO, which includes the latest update to database D, 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 when it is in the distributed ledger, i.e., the blockchain. A further advantage is that the provision of unspendable outputs 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 an unspendable OP_RETURN transaction related to database D from which spendable payloads or UTXOs can be obtained. The UTXO for the recipient, once identified, can then be processed by executing the spendable output script.

[0025] The 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 related to a distributed ledger, the data structure being managed by one or more processors associated by a database management system (DBMS) for the distributed ledger, the data structure including a data transaction type, a table transaction type, and an entry transaction type as presented above with respect to the first aspect. In some embodiments, the data structure is a nested transaction storage structure configured to store an entire identified database D based on storing the TTxID related to the identified database D and in some embodiments the ETxID as described above.

[0026] Some embodiments of the present disclosure relate to a method for executing one or more database requests by performing transactions associated with a distributed ledger, where the transactions use a blockchain-based data structure as presented above. The method is implemented 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 for creating, updating, or performing one or more of modifying / deleting one or more of a database transaction type, a table transaction type, or an entry transaction type. The method also includes providing one or more outputs based on the created transactions associated with the distributed ledger. In some embodiments, the output is a consumable output script and / or a non-consumable output script 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 a table or an entry. The method also includes updating one or more of the data types presented above based on the output of previous transactions. The sequence of steps for generating transactions, providing outputs, and updating data types to execute one or more database requests is described in detail with respect to the following figures.

[0027] Regarding the embodiments described above, and complementarily thereto, related embodiments, when implemented by one or more processors associated with a client entity for carrying out one or more requests related to a database, include sending requests related to creating, updating, or modifying or deleting one or more of a database transaction type, a table transaction type, or an entry transaction type, and monitoring a distributed ledger for at least one transaction output associated with a transaction generated by a DBMS associated with each request.

[0028] Advantageously, the above embodiments provide a way of using standard or known database commands and functions, such as standard Structured Query Language (SQL), for operating on a data structure of a first aspect that is associated with a distributed ledger and includes transaction identifiers related thereto for those of the distributed ledger. Advantageously, by enabling the use of standard SQL commands for use with a blockchain implementation data structure, before, during, and after the migration of an existing database to a blockchain-based implementation form of the database, a user, or a client entity associated with a given user, will not detect a change. This seamlessness is important for the gradual conversion 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 above embodiments use one or more consecutive blockchain transactions to enable standard SQL commands to be applied to a blockchain-based data structure of the first aspect. Although the selection of SQL commands is described herein in the present disclosure, a similar method can be applied to map the entire standard SQL library to a blockchain-based data structure of the first aspect.

[0029] A second aspect of the present disclosure relates to a computer-implemented method for managing access to a data management system (DBMS), where the DBMS manages data related 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, when implemented by one or more processors associated with the database, includes responding to a request for registration with the DBMS by creating a record related to a given user, the record including an identifier for the given user among a plurality of users. The method includes obtaining a public key P related to the given user, the public key being part of a cryptographic key pair related to the given user, the cryptographic key pair including a secret key V for the given user. The method then includes obtaining or assigning one or more attributes associated with the given user, each attribute being associated with settings related to access to the database managed by the DBMS. In some embodiments, the settings for a given attribute confirm whether the given attribute is associated with permissions to perform one or more of a read operation, a write / update operation, a modification operation, or a deletion operation related to the database. This may be referred to as a permission setting. The method also includes updating the record based on the obtained public key P and one or more attributes associated with the given user, and storing or providing the updated record related to the DBMS.

[0030] Accordingly, a second aspect of the present disclosure relates to a management system for facilitating claims related to the blockchain-based data structure of the first aspect. For example, a data management system (DBMS) may be required to assist in accessing data within the data structure, constructing and / or submitting transactions to the distributed ledger for the data structure, and maintaining records of associated transaction IDs (TxID, which may be TTxID or ETxID). This data management is similar to a standard database management system (DBMS) or a distributed DBMS (DDMS) of a conventional distributed database that serves to integrate a distributed data system and can be implemented by a third-party service, or a client-side implementation, i.e., a computing entity for a client entity or organization having sufficient resources to manage their own DBMS, which may be a remote server or one or more distributed processors implementing a single server functionality.

[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 identification information verification resource. The second aspect performs multi-level permission control such as read-only, write-only (to update, modify, or delete data), or both read and write privileges, based on the 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 improves the security of the DBMS, and this can be implemented off-chain as presented above. This is described herein as an off-chain implementation form, i.e., not implemented in the distributed ledger itself or without using the distributed ledger itself, but the present disclosure also relates to an on-chain implementation form using 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 aspect may be implemented 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, the user record may be stored off-chain as a local file in the form of an object (to be used as such when operating using, for example, an object-oriented programming language), or encrypted on the blockchain with respect to the TTxID or ETxID.

[0032] In some embodiments, an attribute may refer to a team or category with which a user is associated. For example, within an organizational structure, the attribute may be the name of a department. Thus, a user having a department attribute of "Human Resources" (HR) in a registered user record may have a setting with an effective permission (permission setting or access attribute setting) to access a database or table related to "personnel management", but does not have an effective setting to access a database or table related to the accounting department. Sub-categories of attributes for different users may also have different settings. For example, a user record having an HR director status in the HR department may have full access (read and write) to the HR database, but may only have "read" access to some accounting databases such as the payroll database. Another user in the same HR department having an HR assistant status may not have any effective permission setting for the payroll database and may similarly only have read access to the HR database.

[0033] In some embodiments, the setting for each attribute may also be provided in a registration request received from a given user (or a client entity associated with the given user), or the setting may be obtained from computing resources associated with the DBMS, or the setting may be pre-determined for each attribute by a system administrator or equivalent computing resources for the database managed by the DBMS.

[0034] In some embodiments related to the second aspect, the present disclosure also provides a computer-implemented method for implementing a DBMS for accessing a database, the method comprising obtaining, from a client entity, a request for an operation related to the database, the client entity being associated with a given user among a plurality of users, 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 the 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 the given user based on a user record associated with the DBMS. In some embodiments, the user record is created upon registration 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, based on the information in the user record created during registration, when a user is registered as described above, the second aspect of the present disclosure provides a single point of reference for distributed data and verifies that a given user has permission, i.e., a valid configuration, to execute a request, and provides a method for implementing a DBMS for processing user requests related to the blockchain data structure of the first aspect.

[0036] In some embodiments, the step of determining that a user is authorized includes determining that a user record associated with the DBMS exists for a given user at the time of registration with the DBMS. In some embodiments, the step of verifying the digital signature is based on determining that the private key V, or the signature key K used to sign the request, is associated with the public key P associated with the given user in the user record. This advantageously enhances the security of the DBMS at the time a request for database access is made because two checks are performed before a given user or a client entity associated with a given user can have any access to the data in the database. First, if the request is from an unregistered user, the request is immediately rejected because there is no associated user record for the requesting user for which to verify permission to access. Second, by verifying that the digital signature in the request is actually associated with the public key P linked to the user record, the identity information of the user making the request is examined so that the signature can be verified using this public key P. If a malicious user sends a request, the public key P held with the user record cannot verify the digital signature (the digital signature is based on the private key V of the same user).

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

[0038] When performed by one or more processors associated with a client entity, a second aspect of the present disclosure also includes generating a request for registration with a DBMS, the request being associated with a given user, and providing or accessing one or more attributes associated with the given user, each attribute being associated with settings related to a database managed by the DBMS, to provide a method for registering with the DBMS. The method also includes 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, and calculating the 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 the network identifier of the client entity associated with the given user. This key V is kept secret, but the public key P is used to generate the public key P in such a way that any message encrypted or signed using the private key V can only be validated, 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 for performing one or more operations related to the blockchain implementation database.

[0039] A second aspect of the present disclosure also includes a method of accessing data associated with a database when implemented by one or more processors associated with a client entity. The method in this case comprises the step of generating the above-described request related to database operation, the request being related 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 the 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 the private key V, the signing key being a short-term key. In some embodiments, the cryptographic keys, i.e., the public key and / or private key and / or session key for a given client entity, are stable elliptic curve digital signature algorithm (ECDSA) keys. The ECDSA public key is, for example, a valid point on the secp256k1 curve that is compressed and hex-encoded. 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, in some embodiments, a known constant that may be known for one or more blockchain transactions or may be shared with one or more entities associated with the client entity. 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] Digital signatures associated with a given user's private key V also advantageously provide an auditable record of request submissions that can be verified using user records without the given user having to directly interact with the blockchain. The system administrator, i.e., the computing resources that provide this functionality to the DBMS, may, in some embodiments, batch requests into one blockchain transaction. By including the signed requests within OP_RETURN, a clear audit trail is still provided, thereby providing interoperability with legacy systems while still maintaining an immutable record on the blockchain, enhancing transparency and accountability. The OP_RETURN payload can, in some embodiments, be encrypted using a deterministically derived key before the transaction is constructed (if the request is a write request). In some embodiments, attributes can also be attached, if necessary, along with data references or hashes of references for easier retrieval.

[0042] In a third aspect, the present disclosure relates to a computer-implemented method for implementing a database management system (DBMS) for managing a database related to transactions associated with a distributed ledger. The method comprises receiving a message related to a current instance of a user record for a given user among one or more users, the request being related to the database and provided by the given user. The method includes parsing a request related to the database, the parsing step comprising extracting one or more attributes associated with the given user from the current instance and verifying that the settings for each of the extracted attributes are valid for the request made by the given user. In some embodiments, the verifying comprises checking that the given user has permission to access the database for the request made, as indicated by the settings for a given attribute among the one or more attributes. In response to a successful verification, the method includes performing one or more operations related to the database based on the request, the database being based on the data structure provided as described in the first aspect. The performing step, when the request is related to a read operation, is to obtain one or more transaction identifiers (TTxID, ETxID) related to the request, each obtained transaction identifier being related to a transaction whereby data for the transaction is associated with the data structure, and further includes accessing data related to the obtained transaction identifier (TTxID, ETxID) from the data structure. When the request is related to a write operation or a modify operation or a delete operation, in addition to the obtaining step, the method further includes generating one or more transactions for consuming or processing the transaction associated with the obtained one or more transaction identifiers (TTxID, ETxID) based on the operation, and updating the data structure using the identifier related to the generated transaction.

[0043] When registering and / or accessing data in the blockchain-based data structure of the first aspect, in addition to the advantages already described above for improving security, reliability, and privacy, 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 this functionality of interpreting, validating, and executing one or more SQL commands with respect to the blockchain, i.e., using a TTxID or ETxID related to the blockchain. Additionally, the method of the third aspect also performs the execution of attribute verification in the user record. Thus, assuming that a user record exists for a given user, then it is checked whether the settings for the attributes for that user are valid for the request made. In some embodiments, such verification is based on the methods and embodiments described with respect to the second aspect. For example, continuing from the above example of an organization where the attribute is a department or team, if a registered user with an HR assistant attribute makes a write request to the HR or payroll database, this is rejected. On the other hand, if a registered user with an HR director attribute makes a read request to the payroll database, this request is permitted to proceed further. If the appropriate settings, i.e., access permissions associated with one or more attributes, are valid, the request is executed by either obtaining the relevant transaction identifier (based on consuming the output of a previous transaction by an authorized or registered user having the necessary permissions) or generating one or more blockchain transactions, and providing an output script having a transaction identifier TxID (which may be a new TTxID or ETxID) for the generated transaction, as a result of which the database data type or table transaction type or entry transaction type may be updated with the new TxID.

[0044] When the claim relates to a read function, i.e., data access rather than an operation, in some embodiments, this may be executed off-chain by the DDMS since no required transaction is generated, and the standard SQL protocol may be used for data access (following the registration and / or access verification of the second aspect). This also advantageously enables the system to utilize standard efficiency optimization and scaling methods for easy interface with existing enterprise data management solutions.

[0045] In some embodiments, when the claim relates to a write operation, a modification operation, or a deletion operation, the steps to be executed further include a method of performing one or more transactions as described above with respect to the first aspect for executing standard database SQL commands. In related embodiments, the generating step further includes obtaining an output script related to the obtained transaction identifier (TTxID, ETxID), and constructing a further transaction based on the output script. The further transaction may be based on, or signed using, a private key V related to the client entity of a given user, the private key being part of a cryptographic key pair that includes a public key P for the given user. The method then includes providing the further transaction to the distributed ledger, and the further transaction is associated with a new transaction identifier (TTxID, ETxID).

[0046] Advantageously, the generation of further transactions is only possible by users having the required attribute permissions and by users who can be verified using the public key P in each user record. Thus, previous transactions referenced by a transaction identified among the most recent versions of the data type in the blockchain implementation database can only be consumed or accessed by registered and verified users, such that their identification information is recorded or linked at each stage using keys P and V. This ensures that there is a record of the users associated with the most recent transactions (even if these are encrypted) using these public keys.

[0047] In embodiments where the request relates to a write operation, a modification operation, or a deletion operation, the step of constructing a further transaction is performed by a simplified payment verification (SPV) client associated with the DBMS, and the SPV client communicatively couples the DBMS to the distributed ledger via a communication network.

[0048] The SPV client is a computing resource associated with the DBMS and ensures that the DBMSs of the second and third aspects connect to the blockchain (distributed ledger) via peer-to-peer connections to all nodes. However, the SPV does not mine or store a copy of the blockchain, and thus such transactions can be verified and executed efficiently and with lower complexity.

[0049] In embodiments where the claim relates to a write operation, a modification operation, or a deletion operation, each transaction identifier (TTxID, ETxID) obtained is associated with a transaction that includes unspendable UTXOs, where the unspendable UTXOs are associated with or include a spendable payload, and the spendable payload is a spendable UTXO. In some embodiments, each spendable UTXO and unspendable UTXO is stored in a UTXO set or memory associated with the DBMS, the unspendable UTXO is an OP_RETURN output script, and one or more spendable UTXOs in the UTXO set or memory are used to construct further transactions.

[0050] Advantageously, to facilitate quick and easy access to the data, an indexed copy of the UTXO set or subset that houses the relevant up-to-date transactions may be provided in relation to the DBMS of the third aspect. In some embodiments, this UTXO set may be integrated with an SPV wallet or node that tracks the cryptographic keys for registered users associated with the DBMS to record updates (spending) of UTXO transactions. In some embodiments, separate records of the index are stored, additionally or alternatively, as a register of all transaction identifiers (TxIDs including TTxID and ETxID of the data type of the data structure of the first aspect). Advantageously, this enables the OP_RETURN data to be retrieved more easily for queries. In some embodiments, the index associated with these registers can be a simple integer count during 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 a memory, the memory including executable instructions that, as a result of execution by the processor, cause the device to execute computer-implemented embodiments of the first and second aspects described above to be performed by a client entity.

[0052] Embodiments of the present disclosure include a DBMS system for managing access to data associated with one or more transactions related to a distributed ledger, the data managed by the DBMS being stored within a data structure such as that provided by the blockchain-based data structure of the first aspect. 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 aspect described above, and a transaction execution system having one or more processors configured to execute instructions for performing the method of the third aspect described above. The DBMS also includes one or more registers for storing a plurality of transaction identifiers associated with the database, and a UTXO set or memory for storing a copy of a plurality of UTXOs associated with the database.

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

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

[0055] Some specific embodiments are described herein by way of example with reference to the accompanying drawings, with like reference numerals referring to like features.

[0056] First Aspect - Blockchain Implementation Data Structure FIG. 1 is a flowchart showing a method related to providing a blockchain-based data structure. In other words, this figure shows a method for providing a data structure associated with one or more transactions associated with a distributed ledger, i.e., a blockchain, according to the first aspect. In the embodiment seen in FIG. 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 an embodiment of the first aspect. However, in some embodiments, since it is possible to provide end data or values and / or references within the table transaction data type itself, it will be understood that an entry transaction identifier (ETxID) and an entry data transaction type are not necessarily required for all embodiments of the first aspect. However, for ease of understanding and consistency, nested data types are described below throughout the description and the accompanying figures.

[0057] To facilitate database functionality, the data being stored must be structured consistently so that it can perform the expected management and access that a conventional database would perform. The best-known example in a conventional database is the Structured Query Language (SQL) that uses a standard library of functions for recording, updating, and querying data in a relational database. To enable SQL integration for blockchain data, the present disclosure proposes a similar structure for the data contained within a blockchain transaction, and FIG. 1 shows a method for providing or implementing such a data structure, which is also referred to herein as a blockchain database or a blockchain implementation data structure. The steps in FIG. 1 are performed by one or more processors associated with a database management system for creating and / or managing a data structure related to a blockchain.

[0058] Step 102 shows creating a database transaction type, and the database transaction type includes an identifier for the database. This can be the name of the database, i.e., D or the first database, which should be used to store or obtain data for one or more transactions related to the distributed ledger. The database D shown in the database transaction type includes within one or more tables related to database D. The created data transaction type is configured to store an identifier (TTxID) for a transaction related to one or more tables.

[0059] Step 104 shows the step of creating a table transaction type, and the table transaction type has an identifier for the table. This can 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 related to the identified database D. The table T shown in the table transaction type includes one or more entries related to table T. The created table transaction type is configured to store an identifier (ETxID) for a transaction related to one or more entries.

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

[0061] Step 108 shows a step of providing one or more data pairs among the entry transaction types of step 106. Each data pair is related to an entry E in the identified table T, and each data pair includes a reference R identifying a position in the identified table and a value VL for the identified position. In some embodiments, R may indicate a row number, which is a position shown in table T, i.e., the first row or the ninth row, etc. The remaining elements in each row may then include the value of the shown row, i.e., VL.

[0062] Step 110 shows a step of providing one or more entry transaction identifiers (ETxIDs) among the table transaction types of step 104. A given ETxID is among one or more ETxIDs that are unique to a given entry among one or more entries related to table T. A given ETxID is related to a transaction related to the 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, since the ETxID is related to the data related to a given entry E of table T, it is called an entry transaction identifier.

[0063] Step 112 shows a step of providing one or more table transaction identifiers (TTxIDs) among the database transaction types of step 102. A given TTxID is among one or more TTxIDs that are unique to a given table among one or more tables related to database D in step 102. This given TTxID is related to a transaction related to the distributed ledger for a given table T, and in other words, since it is related to the data related to the table in database D, it is called a table transaction identifier.

[0064] An in - nested - blockchain - based data structure according to a first aspect, showing transaction data types related to a blockchain and their interrelationships, is seen in FIG. 2. The database transaction data type accommodates the name of a database (D) that can be used to search or query the data structure. It also accommodates the TTxID of all the tables that are components. In this specification, the TTxID is stored for each table T1, T2, T3, etc. The table transaction data type starts with the name of the table (T1, T2, T3) and is filled with an ETxID that refers 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 related data values, where each row in table T1, T2, or T3 represents one. A reference and value pair for entry E3 in table T3 is shown in FIG. 2.

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

[0066] Having structured data as found in SQL relational databases enables efficient data retrieval. A significant amount of work has been poured by developers in the past to optimize the process of querying data based on the structure underlying the data. Most commercial database systems have a dedicated query optimizer and a query execution engine. The execution engine determines the operations (such as sort, scan, and merge) to be applied to the data. The query optimizer then creates a plan for execution (logical flow) to execute the search most efficiently according to the structure of the data and the computational cost. Finally, the query is executed by the query execution engine according to that plan.

[0067] If SQL and its functions and commands are typically used in existing databases including distributed databases, embodiments of the present disclosure provide a method of implementing standard SQL commands for performing one or more standard database operations on a blockchain implementation data structure as shown in FIG. 2. For easier adoption and interoperability with current database systems, FIGS. 3a - 3c show a method for showing how standard SQL commands can be applied to a blockchain database using one or more consecutive transactions associated with the blockchain. In FIGS. 3a - 3b, SELECT or WRITE SQL commands (update / insert, modify, or delete) are illustrated, but a similar method can be applied to map the entire SQL library.

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

[0069] The command CREATE DATABASE can be executed including the following steps.

[0070] TxID1 - Generating a first transaction to create a first database, the first transaction including steps based on the database transaction type of the data structure and providing an output for the first transaction based on the created first database (database_name).

[0071] Subsequently, in response to requests or transactions related to the first database, subsequent SQL commands are executed by the following transactions.

[0072] CREATE TABLE including the following steps.

[0073] TxID2 - Generating a second transaction to create a first table, the second transaction including steps based on the table transaction type of the data structure, providing an output for the second transaction based on the created first table, and including the identifier (TTxID) of the second transaction.

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

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

[0076] INSERT INTO TABLE including the following steps.

[0077] TxID4 - A step of generating a fourth transaction to create a first entry in a first table, wherein the fourth transaction provides an output for the fourth transaction based on the entry transaction type of the data structure and the created entry, and includes an identifier (ETxID) of 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 the first table using the identifier (ETxID) associated with the fourth transaction, and a step of providing an output for the fifth transaction, the output including a step 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 of updating the database transaction type of the first database using the identifier (TTxID) associated with the fifth transaction, and a step of providing an 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 for creating and / or managing the data structure of Figure 2 when executed by one or more processors associated with a DBMS.

[0081] Modifying the first table using an UPDATE / MODIFY command implemented using a blockchain transaction in response to a request or transaction related to the first table, comprising the following steps.

[0082] TxID7 - Generating a seventh transaction to modify a reference and / or value of a data pair related to a first entry in the first table. Subsequently, based on the seventh transaction, updating the entry transaction type of the first entry using the modified entry, and providing an output for the seventh transaction based on the modified entry including the identifier (ETxID) of the seventh transaction.

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

[0084] TxID9 - Generating a ninth transaction based on the output of the eighth transaction, Updating the database transaction type of the first database using the identifier (TTxID) associated with the eighth transaction, and providing an 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 that creates and / or manages the data structure of Figure 2 when executed by one or more processors related to the DBMS.

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

[0087] TxID10 - Generating a tenth transaction to delete a first entry in the first table, Updating the table transaction type of the first table to remove the identifier (ETxID) associated with the fourth transaction, and providing an output for the tenth transaction based on the updated first table and including the identifier (TTxID) of the tenth transaction.

[0088] TxID11 - Generating an eleventh transaction based on the output of the tenth transaction, Updating the database transaction type of the first database using the identifier (TTxID) associated with the tenth transaction, and providing an output for the eleventh transaction, the output including the identifier of the updated first database.

[0089] The above example shows how some SQL commands may be executed using a blockchain-based data structure of the first aspect. Some modifications from the above transaction flow are presented below and are also within the scope of the present disclosure.

[0090] For many enterprise applications and existing databases, data is continuously added, removed, and changed. For these high-volume cases, it may not be practical and may be economically inefficient to submit individual requests or per-request database commands, each requiring a separate blockchain transaction.

[0091] Thus, in some embodiments of the present disclosure, requests can be batched to advantageously enable more efficient resource management at both the entry level and the table level. To insert multiple entries (rows) into a single table, data in the blockchain data structure can be indexed and concatenated within a single transaction. To update entry information, non-consumable transactions (i.e., OP_RETURN transactions) can be copied across related consumable transactions by changing only one or more related entries. For related 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 the data is changed.

[0092] An SQL server may generally store records of all requests (transactions for a blockchain-based data structure as proposed) in a database in a file generally called a transaction log. This usually 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-scale systems, this file can reach terabytes in size, making it difficult and expensive to store. To address this problem, some embodiments of the present disclosure provide a similar logging system implemented using a distributed ledger that uses a series of transactions, i.e., for the blockchain-based data structure of FIG. 2. A series of request transactions can be stored within a single transaction using only the transaction identifier TxID of the latest transaction as a reference. This advantageously dramatically reduces the size of the backup log. Further, storing this backup log of a series of transactions on the blockchain also means that, advantageously, an entity or company does not have to store the backup itself and only needs to retain the record of the latest transaction. Advantageously, this log also provides a permanent and immutable record of all updates to the database and can thus 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) functions to facilitate SQL requests and structure data related to one or more databases. In the case of a blockchain-based database, this is particularly important for constructing and submitting transactions (see FIGS. 3a - 3c), as well as maintaining records of associated transaction IDs (TxIDs) (see the data structures described in FIGS. 1 and 2). This data management system for blockchain-based data structures is similar to a distributed database management system (DDMS) of a conventional distributed database that works to integrate distributed databases. This DBMS can manifest itself in several ways, i.e., one or more computing resources for remote third-party services, or a client application that can be configured for a client entity that may have or be associated with computing resources or processing / network capabilities and availability for managing their own DBMS.

[0094] In a second aspect of the present disclosure, identification information and access verification techniques are described for client entities that desire to access data managed by a DBMS and associated with one or more blockchain transactions. In some embodiments, the method related to the second aspect is implemented by one or more processors associated with the DBMS. In some embodiments, the method of the second aspect is 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 method related to the second aspect enables multi-level access or permission control, such as read-only, write-only, or both read and write privileges, for client entities that desire to perform database operations.

[0095] FIG. 4a is a flowchart showing a method related to an off-chain attribute-based access technique that can be used to verify access to a database via a DBMS and can be advantageously adapted to any type of data or organization. Access to the database or components of the database is restricted unless the user submitting the request has one or more attributes associated with a setting that permits the requested operation. FIG. 4a relates to a method implemented by one or more processors associated with the DBMS.

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

[0097] Step 404a shows the step of creating a record related to a given user. The record may be stored in one or more memories or storage modules related to the DBMS so as to be retrieved as needed and when necessary, or may be stored in a remote server or storage structure. The record includes an identifier for a given user among a plurality of users. This may be the name and other details of the user that can be used to identify the user.

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

[0099] Step 408a indicates obtaining or assigning one or more attributes associated with a given user, and each attribute is associated with a setting related to access to a database managed by the DBMS. For example, the setting may be a permission setting for the 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 status indicating whether a given user with a specific attribute is permitted to access the components of the database for reading / writing. The attribute settings are obtained from the client entity, or in some embodiments, the attributes are either pre-assigned by the DBMS according to the identification information of the given user. The setting may be obtained from the client entity in relation to the attribute, or may be pre-assigned for some attributes received by the system administrator module of the DBMS.

[0100] Step 410a indicates updating a record based on the obtained 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 where the user record may later be accessed therefrom, either in or associated with a DBMS, as described in the following steps. Such storage areas may also be possible in remote computing resources.

[0101] Step 412a indicates obtaining a request for an operation related to the database from a client entity, which is associated with a given user among a plurality of users. The request includes a digital signature associated with the given user who sends the request at 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 the given user. In other words, as described in steps 402a - 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 the user record is not 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 impact 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 sent 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. The digital signature will only succeed in verification or decryption using the paired public key P if it is based on the private key V. This ensures that the request actually originated from the given user as 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 convey this rejection.

[0106] In response to a successful verification of the digital signature, in step 422a, a message based on the current instance of the user record and the request is generated by the DBMS. This message may be machine-readable and is generated in a format that can be parsed by one or more DBMS components (as will be described below with respect to the third aspect). In some embodiments, the message includes details reflecting attributes, settings (if received), and the display of the database operations requested by the user.

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

[0108] Step 402b indicates generating a request for registration with the DBMS, where the request is associated with a given user associated with the client entity sending the request.

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

[0110] Step 406b indicates generating a private key V associated with a given user, where the private key is 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 the DBMS. It may be generated by any known means such as using a common secret or a 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 key as well as the private key may be short-term keys that are generated periodically or at any interval.

[0111] Step 408b indicates calculating the public key P based on the private key V. Since any message signed by the private key V cannot be validated without using the public key P of the cryptographic key pair, this key is related to the private key V and vice versa.

[0112] Step 410b indicates 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 shows generating a request for an operation related to the database, and the request is related to a given user. For simplicity of reference, in this figure, it is understood to be the same user who sent 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 with the DBMS.

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

[0115] Step 416b shows applying the digital signature to the request and sending the signed request to the DBMS. In some embodiments, if the request is rejected by the DBMS (due to a failed authorization or an 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 with respect to the second aspect, the data management system facilitates SQL requests and processes requests for a database such as the blockchain - based database in FIG. 2. The third aspect of the present disclosure relates to a method for interpreting and processing database requests for performing operations related to a blockchain database. In some embodiments, when the method of the third aspect is implemented by one or more processors of the DBMS, it effectively acts as an SQL compiler and performs verification of attributes (subsequent to the authorization and identification information verification of the second aspect).

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

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

[0119] In step 504, the 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-set and stored in memory related to the DBMS. In either case, both the attributes for one or more types of database operations and their associated permissions (settings) are retrieved in this step.

[0120] In step 506, it is verified whether the permission settings for each of the retrieved attributes are valid for the request made by a given user. In other words, the SQL request is parsed and the required database attributes are inspected against the settings associated with each respective attribute for the given user. In some embodiments, considering the user and attributes as objects, this inspection may be performed based on using a simple boolean test as follows. (object instance).(database attribute)==true

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

[0122] If the access condition is satisfied, in some embodiments, the SQL request is compared against the SQL command library. If such a command is not 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, and each transaction identifier obtained is related to a transaction whereby data for said transaction is associated with a data structure. This step also includes accessing data related to the transaction identifier (TTxID, ETxID) obtained from the data structure.

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

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

[0126] If the request is associated with a WRITE operation, i.e., an update / insert operation, a modification operation, or a deletion operation as seen in FIGS. 3a - 3b and described above with respect to the first aspect, in addition to obtaining the data in step 512, the method further includes, in step 516, a process of generating one or more transactions for consuming or processing the transactions associated with the one or more transaction identifiers (TTxID, ETxID) obtained, based on the operation. In some embodiments, for a WRITE operation, the appropriate TxID (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 the SPV wallet for communication with the distributed ledger as described above.

[0127] At the same time, an OP_RETURN payload may be constructed upon generation of a new transaction for the blockchain. This is similar to the generation of a transaction for a command, as presented in FIGS. 3a - 3c, in addition to including, for example, a 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 having to directly interact with the blockchain, and can be used to verify a submission for a given user at the time of submission or at any point in the future. This advantageously provides interoperability with legacy systems while still maintaining an immutable record on the blockchain. In some embodiments, the OP_RETURN payload can then be encrypted using a deterministically derived key before being passed to the transaction constructor.

[0128] The transaction construction can be done in several ways at step 516. For example, upon receiving the required TxID and OP_RETURN payload, the transaction can be constructed using a simple payment verification (SPV) client local (to the DBMS) that connects to the blockchain network via a peer - to - peer connection to all nodes, or a wallet for the DBMS. The SPV client or the wallet itself does not mine or store a copy of the blockchain.

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

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

[0131] Consumable output is first added and linked to an address (address_i) held by the system for the SPV client of the DBMS. The address can be generated using the hash of the public key derived in a known deterministic derivation method. 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 (without using the TxID and unlocking script) using ECDSA. The signature data (sig) and the 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 an SPV wallet to all nodes for verification and inclusion in the 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 associated with the blockchain-based data structure in FIG. 2 are then updated with the TxID of the newly configured or generated transaction.

[0138] FIG. 6 is a schematic diagram showing a data management system or a data or database management system (DBMS) 600 as described with respect to a second or third aspect of the present disclosure for managing storage, access, and manipulation of data in a blockchain-based data structure as seen in FIG. 2.

[0139] This is similar to a distributed database management system (DDMS) of a conventional distributed database that serves to integrate a distributed data system. This DBMS 600 system can be a remote or third-party service implemented by one or more remote servers or may be associated with a client application.

[0140] Regardless of the implementation form, the DBMS 600 includes the following components. · A registration and access management system 604 based on the method described with respect to the second aspect above to provide access control for read / write privileges for users associated with the 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 with respect to the third aspect. This component may include a command interpreter 606a that behaves as an SQL compiler, a transaction constructor 606b that constructs a series of transactions to be submitted, and an SPV wallet 606c for output execution management, transaction submission, network monitoring, etc. when cooperating or communicating with the blockchain 612. · With respect to the DBMS 600, a UTXO set 610 and a TxID register 608 for recording all TxIDs and the latest data in the UTXO set.

[0141] To facilitate quick and easy access to data, an indexed copy of the UTXO set 610 or a subset that houses the relevant latest transactions may be provided to the DBMS 600. This is integrated with an SPV wallet 606c that tracks keys associated with the user (i.e., the client entity that is any node that requests to either register or access the database / DBMS) to record UTXO updates (consumptions). A separate record of the index is stored as the TxID register 608, so that OP_RETURN data can be retrieved for queries.

[0142] The index can be a simple integer count during 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 required when accommodating the associated TTxID or ETxID to rebuild the entire database or data structure. However, in some embodiments, it is also possible to store the TTxID or ETxID and off-chain organize it within the associated database structure to reduce the number of update transactions required. Access attributes can be stored along with the TxID register 608 that can be inspected during the setup / permission verification step executed in the second aspect of the present disclosure by a registration and access management system.

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

[0144] Next, referring to FIG. 7, a simplified exemplary block diagram of a computing device 2600 that may be used to practice 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 illustrated DBMS, 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 of FIG. 6. Thus, the computing device 2600 may be a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 7, the computing device 2600 may include one or more processors (collectively labeled 2602) having one or more levels of cache memory and a memory controller configured to communicate with a memory subsystem 2606 that includes a main memory device 2608 and a persistent memory device 2610. The main memory device 2608 may include, as illustrated, dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620. The memory subsystem 2606 and the cache memory 2602 may be used for storing information such as details related to transactions and blocks as described in the present disclosure. The processors 2602 may be utilized to provide the steps or functionality of any embodiment as described in the present disclosure.

[0145] The processors 2602 may also be able to 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 for 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 an interface to other computing devices and networks. The network interface subsystem 2616 may act as an interface for receiving data from and transmitting data to other systems from the computing device 2600. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a network such that the data technician may transmit data to and receive data from the device even when the data technician is at 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, an integrated mouse, a trackball, a touchpad, or a pointing device such as a graphics tablet, a scanner, a barcode scanner, a touch screen incorporated within a display, an audio input device such as a voice recognition system, a microphone, and other types of input devices. Generally, 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 cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection, or other display device. Generally, 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 such interaction when, for example, user interaction with applications that perform the processes described and their variations is appropriate.

[0150] The memory subsystem 2606 may provide a computer-readable storage medium for storing the basic programming and data configurations that may provide the functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions) may provide the functionality of one or more embodiments of the present disclosure when executed by one or more processors and may be stored within the memory subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The memory subsystem 2606 may additionally provide a repository for storing data used in accordance with the present disclosure. For example, the main memory device 2608 and the cache memory 2602 may provide a volatile storage area for programs and data. The persistent storage device 2610 may provide a persistent (non-volatile) storage area 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 Blue-Ray) drives with associated removable media, and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments as described in the present disclosure, as well as data related to transactions and blocks as described in the present disclosure.

[0151] Computing device 2600 may be of various types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, computing device 2600 may include another device that may be connected to computing device 2600 through one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). A device that may be connected to computing device 2600 may include a plurality of ports configured to receive an optical fiber connector. Thus, this device may be configured to convert an optical signal into an electrical signal that may be transmitted through a port that connects the device to computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of computing device 2600 shown in FIG. 7 is intended only as an example for showing a preferred embodiment of the device. Many other configurations are possible that have more or fewer components than the system shown in FIG. 7.

[0152] Exemplary embodiments to enumerate The present disclosure is described herein based on the following sections related to the above aspects, and the above aspects are provided herein as exemplary embodiments for better explaining, describing, and understanding the claimed aspects and embodiments.

[0153] 1. 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 being implemented by one or more processors associated with a data management system (DBMS) for a distributed ledger, the method comprising: Creating a database transaction type, wherein the database transaction type is An identifier for a database D to be used to obtain data for one or more transactions related to a distributed ledger, and 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 one or more tables related to the identified database D, and the given TTxID is related to a transaction related to a distributed ledger for the given table, the step, and The step of creating a table transaction type, wherein the table transaction type is An identifier for table T, where the table is among one or more tables related to the identified database D, the identifier, and Comprising one or more entries related to the identified table T, the step and Comprising.

[0154] 2. A method as presented in section 1, wherein the table transaction type 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 one or more entries related to the identified table T, and the given ETxID is related to a transaction related to a distributed ledger for the given entry, The method Further comprises creating an entry transaction type, and the entry transaction type Comprises one or more data pairs, each data pair is related to an entry in the identified table T, and each data pair comprises a reference R identifying a position in the identified table and a value VL for the identified position.

[0155] 3. A method as presented in section 1 or 2, wherein the transaction related to one or more TTxIDs or ETxIDs is associated with one or more unspent transaction outputs (UTXOs).

[0156] 4. A method as presented in section 3, wherein the UTXO for a given transaction includes an output script that is consumable by subsequent transactions related to the identified database D and / or table T.

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

[0158] 6. A data structure for storing and / or managing data associated with one or more transactions related 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 the method according to any one of sections 1 to 5.

[0159] 7. A data structure as presented in section 6, the data structure being a nested transaction storage structure, the data structure further comprising entry data types created according to the method of any one of sections 2 to 5, and the data structure being configured to store the identified database D based on storing the TTxID and ETxID related to the identified database D.

[0160] 8. A computer-implemented method for performing one or more transactions associated with a distributed ledger, the transactions using the data structure provided by one of the preceding claims, the method being performed by one or more processors associated with a database management system (DBMS), a step of creating a database, Generating a first transaction to create a first database, the first transaction being based on the database transaction type of the data structure, steps, and Providing an output for the first transaction based on the created first database, the step including Updating the first database in response to a request or transaction related to the first database, Generating a second transaction to create a first table, the second transaction being based on the table transaction type of the data structure, steps, and Providing an output for the second transaction based on the created first table and including the identifier (TTxID) of the second transaction, the step including Generating a third transaction based on the output of the second transaction, Updating the database transaction type of the first database using the identifier (TTxID) associated with the second transaction, and Providing an output for the third transaction based on the updated first database, the step including Comprising.

[0161] 9. A method as presented in section 7, Filling the first table in response to a request or transaction related to the first table, Generating a fourth transaction to create a first entry in the first table, the fourth transaction being based on the entry transaction type of the data structure, steps, and Providing an output for the fourth transaction based on the created entry and including the identifier (ETxID) of the fourth transaction, the step including Generating a fifth transaction based on the output of the fourth transaction, comprising: Updating the table transaction type of the first table using an identifier (ETxID) associated with the fourth transaction, and Providing an output for the fifth transaction, the output being based on the updated first table and an identifier (TTxID) of the fifth transaction; Generating a sixth transaction based on the output of the fifth transaction, comprising: Updating the database transaction type of the first database using an identifier (TTxID) associated with the fifth transaction, and Providing an output for the sixth transaction based on the updated first database; Further comprising.

[0162] 10. A method as presented in section 9, comprising: Modifying the first table in response to a request or transaction related to the first table, comprising: Generating a seventh transaction to modify a reference and / or value of a data pair related to a first entry in the first table; Updating the entry transaction type of the first entry using the modified entry based on the seventh transaction; and Providing an output for the seventh transaction based on the modified entry and including an identifier (ETxID) of the seventh transaction; Generating an eighth transaction based on the output of the seventh transaction, comprising: Updating the table transaction type of the first table using an identifier (ETxID) associated with the seventh transaction; and Providing an output for an eighth transaction based on the updated first table and including an identifier (TTxID) of the eighth transaction; Generating a ninth transaction based on the output of the eighth transaction, Updating a database transaction type of a first database using an identifier (TTxID) associated with the eighth transaction, and Providing an output for a sixth transaction based on the updated first database; comprising.

[0163] 11. A method as presented in either one of Sections 9 or 10, modifying a first table in response to a request or transaction related to the first table, generating a tenth transaction to delete a first entry in the first table, updating a table transaction type of the first table to remove an identifier (ETxID) associated with a fourth transaction, and providing an output for a tenth transaction based on the updated first table and including an identifier (TTxID) of the tenth transaction; generating an eleventh transaction based on the output of the tenth transaction, updating a database transaction type of a first database using an identifier (TTxID) associated with the tenth transaction, and providing an output for the eleventh transaction, the output including an identifier of the updated first database; comprising steps.

[0164] 12. A computer-implemented method for performing one or more transactions associated with a distributed ledger, the transactions using a data structure provided by any one of claims 1 to 7, the method being performed by one or more processors associated with a client entity, sending a request to one or more processors associated with a DBMS to create a first database; monitoring the distributed ledger for at least one transaction output associated with the created first database D; sending a request to one or more processors associated with a DBMS to create a first table for the first database; monitoring the distributed ledger for at least one transaction output associated with the first table (TTxID); sending a request to one or more processors associated with a DBMS to update the first table using a first entry, the first entry including a data pair comprising a reference identifying a position in the first table and a value for the identified position.

[0165] 13. A computer-implemented method for performing one or more transactions associated with a distributed ledger, the transactions using a data structure provided by any one of claims 1 to 7, the method being performed by one or more processors associated with a client entity, monitoring the distributed ledger for at least one transaction output associated with a first entry (ETxID) in a first table of a first database; sending a request to one or more processors associated with a DBMS to modify the first entry, the request including a request to modify a reference and / or a value of a data pair associated with the first entry; monitoring a distributed ledger for at least one transaction output associated with an identifier for an updated first table (TTxID) and / or an updated first database that incorporates a modified first entry comprising.

[0166] 14. A computer-implemented method for performing one or more transactions associated with a distributed ledger, the transactions using a data structure provided by any one of claims 1-7, the method being performed by one or more processors associated with a client entity, monitoring a distributed ledger for at least one transaction output associated with an identifier for a first table of a first database (TTxID); sending a request to one or more processors associated with a DBMS to delete a first entry of the first table; monitoring a distributed ledger for at least one transaction output associated with an identifier for an updated first table (TTxID) and / or an updated first database comprising.

[0167] 15. A computer-implemented method for managing access to a database management system (DBMS), the DBMS managing data related to transactions associated with a distributed ledger, the data being provided in a database, the method comprising: creating a record associated with a given user in response to a request for registration with the DBMS, the record including an identifier for the given user among a plurality of users; obtaining a public key P associated with the given user, the public key being part of a cryptographic key pair associated with the given user, the cryptographic key pair including a secret key V for the given user; Obtaining or assigning one or more attributes associated with a given user, each attribute being associated with settings related to access to a database managed by a DBMS, Updating a record based on the obtained public key P and one or more attributes associated with a given user, Storing or providing the updated record related to the DBMS comprising.

[0168] 16. A method as presented in section 15, wherein the setting for a given attribute checks whether the given attribute is associated with permissions to perform one or more of a read operation, a write operation, a modification operation, or a deletion operation related to the database.

[0169] 17. A method as presented in either section 15 or 16, wherein the setting for each attribute is provided in a request, or the setting is obtained from computing resources related to the DBMS, or the setting is pre-determined for each attribute with respect to the database managed by the DBMS.

[0170] A computer-implemented method for implementing a database management system (DBMS) for managing a database related to transactions associated with a distributed ledger, the method comprising: Obtaining a request for an operation related to the database from a client entity, the client entity being related to a given user among a plurality of users, the request including a digital signature associated with the given user, Determining that the given user is authorized to access the database, Verifying that the digital signature is associated with the given user based on a user record related to the DBMS in response to a successful determination, generating a message based on the current instance of the user record and the request in response to a successful verification; comprising.

[0171] 19. A method as presented in section 18, wherein the request is a request to read, write, modify, or delete data in the database.

[0172] 20. A method as presented in any one of sections 15 - 19, wherein the database is implemented using a data structure as provided by any one of sections 1 - 7.

[0173] 21. A method as presented in any one of sections 16 - 18, wherein the user record is created upon registration of a given user with the DBMS by any one of the methods of sections 15 - 17.

[0174] 22. A method as presented in section 21, wherein the step of determining that the user is authorized includes determining that a user record associated with the DBMS exists for a given user upon registration of the given user with the DBMS.

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

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

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

[0178] 26. A computer-implemented method for registering with a database management system (DBMS), where the DBMS is related to data related to transactions associated with a distributed ledger, the method being implemented by one or more processors related to a client entity, the client entity being related to a given user among a plurality of users, the method comprising: generating a request for registering with the DBMS, the request being related to a given user; providing or accessing one or more attributes associated with the given user, each attribute being associated with settings related to a database managed by the DBMS; generating a private key V related to the given user, the private key being part of a cryptographic key pair including a public key P for the given user; calculating the public key P based on the private key V; sending the public key P and the one or more attributes to the DBMS. and.

[0179] 27. A computer-implemented method for accessing data related to a database management system (DBMS), where the DBMS is related to data related to transactions associated with a distributed ledger, the method being implemented by one or more processors related to a client entity, the client entity being related to a given user among a plurality of users, the method comprising: generating a request related to the database, the request being related to a given user and the database being managed by the DBMS; 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 the given user, and the public key P is provided to a DBMS; Applying the digital signature to a request; Sending the signed request to the DBMS; and comprising;

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

[0181] 29. A method as claimed in section 27 or 28, including a method of registration to a DBMS as presented in section 26.

[0182] 30. A computer-implemented method for implementing a database management system (DBMS) for managing a database related to transactions associated with a distributed ledger, the method comprising: Receiving messages related to the current instance of a user record for a given user among one or more users and requests related to the database, where the requests are provided by the given user; Parsing the requests related to the database, extracting one or more attributes associated with the given user from the current instance, verifying that the settings for each of the extracted attributes are valid for the requests made by the given user; In response to a successful verification, executing one or more operations related to the database based on the requests, where the database is based on a data structure provided according to any one of sections 1 to 6, and the executing step comprises; When the request is related to a read operation, obtaining one or more transaction identifiers (TTxID, ETxID) related to the request, wherein each obtained transaction identifier is related to a transaction, whereby data for said transaction is associated with a data structure, and further comprising accessing data related to the transaction identifier (TTxID, ETxID) obtained from the data structure, When the request is related to a write operation or a modify operation or a delete operation, in addition to the obtaining step, the method generates one or more transactions for consuming or processing the transactions associated with the one or more obtained transaction identifiers (TTxID, ETxID) based on the operation, and further comprising updating the data structure using an identifier related to the generated transaction, and steps comprising.

[0183] 31. A method as presented in section 30, wherein the verifying step includes inspecting that the setting for a given attribute among one or more attributes indicates that a given user has permission for database access for the performed request.

[0184] 32. A method as presented in any one of sections 30 or 31, wherein when the request is related to a write operation, a modify operation, or a delete operation, the performing step further includes a method as presented in any one of sections 7 - 9.

[0185] 33. A method as presented in any one of sections 30 - 32, wherein when the request is related to a write operation, a modify operation, or a delete operation, the generating step includes obtaining an output script related to each obtained transaction identifier (TTxID, ETxID), and To configure additional transactions based on an output script, where the additional 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; To provide the additional transactions to a distributed ledger, where the additional transactions are associated with additional transaction identifiers (TTxID, ETxID); And further comprising.

[0186] 34. A method as presented in section 33, wherein the step of configuring additional transactions is performed by a simple payment verification (SPV) client associated with a DBMS, and the SPV client communicatively couples 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 obtained transaction identifier (TTxID, ETxID) is associated with a transaction containing unspendable UTXOs, and the unspendable UTXOs are associated with or contain a spendable payload, and the spendable payload is a spendable UTXO.

[0188] 36. A method as presented in section 35, wherein each spendable UTXO and unspendable UTXO is stored in a UTXO set or memory associated with the DBMS, and the unspendable UTXO is an OP_RETURN output script.

[0189] 37. A method as presented in section 36, wherein one or more spendable UTXOs in the UTXO set or memory are used to configure additional transactions.

[0190] 38. A computing device, A processor, A memory including executable instructions that cause a device to execute one of the computer-implemented methods of sections 12 - 14 or 26 - 29 as a result of execution by a processor. The computing device is a client entity.

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

[0192] 40. A system, One or more computing devices as presented in section 38, each being a client entity, A DBMS as presented in section 39, A communication network for communicably coupling each client entity to the DBMS and comprising.

[0193] It should be noted that the above embodiments are illustrative of the present disclosure rather than limiting it, and those skilled in the art can design many alternative embodiments without departing from the scope of the present disclosure as defined by the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claims. Words such as "comprising" and "comprises" do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprising" means "including or consisting of", and "comprises" means "including or consisting of". References to the singular form of an element do not exclude references to the plural form of such elements, and vice versa. The present disclosure may be implemented using hardware comprising several different elements and preferably using a computer programmed suitably. In device claims enumerating several means, several of these means may be embodied by one and the same piece of hardware. The mere fact that several measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0194] Exemplary use cases and scenarios Exemplary processing of READ The capabilities of relational databases stem from the ability to aggregate related data across multiple tables. This is typically done using JOIN SQL commands between two tables. There are four subtypes of JOIN. 1. INNER JOIN - Returns values that are common in 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 can be freely selected from both tables. The relevant tables and entry data will be read from the UTXO set from the TxID reference and will be stored in the system memory. Then, the conditions will be applied and matched for analysis and assembly.

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

[0198] The next line sets the join condition (in this case, an inner join) and specifies the right table to which to join.

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

[0200] Since this is executed off-chain in its entirety by the DBMS, equivalent transactions are not required, and the standard SQL protocol can be incorporated. This also enables the system to utilize standard efficiency optimization and scaling methods that have been explored extensively over the past few decades. This approach enables an easy interface with existing enterprise data management solutions (e.g., ORACLE, SAP, etc.).

Explanation of Signs

[0201] 600 Database Management System (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 Device 2602 Processor 2602 Cache Memory 2604 Bus Subsystem 2606 Memory Subsystem 2608 Main Memory Device 2610 Persistent Memory Device 2612 User Interface Input Device 2614 User Interface Output Device 2616 Network Interface Subsystem 2618 Dynamic Random Access Memory (DRAM) 2620 Read-Only Memory (ROM)

Claims

1. 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 being implemented by one or more processors associated with a data management system (DBMS) for the distributed ledger, the step of creating a database transaction type, wherein the database transaction type is an identifier for a database D to be used to obtain data for one or more transactions related to the distributed ledger, and one or more table transaction identifiers (TTxID), wherein a given TTxID among the one or more TTxID is unique to a given table among the 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, the step of the step of creating a table transaction type, wherein the table transaction type is an identifier for a table T, wherein the table is among the one or more tables related to the identified database D, the identifier, and one or more entries related to the identified table T the step of comprising the method of comprising

2. the table transaction type further comprises one or more entry transaction identifiers (ETxID), wherein a given ETxID among the one or more ETxID is unique to a given entry among the one or more entries related to the identified table T, and the given ETxID is related to a transaction related to the distributed ledger for the given entry, the method further comprises the step of creating an entry transaction type, wherein the entry transaction type comprises one or more data pairs, each data pair being related to an entry in the identified table T, each data pair comprising a reference R identifying a position in the identified table and a value VL for the identified position, The method according to claim 1.

3. The method according to claim 1 or 2, wherein the transaction related to the 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 given transaction includes an output script that is consumable by a subsequent transaction related to the identified database D and / or table T.

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

6. A data structure for storing and / or managing data associated with one or more transactions related to a distributed ledger, managed by one or more processors associated by a database management system (DBMS) for the distributed ledger, and including a data transaction type and a table transaction type created according to the method according to any one of claims 1 to 5.

7. An nested transaction storage structure, further comprising an entry data type created according to the method according to any one of claims 2 to 5, and configured to store the identified database D based on storing TTxIDs and ETxIDs related to the identified database D. The data structure according to claim 6.

8. A computer-implemented method for performing one or more transactions associated with a distributed ledger, wherein the transaction uses the data structure provided by any one of claims 1 to 7, and the method is performed by one or more processors associated with a database management system (DBMS), A 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 step, A step of providing an output for the first transaction based on the created first database Including, steps, Updating the first database in response to a request or transaction related to the first database, comprising: Generating a second transaction to create a first table, the second transaction being based on the table transaction type of the data structure; Providing an output for the second transaction based on the created first table and including an identifier (TTxID) of the second transaction; Including steps; Generating a third transaction based on the output of the second transaction, comprising: Updating the database transaction type of the first database using the identifier (TTxID) associated with the second transaction; Providing an output for the third transaction based on the updated first database; Including steps; A computer-implemented method comprising the above steps. **Claim 9** Filling the first table in response to a request or transaction related to the first table, comprising: Generating a fourth transaction to create a first entry in the first table, the fourth transaction being based on the entry transaction type of the data structure; Providing an output for the fourth transaction based on the created entry and including an identifier (ETxID) of the fourth transaction; Including steps; Generating a fifth transaction based on the output of the fourth transaction, comprising: Updating the table transaction type of the first table using the identifier (ETxID) associated with the fourth transaction; Providing an output for the fifth transaction, the output being based on the updated first table and an identifier (TTxID) of the fifth transaction; Including steps; Generating a sixth transaction based on the output of the fifth transaction, comprising: Updating the database transaction type of the first database using the identifier (TTxID) associated with the fifth transaction; Providing an output for the sixth transaction based on the updated first database; Including steps; The method according to claim 7, further comprising.

10. Responding to a request or transaction related to the first table, the step of modifying the first table, Generating a seventh transaction to modify the reference and / or the value of the data pair related to the first entry in the first table; Updating the entry transaction type of the first entry using the modified entry based on the seventh transaction; Providing an output for the seventh transaction based on the modified entry and including the identifier (ETxID) of the seventh transaction; Including steps; Generating an eighth transaction based on the output of the seventh transaction, Updating the table transaction type of the first table using the identifier (ETxID) associated with the seventh transaction; Providing an output for the eighth transaction based on the updated first table and including the identifier (TTxID) of the eighth transaction; Including steps; Generating a ninth transaction based on the output of the eighth transaction, Updating the database transaction type of the first database using the identifier (TTxID) associated with the eighth transaction; Providing an output for the sixth transaction based on the updated first database; Including steps; The method according to claim 9, comprising.

11. Responding to a request or transaction related to the first table, the step of modifying the first table, Generating a tenth transaction to delete the first entry in the first table; Updating the table transaction type of the first table to remove the identifier (ETxID) associated with the fourth transaction; Providing an output for the tenth transaction based on the updated first table and including the identifier (TTxID) of the tenth transaction; Steps including; Generating an eleventh transaction based on the output of the tenth transaction, comprising: Updating the database transaction type of the first database using the identifier (TTxID) associated with the tenth transaction; Providing an output for the eleventh transaction, the output including the identifier of the updated first database; Steps including; The method according to any one of claims 9 or 10, comprising steps.

12. A computer-implemented 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, Sending a request to one or more processors associated with a DBMS to create a first database; Monitoring the distributed ledger for at least one transaction output related to the created first database D; Sending a request to the one or more processors associated with the DBMS to create a first table for the first database; Monitoring the distributed ledger for at least one transaction output related to the first table (TTxID); Sending a request to the one or more processors associated with the DBMS to update the first table using a first entry, the first entry including a data pair comprising a reference identifying a position in the first table and a value for the identified position; A method comprising.

13. A computer-implemented 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, monitoring the distributed ledger by seeking at least one transaction output associated with a first entry (ETxID) in a first table of a first database; sending a request to one or more processors associated with a DBMS to modify the first entry, the request including a request to modify the reference and / or the value of the data pair associated with the first entry; monitoring the distributed ledger by seeking at least one transaction output associated with an identifier for an updated first table (TTxID) and / or an updated first database D incorporating the modified first entry; A method comprising the steps of:

14. A computer-implemented 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, monitoring the distributed ledger by seeking at least one transaction output associated with an identifier (TTxID) for a first table of a first database; sending a request to one or more processors associated with a DBMS to delete the first entry of the first table; monitoring the distributed ledger by seeking at least one transaction output associated with an identifier for an updated first table (TTxID) and / or an updated first database; A computer-implemented method comprising the steps of:

15. A computer-implemented method for managing access to a data management system (DBMS), wherein the DBMS manages data related to transactions associated with a distributed ledger, the data being provided in a database, and the method comprising: In response to a request for registration with the DBMS, creating a record related to a given user, wherein the record includes an identifier for the given user among a plurality of users; Obtaining a public key P related to the given user, wherein the public key is part of a cryptographic key pair related to the given user, and the cryptographic key pair includes a secret key V for the given user; Obtaining or assigning one or more attributes associated with the given user, wherein each attribute is associated with a setting related to access to a database managed by the DBMS; Updating the record based on the obtained public key P and the one or more attributes associated with the given user; Storing or providing the updated record related to the DBMS; A method comprising.

16. The method according to claim 15, wherein the setting for a given attribute checks whether the given attribute is associated with a permission to perform one or more of a read operation, a write operation, a modification operation, or a deletion operation related to the database.

17. The method according to any one of claims 15 or 16, wherein the setting for each attribute is provided in the request, or the setting is obtained from computing resources related to the DBMS, or the setting is pre-determined for each attribute with respect to the database managed by the DBMS.

18. A computer-implemented method for implementing a database management system (DBMS) for managing a database related to a transaction associated with a distributed ledger, Obtaining, from a client entity, a request for an operation related to the database, wherein the client entity is related to a given user among a plurality of users, and the request includes a digital signature associated with the given user; Determining that the given user is authorized to access the database; In response to a successful decision, verifying that the digital signature is associated with the given user based on a user record associated with the DBMS; In response to a successful verification, generating a message based on the current instance of the user record and the request; A computer-implemented method comprising:

19. The method according to claim 18, wherein the request is a request to read, write, modify, or delete data in the database.

20. The method according to any one of claims 15 to 19, wherein the database is implemented using a data structure as provided by any one of claims 1 to 7.

21. The method according to any one of claims 16 to 18, wherein the user record is created at the time of registration of the given user to the DBMS by the method according to any one of claims 15 to 17.

22. The method according to claim 21, wherein the step of determining that the user is authorized includes determining that a user record associated with the DBMS exists for the given user at the time of registration of the given user to the DBMS.

23. The method according to any one of claims 22 or 22, wherein the step of verifying the digital signature is based on determining that the private key V or the signature key K used to sign the request is associated with the public key P associated with the given user in the user record.

24. The method according to any one of claims 18 to 23, further comprising, in response to a failure of the determination, generating an error notification specifying that the given user is not authorized to access the database or is not registered to access the database.

25. The method according to any one of claims 18 to 23, further comprising, in response to a failure of the verification of the digital signature, generating an error notification specifying that the signature applied to the request is not valid for the given user.

26. A computer-implemented method for registration in a database management system (DBMS), wherein the DBMS is related to data related to transactions associated with a distributed ledger, and the method is implemented by one or more processors related to a client entity, the client entity being related to a given user among a plurality of users, the method comprising: generating a request for registration in the DBMS, the request being related to the given user; providing or accessing one or more attributes associated with the given user, each attribute being associated with a setting related to the database managed by the DBMS; generating a private key V for the given user, the private key being part of a cryptographic key pair including a public key P for the given user; calculating the public key P based on the private key V; sending the public key P and the one or more attributes to the DBMS A method comprising: Claim 27 A computer-implemented method for accessing data related to a data management system (DBMS), wherein the DBMS is related to data related to transactions associated with a distributed ledger, and the method is implemented by one or more processors related to a client entity, the client entity being related to a given user among a plurality of users, the method comprising: generating a request related to a database, the request being related to the given user and the database being managed by the DBMS; generating a digital signature based on a private key V for the given user, the private key being part of a cryptographic key pair including a public key P for the given user, and the public key P being provided to the DBMS; applying the digital signature to the request; sending the signed request to the DBMS A method comprising: Claim 28 The method according to claim 27, further comprising generating a signature key K based on the private key V, the signature key being a short-term key. Claim 29 The method according to claim 27 or 28, including the method of registration to the said DBMS according to claim 26.

30. A computer-implemented method for implementing a database management system (DBMS) for managing a database related to transactions associated with a distributed ledger, comprising: Receiving messages related to the current instance of a user record for a given user among one or more users and requests related to the said database, wherein the said request is provided by the said given user; Parsing the syntax of the said request related to the database; Extracting one or more attributes associated with the said given user from the said current instance; Verifying that the said settings for each of the said extracted attributes are valid for the said request made by the said given user; Including steps; In response to a successful verification, performing one or more operations related to the said database based on the said request, wherein the said database is based on a data structure provided according to any one of claims 1 to 6, and the said performing step includes: When the said request is related to a read operation, obtaining one or more transaction identifiers (TTxID, ETxID) related to the said request, wherein each obtained transaction identifier is related to a transaction, whereby the said data for the said transaction is associated with the said data structure; Accessing the said data related to the obtained transaction identifier (TTxID, ETxID) from the said data structure; Further including; When the said request is related to a write operation or a modification operation or a deletion operation, in addition to the said obtaining step, the said method includes generating one or more transactions for consuming or processing the said transaction associated with the obtained one or more transaction identifiers (TTxID, ETxID) based on the said operation; Updating the said data structure using the identifier related to the generated transaction; Further including steps; A computer-implemented method comprising.

31. The step of verifying includes the step of checking that the setting for a given attribute among the one or more attributes indicates that the given user has permission for access to the database for the performed request, the method according to claim 30.

32. The method according to any one of claims 30 or 31, wherein when the request is related to a write operation, a modification operation, or a deletion operation, the step of executing further includes the method according to any one of claims 7 to 9.

33. When the request is related to a write operation, a modification operation, or a deletion operation, the step of generating includes the step of obtaining an output script related to each obtained transaction identifier (TTxID, ETxID); the step of constructing a further transaction based on the output script, wherein the further transaction is based on a private key V related to the given user, and the private key is part of a cryptographic key pair including a public key P for the given user; the step of providing the further transaction to the distributed ledger, wherein the further transaction is associated with a further transaction identifier (TTxID, ETxID) and further includes the method according to any one of claims 30 to 32.

34. The method according to claim 33, wherein the step of constructing the further transaction is executed by a simple payment verification (SPV) client related to the DBMS, and the SPV client communicatively couples the DBMS to the distributed ledger via a communication network.

35. The method according to any one of claims 30 to 34, wherein each obtained transaction identifier (TTxID, ETxID) is associated with a transaction including unspendable UTXOs, and the unspendable UTXOs are associated with a spendable payload or include a spendable payload, and the spendable payload is a spendable UTXO.

36. The method according to claim 35, wherein each spendable UTXO and unspendable UTXO is stored in a UTXO set or memory related to the DBMS, and the unspendable UTXO is an OP_RETURN output script.

37. The method according to claim 36, wherein one or more spendable UTXOs in the UTXO set or memory are used to construct the further transaction.

38. A computing device, a processor, a memory including executable instructions that cause the device to execute the computer-implemented method according to any one of claims 12 to 14 or 26 to 29 as a result of execution by the processor comprising, The computing device, wherein the computing device is a client entity.

39. A DBMS system for managing access to data associated with one or more transactions related to a distributed ledger, wherein the data managed by the DBMS is stored in a data structure such as provided by any one of claims 1 to 7, and the DBMS a registration and access management system having one or more processors configured to execute instructions for executing the computer-implemented method according to any one of claims 15 to 25, a transaction execution system having one or more processors configured to execute instructions for executing the computer-implemented method according to any one of claims 30 to 37, one or more registers for storing a plurality of transaction identifiers related to the database, a UTXO set or memory for storing copies of a plurality of UTXOs related to the database comprising a DBMS system.

40. A system, one or more computing devices according to claim 38, each being a client entity, a DBMS according to claim 39, a communication network for communicably coupling each client entity to the DBMS comprising a system.

Images