Blockchain database management system

Abstract

In one aspect, this disclosure proposes methods, apparatus, and systems for providing new structured data about blockchain transactions to implement a new data structure. The new data structure is provided for implementing a distributed database. In another aspect, a new distributed data management system (DBMS) is provided, which can manage data associated with the new data structure. However, unlike conventional DBMSs for traditional databases, this disclosure provides a blockchain DBMS configured to manage data associated with one or more blockchain transactions stored in the new data structure. In yet another aspect, this disclosure provides a method for generating or providing one or more blockchain transactions to implement one or more standard database commands, the commands receiving access to or manipulation of a database, wherein the data is stored on the new data structure.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to methods and systems implementing databases and / or database management systems for data pertaining to transactions associated with a distributed ledger. The present disclosure is particularly applicable, but not limited to, migrating existing databases to a distributed ledger or applications implemented in association with a distributed ledger, i.e. the corpus of the database is associated with transactions pertaining to the distributed ledger after such migration. BACKGROUND

[0002] In this document, the term“blockchain” encompasses all forms of computer- based electronic, distributed ledgers. These include consensus-based blockchain and transaction-chain technologies, permissioned and un-permissioned ledgers, shared ledgers, public and private blockchains, and variations thereof. The terms“user”,“sender”,“recipient” can refer to computing resources or processor-based resources in this document. The term“digital asset” can refer to any transferable asset, such as a smart contract, a license (i.e. a software license) or a DRM contract for media content, etc. It will be appreciated that the term“digital asset” used throughout this document denotes a commodity that can be associated with a value that can be transferred from one entity to another or provided to another as a payment in a transaction.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer- based decentralised distributed system made up of blocks, which in turn are made up of transactions. Each transaction is a data structure that encodes the transfer of control of a digital asset between 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, so blocks are linked together to create a permanent, unalterable record of all transactions written into it since the creation of the blockchain. Transactions include small programs, called scripts, embedded into their inputs and outputs that specify how and by whom the outputs of the transaction can be accessed. These scripts can be written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be "verified." Network nodes work to ensure that each transaction is valid, while invalid transactions are rejected by the network. Software clients installed on these nodes perform this verification by executing their locking and unlocking scripts on unspent transaction outputs. If the execution of the locking and unlocking scripts evaluates to TRUE, the transaction is valid and is then written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must: i) be verified by the first node that receives the transaction—if the transaction passes verification, this node relays it to other nodes in the network; ii) be added to a newly constructed block; and iii) be mined, i.e., added to the public ledger of past transactions.

[0005] Once stored in the blockchain as an unspent transaction output, a user can transfer control of the associated resources to another address associated with an input in another transaction. This transfer is typically accomplished using a digital wallet. This digital wallet can be: a device; physical media; a program; an application on a computing device such as a desktop, laptop, or mobile device; or a remote hosting service associated with a domain on a network such as the internet. A digital wallet stores public and private keys and can be used to: track ownership of resources, assets, etc., associated with the user; receive or spend digital assets; and transfer licenses, property, or other types of resources.

[0006] While blockchain technology is best known for its applications related to digital assets, digital entrepreneurs have begun exploring how to leverage its underlying cryptographic security systems and other types of data that can be stored on the blockchain to create new systems. Blockchain could be highly advantageous if it could be used for automated tasks and processes not limited to digital assets. Such solutions would be able to capitalize on the advantages of blockchain (e.g., permanent and tamper-proof event logging, distributed processing, etc.) while broadening its applications. Thus, public blockchains act as immutable distributed data storage systems, fully utilizing cryptography and economic incentives for security.

[0007] However, such security elements are not always present in databases, such as distributed databases and / or private and / or enterprise databases. A distributed database is one where data is stored in several different physical locations and computing power is distributed across related nodes. This makes such distributed databases vulnerable to attack. Security features are crucial for many enterprises using distributed databases, and this can be managed by a distributed database management system (DDBMS). A DDBMS is a computer software system that integrates distributed data, allowing it to be managed as if it were stored on a single server or computing resource, and provides a systematic approach to updating and querying data in the distributed database.

[0008] There are many similarities between blockchain and distributed databases, such as preventing single points of failure by distributing information across a network. The advantages of blockchain stem from its underlying data structure, where cryptographic hash functions are used to link data, resulting in an immutable record of all valid actions since its creation. This is a crucial characteristic of transparency and auditability that private or existing databases cannot provide. However, even so, there is no simple technology to migrate current distributed databases and DDBMS systems to a system that is associated with a distributed ledger (i.e., incorporated into a blockchain). Many proposed blockchain solutions designed to manage data do not offer interoperability with current distributed databases, representing a technical barrier that prevents enterprises from turning to more secure blockchain-based implementations for managing and storing data. From a business perspective, such interoperability involves significant investments from enterprises and can make them resistant to change. Summary of the Invention

[0009] This disclosure addresses these technical problems by proposing existing and common database features, such as those already used in existing (distributed) databases, that can be used to implement distributed databases or utilize distributed ledgers (i.e., blockchains). Therefore, this disclosure provides aspects and embodiments for implementing new data structures that are compatible with existing databases and their features, as well as blockchains, thereby ensuring interoperability and scalability, and leveraging the additional security offered by blockchain implementations. This disclosure also provides a blockchain-associated DBMS for managing this new data structure. This disclosure thus enables methods for achieving interoperability with existing non-blockchain databases, which is crucial for the gradual transformation of current (private enterprise or other) database systems into more secure and robust equivalent blockchain systems.

[0010] On one hand, this disclosure proposes methods, apparatus, and systems for providing new structured data storage technologies for blockchain transactions to implement new data structures. These new data structures are provided for implementing distributed databases. On the other hand, a new distributed data management system (DBMS) is provided, which can manage data associated with the new data structures. However, unlike conventional DBMSs for traditional databases, this disclosure provides a blockchain DBMS configured to manage data associated with one or more blockchain transactions.

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

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

[0013] The word “comprising” or variations thereof (such as “including”, “including” or “including”) used throughout this specification shall be understood to mean that the specified element, integer, step or element, integer or group of steps is included, but does not exclude any other element, integer or step or element, integer or group of steps. Attached Figure Description

[0014] Various aspects and embodiments of this disclosure will now be described by way of example only and with reference to the accompanying drawings, wherein:

[0015] Figure 1 It is a flowchart depicting a method for providing a data structure according to a first aspect to store and / or manage data associated with transactions about a distributed ledger, the method being implemented by one or more processors associated with a data management system (DBMS).

[0016] Figure 2 It is a schematic diagram depicting a data structure used for storing and / or relating to transactions in relation to a distributed ledger, according to the first aspect.

[0017] Figures 3a to 3c It is a schematic diagram depicting transactions for managing data using data structures, based on the first aspect.

[0018] Figure 4a This is a flowchart depicting a DBMS identity and access authentication method for processing transactions associated with a distributed ledger, according to a second aspect of this disclosure, implemented by one or more processors associated with the DBMS.

[0019] Figure 4b This is a flowchart depicting a DBMS identity and access authentication method for processing transactions associated with a distributed ledger, according to a second aspect of this disclosure, implemented by one or more processors associated with a client entity.

[0020] Figure 5 This is a flowchart depicting a method for implementing a DBMS for managing data associated with transactions, according to a third aspect of this disclosure, whereby transactions are associated with a distributed ledger, and whereby the method is implemented by one or more processors associated with the DBMS.

[0021] Figure 6 It is a schematic diagram depicting a DBMS used for transactions associated with a distributed ledger according to the second and / or third aspects.

[0022] Figure 7 This is a schematic diagram illustrating a computing environment in which various aspects and embodiments of the present disclosure can be implemented. Detailed Implementation

[0023] According to a first aspect, this disclosure provides a computer-implemented method for providing a data structure to store and / or manage data associated with one or more transactions relating to a distributed ledger. The method is implemented by one or more processors associated with a data management system (DBMS) for a distributed ledger, and includes creating a database transaction type comprising:

[0024] The identifier used for database D, which is used to retrieve data about one or more transactions in the distributed ledger;

[0025] One or more table transaction identifiers (TTxIDs), wherein a given TTxID of the one or more TTxIDs is specific to a given table in one or more tables associated with the identified database D, wherein the given TTxID relates to a transaction on a distributed ledger for the given table.

[0026] The method also includes creating table transaction types, which include:

[0027] The identifier for table T, which is in one or more tables associated with the identified database D; and one or more entries associated with the identified table T.

[0028] There are many similarities between distributed ledgers (i.e., blockchains) and distributed databases, such as the ability to distribute information across a network to prevent single points of failure. The advantages of blockchains stem from their underlying data structure, where each block contains the hash of the previous block, thus linking the blocks together, and where cryptographic hash functions are used to link the data, resulting in an immutable record of all valid actions since its creation. This structure of data in a blockchain is a key feature offering transparency and auditing advantages that existing databases cannot provide. Advantageously, the approach of the first aspect provides a technique for providing a data structure based on data types associated with one or more transactions linked to the distributed ledger, namely database data types and tabular data types, and as described above, identifying transactions representing tables with their associated entries. For ease of reference, the data structure of the first aspect is hereinafter referred to as a (blockchain-based) data structure, such as a data structure that enables common database features to be provided and implemented by constructing and managing data within a blockchain. For example, common database features used in existing databases can be based on the arrangement of data in tables with entries, which can be identified by a row in a given table, and then manipulated by common database commands, such as using Structured Query Language (SQL) commands. By enabling a data structure that allows data associated with one or more blockchain transactions to be stored and manipulated using the same common characteristics, the first aspect of this disclosure makes interoperability between existing databases and / or distributed databases possible, thereby making the conversion or transformation process of using blockchain to replace existing databases easy, scalable, seamless, simple, completely transparent, traceable, and efficient. Therefore, the blockchain data structure proposed in the first aspect can provide a structured storage for the entire database based on a blockchain transaction identifier (TTxID) associated with a given transaction.

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

[0030] In addition to the advantages described above in the first aspect, the above embodiments also define an entry data type for storing transaction identifiers of blockchain transactions associated with entry E, which in turn is associated with table T of a given database D. Therefore, any change to an entry can be made by spending a transaction that is the most recent (identified by the ETxID in the entry data type), where the new transaction contains the updated data. For consistency, each dependent transaction will also have to be updated to reflect the latest transaction identifier TxID (which can refer to the ETxID of the entry transaction or the TTxID of the table transaction). That is, if the value of entry E is updated, the entry transaction identifier ETxID in the table transaction must also be updated, and therefore the table transaction identifier TTXID in the database transaction referring to the updated entry E must also be updated.

[0031] This advantageously provides a nested data structure according to the first aspect, where any change to entry E requires updating the entry data type with the new ETxID, updating the table so that the TTxID associated with entry E includes the new ETxID, and updating the database D with the updated TTxID. This allows for robust, immutable, and fully auditable logging of changes to the database and its current state, since data from the data structure cannot be simply deleted or modified (without modifying the entire transaction chain associated with a given entry E). Furthermore, advantageously, using such a data structure, data can be reconstructed or queried simply by monitoring the transactions associated with the database (identified by the database name D or table T). This is similar to storing a compressed form of the database, rather than a complete record of the database.

[0032] In some embodiments, instead of an entry data type, data references and / or values ​​can be stored immediately in table T, i.e., included in the table transaction type itself. This would mean that the data can be identified based on the table transaction (TTxID) in the database transaction data type. However, for ease of reference and consistency, a nested data structure for storing ETxID and TTxID is mentioned below, but this disclosure is not limited thereto.

[0033] In some embodiments, a transaction associated with one or more TTxIDs or ETxIDs is associated with one or more unspent transaction outputs. In some embodiments, an unspent transaction output for a given transaction includes an output script that is spendable for subsequent transactions associated with the identified database D and / or table T. In some embodiments, an unspent transaction output for a given transaction includes a non-spendable output associated with a spendable output script for the given transaction.

[0034] Advantageously, non-spendable outputs (e.g., OP_RETURN scripts) are included to represent valid transactions associated with the execution of one or more database operations. This allows operable or spendable unspendable transaction outputs associated with OP_RETURN (including the latest updates to database D, table T, or entry E) in the distributed ledger (i.e., blockchain) to be easily and readily identifiable by one or more processors associated with the client entity for user interaction with the database. A further advantage is the provision of transaction identifiers (TTxID or ETxID) for identifying non-spendable outputs used for the latest database operation or update. The client entity can simply query the blockchain or distributed ledger to identify the non-spendable OP_RETURN transaction associated with database D, from which spendable payloads or unspendable transaction outputs can be obtained. Once the recipient's unspendable transaction output is identified, it can be processed by executing a spendable output script.

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

[0036] Some embodiments of this disclosure relate to a method of executing one or more database requests by implementing transactions associated with a distributed ledger, the transactions using a blockchain-based data structure as described above. The method is implemented by one or more processors associated with a database management system (DBMS) and involves generating one or more transactions concerning the distributed ledger to perform one or more of the following operations: creating, updating, or modifying / deleting 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 creation transaction associated with the distributed ledger. In some embodiments, the outputs are spendable and / or non-spendable output scripts as described above. In some embodiments, generating one or more transactions is based on processing or spending a previous transaction associated with a database, table, or entry. The method also includes updating one or more data types described above based on the output of the previous transaction. The sequence of steps for generating transactions, providing outputs, and updating data types to fulfill one or more database requests is explained in detail with respect to the following diagram.

[0037] Related to and compared to the above embodiments, the related embodiments, when implemented by one or more processors associated with a client entity to fulfill one or more requests associated with a database, include the following steps: sending a request associated with one or more of the following: creating, updating, modifying, or deleting a database transaction type, a table transaction type, or an entry transaction type; and monitoring a distributed ledger associated with at least one transaction output that has been generated by the DBMS associated with the corresponding request.

[0038] Advantageously, the above embodiments provide a method for manipulating a data structure of the first aspect using standard or known database commands and functionalities, such as standard Structured Query Language (SQL), which is associated with a distributed ledger and includes transaction identifiers associated with the distributed ledger. Advantageously, by enabling standard SQL commands for use with the data structure implemented in the blockchain, the user or client entity associated with a given user cannot monitor changes before, during, or after migrating an existing database to a blockchain-based database implementation. This seamlessness is crucial for the gradual transition of enterprise systems to a more secure and robust equivalent blockchain system for databases. For ease of adoption and interoperability with current database systems, the above embodiments enable standard SQL commands to be applied to the blockchain-based data structure of the first aspect using one or more consecutive blockchain transactions. Although the selection of SQL commands is discussed herein, a similar approach can be applied to map an entire standard SQL library to the blockchain-based data structure of the first aspect.

[0039] A second aspect of this disclosure relates to a computer-implemented method for managing access to a data management system (DBMS), which manages data about transactions associated with a distributed ledger, provided in a database. In some embodiments, the database is implemented using the data structures explained above. When implemented by one or more processors associated with the database, the method includes the steps of: creating a record associated with a given user in response to a request to register with the DBMS, the record including an identifier of the given user among a plurality of users. The method includes: obtaining a public key P associated with the given user; the public key is part of an encryption key pair associated with the given user, the encryption key pair including a private key V for the given user. The method then includes: obtaining or assigning one or more attributes associated with the given user, wherein each attribute is associated with settings relating 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 permission to perform one or more of read, write / update, modify, or delete operations associated with the database. This may be referred to as permission settings. The method also includes the steps of updating the record based on the obtained public key P and the one or more attributes associated with the given user; and storing or providing the updated record associated with the DBMS.

[0040] Therefore, the second aspect of this disclosure relates to a management system for facilitating requests related to the blockchain-based data structure of the first aspect. For example, a data management system (DBMS) may be needed to facilitate access to data within the data structure, construct and / or submit transactions to the distributed ledger of the data structure, and maintain a record of the associated transaction IDs (TxIDs, which may be TTxIDs or ETxIDs). This data management is similar to a standard database management system (DBMS) or a distributed DBMS (DDMS) of a conventional distributed database used to integrate distributed data systems, and may be a third-party service implemented by a remote server or one or more distributed processors implementing single-server functionality, or even a client-side implementation, i.e., a computing entity of a client entity or organization with sufficient resources to manage its own DBMS.

[0041] Advantageously, the method for managing access to the data management system of the second aspect protects the integrity of the database of the blockchain implementation of the first aspect and provides security by acting as an authentication resource. The second aspect provides multi-level permission control based on attributes associated with each user registered with the DBMS, such as read-only, write-only (updating, modifying, or deleting data), or read and write privileges. The use of cryptographic keys associated with the client entity of a given user in the created user record enhances the security of the DBMS, which can be implemented off-chain as described above. Although this is described herein as an off-chain implementation, i.e., not implemented on a distributed ledger or using the distributed ledger itself, this disclosure also relates to on-chain implementations using known methods, including: a credential authority of a public key infrastructure (PKI), a session key derived from an initial shared key, or a standard username / password authentication system encrypted in transactions. In some embodiments, the method of the second aspect can be implemented by a system administrator component or resource responsible for DBMS registration and key distribution, as well as access attribute records that can be used to write to or read from the database. In some embodiments, user records may be stored off-chain as objects as local files (e.g., when manipulated using an object-oriented programming language) or encrypted on the blockchain using references to TTxID or ETxID.

[0042] In some embodiments, an attribute can refer to a team or category associated with a user. For example, in an organizational structure, an attribute could be the name of a department. Therefore, a user with the department attribute "Human Resources" (HR) in their registered user record might have valid permission settings (permission settings or access attribute settings) to access databases or forms related to "Personnel Management," but not valid settings to access databases or forms associated with the accounting department. Different users might also have different settings for their attribute subcategories. For example, a user record with the identity of HR Director in the HR department might have full access to the HR database (read and write), but only "read" access to some accounting databases, such as payroll. Another user in the same HR department with the identity of HR Assistant might not have any valid permission settings for the payroll database and might only have read access to the HR database.

[0043] In some embodiments, the setting of 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 a computing resource associated with the DBMS, or for a database managed by the DBMS, the setting of each attribute may be predetermined by a system administrator or an equivalent computing resource.

[0044] In some embodiments related to the second aspect, this disclosure also provides a computer-implemented method for implementing a DBMS to access a database, the method including the step of obtaining a request for an operation associated with the database from a client entity associated with a given user among a plurality of users, wherein the request includes 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 explained in the first aspect and embodiments 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 whether the digital signature is associated with the given user based on a user record associated with the DBMS. In some embodiments, as described above, the user record is created upon DBMS registration. In response to a successful verification, the method includes generating a message based on the current instance of the user record and the request.

[0045] Advantageously, once a user registers based on information in a user record created during registration as described above, the second aspect of this disclosure provides a method for implementing a DBMS to process user requests associated with the blockchain data structure of the first aspect, thereby providing a single point of reference for distributed data and verifying that a given user has permission to execute the request, i.e., a valid setup.

[0046] In some embodiments, the step of determining that a user is authorized includes determining that a user record associated with the DBMS exists for the given user when registering with the DBMS. In some embodiments, the step of verifying a digital signature is based on determining that the private key V or signing 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 improves the security of the DBMS when requesting database access because two checks are performed before a given user or a client entity associated with the given user can have any access to data in the database. First, if the request comes from an unregistered user, it is immediately rejected because there is no relevant user record to verify the permission of the requesting user to access the database. Second, by verifying whether the digital signature in the request is actually associated with the public key P linked to the user record, the identity of the requesting user can be checked by using this public key P to verify the signature. If a malicious user sends the request, the public key P stored with the user record will be unable to verify the digital signature (this instead relies on the private key V of the same user).

[0047] In some embodiments, in response to unsuccessful authorization, the method includes generating an error notification indicating that the given user is not authorized or registered to access the database. Furthermore, in response to unsuccessful digital signature verification, the method includes generating an error notification indicating that the signature applied to the request is invalid for the given user.

[0048] When implemented by one or more processors associated with a client entity, a second aspect of this disclosure also provides a method for registration in a DBMS, comprising the steps of: generating a DBMS registration request associated with 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. The method further includes generating a private key V associated with the given user, which is part of an encryption key pair including 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 methods, i.e., it may be based on a secret seed or a random number generator as a starting point, or it may be based on a network identifier of the client entity associated with the given user. The key V is kept secret but used to generate the public key P, such that any message encrypted or signed using the private key V can only be verified, read, or decrypted using the public key P. The method further includes sending the public key P and one or more attributes to the DBMS. Advantageously, this improves the security of the DBMS and enhances the privacy of all requests for performing one or more operations associated with a database implemented with a blockchain.

[0049] A second aspect of this disclosure also includes a method for accessing data associated with a database when implemented by one or more processors associated with a client entity. In this case, the method includes the step of generating the aforementioned request associated with a database operation, the request being associated with 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 the given user, the private key being a portion of an encryption key pair including a public key P for the given user, wherein 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, as described above, the method includes a method of registering with the DBMS.

[0050] In some embodiments, the method includes generating a signing key K based on a private key V, wherein the signing key is a temporary key. In some embodiments, the encryption key (i.e., the public key and / or private key and / or session key for a given client entity) is a stable Elliptic Curve Digital Signature Algorithm (ECDSA) key. For example, the ECDSA public key would be a compressed and hexadecimal-encoded valid point on the secp256k1 curve. In some embodiments, a secure hash of a secret seed or generator G associated with the client entity can be used to generate the private key V. G is typically a known constant, which in some embodiments may be known for one or more blockchain transactions or shared by 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 the public (address) address of the client entity and may include a secure hash value, i.e., based on a secure hash algorithm (SHA).

[0051] The digital signature associated with a given user's private key V also advantageously provides an auditable record of request submissions that can be verified through the user's records, where the given user does not need to interact directly with the blockchain. In some embodiments, a system administrator (i.e., the computational resources providing this functionality for the DBMS) can batch requests into a single blockchain transaction. By including the signed request in OP_RETURN, a clear audit trail is still provided, thereby increasing transparency and trustworthiness, while providing interoperability with regular systems, and simultaneously maintaining an immutable record on the blockchain. In some embodiments, the OP_RETURN payload can be encrypted using a deterministic derived key before constructing the transaction (if the request is a write request). In some embodiments, attributes and hashes of data references or references can also be appended, if necessary, to facilitate retrieval.

[0052] In a third aspect, this disclosure relates to a computer implementation method for a database management system (DBMS) for managing a database of transactions associated with a distributed ledger, the method comprising the steps of: receiving a message associated with a current instance of a user record of a given user among one or more users, and a request associated with the database, the request being provided by the given user. The method includes the step of parsing the request associated with the database, which includes the steps of: retrieving one or more attributes associated with the given user from the current instance, and verifying that settings for each of the retrieved attributes are valid for the request of the given user. In some embodiments, the verification includes checking that settings of a given attribute among the one or more attributes indicate that the given user has permission to access the database for the resulting request. In response to successful verification, the method includes performing one or more operations associated with the database based on the request, wherein the database is based on a data structure as provided in the first aspect. The execution steps further include: if the request is associated with a read operation, obtaining one or more transaction identifiers (TTxID, ETxID) associated with the request, each obtained transaction identifier being associated with a transaction, whereby data of the transaction is associated with the data structure, and accessing data associated with the obtained transaction identifiers (TTxID, ETxID) from the data structure. If the request is associated with a write, modify, or delete operation, the method further includes, in addition to the retrieval step, generating one or more transactions based on the operation to spend or process transactions associated with one or more retrieval transaction identifiers (TTxID, ETxID), and updating the data structure with the identifiers associated with generating the transactions.

[0053] In addition to the advantages described above for improving security, reliability, and privacy when registering and / or accessing data in the blockchain-based data structure of the first aspect, the method according to the third aspect advantageously provides a method for interpreting and processing standard database commands associated with the database, i.e., the blockchain-based data structure. Therefore, advantageously, the method according to the third aspect acts as an SQL compiler, but for the blockchain, i.e., using the TTxID or ETxID associated with the blockchain to implement the function of interpreting, validating, and executing one or more SQL commands. Furthermore, the method of the third aspect also performs attribute validation in user records. Therefore, assuming a user record for a given user exists, it is checked whether the user's attribute settings are valid for the request. In some embodiments, such validation is based on the methods and embodiments discussed with respect to the second aspect. For example, in the example of an organization where the attribute is a department or team, if a registered user with the HR Assistant attribute submits a write request to the HR or payroll database, the request will be rejected. However, if a registered user with the HR Director attribute submits a read request to the payroll database, the request is allowed to proceed. If the appropriate settings (i.e., access permissions associated with one or more attributes) are valid, the request is executed by: obtaining the relevant transaction identifier, generating one or more blockchain transactions (based on the output of the previous transaction spent by an authorized or registered user with the necessary permissions), and providing an output script with a transaction identifier TxID (which can be a new TTxID or ETxID) for the generated transactions, so that the database data type, table transaction type, or entry transaction type can be updated with the new TxID.

[0054] If the request is associated with a read function (i.e., data access, not manipulation), in some embodiments this can be performed off-chain by DDMS because the required transaction is not generated and standard SQL protocols are available for data access (after registration and / or access verification in the second aspect). This also advantageously allows the system to fully leverage standard efficiency optimization and scaling methods for easy interfacing with existing enterprise data management solutions.

[0055] In some embodiments, if the request is associated with a write, modify, or delete operation, the execution step further includes a method for implementing one or more transactions as described above regarding the first aspect, relative to executing standard database SQL commands. In related embodiments, the generation step further includes obtaining an output script associated with the obtained transaction identifiers (TTxID, ETxID), and constructing a further transaction based on the output script. This further transaction may be based on or signed using a private key V associated with a client entity of a given user, the private key being part of an encryption key pair including a public key P for the given user. The method then includes providing the further transaction to a distributed ledger, the further transaction being associated with the new transaction identifiers (TTxID, ETxID).

[0056] Advantageously, only users with the required attribute permission settings and those who can be verified using the public key P in the corresponding user record can generate further transactions. Therefore, previous transactions referenced by the latest data type identified in the blockchain implementation's database can only be spent or accessed by registered and verified users, enabling the recording or linking of their identities using keys P and V at each stage. This ensures the existence of user records associated with the latest transactions (even if encrypted), where these public encryption keys are used.

[0057] In embodiments where a request is associated with a write, modify, or delete operation, the step of constructing a further transaction is performed by a Simple Payment Verification (SPV) client associated with the DBMS, wherein the SPV client communicatively couples the DBMS to the distributed ledger via a communication network.

[0058] An SPV client is a computational resource associated with a DBMS that ensures that the DBMSs of the second and third parties are connected to the blockchain (distributed ledger) through peer-to-peer connections with full nodes. However, SPVs do not mine or store copies of the blockchain, and therefore such transactions can be verified and executed efficiently with lower complexity.

[0059] In embodiments, where requests are associated with write, modify, or delete operations, each acquired transaction identifier (TTxID, ETxID) is associated with a transaction that includes a non-spendable unspendable transaction output, which is associated with or includes a spendable payload that is a spendable unspendable transaction output. In some embodiments, each spendable and non-spendable unspendable transaction output is stored in a set or memory of unspendable transaction outputs associated with a DBMS, wherein the non-spendable unspendable transaction outputs are OP_RETURN output scripts, and one or more spendable unspendable transaction outputs in the set or memory are used to construct further transactions.

[0060] Advantageously, to facilitate rapid and simple access to data, an indexed copy of the unspent transaction output set or a subset containing the latest relevant transactions of the database can be provided in association with the DBMS of the third party. In some embodiments, this unspent transaction output set can be integrated with an SPV wallet or node that tracks the cryptographic keys of registered users associated with the DBMS to record updates (spending) of unspent transaction output transactions. In some embodiments, a separate record of the index is additionally or alternatively stored as a register of all transaction identifiers (TxIDs, including TTxID and ETxID in the data types of the data structure of the first party). Advantageously, this makes OP_RETURN data easier to retrieve for querying. In some embodiments, the index associated with these registers is simply a run-in integer count or more detailed data such as names, function output values, or hash values.

[0061] Embodiments of this disclosure include a computing device comprising a processor and a memory including executable instructions that, when executed by the processor, cause the device to perform a computer-implemented method of the embodiments of the first and second aspects described above, intended to be implemented by a client entity.

[0062] Embodiments of this disclosure include a DBMS system for managing access to data associated with one or more transactions relating to a distributed ledger, wherein the data managed by the DBMS is stored in a data structure provided by a blockchain-based data structure as described in the first aspect. The DBMS includes a registration and access management system having one or more processors configured to execute instructions to perform the methods described in the second aspect as described above; and a transaction execution system having one or more processors configured to execute instructions to perform the methods described in the third aspect as described above. The DBMS also includes one or more registers for storing a plurality of transaction identifiers associated with the database; and a set or memory of unspent transaction outputs for storing copies of the plurality of unspent transaction outputs associated with the database.

[0063] Embodiments of this disclosure include a system comprising one or more computing devices, each being a client entity as described above; a DBMS as described above; and a communication network for communicatively coupling each client entity to the DBMS.

[0064] In some embodiments, a computer-readable storage medium is provided having executable instructions stored thereon, which, when executed by a processor of a computer system, cause the computer system to perform the methods described above and / or the embodiments.

[0065] Some specific embodiments will now be described illustratively with reference to the accompanying drawings, wherein similar reference numerals denote similar features.

[0066] First aspect - data structure for blockchain implementation

[0067] Figure 1 This is a flowchart depicting a method for providing a blockchain-based data structure. In other words, the diagram depicts a method, according to the first aspect, for providing a data structure associated with one or more transactions linked to a distributed ledger (i.e., a blockchain). Figure 1 In the illustrated embodiments, a nested data structure is provided according to the first aspect, which includes a database transaction data type, a table transaction data type, and an entry data type. However, it should be understood that the entry transaction identifier (ETxID) and the entry data transaction type are not required for all embodiments of the first aspect, as in some embodiments, end data or values ​​and / or references may be provided within the table transaction data type itself. However, for ease of understanding and consistency, nested data types will be discussed below throughout the specification and drawings.

[0068] To facilitate database functionality, the stored data must have a consistent structure to provide the expected management and access offered by conventional databases. The most well-known example in conventional databases is Structured Query Language (SQL), which uses a standard library of functions to record, update, and query data in relational databases. To enable SQL integration for blockchain data, this disclosure proposes a similar structure for data contained in blockchain transactions, and Figure 1 This paper describes a method for providing or implementing such data structures, also referred to herein as a blockchain database or a data structure implemented in a blockchain. Figure 1 The steps are implemented by one or more processors associated with the database management system for creating and / or managing data structures associated with the blockchain.

[0069] Step 102 describes the creation of a database transaction type, which includes an identifier for a database. This can be the name of the database, i.e., D or First Database, used to store or retrieve data about one or more transactions in the distributed ledger. The database D indicated in the database transaction type includes one or more tables associated with database D. The created data transaction type is configured to store identifiers for transactions (TTxIDs) associated with one or more tables.

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

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

[0072] Step 108 describes the step of providing one or more data pairs in the entry transaction type of step 106. Each data pair relates to an entry E in an identified table T, and each data pair includes: a reference code R for 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 the position indicated in table T, such as row 1 or row 9, etc. The remaining elements in each row may then include the value for the specified row, i.e., VL.

[0073] Step 110 describes the step of providing one or more entry transaction identifiers (ETxIDs) in the table transaction type of step 104. A given ETxID is specific to a given entry in one or more entries associated with table T. The given ETxID relates to a transaction in the distributed ledger for a given entry E in the given table T of step 104, which in step 102 is then located in database D. In other words, the ETxID is called an entry transaction identifier because it relates to data associated with a given entry E in table T.

[0074] Step 112 describes the step of providing one or more table transaction identifiers (TTxIDs) in the database transaction type of step 102. A given TTxID, among one or more TTxIDs, is specific to a given table in one or more tables associated with database D in step 102. This given TTxID relates to a transaction in the distributed ledger concerning a given table T, and in other words, is called a table transaction identifier because it relates to data associated with the table in database D.

[0075] Figure 2 As can be seen in the first aspect, based on the nested blockchain data structure, the transaction data types associated with the blockchain and their interrelationships are illustrated. The database transaction data type contains the database (D) name that can be used to search or query the data structure. It also contains the TTxIDs of all the constituent tables. For each table, T1, T2, T3, etc., the TTxID is stored herein. The table transaction data type begins with the table name (T1, T2, T3) and is filled with the ETxIDs for each table's reference entry data E1, E2, E3, etc. The figure illustrates this for T3. The entry transaction data type includes a reference code and an associated data value, each value representing a row in table T1, T2, or T3. The reference code and value pair for entry E3 in table T3 is shown in... Figure 2 As shown in the image.

[0076] First aspect - SQL commands for blockchain data structure

[0077] Structured Query Language (often abbreviated as SQL) is a general-purpose programming language that allows users to efficiently manage and query relational databases—databases where data elements have structured relationships. The code is passed to a Database Management System (DBMS), which compiles and processes requests locally or remotely in the case of a distributed database. Generally, there are four main categories of SQL code.

[0078] 1. Data retrieval using the SELECT function and conditional statements (FROM, WHERE).

[0079] 2. Data manipulation using INSERT, DELETE, and UPDATE.

[0080] 3. Use CREATE to define data.

[0081] 4. Control over permitted data access, such as GRANT or REVOKE.

[0082] Having structured data, such as data found in SQL relational databases, makes data retrieval efficient. Developers have invested heavily in optimizing the process of querying data based on its underlying structure. Most commercial database systems have dedicated query optimizers and query execution engines. The execution engine determines the operations to be applied to the data (such as sorting, scanning, and merging). The query optimizer then creates an execution plan (logical flow) to execute the search most efficiently based on the data structure and computational cost. Finally, the query is executed by the query execution engine according to the plan.

[0083] Given that SQL, its functions, and commands are commonly used in existing databases, including distributed databases, embodiments of this disclosure provide methods for executing standard SQL commands to perform operations against... Figure 2 The blockchain implementation shown performs one or more standard database operations. For ease of adoption and interoperability with current database systems, Figures 3a to 3c This describes how standard SQL commands can be applied to a blockchain database using one or more consecutive transactions associated with the blockchain. Figures 3a to 3b The text illustrates the select or write (WRITE) SQL commands (update / insert, modify, or delete), but similar methods can be applied to map the entire SQL database.

[0084] Figure 3a This describes the SQL database commands used by the administrator. Figure 2This diagram illustrates the execution of one or more processors associated with the DBMS, representing the data structure shown. In some embodiments, one or more processors associated with or communicatively coupled to the DBMS and the SQL server may also be used to implement one or more of the following commands:

[0085] The `CREATE DATABASE` command can be used to create a database, which includes the following steps:

[0086] TxID1 — Generates the first transaction to create the first database. This first transaction is a database transaction type based on the data structure and provides output for the first transaction based on the created first database (database_name).

[0087] Then, in response to a request or transaction associated with the first database, the following SQL commands are executed through the following transactions.

[0088] Creating a table involves the following steps:

[0089] TxID2 — Generates a second transaction to create a first table, which is a table transaction type based on a data structure; the output for the second transaction is provided based on the created first table, and includes the identifier (TTxID) of the second transaction.

[0090] TxID3 – Generating a third transaction based on the output of a second transaction, which includes the following steps: updating the database transaction type of the first database with an identifier (TTxID) associated with the second transaction, and providing the output for the third transaction based on the updated first database.

[0091] Then, in response to the request or transaction associated with the first table, the following SQL commands are executed based on the following transactions:

[0092] Inserting a table (INSERT INTO TABLE) involves the following steps:

[0093] TxID4 — Generates a fourth transaction to create a first entry in the first table. This fourth transaction is based on the entry transaction type of the data structure and provides output for the fourth transaction based on the created entry, including the identifier (ETxID) of the fourth transaction.

[0094] TxID5 – Generates a fifth transaction based on the output of the fourth transaction, and includes the following steps:

[0095] Update the table transaction type of the first table with the identifier (ETxID) associated with the fourth transaction, and provide output for the fifth transaction based on the updated identifier (TTxID) of the first table and the fifth transaction.

[0096] TxID6 – Generates the sixth transaction based on the output of the fifth transaction, and includes the following steps:

[0097] Update the database transaction type of the first database with the identifier (TTxID) associated with the fifth transaction, and provide output for the sixth transaction based on the updated first database.

[0098] Figure 3b This describes the following SQL update (UPDATE) database command used by database creators and / or administrators. Figure 2 This diagram illustrates the execution of one or more processors associated with the DBMS that display the data structure.

[0099] In response to a request or transaction associated with the first form, the first form is modified using an update / modify command implemented using blockchain transactions, which includes the following steps:

[0100] TxID7—Generates a seventh transaction to modify the reference and / or value of the data pair associated with the first entry in the first table. Then, based on the seventh transaction, the entry transaction type of the first entry is updated with the modified entry.

[0101] The modified entry provides the output for the seventh transaction, including the identifier (ETxID) of the seventh transaction.

[0102] TxID8 – Generates the eighth transaction based on the output of the seventh transaction, and includes the following steps:

[0103] Update the table transaction type of the first table with the identifier (ETxID) associated with the seventh transaction, and provide output for the eighth transaction based on the updated first table, including the identifier (TTxID) of the eighth transaction.

[0104] TxID9 – Generates the ninth transaction based on the output of the eighth transaction, and includes the following steps:

[0105] Update the database transaction type of the first database with the identifier (TTxID) associated with the eighth transaction, and provide output for the sixth transaction based on the updated first database.

[0106] Figure 3c This describes the SQL DELETE database command used by database creators and / or administrators. Figure 2 This diagram illustrates the execution of one or more processors associated with the DBMS that display the data structure.

[0107] In response to a request or transaction associated with the first table, the first table is modified using the DELETEFROM command implemented using blockchain transactions, which includes the following steps:

[0108] TxID10 — Generates the tenth transaction to delete the first entry in the first table, which includes the following steps:

[0109] Update the table transaction type of the first table with the identifier (ETxID) associated with the fourth transaction, and provide output for the tenth transaction based on the updated first table, including the identifier (TTxID) of the tenth transaction.

[0110] TxID11 – Generates the eleventh transaction based on the output of the tenth transaction, which includes the following steps:

[0111] Update the database transaction type of the first database with the identifier (TTxID) associated with the tenth transaction, and provide output for the eleventh transaction, which includes the updated identifier of the first database.

[0112] The examples above illustrate how some SQL commands can be executed using the blockchain-based data structures described in the first aspect. Some modifications from the transaction process described above are also within the scope of this disclosure, as detailed below.

[0113] For many enterprise applications and existing databases, data is constantly being added, deleted, and changed. In these high-volume scenarios, submitting separate requests or database commands for each request may be impractical and economically inefficient, as each request requires a separate blockchain transaction.

[0114] Therefore, in some embodiments of this disclosure, requests can be advantageously batched to allow for more efficient resource management at the entry and table levels. For inserting multiple entries (rows) into a single table, data in the blockchain data structure can be indexed and juxtaposed in a single transaction. To update entry information, a non-spendable transaction (i.e., an OP_RETURN transaction) can be copied to the relevant spending transaction by only changing the relevant entry. For related tables sharing common entries, in some embodiments, they can be included in the same transaction to limit the number of update transactions required when data changes.

[0115] Generally, SQL servers can contain a record of all requests to the database (for transactions related to the proposed blockchain-based data structure) in a file called the transaction log. This typically acts 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 high-volume systems, this file can reach trillions of bytes in size, making storage difficult and expensive. To address this issue, some embodiments of this disclosure provide a database implemented using a distributed ledger (i.e., Figure 2 A similar log system (based on a blockchain data structure) is shown, where a series of transactions are used. A series of request transactions can be stored in a single transaction using only the transaction identifier (TxID) of the latest transaction as a reference. This advantageously and significantly reduces the size of the backup log. Furthermore, advantageously, storing such a backup log of a series of transactions on the blockchain means that an entity or company will not have to store backups itself, but will only keep a record of the latest transaction. Advantageously, this log can also be used for auditing or regulatory requirements because it provides a permanent and immutable record of all updates to the database.

[0116] Second aspect - registration and access management for DBMS associated with data about blockchain transactions

[0117] A Data Management System (DBMS) is used to facilitate SQL requests and the construction of data associated with one or more databases. For blockchain-based databases, this is crucial for constructing and submitting transactions (see...). Figures 3a to 3c And it is especially important to keep records of the relevant transaction IDs (TxIDs) (see...). Figure 1 and Figure 2 The data structure discussed in the text is similar to a Distributed Database Management System (DDMS) for blockchain-based data structures, used to integrate distributed databases. This DBMS can represent itself in several ways: as one or more computing resources for remote third-party services, or as a client application that can be built to represent client entities that have or are associated with computing resources or processing / network capabilities and manage the availability of their own DBMS.

[0118] In a second aspect of this disclosure, identity and access verification technologies for client entities wishing to access data managed by a DBMS and associated with one or more blockchain transactions are discussed. In some embodiments, the methods associated with the second aspect are implemented by one or more processors associated with the DBMS. In some embodiments, the methods of the second aspect are implemented by a registration and access management system that is part of or associated with the DBMS to protect the integrity of the database and provide sufficient security. The database managed by the DBMS in the second aspect is a blockchain-based data structure of the first aspect. Advantageously, the methods associated with the second aspect allow for multi-level access or permission control for client entities wishing to perform database operations, such as read-only, write-only, or read and write permissions.

[0119] Figure 4a This is a flowchart depicting a method associated with an off-chain attribute-based access technique, which can be used to verify database access via a DBMS and is advantageously applicable to any type of data or organization. Access to the database or its components is restricted unless the user sending the request has one or more attributes associated with settings that allow the requested operation. Figure 4a This involves methods implemented by one or more processors associated with the DBMS.

[0120] In step 402a, a DBMS registration request is received by one or more processors associated with the DBMS. In some embodiments, the registration request is received from one or more processors associated with a client entity of a given user who wishes to use, view, or manipulate a blockchain-implemented database (such as...). Figure 2 The data in the data structure.

[0121] Step 404a describes the steps for creating a record associated with a given user. The record may be stored in one or more storage devices or modules associated with the DBMS, or it may be stored on a remote server or storage structure for retrieval when needed. The record includes an identifier for the given user among multiple users. This may be the user name and other details that can be used to identify the user.

[0122] In step 406a, the public key P associated with the given user is obtained from the client entity. The public key is part of an encryption key pair associated with the given user, which also includes a private key V for the given user. The public key and / or private key of the given user can be generated using known methods as explained above regarding the second aspect, such as based on random numbers or a secret seed.

[0123] Step 408a describes obtaining or assigning one or more attributes associated with a given user, where each attribute is associated with settings related to access to a database managed by the DBMS. For example, the settings could be permission settings for an attribute, such as the name of a team or department, like HR or an account as described above. In some examples, the settings could be a flag or binary toggle (0 or 1) or state indicating whether a given user with that particular attribute is allowed read / write permissions to a database component. Attribute settings are obtained from a client entity, or in some embodiments, the DBMS pre-assigns attributes based on the identity of a given user. The settings can be obtained in association with attributes from a client entity, or they can be pre-assigned for certain attributes received by the DBMS's system administrator module.

[0124] Step 410a describes updating the record based on the obtained public key P and one or more attributes and permission settings (if received) associated with a given user. In some embodiments, as explained in the following steps, the user record is stored in or associated with the DBMS in the form of one or more storage areas and can be accessed later. Such storage may also be performed at a remote computing resource.

[0125] Step 412a describes a request to obtain an operation associated with the database from a client entity associated with a given user among a plurality of users. The request includes a digital signature associated with the given user who sent the request in this step.

[0126] 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 for the given user exists. In other words, as explained in steps 402a to 410a above, it is checked whether the user who made the request in the previous step is actually registered in the database.

[0127] If the user is not registered, or if no user record is found, then in step 416a, the request received in step 412a is rejected or not accepted. In some embodiments, a corresponding error notification may be generated.

[0128] If a user record is found, authorization is granted to the given user who made the request in step 412a. The method then proceeds to step 418a, where the digital signature is verified to be correctly associated with the given user who sent the request. This is accomplished by ensuring that the request can be verified or decrypted using the public key P present in the given user's record. Verification or decryption can only be successfully performed using the paired public key P if the digital signature is based on the private key V. This ensures that the request actually originates from the given user identified in the user request, and not from a malicious party impersonating the given user.

[0129] If the digital signature cannot be verified using the public key P in the record, the request in step 412a is rejected in step 410a. In some embodiments, an error message may be generated to convey this rejection.

[0130] In response to successful verification of the digital signature, in step 422a, the DBMS generates a message based on the current instance and the request from the user record. This message is generated in a machine-readable format that can be parsed by one or more DBMS components (as explained below regarding the third aspect). In some embodiments, the message includes detailed information reflecting attributes, settings (if received), and instructions for the database operation requested by the user.

[0131] Involving the second aspect Figure 4b Related to the above Figure 4a The methods explained herein are complementary, but are implemented by one or more processors of a client entity associated with a given user who makes registration and / or operation requests associated with the database, such as... Figure 2 The data structure for a blockchain implementation is shown below.

[0132] Step 402b describes the request to generate DBMS registration, which is associated with a given user and the client entity that sent the request.

[0133] Step 404b describes providing or accessing one or more attributes associated with a given user, each attribute being associated with settings related to a database managed by the DBMS. If the attribute is available at the client entity, this will be included as part of the registration request. If it is not available, these attributes (and settings, if available) are obtained from a different system or storage used for the given user.

[0134] Step 406b describes generating a private key V associated with a given user; the private key is part of an encrypted key pair that includes the public key P for the given user. This private key is not shared with any other entity or DBMS. It can be generated in any known manner, such as using a public secret or a generator, and such generation methods are beyond the scope of this disclosure. In some embodiments, the public and private keys may be temporary keys generated periodically or at arbitrary intervals to improve system security.

[0135] Step 408b describes the calculation of the public key P based on the private key V. This key is associated with the private key V because without the public key P of the cryptographic key pair, it is impossible to verify any message signed by the private key V, and vice versa.

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

[0137] Step 412b describes generating a request for an operation associated with the database, which is associated with a given user. For ease of reference, this is considered in this figure to be the same user who sent the registration request in step 402b. In other embodiments, this step and the following steps may be performed by different client entities for different users who are also registered with the DBMS.

[0138] Step 414b describes generating a digital signature based on a private key V for a given user, which is part of an encryption key pair including a public key P for the given user, wherein the public key P is provided to the DBMS during the registration process as discussed in steps 402b to 410b.

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

[0140] Third aspect - command interpretation and transaction construction for DBMS associated with data about blockchain transactions Figure 2

[0141] As described in the second aspect, the data management system facilitates SQL requests and processes databases (such as...). Figure 5 This disclosure relates to a method for interpreting and processing database requests to perform operations related to a database blockchain. In some embodiments, the method of the third aspect effectively acts as an SQL compiler when implemented by one or more processors of the DBMS, and performs attribute verification (after authorization and authentication in the second aspect).

[0142] Figure 2 It is a flowchart depicting and explaining the methods associated with processing one or more SQL commands or requests for database operations, where the database is... Figure 4a The data structure shown is a blockchain implementation.

[0143] Step 502 describes receiving a message associated with the current instance of a user record for a given user among one or more users, the message also including a request associated with a database. In some embodiments, the message is as follows: Figures 3a to 3b As described in step 422a, the request is for an operation provided by a given user. This request can be a read request or a write request, i.e., updating / inserting, modifying, or deleting data in the database.

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

[0145] In step 506, the permission settings for each of the retrieved attributes are then verified to be valid for the request of a given user. In other words, the SQL request is parsed, and the required database attributes are checked against the settings associated with the corresponding attributes of the given user. In some embodiments, the user and attributes are treated as objects, and this check can be based on a simple Boolean check, as follows:

[0146] (object instance).(database attribute)==true

[0147] If more than one attribute is to be validated based on its corresponding permission settings, the attributes can be merged or linked using AND and OR operations. In some embodiments, a failure of the attribute access condition will trigger a permission error message to be displayed to the user, and the request will not proceed further and will be rejected, as described in step 508.

[0148] Once the access conditions are met, in some embodiments, the SQL request is compared with a database of SQL commands. If such a command is not in the database or is not recognized by the DBMS, a request error message can be returned to the user. If it is a valid function, the method proceeds to step 510.

[0149] Step 510 describes retrieving one or more transaction identifiers (TTxID, ETxID) associated with the request, each transaction identifier being associated with a transaction, thereby linking the transaction's data to a data structure. This step includes accessing data associated with the retrieved transaction identifiers (TTxID, ETxID) from the data structure.

[0150] Once the data is now accessible, step 512 determines whether the request is for a read or write operation that will use the accessed data.

[0151] If the data is not updated in any way during a READ operation, then in step 514, an operation is performed to retrieve the accessed data to provide an interface to one or more processors, display devices, or client entities associated with the DBMS. In some embodiments, for a READ operation (database query), the relevant TxID is collected and the system's memory is built. The query is executed, and a summary table is built and returned to the user.

[0152] If the request is associated with a write (WRITE) operation, i.e., an update / insert, modify, or delete operation, such as Figures 3a to 3c The operation described above, as explained with respect to the first aspect, further includes, in step 516, generating one or more transactions based on the operation to spend or process transactions associated with the acquired one or more transaction identifiers (TTxID, ETxID). In some embodiments, for a write (WRITE) operation, the appropriate one or more TxIDs that need to be updated are collected and transmitted to a transaction builder, which may be one or more processors associated with a DBMS. As explained above, this transaction builder may be associated with an SPV wallet for communicating with the distributed ledger.

[0153] Additionally, the OP_RETURN payload can be constructed when generating new transactions for the blockchain. Besides including the user's digital signature, this is similar to that for example... Figure 2 The command shown represents the generation of a transaction. Digital signatures advantageously provide an auditable record of request submissions that can be verified through user records, whereby the user does not need to interact directly with the blockchain, and can be used to verify a given user's submission at the time of submission or at any point in the future. This advantageously provides interoperability with conventional systems while still maintaining an immutable record on the blockchain. In some embodiments, the OP_RETURN payload can then be encrypted using a deterministic derived key before being passed to the transaction builder.

[0154] Transaction construction can be performed in several ways in step 51. For example, upon receiving the necessary TxID and OP_RETURN payload, a transaction can be constructed using a local (DBMS-side) Simple Payment Verification (SPV) client or wallet for the DBMS, which is connected to the blockchain network via a peer-to-peer connection with a full node. The SPV client or wallet itself does not mine or store a copy of the blockchain.

[0155] Below is an example of code for creating fake transactions:

[0156] Instantiate the transaction object using the builder.

[0157] tx = Transaction(NetworkParameters params)

[0158] First, add a spendable output linked to the address (address_i) reserved by the system for the DBMS's SPV client. This address can be generated using a public key hash derived from a known deterministic derivation scheme:

[0159] tx.addOutput(Coin.MIN_NONDUST_OUTPUT, Address address_i)

[0160] The OP_RETURN payload is stored in the variable OPR_DATA and then added to the transaction using the addOutput function, as shown below:

[0161] tx.addOutput(Coin.MIN_NONDUST_OUTPUT,newScriptBuilder().op(ScriptOpCodes.OP_RETURN).data(OPR_DATA.getBytes).build())

[0162] The corresponding unspent transaction output reference is stored in a variable named prevOut. Then, the required private key V for spending this output is retrieved, and the corresponding public key P is stored in the variable sigKey.

[0163] Finally, the private key V is used to sign transactions using ECDSA (without TxID and unlock script). The signature data (sig) and public key are stored as follows:

[0164] scriptPubKey = OP_PUSH sig OP_PUSH sigKey

[0165] Then, the input data is added to the transaction object using the addSignedInput function:

[0166] tx.addSignedInput(TransactionOutPoint prevOut, Script scriptPubKey,ECKey sigKey)

[0167] The transaction can then be submitted to the network via the SPV wallet of the full node for verification and inclusion in a block:

[0168] tx.broadcastComplete.get()

[0169] In step 518, then withFigure 6 One or more of the entry transaction data types, table transaction data types, and / or database transaction data types associated with the blockchain-based data structure are updated with the TxID of the newly constructed or generated transaction.

[0170] Figure 2 This is a schematic diagram depicting the data management system or data or database management system (DBMS) 600 discussed in the second or third aspect of this disclosure, for use in managing such... Figure 7 This illustrates data storage, access, and manipulation within a blockchain-based data structure.

[0171] This is similar to a Distributed Database Management System (DDMS) used to integrate distributed databases. This DBMS 600 system can be a remote or third-party service implemented by one or more remote servers, or it can be associated with a client application.

[0172] Regardless of the implementation method, DBMS 600 includes the following components:

[0173] • Registration and access management system 604, which is based on the method described above regarding the second aspect, for providing access control to provide read / write permissions to users associated with client entity 602.

[0174] • Transaction execution system 606, as explained with respect to the third aspect, is used to interpret and execute standard SQL commands to create transactions or queries against data associated with the blockchain data structure. This component may include a command interpreter 606a that acts as an SQL compiler, a transaction builder 606b that constructs a series of transactions to be submitted, and an SPV wallet 606c that is used to output execution management, transaction submission, network monitoring, etc., when contacting or communicating with the blockchain 612.

[0175] • Unspent transaction output set 610 and TxID register 608, which are used to record all TxIDs and latest data in the unspent transaction output set in association with DBMS 600.

[0176] To facilitate fast and easy access to data, the DBMS 600 may have an indexed copy of the unspent transaction output set 610 or a subset containing the latest relevant transactions of the database. This is integrated with an SPV wallet 606c, which tracks the keys associated with the user (i.e., the client entity requesting registration or access to the database / DBMS as a full node) to record updates (spending) of the unspent transaction outputs. A separate record of the index is stored as a TxID register 608, so OP_RETURN data can be retrieved for querying.

[0177] The index can be a simple integer count or more detailed data such as a name, function output value, or hash value. Transaction identifiers (TxIDs) for database transactions are required because they contain associated TTxIDs or ETxIDs for reassembling the database or the entire data structure. However, to reduce the number of transactions requiring updates, in some embodiments, TTxIDs or ETxIDs may also be stored and organized off-chain into the relevant database structure. Access attributes can be stored in TxID register 608, which can be checked by the registration and access management system during the setup / license verification steps performed in the second aspect of this disclosure.

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

[0179] Now go to Figure 6 This document provides an illustrative simplified block diagram of a computing device 2600 that can be used to implement at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 can be used to implement any system shown and described above. For example, the computing device 2600 may be configured to serve as one or more components of the DBMS shown in the diagram, or the computing device 2600 may be configured as a client entity associated with a given user, the client entity targeting a system provided by… Figure 7 The DBMS-managed database submits database requests. Therefore, the computing device 2600 can be a portable computing device, a personal computer, or any electronic computing device. Figure 7 As shown, computing device 2600 may include one or more processors with one or more levels of cache and a memory controller configured to communicate with a storage subsystem 2606 including main memory (also referred to as memory subsystem 2608) and persistent memory (also referred to as file storage subsystem 2610). As shown, the main memory may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620. Storage subsystem 2606 and cache memory can be used to store information, such as details associated with transactions and blocks described in this disclosure. Processor 2602 can be used to provide steps or functions of any embodiment described in this disclosure.

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

[0181] Bus subsystem 2604 can provide a mechanism for enabling the various components and subsystems of computing device 2600 to communicate with each other as intended. Although bus subsystem 2604 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0182] The network interface subsystem 2616 can provide interfaces to other computing devices and networks. The network interface subsystem 2616 can serve as an interface for receiving data from the computing device 2600 and transmitting data to other systems. For example, the network interface subsystem 2616 enables data technicians to connect devices to a network, allowing them to send and receive data to and from the device from remote locations (e.g., data centers).

[0183] User interface input device 2612 may include one or more user input devices, such as a keyboard; pointing devices, such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touchscreen included in a display; audio input devices, such as a speech recognition system, a microphone; and other types of input devices. Generally, the term "input device" is used to encompass all possible types of devices and mechanisms for inputting information into computing device 2600.

[0184] One or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display (such as 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 projector or other display device. Generally, the term "output device" is used to encompass all possible types of devices and mechanisms for outputting information from the computing device 2600. For example, one or more user interface output devices 2614 may be used to present a user interface to facilitate user interaction with applications performing described processes and variations thereof (where such interaction may be appropriate).

[0185] Storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data constructs that provide functionality for at least one embodiment of the present disclosure. When executed by one or more processors, application programs (programs, code modules, instructions) may provide functionality for one or more embodiments of the present disclosure and may be stored in storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. Storage subsystem 2606 may additionally provide a repository for storing data used according to the present disclosure. For example, main memory and cache memory may provide volatile storage for programs and data. Persistent memory may provide persistent (non-volatile) storage for programs and data and may include flash memory, one or more solid-state drives, one or more magnetic hard disk drives, one or more floppy disk drives with associated removable media, one or more optical drives (e.g., CD-ROMs, DVDs, or Blu-rays) with associated removable media, and other similar storage media. Such programs and data may include programs for performing steps as described in one or more embodiments of the present disclosure, as well as data associated with transactions and blocks described in the present disclosure.

[0186] The computing device 2600 can be of various types, including portable computer devices, tablets, workstations, or any other devices described below. Additionally, the computing device 2600 may include another device that can be connected to the computing device 2600 via one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). Devices that can be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. Therefore, the device can be configured to convert optical signals into electrical signals, which can be transmitted via the ports to which the device is connected for processing by the computing device 2600. Due to the constantly evolving nature of computers and networks, Figure 7 The description of the computing device 2600 shown is merely used as a specific example to illustrate a preferred embodiment of the device. Read (READ) example processing: Compared to the system described in [the document], many other configurations with more or fewer components are possible.

[0187] Exemplary embodiments listed

[0188] This disclosure is discussed herein based on the following terms relating to the foregoing aspects, which are provided herein as exemplary embodiments to better explain, describe and understand the claimed aspects and embodiments.

[0189] 1. A computer-implemented method for providing a data structure to store and / or manage data associated with one or more transactions relating 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 method comprising the steps of:

[0190] Create database transaction types, including:

[0191] The identifier used for database D, which is used to retrieve data about one or more transactions in the distributed ledger;

[0192] One or more table transaction identifiers (TTxIDs), wherein a given TTxID of the one or more TTxIDs is specific to a given table in one or more tables associated with the identified database D, wherein the given TTxID relates to a transaction in the distributed ledger for the given table;

[0193] Create a table transaction type, which includes:

[0194] An identifier for table T, which is in one or more tables associated with the identified database D;

[0195] One or more entries associated with the identified table T.

[0196] 2. The method as described in Clause 1, wherein the form transaction type further includes:

[0197] One or more entry transaction identifiers (ETxIDs), wherein a given ETxID of the one or more ETxIDs is specific to a given entry in one or more entries associated with the identified table T, wherein the given ETxID relates to a transaction in the distributed ledger for the given entry;

[0198] The method further includes:

[0199] Create an entry transaction type, which includes:

[0200] One or more data pairs, wherein each data pair relates to an entry in the identified table T, and wherein each data pair includes a reference R for identifying a location in the identified table and a value VL for the identified location.

[0201] 3. As described in Clause 1 or 2, wherein a transaction associated with one or more TTxIDs or ETxIDs is associated with one or more unspent transaction outputs.

[0202] 4. The method as described in Clause 3, wherein the unspent transaction output for a given transaction includes an output script that can be spent by subsequent transactions associated with the identified database D and / or table T.

[0203] 5. The method of any one of Clauses 3 or 4, wherein the unspent transaction output for a given transaction includes a non-spentable output associated with a spendable output script for the given transaction.

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

[0205] 7. The data structure as described in Clause 6, wherein the data structure is a nested transaction storage structure, wherein the data structure further includes an entry data type created according to any one of Clauses 2 to 5, the data structure being configured to store the identified database D based on TTxID and ETxID associated with the identified database D.

[0206] 8. A computer-implemented method for implementing one or more transactions associated with a distributed ledger, the transactions using the data structure provided by any one of the preceding clauses, the method being implemented by one or more processors associated with a data management system (DBMS) and comprising the following steps:

[0207] Creating a database involves the following steps:

[0208] A first transaction is generated to create a first database, the first transaction being based on the database transaction type of the data structure;

[0209] The first database created provides output for the first transaction;

[0210] In response to a request or transaction associated with the first database; updating the first database includes the following steps:

[0211] A second transaction is generated to create a first table, the second transaction being based on the table transaction type of the data structure;

[0212] The first table created provides output for the second transaction, including the identifier (TTxID) of the second transaction.

[0213] Generating a third transaction based on the output of the second transaction includes the following steps:

[0214] Update the database transaction type of the first database with the identifier (TTxID) associated with the second transaction;

[0215] The updated first database provides output for the third transaction.

[0216] 9. The method as described in Clause 7 further includes the following steps:

[0217] In response to a request or transaction associated with the first form, populating the first form includes the following steps:

[0218] A fourth transaction is generated to create a first entry in the first table, the fourth transaction being based on the entry transaction type of the data structure;

[0219] The output of the fourth transaction is provided based on the created entry, and includes the identifier (ETxID) of the fourth transaction;

[0220] The fifth transaction is generated based on the output of the fourth transaction, which includes the following steps:

[0221] Update the table transaction type of the first table with the identifier (ETxID) associated with the fourth transaction;

[0222] Provide output for the fifth transaction, the output being based on the updated first table and the identifier (TTxID) of the fifth transaction;

[0223] The sixth transaction is generated based on the output of the fifth transaction, which includes the following steps:

[0224] Update the database transaction type of the first database with the identifier (TTxID) associated with the fifth transaction;

[0225] The updated first database provides output for the sixth transaction.

[0226] 10. The method as described in Clause 9, comprising the following steps:

[0227] In response to a request or transaction associated with the first form, the first form is modified, which includes the following steps:

[0228] A seventh transaction is generated to modify the reference and / or value of the data pair associated with the first entry in the first table;

[0229] The entry transaction type of the first entry is updated based on the modified entry of the seventh transaction;

[0230] The output of the seventh transaction is provided based on the modified entry, and includes the identifier (ETxID) of the seventh transaction.

[0231] The eighth transaction is generated based on the output of the seventh transaction, which includes the following steps:

[0232] Update the table transaction type of the first table with the identifier (ETxID) associated with the seventh transaction;

[0233] The updated first table provides output for the eighth transaction, and includes the identifier (TTxID) of the eighth transaction.

[0234] The ninth transaction is generated based on the output of the eighth transaction, which includes the following steps:

[0235] Update the database transaction type of the first database with the identifier (TTxID) associated with the eighth transaction;

[0236] The updated first database provides output for the sixth transaction.

[0237] 11. The method as described in any one of Clauses 9 or 10, comprising the following steps:

[0238] In response to a request or transaction associated with the first form, the first form is modified, which includes the following steps:

[0239] Generating a tenth transaction to delete the first entry in the first table includes the following steps:

[0240] Update the table transaction type of the first table to remove the identifier (ETxID) associated with the fourth transaction.

[0241] The updated first table provides output for the tenth transaction and includes the identifier (TTxID) of the tenth transaction.

[0242] The eleventh transaction is generated based on the output of the tenth transaction, which includes the following steps:

[0243] Update the database transaction type of the first database with the identifier (TTxID) associated with the tenth transaction;

[0244] The output for the eleventh transaction is provided, the output including the identifier of the updated first database.

[0245] 12. A computer-implemented method for implementing one or more transactions associated with a distributed ledger, the transactions using the data structure provided by any one of items 1 to 7, the method being implemented by one or more processors associated with a client entity and comprising the steps of:

[0246] Send a request to one or more processors associated with the DBMS to create the first database;

[0247] A distributed ledger that monitors at least one transaction output associated with the first database D created;

[0248] Send a request to one or more processors associated with the DBMS for creating a first table in the first database;

[0249] The distributed ledger monitors at least one transaction output associated with the first table (TTxID);

[0250] A request is sent to one or more processors associated with the DBMS to update the first table with a first entry, wherein the first entry comprises a data pair including a reference identifying a location in the first table and a numerical value of the identified location.

[0251] 13. A computer-implemented method for implementing one or more transactions associated with a distributed ledger, the transactions using the data structure provided by any one of items 1 to 7, the method being implemented by one or more processors associated with a client entity and comprising the following steps:

[0252] The distributed ledger monitors at least one transaction output associated with a first entry (ETxID) in a first table of a first database;

[0253] A request is sent to one or more processors associated with the DBMS to modify the first entry, the request including modifying the reference and / or value of the data pair associated with the first entry;

[0254] A distributed ledger that monitors at least one transaction output associated with an identifier used to update a first table (TTxID) and / or update a first database D, containing the first entry of the said modification.

[0255] 14. A computer-implemented method for implementing one or more transactions associated with a distributed ledger, the transactions using the data structure provided by any one of items 1 to 7, the method being implemented by one or more processors associated with a client entity and comprising the following steps:

[0256] The distributed ledger monitors at least one transaction output associated with an identifier in the first table (TTxID) of the first database;

[0257] Send a request to one or more processors associated with the DBMS to delete the first entry in the first table;

[0258] A distributed ledger that monitors and updates the identifier of at least one transaction output associated with the identifier of the first table (TTxID) and / or the first database.

[0259] 15. A computer-implemented method for managing access to a data management system (DBMS), the DBMS managing data about transactions associated with a distributed ledger, the data being provided in a database, the method comprising the steps of:

[0260] In response to the DBMS registration request, a record associated with a given user is created, the record including an identifier of the given user among a plurality of users;

[0261] Obtain the public key P associated with the given user; the public key is part of an encryption key pair associated with the given user, the encryption key pair including the private key V for the given user;

[0262] Get or assign one or more attributes associated with the given user, wherein each attribute is associated with settings related to accessing a database managed by the DBMS;

[0263] The record is updated based on the obtained public key P and one or more attributes associated with the given user;

[0264] Store or provide records of the updates associated with the DBMS.

[0265] 16. The method as described in Clause 15, wherein the setting of a given attribute confirms whether the given attribute is associated with permission to perform one or more of the read, write, modify, or delete operations associated with the database.

[0266] 17. The method as described in any one of Clauses 15 or 16, wherein the setting of each attribute is provided in a request, or the setting is obtained from a computing resource associated with the DBMS, or, for a database managed by the DBMS, the setting of each attribute is predetermined.

[0267] 18. A computer-implemented method for implementing a data management system (DBMS) for managing a database of transactions associated with a distributed ledger, the method comprising the steps of:

[0268] A request is obtained from a client entity that is associated with a given user among a plurality of users, wherein the request includes a digital signature associated with the given user;

[0269] Determine that the given user is authorized to access the database;

[0270] In response to a successful determination, the digital signature is verified as being associated with the given user based on the user records associated with the DBMS.

[0271] In response to successful verification, a message is generated based on the current instance of the user record and the request.

[0272] 19. The method as described in Clause 18, wherein the request is a request to read, write, modify, or delete data in the database.

[0273] 20. The method of any one of Clauses 15 to 19, wherein the database is implemented using the data structure of any one of Clauses 1 to 7.

[0274] 21. The method of any one of Clauses 16 to 18, wherein the user record is created when the given user registers with the DBMS in accordance with the method of any one of Clauses 15 to 17.

[0275] 22. The method as described in Clause 21, wherein the step of determining that a user is authorized includes determining that a user record associated with the DBMS exists for the given user when the given user registers with the DBMS.

[0276] 23. The method of any one of Clauses 22 or 22, wherein the step of verifying the digital signature is based on determining that the private key V or signing key K used for signing the request is associated with the public key P in the user record associated with the given user.

[0277] 24. The method as described in any one of Clauses 18 to 23, including generating an error notification in response to determining that unsuccessful access has not been granted or registered for the database.

[0278] 25. The method of any one of Clauses 18 to 23, including generating an error notification in response to unsuccessful verification of the digital signature to specify that the signature applied to the request is invalid for a given user.

[0279] 26. A computer-implemented method for registering with a database management system (DBMS), the DBMS being associated with data relating to transactions linked to a distributed ledger, the method being implemented by one or more processors associated with a client entity, the client entity being associated with a given user among a plurality of users, the method comprising the steps of:

[0280] Generate a DBMS registration request, the request being associated with the given user;

[0281] Provide or access one or more attributes associated with the given user, each attribute being associated with settings related to the database managed by the DBMS;

[0282] Generate a private key V associated with the given user; the private key is part of an encryption key pair that includes the public key P for the given user;

[0283] Calculate the public key P based on the private key V;

[0284] Send the public key P and one or more attributes to the DBMS.

[0285] 27. A computer-implemented method for accessing data associated with a data management system (DBMS), the DBMS being associated with data about transactions related to a distributed ledger, the method being implemented by one or more processors associated with a client entity, the client entity being associated with a given user among a plurality of users, the method comprising the steps of:

[0286] Generate a request associated with a database, the request being associated with the given user, and the database being managed by the DBMS;

[0287] A digital signature is generated based on a private key V for the given user, the private key being part of an encryption key pair including a public key P for the given user; the public key P is provided to the DBMS.

[0288] Apply the digital signature to the request;

[0289] Send the signed request to the DBMS.

[0290] 28. The method as described in Clause 27 includes generating a signing key K based on a private key V, wherein the signing key is a temporary key.

[0291] 29. The methods described in Clause 27 or 28, including the method of registering with the DBMS as described in Clause 26.

[0292] 30. A computer-implemented method for implementing a data management system (DBMS) for managing a database of transactions associated with a distributed ledger, the method comprising the steps of:

[0293] Receive a message associated with the current instance of a user record for a given user among one or more users, and a request associated with the database, the request being provided by the given user;

[0294] Parse the request associated with the database, which includes:

[0295] Retrieve one or more attributes associated with the given user from the current instance;

[0296] Verify that the settings for each of the search attributes are valid for the request of the given user;

[0297] In response to successful verification, one or more operations associated with the database are performed based on the request, wherein the database is based on a data structure provided in accordance with any one of clauses 1 to 6, and the execution steps further include:

[0298] If the request is associated with a read operation, one or more transaction identifiers (TTxID, ETxID) associated with the request are obtained, each transaction identifier being associated with a transaction, thereby associating the data of the transaction with the data structure;

[0299] Access the data associated with the acquired transaction identifiers (TTxID, ETxID) from the data structure;

[0300] If the request is associated with a write, modify, or delete operation, then in addition to the acquisition step, the method further includes generating one or more transactions based on the operation for spending or processing transactions associated with the acquired one or more transaction identifiers (TTxID, ETxID);

[0301] Update the data structure with the identifier associated with the generated transaction.

[0302] 31. The method as described in Clause 30, wherein the verification step includes checking that the setting of a given attribute among one or more attributes indicates that a given user has permission to access the database for the resulting request.

[0303] 32. The method as described in any one of Clauses 30 or 31, wherein if the request is associated with a write, modify, or delete operation, the execution steps further include the method as described in any one of Clauses 7 to 9.

[0304] 33. The method of any one of clauses 30 to 32, wherein if the request is associated with a write, modify, or delete operation, the generation step further includes:

[0305] Retrieve the output script associated with each retrieved transaction identifier (TTxID, ETxID);

[0306] Further transactions are constructed based on the output script, the further transactions being based on a private key V associated with the given user, the private key being part of an encrypted key pair including a public key P for the given user;

[0307] The further transactions are provided to the distributed ledger, and the further transactions are associated with further transaction identifiers (TTxID, ETxID).

[0308] 33. The method as described in Clause 33, wherein the step of constructing further transactions is performed by a Simple Payment Verification (SPV) client associated with the DBMS, wherein the SPV client communicatively couples the DBMS to the distributed ledger via a communication network.

[0309] 35. The method of any one of Clauses 30 to 34, wherein each acquired transaction identifier (TTxID, ETxID) is associated with a transaction that includes a non-spendable unspendable transaction output, said non-spendable unspendable transaction output being associated with or including a spendable payload, the spendable payload being a spendable unspendable transaction output.

[0310] 36. The method as described in Item 35, wherein each spendable and unspendable unspendable transaction output is stored in a set or memory of unspendable transaction outputs associated with the DBMS, wherein the unspendable unspendable transaction outputs are OP_RETURN output scripts.

[0311] 37. The method as described in Clause 36, wherein one or more spendable unspent transaction outputs in a set of unspent transaction outputs or a memory are used to construct further transactions.

[0312] 38. A computing device, comprising:

[0313] Processor; and

[0314] The memory includes executable instructions, wherein when the processor executes the executable instructions, it causes the device to perform a computer-implemented method according to any one of clauses 12 to 14 or 26 to 29;

[0315] The computing device mentioned above is the client entity.

[0316] 39. A DBMS system for managing access to data associated with one or more transactions relating to a distributed ledger, wherein the data managed by the DBMS is stored in a data structure as described in any one of clauses 1 to 7, the DBMS comprising:

[0317] A registration and access management system having one or more processors configured to execute instructions to perform a computer-implemented method as described in any one of Articles 15 to 25;

[0318] A transaction execution system having one or more processors configured to execute instructions to perform a computer-implemented method as described in any one of Articles 30 to 37;

[0319] One or more registers for storing multiple transaction identifiers associated with the database;

[0320] A collection or storage of unspent transaction outputs, used to store copies of multiple unspent transaction outputs associated with the database.

[0321] 38. A system comprising:

[0322] One or more computing devices as described in Clause 38, each being a client entity;

[0323] DBMS as described in Clause 39;

[0324] A communication network is used to communicatively couple each client entity with the DBMS.

[0325] It should be noted that the above embodiments are illustrative and not limiting of this disclosure, and those skilled in the art will be able to devise many alternative embodiments without departing from the scope of this disclosure as defined by the appended claims. Any reference numerals in parentheses in the claims should not be construed as limiting the claims. The words “comprising” and the like do not exclude the presence of elements or steps other than those listed in their entirety in any claim or specification. In this specification, “comprising” means “including” or “consisting of”. The singular form of an element does not exclude the plural form of such elements, and vice versa. This disclosure can be implemented by hardware comprising several different elements and by a suitably programmed computer. In device claims enumerating several means, several of these means may be embodied in the same hardware. The fact that certain measures are referenced in dissimilar dependent claims does not mean that combinations of these measures cannot be advantageously used.

[0326] Exemplary use cases and scenarios

[0327] ​

[0328] The power of relational databases lies in their ability to aggregate related data across multiple tables. This is typically accomplished using the JOIN SQL command between two tables. There are four subtypes of JOIN:

[0329] 1. INNER JOIN — Returns common values ​​from two tables.

[0330] 2. LEFT JOIN — Returns all values ​​from the left table and common values ​​from the right table.

[0331] 3. RIGHT JOIN — Returns all values ​​from the right-hand table and common values ​​from the left-hand table.

[0332] 4. OUTER JOIN — Returns all values ​​from two tables.

[0333] The INNER JOIN command will have the following form:

[0334] SELECT table_name.column_name, table_name.column_name,......

[0335] FROM lefttable_name

[0336] INNER JOIN righttable_name ON [matching condition];

[0337] In this command, the first line selects the column values ​​reported in the query response, and you can freely choose from two tables. The relevant table and entry data are read from the set of unspent transaction outputs from the TxID reference and stored in system memory. Conditions are then applied and organized for analysis and assembly.

[0338] The next row allows users to select the 'left' table.

[0339] The next line sets the join conditions (inner join in this case) and specifies the right-hand table to be joined.

[0340] Finally, specify the matching criteria to search for common elements in both tables. For example, to search the buyer's and seller's tables by name, the criteria would be as follows:

[0341] buyers.name = sellers.name

[0342] Because this is executed entirely off-chain by the DBMS, no equivalent transactions are required, and it can be incorporated into standard SQL protocols. This also allows the system to fully leverage standard efficiency optimization and scaling methods that have been extensively explored over the past few decades. This approach allows for easy integration with existing enterprise data management solutions such as Oracle and SAP.

Claims

1. A computer-implemented method for providing a blockchain-implemented data structure to store and / or manage data associated with one or more transactions relating to a distributed ledger, said method being implemented by one or more processors associated with a data management system (DBMS) for said distributed ledger, said method comprising the steps of: Create database transaction types, including: An identifier for database D, used to retrieve data about one or more transactions in the distributed ledger; and One or more table transaction identifiers TTxIDs, wherein a given TTxID of the one or more TTxIDs is specific to a given table in one or more tables associated with an identified database D, wherein the given TTxID is associated with a transaction on a distributed ledger for the given table; and, Create a table transaction type, which includes: An identifier for table T, which is in one or more tables associated with the identified database D; and One or more entries associated with the identified table T; and, Create the database D, wherein creating the database D includes: generating a first transaction to create a first database, the first transaction being based on the database transaction type of the data structure, and providing output for the first transaction based on the created first database.

2. The method of claim 1, wherein the form transaction type further comprises: One or more entry transaction identifiers ETxID, wherein a given ETxID of the one or more ETxIDs is specific to a given entry in one or more entries associated with the identified table T, wherein the given ETxID is associated with a transaction in the distributed ledger for the given entry; The method further includes: Create an entry transaction type, which includes: One or more data pairs, wherein each data pair is associated with an entry in the identified table T, and wherein each data pair includes a reference R for identifying a position in the identified table and a value VL for the identified position.

3. The method of claim 1 or 2, wherein the transaction associated with the one or more TTxIDs or ETxIDs is associated with one or more unspent transaction outputs.

4. The method of claim 3, wherein the unspent transaction output for a given transaction includes an output script that is spendable for subsequent transactions associated with the identified database D and / or table T.

5. The method of claim 4, wherein the unspent transaction output for the given transaction includes a non-spentable output associated with the spendable output script of the given transaction.

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

7. The system of claim 6, wherein the data structure is a nested transaction storage structure, wherein the data structure further comprises an entry data type created by the method of any one of claims 2 to 5, the data structure being configured to store the identified database D based on storing TTxID and ETxID associated with the identified database D.

8. A computer-implemented method for implementing one or more transactions associated with a distributed ledger, said transactions using the data structure provided by claim 6 or 7, said method being implemented by one or more processors associated with a data management system (DBMS) and comprising the following steps: Creating a database involves the following steps: A first transaction is generated to create a first database, the first transaction being based on the database transaction type of the data structure; and The first database created provides output for the first transaction; In response to a request or transaction associated with the first database; updating the first database includes the following steps: A second transaction is generated to create a first table, the second transaction being based on the table transaction type of the data structure; and The first table created provides output for the second transaction, and includes the identifier TTxID of the second transaction; Generating a third transaction based on the output of the second transaction includes the following steps: Update the database transaction type of the first database with the identifier TTxID associated with the second transaction; and The updated first database provides output for the third transaction.

9. The method of claim 8, further comprising the following steps: In response to a request or transaction associated with the first form, populating the first form includes the following steps: A fourth transaction is generated to create a first entry in the first table, the fourth transaction being based on the entry transaction type of the data structure; and The output of the fourth transaction is provided based on the created entry, and includes the identifier ETxID of the fourth transaction; The fifth transaction is generated based on the output of the fourth transaction, which includes the following steps: Update the table transaction type of the first table with the identifier ETxID associated with the fourth transaction; and Provide output for the fifth transaction, the output being based on the updated first table and the identifier TTxID of the fifth transaction; and, The sixth transaction is generated based on the output of the fifth transaction, which includes the following steps: Update the database transaction type of the first database using the identifier TTxID associated with the fifth transaction; and The updated first database provides output for the sixth transaction.

10. The method according to claim 9, wherein the method comprises the following steps: In response to a request or transaction associated with the first form, the first form is modified, which includes the following steps: A seventh transaction is generated to modify the reference and / or value of the data pair associated with the first entry in the first table; The entry transaction type of the first entry is updated using the modified entry based on the seventh transaction; and The output of the seventh transaction is provided based on the modified entry, and includes the identifier ETxID of the seventh transaction; The eighth transaction is generated based on the output of the seventh transaction, which includes the following steps: Update the table transaction type of the first table using the identifier ETxID associated with the seventh transaction; and The updated first table provides output for the eighth transaction, including the identifier TTxID of the eighth transaction; and, The ninth transaction is generated based on the output of the eighth transaction, which includes the following steps: The database transaction type of the first database is updated using the identifier TTxID associated with the eighth transaction; and The updated first database provides output for the sixth transaction.

11. The method according to any one of claims 9 or 10, the method comprising the following steps: In response to a request or transaction associated with the first form, the first form is modified, which includes the following steps: Generating a tenth transaction to delete the first entry in the first table includes the following steps: Update the table transaction type of the first table to remove the identifier ETxID associated with the fourth transaction; and The updated first table provides output for the tenth transaction, including the identifier TTxID of the tenth transaction; and, The eleventh transaction is generated based on the output of the tenth transaction, which includes the following steps: Update the database transaction type of the first database using the identifier TTxID associated with the tenth transaction; and The output for the eleventh transaction is provided, the output including the identifier of the updated first database.

12. A computer-implemented method for implementing one or more transactions associated with a distributed ledger, said transactions using the data structure provided by any one of claims 6 or 7, said method being implemented by one or more processors associated with a client entity and comprising the following steps: Send a request to one or more processors associated with the DBMS to create the first database; A distributed ledger that monitors at least one transaction output associated with the first database D created; Send a request to one or more processors associated with the DBMS for creating a first table in the first database; The distributed ledger monitors at least one transaction output associated with the first table TTxID; A request is sent to one or more processors associated with the DBMS to update the first table with a first entry, wherein the first entry comprises a data pair including a reference identifying a location in the first table and a value for the identified location.

13. A computer-implemented method for implementing one or more transactions associated with a distributed ledger, said transactions using the data structure provided by any one of claims 6 or 7, said method being implemented by one or more processors associated with a client entity and comprising the following steps: The distributed ledger monitors at least one transaction output associated with the first entry ETxID in the first table of the first database; Send a request to one or more processors associated with the DBMS for modifying the first entry, the request including a request to modify the reference and / or value of the data pair associated with the first entry; A distributed ledger that monitors and updates at least one transaction output associated with the identifier of the first table TTxID and / or the first database D, containing the modified first entry.

14. A computer-implemented method for implementing one or more transactions associated with a distributed ledger, said transactions using the data structure provided by any one of claims 6 or 7, said method being implemented by one or more processors associated with a client entity and comprising the following steps: The distributed ledger monitors at least one transaction output associated with the identifier of the first table TTxID in the first database; Send a request to one or more processors associated with the DBMS to delete the first entry in the first table; Monitor and associate at least one transaction output of the distributed ledger with the updated first form TTxID and / or the updated first database identifier.

15. A computing device, comprising: processor; as well as A memory containing executable instructions, wherein when the processor executes the executable instructions, the device causes the device to perform a computer-implemented method according to any one of claims 12 to 14; The computing device mentioned above is the client entity.

Images