Patent Publication Number: US-11657039-B2

Title: Relational data management and organization using DLT

Description:
COPYRIGHT NOTICE 
     A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 
     CLAIM OF PRIORITY 
     This application is a continuation of and claims the benefit of priority under 35 U.S.C. § 120 to U.S. patent application Ser. No. 16/544,538, filed on Aug. 19, 2019, now U.S. Pat. No. 10,726,002, which is hereby incorporated by reference herein in its entirety. 
     TECHNICAL FIELD 
     The application is directed to the management and organization of data to enable storage and retrieval of that data to/from a distributed ledger in accordance with relational database principles. 
     BACKGROUND 
     The original relational database systems came in response to a major new development in computing in the late 1960s. As systems got larger and more complex, it became clear that new and updated programs needed to work with data created by older ones. Existing systems made this difficult because programs often stored data each in their own way. The relational model standardized important aspects of storage and retrieval and those who adopted it enjoyed a range of benefits, including cheaper upgrades and reduced vendor lock-in. 
     Conversely, those who were still led by computer vendors into program-specific storage approaches endured higher maintenance costs and a larger effort later, particularly when what was sometimes a long-delayed decision to move to a Relational Database Management System (RDBMS) platform was finally made. The years-long Australian Department of Defense project in the 1970s to finally move off the non-relational Honeywell FACT language is a testament to these costs. 
     From time to time since then, advancements in other areas of computing have made existing relational database tools incompatible or inconvenient. For example, the file-oriented nature of the early world wide web led many projects back to the inefficient times before the relational database until connecting of web pages to an RDBMS back-end was achieved and practiced. Similarly, the rise of object-oriented programming temporarily made it less natural for programmers to represent data using the relational data model. Data encapsulated in objects was difficult to break out into RDBMS tables. However, the advantages of relational representation were significant enough that now Object-Relational Mapping (ORM) is a common approach where object-oriented programming is still used. 
     On the other hand, distributed ledger technology (DLT) has the potential to ignite and enable what is tantamount to the information technology revolution of this century. Distributed ledger technology is tackling and solving one of the largest and most perplexing challenges of the Internet—the lack of trust. Distributed ledger technology is a nascent but powerful distributed computing paradigm and the only technology to date that has the potential to bring trust to the Internet by making data immutable for practical purposes. Unfortunately, existing RDBMS platforms and tools are not compatible with distributed ledger technology&#39;s constraints. As a result, program/data lock-in, wherein the data is inextricably linked to the program, is even greater for smart contracts on distributed ledgers than it was for programs in the pre-relational database days in the 1960s. Systems and methods are desired whereby data in distributed ledgers will only be locked into the particulars of a deployed smart contract if that was the specific intent of the developer. 
     SUMMARY 
     The systems and methods described herein address the needs in the art by providing a set of both smart contract and off-chain tools that enable relational data management and organization prior to storage on a distributed ledger, making it possible to leverage previously existing developer knowledge about relational databases without trading away the benefits of the distributed ledger. In sample embodiments, data is managed and organized according to relational principles, stored on a distributed ledger platform of choice and accessed using programming languages, such as Structured Query Language (SQL), that are already familiar to the developer. The result is a highly secure and auditable relational database on a distributed ledger. Also, the systems and methods described herein may be used with smart contracts to make the data storage aspect of those smart contracts more tractable. 
     In sample embodiments, a cross-distributed-ledger-platform specification plus reusable core components together create a relational data management and organization system that may be implemented on common distributed ledger technology platforms such as Hyperledger® Fabric and accessed from popular programming platforms such as Node.js®. The relational data management and organization system enables the ability to add system chaincode for use with Hyperledger® Fabric and uses schemas and data represented as JavaScript Object Notation (JSON). Also, Fabric&#39;s world state database is used for data storage and Fabric&#39;s identity provider is used for data access control over, for example, five levels including create database, authorize users for database access, add table and modify schema, write data, and query only. In use, the user may create, update, and query tables from code, a console, or a smart contract where every update is a distributed ledger transaction. 
     In sample embodiments, systems and methods are provided for querying a distributed ledger platform that implements a distributed ledger including transaction data on the distributed ledger with a relational database management query. The method includes creating a database and recording information about the database on the distributed ledger and converting a received relational database management query into a query operation that may be processed by the distributed ledger platform. The query operation is executed on the distributed ledger platform to generate a query result, and the query result is logged to the distributed ledger platform in a form that may be processed by the distributed ledger platform for inclusion on the distributed ledger. In sample embodiments, the relational database management query is generated by (1) receiving a structured query language (SQL) query from a user via a user interface; (2) receiving an SQL query from a user application via an application program interface; or (3) a smart contract that executes an SQL query. 
     In sample embodiments, a relational data management and organization system is adapted to parse the SQL query into an SQL operation that may be one of either a data manipulation language (DML) write operation, a DML read operation, or a data definition language (DDL) operation. A JavaScript Object Notation (JSON) representation of the SQL operation and any relational data included in the SQL operation is created for processing by the distributed ledger platform. 
     In other sample embodiments, whether a transaction resulting from execution of the SQL operation has progressed toward acceptance into a distributed ledger to a platform-relevant extent is determined by, for example, adding an operation broadcast status (OPSTAT) instruction at the end of a DML Write operation to fetch a more definitive status of a corresponding transaction. Executing the query operation on the distributed ledger platform may further include confirming that an entity invoking the SQL query has authority to perform the requested SQL operation. Executing the query operation on the distributed ledger platform also may include creating a query operation that may be processed and stored by the distributed ledger platform as a JSON representation of the query operation and its result. 
     In the case where the SQL operation is an SQL DML write operation, the methods may include retrieving data from the distributed ledger platform as required to execute the SQL DML write operation, executing the SQL DML write operation including the retrieved data, preparing JSON representations of any new or updated records in the query result, and committing the SQL DML write operation and any updated records to the distributed ledger platform in the form that may be processed by the distributed ledger platform for inclusion on the distributed ledger. The methods may also include monitoring the distributed ledger for acceptance of the SQL DML write operation into the distributed ledger and informing an entity invoking the SQL query whether the SQL DML write operation was successful. 
     On the other hand, in the case where the SQL operation is an SQL DML read operation, the methods may include retrieving data from the distributed ledger platform as required to execute the SQL DML read operation, executing the SQL DML read operation including the retrieved data, preparing a JSON representation of the query result, and logging the JSON representation of the query result to the distributed ledger platform in the form that may be processed by the distributed ledger platform for inclusion on the distributed ledger. The method may also include returning the JSON representation of the query result to an entity invoking the SQL query. 
     In sample embodiments, the distributed ledger platform is a Hyperledger® Fabric platform. In such embodiments, the database may be created within the distributed ledger by executing a configuration transaction that creates a channel and defines which peer computers will maintain a copy of the database and a regular transaction that writes metadata about the database. Also, code may be created that defines transaction data in the distributed ledger and transaction instructions for modifying the transaction data. In the sample embodiments, the code may define attributes of the database in a JavaScript Object Notation (JSON) as the transaction data. At the conclusion of an operation, the database is updated with the database attributes. Also, the method may include creating a parsed and translated structured query language (SQL) query that accounts for the form that may be processed by the distributed ledger platform for inclusion on the distributed ledger. For example, the SQL query may account for JSON elements of the relational management and organization system specification on the Hyperledger® Fabric platform. 
     In other sample embodiments, a system is provided that includes a distributed ledger platform that implements a distributed ledger including transaction data, and at least one processor that executes instructions to implement a relational data management and organization system that performs operations including creating a database and recording information about the database on the distributed ledger; converting a received relational database management query into a query operation that may be processed by the distributed ledger platform; executing the query operation on the distributed ledger platform to generate a query result; and logging the query result to the distributed ledger platform in a form that may be processed by the distributed ledger platform for inclusion on the distributed ledger. The system may further include means for generating the relational database management query including (1) a user interface to the relational data management and organization system through which a user provides a structured query language (SQL) query, (2) a user application that passes an SQL query to the relational data management and organization system via an application program interface to the relational data management and organization system, or (3) a smart contract that executes an SQL query. 
     In sample embodiments of the system, the at least one processor further executes instructions to parse the SQL query into an SQL operation including as alternatives a data manipulation language (DML) write operation, a DML read operation, or a data definition language (DDL) operation, and to create a JavaScript Object Notation (JSON) representation of the SQL operation and any relational data included in the SQL operation. The at least one processor may further execute instructions to determine whether a transaction resulting from execution of the SQL operation has progressed toward acceptance into the distributed ledger to a platform-relevant extent. For example, an OPSTAT instruction may be added at the end of a DML Write operation to fetch a more definitive status of a corresponding transaction. 
     In further sample embodiments, the distributed ledger platform is a Hyperledger® Fabric platform, and the at least one processor executes instructions to create the database within the distributed ledger by executing a configuration transaction that creates a channel and defines which peer computers will maintain a copy of the database and a regular transaction that writes metadata about the database, and to create code defining transaction data in the distributed ledger and transaction instructions for modifying the transaction data. The at least one processor may further execute instructions corresponding to code that defines attributes of the database in a JavaScript Object Notation (JSON) as the transaction data and to update the database with the database attributes. The at least one processor may also execute instructions to create a parsed and translated structured query language (SQL) query that accounts for the form that may be processed by the distributed ledger platform for inclusion on the distributed ledger. 
     The embodiments described herein also encompass computer systems and computer readable media coded with instructions for implementing the methods described throughout this disclosure. For example, the systems and methods described herein may be implemented on a computing platform in the cloud to provide functionality for accessing and storing data to a database implemented on a distributed ledger platform as described herein. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present disclosure is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: 
         FIG.  1    is a block diagram of the relational data management and organization system in sample embodiments. 
         FIG.  2    is a block diagram of an implementation of the relational data management and organization system in a realization where Node.js® is the programming language and Hyperledger® Fabric is the distributed ledger platform used in sample embodiments. 
         FIG.  3    is a block diagram illustrating the activities, components and data involved in database creation for the relational data management and organization system in sample embodiments. 
         FIG.  4    is a block diagram illustrating an operation to write relational data to an existing database of the relational data management and organization system in sample embodiments. 
         FIG.  5    is a block diagram illustrating the execution of Data Manipulation Language (DML) read queries requested by the user interface of the relational data management and organization system or by a user&#39;s application via the Language Specific SDK and application program interface of the relational data management and organization system in sample embodiments. 
         FIG.  6    is a block diagram illustrating the components and data involved in the first part of relational data access control for the addition of users for access below the super-admin level in sample embodiments. 
         FIG.  7    is a block diagram illustrating the interaction of the ELEMENT Fabric-Node.js® SDK with a user&#39;s application and the execution environment in which they are both hosted, which is modeled as the User Application Node in sample embodiments. 
         FIG.  8    is a logical flow diagram of an example of a successful SQL DML write operation to a distributed ledger using the relational data management and organization system in sample embodiments. 
         FIG.  9    is a logical flow diagram of an example of a successful SQL DML read operation from a distributed ledger using the relational data management and organization system in sample embodiments. 
         FIG.  10    is a block diagram illustrating the successful execution of Data Definition Language (DDL) writes in sample embodiments. 
         FIG.  11    is a block diagram of a typical, general-purpose computer that may be programmed into a special purpose computer suitable for implementing one or more embodiments of the relational data management and organization disclosed herein. 
         FIG.  12    illustrates an “execute first and order next” design. 
         FIG.  13    illustrates a blockchain network comprised of peer nodes, each of which can hold copies of ledgers and copies of smart contracts. 
         FIG.  14    illustrates a peer hosting instances of ledgers and instances of chaincodes. 
         FIG.  15    illustrates a peer hosting multiple ledgers. 
         FIG.  16    illustrates an example of a peer hosting multiple chaincodes. 
         FIG.  17    illustrates peers, in conjunction with orderers, that ensure that the ledger is kept up-to-date on every peer. 
         FIG.  18    illustrates channels that allow a specific set of peers and applications to communicate with each other within a blockchain network. 
         FIG.  19    illustrates peers in a blockchain network with multiple organizations. 
         FIG.  20    illustrates that when a peer connects to a channel, its digital certificate identifies its owning organization via a channel MSP. 
         FIG.  21    illustrates transaction proposals that are independently executed by peers who return endorsed proposal responses. 
         FIG.  22    illustrates the second role of an orderer node, which is to distribute blocks to peers. 
         FIG.  23    illustrates a ledger world state containing two states. 
         FIG.  24    illustrates that having a valid credit card is not enough—it must also be accepted by the store. 
         FIG.  25    illustrates the elements of Public Key Infrastructure (PKI). 
         FIG.  26    illustrates a digital certificate describing a party called Mary Morris. 
         FIG.  27    illustrates an example where Mary uses her private key to sign the message. 
         FIG.  28    illustrates a Certificate Authority that dispenses certificates to different actors. 
         FIG.  29    illustrates a chain of trust is established between a Root CA and a set of Intermediate CAs as long as the issuing CA for the certificate of each of these Intermediate CAs is either the Root CA itself or has a chain of trust to the Root CA. 
         FIG.  30    illustrates using a CRL to check that a certificate is still valid. 
         FIG.  31    illustrates access levels and permission determination. 
         FIG.  32    illustrates an overview of data and operation objects. 
     
    
    
     DESCRIPTION 
     The following description with respect to  FIGS.  1 - 32    sufficiently illustrates specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass all available equivalents of those claims. 
     Terminology 
     Distributed Ledger Technology (DLT): Any of a number of technologies enabling replicated, shared, and synchronized digital data across multiple computers participating in a network. Distributed ledger technology is designed to be inherently resistant to modification of the digital data which, once synchronized, is known collectively as a “distributed ledger”. A distributed ledger is typically managed by a peer-to-peer network that collectively adheres to a protocol for validating new information. A system that is capable of producing and maintaining a distributed ledger is known as a Distributed Ledger Platform. “Distributed Ledger Platforms” is inclusive of known platforms such as Aion, ArcBlock, Cardano™, Corda, Enigma, EOS, Ethereum, Hyperledger® Fabric, Hyperledger® Iroha, Hyperledger® Sawtooth, ICON, IOTA, Komodo, Lisk™, MultiChain, Neblio, NEM, NEO, NxT, Qtum, Smilo, Stella, Straitis, Tezos, Wanchain, Waves, and Zilliqa, plus derivations from the foregoing, and others. Many of these platforms are also “blockchain technology” or “blockchain” platforms, a subset of distributed ledger technology platforms. 
     Smart Contract: A computer protocol that provides the general-purpose computation that takes place on the distributed ledger platform. The smart contract transactions may be simple or may implement sophisticated logic. The resulting transactions are typically transparent to ledger participants, trackable and irreversible. 
     JSON: JavaScript Object Notation is a lightweight, text-based, human-readable data-interchange format. 
     SQL: Structure Query Language is the standard language for accessing and manipulating relational database management systems. 
     Node.js®: A free open source server environment that executes JavaScript code outside of a browser. Node.js® is an asynchronous programming platform built on the Chrome browser&#39;s JavaScript runtime. More information about Node.js® may be found at “About Node.js®.” Node.js, Node.js Foundation, https://nodejs.org/en/about/. 
     Hyperledger® Fabric: An enterprise grade permissioned distributed ledger platform that offers modularity and versatility for a broad set of industry use cases. Fabric&#39;s architecture includes an identity provider, channels, a world state database, and user and system chaincode. Further details regarding Hyperledger® Fabric are available in Appendix A attached hereto. 
     Chaincode: In Fabric, software either (a) defines an asset or assets, and the transaction instructions for modifying the asset(s); in other words, the business logic, or (b) extends or modifies the platform including the rules and activities governing the execution of the former. Chaincode enforces the rules for reading or altering key-value pairs or other state database information. Chaincode functions execute against the ledger&#39;s current state database and are initiated through a transaction proposal. Chaincode execution results in a set of key-value writes (write set) that may be submitted to the network and applied to the ledger on all peers. Chaincode may be considered equivalent to the platform-independent concept of Smart Contracts. 
     Apache CouchDB®: An option for a world state database that is incorporated into Hyperledger® Fabric. Apache CouchDB® supports rich queries when chaincode data values are modeled as JSON. CouchDB® indexing and querying are an option for use in sample embodiments of the relational data management and organization system described herein. Further details regarding CouchDB® are available in Appendix A attached hereto. 
     Overview 
     The relational model&#39;s value comes from establishing independence between the representation of data and the programs that read and write it. In addition to encouraging reusable frameworks for data management, Relational Database Management Systems (RDBMSs) enforce rules on the writing of data that make it impossible for one program&#39;s data manipulations to break other programs&#39; ability to locate and access that data. The first of these principles is the outlawing of “ordering dependence.” If one program depends on data being physically maintained in a specific order, then another program which is oblivious to this requirement may break the first. The second principle is the prevention of “indexing dependence.” Indexing is redundant storage of data to improve the performance of some operations, perhaps at the expense of others. Although it is impossible to cater to the performance preferences of every program, the relational model at least guarantees that no program will break if the indexes for a data set change. The third principle is to prevent “access path dependence.” In the relational model, a program only needs to know what data it wants to read and write and no additional information about how the data is organized in storage. Before RDBMSs, it was common for data to be organized in hierarchical structures which might subsequently be rearranged, unnecessarily breaking a program&#39;s ability to locate and work with that data. 
     The relational data management and organization system described herein achieves these three principles. But to understand the challenges that were involved in creating a relational data management and organization system for use with distributed ledgers that achieves these three principles, it is necessary first to understand some considerations particular to distributed ledger platforms. 
     Distributed ledger technology is closely associated in the public&#39;s mind with cryptocurrency, the use for which it was invented in 2009. But the creation of peer-to-peer money was also the invention of an entirely novel approach to distributed computation for other purposes. A wide variety of uses are being explored to take advantage of features like guaranteed data availability, freedom from centralized control, or cryptographic tamper-proofing. 
     The current energy around distributed ledger adoption is reminiscent of early adoption of the Internet. The potential exists to either re-live or avoid the same missteps with respect to data management that weighed down web sites as they matured. Analogous to early websites, cryptocurrency uses of distributed ledgers featured relatively simple data structures and hard-coded business logic to govern them. However, the subsequent invention of smart contracts opened the door for data and rules of arbitrary complexity. 
     Enterprise use cases like supply chain logistics are putting information and logic on distributed ledgers in volumes that rival and will soon vastly outpace traditional solutions, but without the benefit of existing standardized data management tools. With every programmer designing her own storage, the result once again is data coupled tightly to the programs (smart contracts) that write it. A relational data management and organization system such as that described herein is needed to reduce this coupling. 
     Unfortunately, breaking that connection in distributed ledgers is more complicated than the situation faced when implementing relational databases. In its original fully decentralized form, distributed ledgers actually rely on the tight connection between logic and data to create consensus and trust among participants. All participants run the exact same logic, confirming that they receive the exact same outcomes. This leads to some major implications for the management of data on those distributed ledger platforms. For example, any portion of a data management system that affects the writing of data to a distributed ledger is positioned within and under the control of the smart contracts governing the data, essentially making it a part of the smart contract itself. Also, as a part of the smart contract, the data is propagated to all participants in the network so that the participants may run the same data-creation logic. 
     However, this coupling between logic and data does not make the advantages of the relational model irrelevant, even for restrictive distributed ledger platforms. First, the same consensus mechanism that allows data to be updated by collective agreement may be configured so that participants may agree to upgrades or additions to existing smart contracts. However, if those contracts cannot read and use existing distributed ledger data, they will not be useful. Smart contracts generally cannot do that today and, as a result, such upgrades are not commonly seen in production distributed ledger systems, despite their usefulness. 
     Even within individual smart contract programs, a consistent approach to storage is increasingly important as the contracts increase in scope and complexity. The relatively simple rules of today&#39;s electronic currencies and tradable assets are giving way to fully-distributed ledger-based supply chains and social platforms involving many developers, reusable components, and evolving requirements. Those developers will desire a predictable approach to data storage, just as they do with large traditional programs, and the relational model provides that predictable approach. 
     The usefulness of the relational model is even greater for pure read operations because they are not governed by consensus, other than for access permission to the data itself in some platforms. This leads to more situations where it is worth the effort to use existing data for new reasons. If data on the distributed ledger is stored according to relational rules, then it may be efficiently read and processed by an RDBMS system running either inside or outside of the distributed ledger, for purposes that go beyond what was envisioned by the original smart contract programmers. 
     Not every implementation of distributed ledger technology takes advantage of every distributed ledger technology feature or is forced to assume the level of mutual mistrust one sees in public networks like cryptocurrencies. Especially in enterprise settings, partial adoption is actually more common for a variety of reasons. Common situations include the use of distributed ledger platforms as a convenient way to achieve features like cryptographic tamper proofing and data replication. Enterprises also implement a distributed ledger network under their full control, with relaxed consensus rules or a centralized front end, perhaps as a first step toward a more distributed application in the future. Also, consortia with high levels of trust set up distributed ledger networks together with strict smart contract enforcement for support staff but allow administrators and internal auditors to update distributed ledger data directly on their own authority. In each of these cases, there are times when distributed ledger data may be managed exactly like a traditional database for both read and write, much as it could for read-only operations. 
     Sample Embodiments 
     The relational data management and organization system described herein delivers the benefits discussed above and provides a set of specifications that may standardize implementations of the relational data management and organization system across different distributed ledger platforms and programming languages. The relational data management and organizations described herein also provides a subset of a standard dialect of SQL (Structured Query Language) for use in directing the management and organization of relational data for a distributed ledger. The relational data management and organization system described herein has further been designed for implementation across a variety of platforms and languages. In sample embodiments, the relational data management and organization system is implemented on the Hyperledger® Fabric distributed ledger network and Node.js® programming language, with mechanisms to support user programs written in Node.js®. However, it will be appreciated that other distributed ledger platforms and programming languages may be used, with the attendant advantages and disadvantages of such platforms and languages. 
     The description of the relational data management and organization system will begin with a set of specifications, interfaces, and core components that are intended to guide all implementations.  FIG.  1    is a block diagram of the relational data management and organization system  100  of sample embodiments. Parts of the relational data management and organization system  100  illustrated in  FIG.  1    are common to all implementations, while other parts are customized but follow a set of common specifications.  FIG.  1    is an adapted component diagram showing these components and specifications. Throughout this description, relational data management and organization system  100  is also referred to as “ELEMENT” for ease of description. 
     The common specifications are represented as object elements with the «specification» stereotype to indicate conceptual requirements. Specifications are aspects that are expected to be implemented in a common way among all implementations of the relational data management and organization system. The «abstract» stereotype represents actual software components that are required to be present but will be implemented differently in each realization. The interfaces shown are also specifications in common for all implementations. 
     The Language Specific Software Development Kit (SDK) components  102  integrate with user applications and relay commands to the relational data management and organization system (ELEMENT) API  104 . The Language Specific SDK specification  102  aims to create a common experience across different user programming languages. Among the supported commands is a subset of SQL, which is specified herein as ELEMENT SQL  105 . Along with all other calls from the Language Specific SDK  102  and inputs from the ELEMENT user interface (UI)  106 , the received commands are parsed, validated, and handled by the ELEMENT Console  108 , which has a dependency on the ELEMENT Data Definition Language (DDL) Parser  110 . The ELEMENT UI  106  handles direct human interactions for administrative and reporting tasks. ELEMENT UI  106  is a graphical web platform that assists the user to construct valid input queries and represents system responses in an organized format. 
     In sample embodiments, only DDL operations are handled by the ELEMENT Console  108  via the ELEMENT DDL Parser  110 . Data Manipulation Language (DML) operations are passed along to the Distributed-Ledger-Platform-Specific Components  112  over the Service Layer Interface  114  and are parsed by the ELEMENT SQL DML Parser  116  for handling by the Distributed-Ledger-Platform-Specific Components  112 . Functionality not described above is realized by a series of Distributed-Ledger-Platform-Specific Components  112 . The Service Layer Interface  114  acts as a link between the ELEMENT Console  108  and the Distributed-Ledger-Platform-Specific Service Layer  118  that is the entry-point to these components and their functionality. The Service Layer Interface  114  is involved in all actions with the possible exception of operations initiated by users&#39; smart contracts. 
     The Distributed-Ledger-Platform-Specific Service Layer  118  forms the major operational logic of the relational data management and organization system  100  and is responsible for accomplishing all user and data management operations. Such operations are split between the Distributed-Ledger-Platform-Specific Service Layer  118  itself and the Distributed-Ledger Platform with Added ELEMENT Features  120 . The exact division of work depends on the capabilities of the distributed ledger platform. The functionality is provided by three sub-specifications:
         1. The Relational Data Access Control specification  122  specifies the five-level coarse grained access control model that is followed by all implementations of the relational data management and organization system  100 . This specification documents user roles and how they affect access to system functionality of the relational data management and organization system  100  including access to data. Access control will use significantly different approaches on different platforms. The specification is Appendix B documents the aspects in common.   2. The Relational Data On Distributed Ledger specification  124  defines requirements for data representations (JSON schemas) and data operations that are supported. This specification documents the requirements for relational data storage in Appendix C.   3. Smart Contract Integration specification  126  specifies which relational data features are accessible from smart contracts.       

     The Language-Specific SDKs  102  each provide interfaces to access the full functionality of the ELEMENT API  104  from a programming language popular with distributed ledger application implementers. The specification for these SDKs maximizes consistency with respect to function names, parameter ordering and meaning, return values and errors, and so forth. A realization implemented using Fabric and Node.js® is described below. 
     In sample embodiments, the ELEMENT API  104  is an interface used internally within the relational data management and organization system  100  as a common entry point for invoking database operations. It is called by both the ELEMENT UI  106  and whatever Language-Specific SDK  102  exists in the realization being used. It is specified in the form of a web interface, sometimes referred to as a “REST API.” The ELEMENT API  104  is implemented by the ELEMENTDB_Console  108  and reused in all realizations of the relational data management and organization system  100 . Further details of the ELEMENT API  104  are provided in APPENDIX D. 
     The ELEMENT UI  106  is a user interface component that allows users to work manually with databases implemented by the relational data management and organization system  100 . The ELEMENT UI  106  provides users the capability to add users and to adjust user access levels, execute SQL queries on the available databases using a built-in text editor, access user documentation including query examples and syntax of ELEMENT-specific SQL language extensions, and view status information of submitted queries and view returned data from queries whose execution has completed successfully. 
     The ELEMENT console  108  and ELEMENT SQL DDL Parser  110  are core components that are present in all realizations of the relational data management and organization system  100 . The ELEMENT console  108  accepts database commands via the ELEMENT API  104  (which may be a representational state transfer (REST) API), originating from the Language Specific SDK  102  or directly from users via the ELEMENT UI  106 , which the ELEMENT console  108  also serves. The ELEMENT console  108  converts those commands to a form that may be passed to the Service Layer Interface  114  that links to the Distributed-Ledger-Platform-Specific Components  112  of the relational data management and organization system  100 . 
     In sample embodiments, the common components of the relational data management and organization system  100  ( 104 ,  106 ,  108 ,  110 ) are implemented in Node.js® as a web service, which allows for deployment flexibility and horizontal scaling if needed. 
     ELEMENT SQL  105 , which comprises typical SQL operations along with some ELEMENT-specific extensions, is a grammar for describing RDBMS operations in the manner most familiar to developers. In sample embodiments, SQL syntax for the relational data management and organization system  100  was designed for compatibility with a subset of ISO/IEC 9075 (currently SQL:2016). For sake of access management and implementation, operations in ELEMENT SQL have been classified into DDL, DML Write and DML Read queries. 
     ELEMENT extensions to SQL include adaptations for working in a distributed ledger data environment as well as convenience functions. These extensions are ELEMENT specific keywords that may be used in combination with SQL syntax to form meaningful queries for the ELEMENT system. The extension keywords in sample embodiments include:
         1. OPSTAT (Operation Broadcast Status)—This operation checks whether a particular operation&#39;s transaction has progressed into the distributed ledger to an extent relevant to the particular distributed ledger platform employed. OPSTAT for DDL operations is set by default for the relational data management and organization system  100 ; however, OPSTAT may be added at the end of a DML Write operation to fetch a more definitive status of that transaction. There are 3 possible responses expected while OPSTAT is used—SUCCESS, FAILURE or TIMEOUT.   2. QUERYLEVEL—The QUERYLEVEL feature works exclusively with DML Read operations (e.g., SELECT) to fetch metadata information about a particular record of the relational data management and organization system  100 . There are two levels of information that may be obtained by using QUERYLEVEL—the first is basic information about a record and the second is a deeper query that provides granular information such as record creation date, last modified date, modified by user and other details.   3. BOOKMARK—This feature relates to the retrieval of table data in pages defined by record count in the relational data management and organization system  100 . By default, every query executed with a limit on row count is accompanied by a bookmark value which acts as a reference to the next equally sized page of data based on the same criteria. It will be included with query results if the BOOKMARK keyword is provided (applicable to SELECT queries only).   4. ELEMENT_COLUMN_DEFAULT—This keyword is used with the UPDATE or INSERT SQL operations to indicate that the default value should be used for a table column in the relational data management and organization system  100 . The default value may be assigned to a column while creating a table. Columns configured without a default value will not be impacted by this keyword. The ELEMENT SQL Specification in Appendix E below provides additional details of each of these keywords in combination with SQL syntax to form a variant of SQL syntax that may be used to represent queries and commands for processing by the relational data management and organization system  100 .       

     The Service Layer Interface  114  includes functionalities that are to be supported in every realization of the relational data management and organization system  100  for a distributed ledger platform. The specification for the Service Layer Interface  114  covers the entire interface plus the subset of functions that may be realized in either this service layer or on the distributed ledger platform itself. These functions include:
         Database creation and drop   Table creation, alter, and drop   Retrieval of database object metadata   DML operations, e.g., insert and select of records   Further DDL operations such as index creation, alter, and drop   User privilege management.
 
It is noted that modification and deletion in a distributed ledger context will always be done by the appending of changes or deletion indicators, because of the immutability of distributed ledger data history. The relational data management and organization system  100  is also required to provide bulk transaction support, covering at least record-level changes.
       

     In sample embodiments, the service layer interface  114  is implemented in Node.js® and reused regardless of the SDK language or distributed ledger platform targeted. Servicing of requests received via the interface is performed by distributed-ledger-specific components  112 ; with some functions realizable only on the distributed ledger platform itself, as required to achieve smart contract integration. 
     The Distributed Ledger Platform with added ELEMENT features specification  120  describes functionality that is to be implemented directly on the distributed ledger platform in order for the relational functionality to be usable by smart contracts on that platform. Like the platforms themselves, these implementations will differ greatly in approach. These specifications set out what will still be common, including a common JSON-based data format for the relational data and schemas. The specifications are split into three categories: relational data on distributed ledger, access control, and smart contract integration. 
     1. Relational Data On Distributed Ledger (RDODL) Specification 
     Five familiar abstractions are used in specifying relational data and related functionality in the relational data management and organization system  100 . They are: database, table, field, index, and record. There are significant differences in the way these concepts may be implemented for different distributed ledger platforms, but the following is true on every platform:
         1. Each instance of each of the five element types will be represented by a standalone JSON document in the standard ELEMENT format.   2. These documents are written to the distributed ledger using the same method and consensus as other distributed ledger transactions.   3. Each modification or change in state to one of these elements is represented by appending to the distributed ledger a complete, updated version of the JSON document.
 
JSON Schema definitions for the five objects and minimum requirements for indexing are formally specified in the design of the relational data management and organization system  100 .
       

     2. Relational Data Access Control Specification 
     Implementations of the relational data management and organization system  100  support a coarse-grained access control which is defined for individual distributed ledger identities at the database level. The privileges granted to the five access levels are as follows:
         SuperAdmin—Database management such as create and drop, plus all privileges of the Admin access level.   Admin—Access to privilege management functionality, plus all privileges of the DDL access level.   DDL—Access to functionality classified as DDL, which includes (for example) functions that change the schema of tables and indexes, plus all privileges of the DML Write access level.   DML Write—Access to functionality classified as DML Write, which includes data writes such as inserts, plus the privileges of the DML Read access level.   DML Read—Access to functionality classified as DML Read. Includes select queries of relational data, schema retrieval, viewing of statistics, and so forth.
 
Data Definition Language (DDL) refers to operations that change the structure, organization, or description of relational data. Data Manipulation Language (DML) refers to operations involving the relational data itself.
       

     Implementations of the relational data management and organization system  100  base access on the same identities as are used for distributed ledger operations, which enables smart contract integration, and for the requirement that relational data have distributed ledger characteristics equivalent to other data stored on the distributed ledger. 
     3. Smart Contract Integration Specification 
     As mentioned, a key aspect of the relational data management and organization system  100  is the ability to access most of the relational data functionality directly from smart contracts. For smart contract integration, the smart contracts have the ability to execute equivalent functions to those specified for the Language Specific SDK  102 , excluding DDL database operations. Distributed ledger considerations for these invocations, for example consensus and immutable recording of inputs and results, are equivalent to native smart contract execution. Also, invocation of these functions should conform to the form, naming, and semantics described in the Language Specific SDK  102  to the extent possible in the distributed ledger platform on which the relational data management and organization system  100  is being realized. DDL operations such as schema changes are excluded from smart contract integration because these operations often involve such extensive updates to relational storage that executing them within a single distributed ledger transaction would be unsupportable. 
     It will be appreciated that the Distributed Ledger Platform with added ELEMENT features specification  120  describes a set of common interfaces, syntax, and requirements that, no matter the implementation, enable relational data storage and operations on the distributed ledger using syntax and semantics already familiar to non-distributed-ledger programmers and that are identical across distributed ledger platforms, particularly the ability to use SQL syntax, which is common to all implementations of the relational data management and organization system  100 . The storage is implemented using a standardized JSON data format that eases future data portability across distributed ledger platform implementations. A set of required functionalities are standardized across platforms, so the choice of distributed ledger platform may be a separate concern from the decision to use an RDODL platform like the relational data management and organization system  100 . Such capabilities make possible relational data storage access that is consistent via the Language Specific SDK  102 , user console and API, or smart contracts. 
     Relational Data Management and Organization System  100  on Hyperledger® Fabric 
     In sample embodiments, a software development kit for Node.js® applications is provided that uses Hyperledger® Fabric for its distributed ledger platform. 
       FIG.  2    provides a visual outline of how the Fabric implementation realizes the specifications of the relational data management and organization system  100  described herein plus additional functionality. In sample embodiments, the RDODL realization of the relational data management and organization system  100  on Fabric involves the following aspects. The databases of the relational data management and organization system  100  make use of Fabric&#39;s “channel” concept. The Fabric Service Layer of the relational data management and organization system  100  uses the Fabric SDK (included with the distributed ledger platform) to create a Fabric channel each time a new database is requested. System chaincode, which includes functionality of the relational data management and organization system  100  is already present in the peer nodes and becomes accessible to the newly created channel. Channel creation also automatically sets up a new distributed ledger and “world state” database on all participating peer nodes. Also, the script initiates a transaction, invoking the system chaincode of the relational data management and organization system  100  to record high-level information about the database on the distributed ledger. All subsequent database write operations involve similar transactions and the appending of data objects to the distributed ledger in JSON formats pursuant to the RDODL specification. Each such append of database information to the ledger is also reflected by each peer in its world state database. This makes the current version of each data object quickly available for read operations. 
     In addition to the core components and specifications of the relational data management and organization system  100 ,  FIG.  2    is a block diagram of an implementation of the relational data management and organization system in a realization where Node.js® is the programming language and Hyperledger® Fabric is the distributed ledger platform used.  FIG.  2    focuses on how the Fabric/Node.js® implementation realizes the specifications outlined in  FIG.  1    along with some additional functionalities. 
     As illustrated in  FIG.  2   , Node.js® SDK component  200  realizes the user-language-specific functionality of the Language Specific SDK  102  and enables developers to interact with the relational data management and organization system  100  directly from their application code. Details of the version of the Node.js® SDK component  200  developed for use with Node.js® applications is provided in Appendix F. The ELEMENTDB Console  108 , ELEMENT API  104 , ELEMENT UI  106 , and Service Layer Interface  114  are common to all implementations, identical to  FIG.  1   . Below them, the ELEMENT FabricService  202  realizes the facade for all platform operations. ELEMENT FabricService  202  implements the Service Layer Interface  114  which acts as a middle man for interaction between the API layer and the distributed ledger. Its services help to perform RDBMS related operations as described in more detail in Appendix G. The realization of ELEMENT SQL parsing is realized by a component called Element_Parser  204  that appears twice in the Fabric realization. First, the Element_Parser  204  appears as a dependency of the ELEMENTDB Console  108  and realizes the DDL parser. This is common to all realizations. Second, the Element_Parser  204  appears as a dependency of the Element_Chaincode  206  and provides DML parsing, which makes DML SQL supportable in user chaincode smart contracts. The specification for the Element_Parser  204  is provided in Appendix H. 
     Supporting the FabricService  202  directly through its dependency on the Distributed Ledger Platform Plus ELEMENT Features specification are an identity provider (e.g., a Fabric Certificate Authority  208 ) to which users are registered and access privileges are recorded, and a world state database (e.g., the Fabric world state database  210 ) which is directly accessed for certain indexing capabilities, and the ELEMENT Fabric Peer Image  212 , a core component of Hyperledger® Fabric  214  that is customized for the relational data management and organization system  100 . 
     Element_Chaincode  206  is an additionally created system chaincode added to the ELEMENT Fabric Peer Image  212  that performs all database related operations on Fabric and also has dependencies on the identity provider (e.g., Certificate Authority  208 ) and world state database (e.g., Fabric world state database  210 ). Combined with the ledger storage in the peer itself, these empower the ELEMENT Fabric Peer  214  to realize relational data with access control. Also, since the user&#39;s smart contracts may call the system chaincode, this realizes Smart Contract Integration, as well. The specification for the Element_Chaincode  206  is provided in Appendix I. 
       FIG.  3    is a block diagram illustrating the activities, components and data involved in database creation for the relational data management and organization system  100 . Data-wise, database creation involves two Fabric transactions. The first is a “configuration transaction” that creates the channel and defines which peers will maintain a copy of the database. The second is a regular transaction which writes metadata about the relational database itself. 
       FIG.  3    is a combination of a unified modeling language (UML) Activity model illustrated on the left and a UML object diagram overlaid on the topology of the ELEMENT Fabric Service Layer  202  (on the right) and a deployed Fabric network that hosts these objects.  FIG.  3    illustrates the sequence of operations on the left side and the relevant data that exists during and immediately after the system is asked to create a new database in the relational data management and organization system  100  in Fabric on the right side. Creating a database makes use of Fabric&#39;s channel (distributed ledger data segregation) creation mechanism plus added functionality. 
     The blocks on the left half of  FIG.  3    are components relevant to database creation, i.e. Fabric Service  202  and Fabric Peer  214 . Three data objects are created by the service layer when initially processing a database creation request. As shown, a prepare Fabric channel configuration file activity  300  creates a «channel configuration file» channel.tx  302  for use by the network. A generate config transaction with the genesis block activity  304  creates a special Fabric transaction «fabric config tx»  306  that contains a genesis block and initiates the channel. A genesis block is the proposed first piece of data to be recorded to the distributed ledger, which contains its initial configuration. &lt;database_name&gt;.block is the genesis block itself. Both it and the channel are given names consistent with the name of the database of the relational data management and organization system  100 . A create channel and join authorized peer nodes to channel activity  308  creates channel configuration data  310  from «fabric config tx»  306 . The create channel and join authorized peer nodes to channel activity  308  also creates a ledger  313  that includes the genesis block  314  and a corresponding empty world state database  322 . A prepare Fabric transaction activity  312  containing data representations of attributes of the database of the relational data management and organization system  100  creates a Fabric distributed ledger transaction «fabric tx»  316  that contains a JSON object representing the relational schema and other attributes that will govern data to be stored in this database of the relational data management and organization system  100 . A submit Fabric transaction  318  with initial database schema incorporates the Fabric distributed ledger transaction «fabric tx»  316  into a Fabric block  320 . Finally, the Fabric Peer  214  automatically updates the world state database  322  with attributes of the database of the relational data management and organization system  100  at  324 . 
     Channels are boundaries within which data is shared in a Fabric distributed ledger network. A peer node outside the area  326  does not receive schema information or data. The network connections between the nodes are also shown. They include the normal interconnects between Fabric nodes, plus an HTTPS path  328  through which the Fabric SDK library (not shown) within the Fabric Service layer contacts a peer node. It is noted that the Fabric SDK is a component supplied by Hyperledger® Fabric and is included as a dependency in the Fabric Service of the relational data management and organization system  100  that allows client programs to initiate basic distributed ledger operations on the Fabric platform. 
     The full process by which channels are created and transactions processed in a Fabric network is not modeled, but the above objects are communicated to the network during those steps, and the remaining objects are created. First, when the channel is created, three items are obtained that are normal in Fabric for that process:
         1. channel configuration from config.tx—The ordering service retains information from the channel configuration file using it to ensure channel data is restricted to participating nodes, among other things.   2. «ledger»&lt;database_name&gt;—Append-only data storage for the channel/database is created and replicated to every participating peer node.   3. «world state»&lt;database_name&gt;—Companion storage to the ledger that contains only the latest value for each item in the ledger is provided in a form that is much more efficiently queried. In the relational data management and organization system  100 , this database could be a CouchDB® instance, which is one of the standard choices for Fabric.
 
After the channel is created, a normal Fabric transaction is processed containing the JSON representation of the database schema (relational data attributes).
       

     Subsequent relational database operations are represented as a JSON object in further appended Fabric transactions (with the exception of read queries for which committing to the ledger was explicitly excluded).  FIG.  4    illustrates the execution of DML write operations. This process creates JSON relational data objects that, once brought into the world state database, may be used by the system chaincode of the relational data layer  100  to respond to queries and other requests.  FIG.  5    shows this, depicting the execution of DML read queries requested by the ELEMENT UI  106  or by a user&#39;s application via the Language Specific SDK  102  and ELEMENT API  104 . 
       FIG.  4    is a block diagram illustrating an operation to write relational data to an existing database of the relational data management and organization system  100 . Swimlanes on the left represent two participating components, FabricService and the System Chaincode of the relational data management and organization system  100 . UML Activities inside each swimlane represent the key activities they perform. Bold arrows connect the activities in order, and additional arrows connect to the data object affected by the activity. 
     Walking through an update operation, the «ledger»&lt;database_name&gt;object  400  within the Fabric Peer node  402  in the defined channel is the same ledger created in  FIG.  3    that may be replicated in each peer node. An additional «fabric block»  404  has been appended within it which contains a «fabric transaction»  406  specifying a relational database operation. This specific operation would have been received from the user in an upstream process including the preparation of a Fabric transaction  408  containing a desired operation that creates the «fabric tx» and submits the Fabric transaction containing the operation to a peer node at  412  for execution of the transaction and the generation of the resulting data at  414  as illustrated under the Activities section located on the left half of  FIG.  4   . The transaction also contains the results of that operation, which would have been executed by System Chaincode of the relational data management and organization system  100  when the transaction was processed into a block. In some cases, this execution would also involve the chaincode reading data from the world state database. This flow is not shown but may be understood from the DML Read operation in  FIG.  5   . 
     The resulting ELEMENT relational data JSON  416  contains objects representing new or changed tables, records, users, and database attributes. Each of these has a unique key identifying the data affected. The Fabric network processes the transaction and the resulting data into a Fabric block at  418  and appends the Fabric block to the ledger  400 . In addition to being recorded permanently in the ledger  400  as part of the transaction, the system chaincode updates the world state database  420  with the currently relational data at  422 , where the data flows to the oworld state» database  420 , the same world state database as was created in  FIG.  3   . There, older entries with the same key are overwritten, with the relational data as the world state database contains just the current state of the database of the relational data management and organization system  100 , while the ledger  400  preserves its history. One such object  424  is shown within the world state database  420 , but in practice there will be many keys and objects. 
       FIG.  5    has a similar premise as  FIG.  4   , with all the components and data objects remaining unchanged. The only difference is the Activities and processes that the data objects go through while processing a DML read operation. The Activities section in the Fabric Service component is fairly similar to  FIG.  4    except that the service layer receives a query response at  500  after DML Read operation is executed successfully. 
     In sample embodiments, the system chaincode executes a query at  502  against the world state database instance  504  with relevant ELEMENT data JSON flowing in return. The system chaincode further processes this data to produce a query result  500  back to the initiator of the query. The read happens on the world state data, so subsequently there is no modifications made on the world state like the update scenario. The DML Read does not access the peer ledger  400 . However, the Fabric transaction is logged on the ledger of the peer node upon which the transaction is conducted to keep a record of the operation, unless the default “OPSTAT” option is overridden. If the “OPSTAT” option was selected at  506 , the Fabric network processes the transaction into a block and appends the block to the ledger  400 . The memorialized transaction contains the input, which is the JSON representing the query but not the resulting records. 
     DML Read operations that are initiated from user chaincode (smart contracts) operate similarly to  FIG.  5   , except that the query result is returned directly to the smart contract for its further processing. 
     In order to realize the five required levels of database access permissions, two Fabric mechanisms are re-used. First, since database creation requires the prerequisite power to create Fabric channels, only the Fabric network administrator is eligible for that permission. For the remaining four access levels, ELEMENT Fabric piggybacks on top of Fabric&#39;s existing identity provider functionality. The ELEMENT Fabric relational data access control realization on Fabric thus involves database specific attributes that are appended to every user while registering it to the identity provider. Also, attributes adjoined to the user&#39;s registration pertain to its specific access for that database. Subsequently, a transaction to the ELEMENT system chaincode may be initiated to add the user to the database metadata. 
       FIG.  6    is a block diagram illustrating the components and data involved in the first part of relational data access control for the addition of users for access below the super-admin level. The control process involves two steps. The first is enrolling a user with database specific attributes in an identity provider such as a Fabric Certificate Authority by preparing a Fabric transaction memorializing the add user operation at  600  to create the add user operation  602 . The second is a regular transaction which adds the user to the database itself by using the authority of the requesting entity to append a JSON representation  604  of the new user access level to the user&#39;s identity card in the identity provider  606  at  608 . 
     Like  FIG.  3   ,  FIG.  6    is a UML object model laid over the topology of an executing ELEMENT Fabric Service Layer and relevant Fabric network. The UML object models the Fabric Service component and related sequential Activities mentioned on the left section of the model and representation of associated data on the right, for adding a user to the relational data management and organization system  100 . The model explanations and operational premises from  FIG.  3    apply here, with the notable addition of an identity provider such as the Fabric Certificate Authority node  606 , although, only the affected sections are displayed in the model. The UML model connects with the service layer, Fabric peer node and ordering service nodes, serving them information about distributed ledger identities. The ordering service and its connections are not shown in this model as they have no special role in this process, beyond what is usual in Fabric transaction processing. It is noted that the Ordering Service node and identity provider (e.g. Certificate Authority) are at the same time likely to be serving other peer nodes, channels, and perhaps databases of the relational data management and organization system  100 . 
     The data objects in  FIG.  6    are created during the addition of a new user to one ELEMENT database. The addition of a user is built atop Fabric&#39;s existing identity management, similar to how the database itself is built on a Fabric channel and its ledger. In fact, the highest level of access, Super Admin is an exact reuse of Fabric&#39;s administrator role.  FIG.  6    relates to adding a user with one of the four lower ELEMENT access levels. The model may be divided into three parts in the rough order of their involvement in the process: 
     1. ELEMENT Fabric Service Layer Node 
     2. Identity Provider Node, e.g., Certificate Provider (CA) 
     3. Element Fabric Peer Nodes and Ordering Service Nodes 
     The initial part of the process involves the first two of these: the ELEMENT Fabric Service Layer arranges for the identity provider (e.g., Fabric Certificate Authority  606 ) to enroll a user identity or to locate the relevant identity if it already exists, and to add ELEMENT privilege attributes to that identity. Note that it is possible but not shown that multiple identity provider nodes may be supporting a given channel and its ELEMENT database. In this case, the process is essentially the same except for specifying which authority is involved. 
     The «User» object  604  is the representation of that identity in the identity provider (e.g., Certificate Authority  606 ), sometimes called an “identity card.” It is extensible with custom attributes, and the relation data management and organization system  100  takes advantage of this by adding an attribute that represents the identity&#39;s access privilege level to an ELEMENT database. The attribute takes the form of a JSON object labeled user access-level attributes  604  in the model. 
     The other part of the process is a corresponding Fabric transaction  610  to log the access level change in the distributed ledger  612 . This transaction  610  is prepared in the service layer (the «fabric tx»  614  containing the add user operation JSON) and added to the «ledger»  612  in a process that first passes it through one peer node, then the ordering service, and finally back to all of the peer nodes as part of a block which is appended to the ledger  612  at  616 . 
     The ledger  612  is the same as was illustrated in  FIGS.  3 - 5   . The model focuses on the new «fabric block» containing the add user operation JSON  614 , but that block  614  would actually be appended after the genesis and configuration blocks (excluded in this model) of  FIG.  3    and any number of blocks for relational operations as illustrated in  FIG.  4    and  FIG.  5   . 
     After user access levels are defined, the distributed-ledger-specific components read them during each relational database operation to determine if the operation is authorized. The relational database operations occur in two steps. The identity is verified by an identity provider, and the access level is checked. Access is granted for the corresponding function only if the invoking user&#39;s access level is found to be appropriate to invoke the function, following which the actual function is executed as described above with respect to  FIG.  3   . 
     Achieving the required integration with user smart contracts is straightforward in the Fabric realization. User chaincode is able to call ELEMENT system chaincode directly, which gives access to all the DML features except the bulk operations. 
     However, the default Fabric setup does not allow system chaincode plugins. The primary change involves rebuilding the Fabric peer with a build tag that allows ELEMENT system chaincode to be deployed. After this the peer&#39;s base configuration file requires modification in the path to the compiled ELEMENT system chaincode binary. This allows Fabric peer(s) to read and start the ELEMENT system chaincode upon restart. 
     The Fabric-specific service layer accepts database commands from the common Console/Parser/API component and translates them to action by invoking a combination of the ELEMENT system chaincode, an identity provider such as a Fabric Certificate Authority, and a world state database as described above. 
     The ELEMENT Node.js® SDK primarily includes wrapper functions for calling the common Console/Parser/API component from a developer&#39;s Node.js® application. Specifically, the ELEMENT Node.js® SDK provides wrapper functions to create a connection with the relational data management and organization system  100 , perform DDL operations to define tables and indexes, perform DML operations for data writing and querying, and add a custom smart contract to the channel. 
       FIG.  7    is a block diagram illustrating the interaction of the ELEMENT Fabric-Node.js® SDK with a user&#39;s application  702  and the execution environment in which they are both hosted, which is modeled as the User Application Node  700 . This node  700  covers a broad range of potential implementations, constrained by required support for Node.js® and the ability to be configured to communicate over HTTPS with a running instance of the ELEMENT Console  108  via its REST ELEMENT API  104  as shown. 
     Drilling down into the User Application Node  700  in  FIG.  7   , the User Application  702  in Node.js® is modeled as a component with a dependency on the Fabric/Node.js® ELEMENT SDK  704 , which is also installed. Node.js® Wrapper Function Interfaces  706  define the functions directly available to the user&#39;s application code  702 . These interfaces  706  conform generally to the Language Specific SDK «specification»  102  described with respect to  FIG.  1   . However, they go beyond the specification in a few ways, supporting some additional Fabric-specific features. This is reflected in the modeling by the inclusion of “Fabric” in the SDK&#39;s name. Code in ELEMENT_SDK  704  implements that interface, translating SDK function calls into calls to the ELEMENT API  104 . 
     Beyond the functions required by the ELEMENT specifications, the Fabric/Node.js® realization also includes the abilities to deploy smart contracts (user chaincode) via the ELEMENTDB Console  108  or Language Specific SDK  102  and to maintain physical separation (in the physical versus logical sense) between created databases. 
     It will be appreciated that the Fabric/Node.js® embodiment provides relational data on a distributed ledger with physical separation between databases as well as a relational data implementation on Fabric that maximizes the reuse of built-in properties of the Fabric platform, thus improving performance and reducing the possibility that platform changes will introduce breaking changes. A programmer-friendly SDK also unifies the structuring of relational data on distributed ledger with the deployment of smart contracts that use that data. 
     It will be appreciated by those skilled in the art that the full ANSI SQL language specification is not supported, nor are stored procedures per se. However, user chaincode provides similar ability to couple logic and relational data if desired). By way of example,  FIG.  8    and  FIG.  9    illustrate use of the relational data management and organization system  100  to implement SQL DML write and read operations. Those skilled in the art will appreciate that the techniques described herein may also be used to implement other SQL activities for interaction with data stored in databases implemented on the distributed ledger as described herein. 
       FIG.  8    is a logical flow diagram of an example of a successful SQL DML write operation to a distributed ledger using the relational data management and organization system in sample embodiments. As illustrated, the SQL query may be received by the relational data management and organization system  100  in at least three ways: the user may input an SQL query into ELEMENT UI  106  at  800 ; a user application may pass an SQL query via the ELEMENT SDK  200  at  802 ; or a smart contract may execute an SQL query at  804 . The received SQL query is parsed into a DML write operation at  806 . The relational data management and organization system  100  then creates a JSON representation of the SQL operation and incorporates JSON representations of any included relational data at  808 . The JSON representation (ELEMENT SQL) is then processed by Fabric/Node.js® operations that preserve the distributed ledger&#39;s identity, privacy, and consensus provisions. Such operations include confirming that the invoking identity has at least DML write authority at  810 . The relational data management and organization system  100  then retrieves data from the distributed ledger platform as required to execute the relational operation at  812  and executes the operation and prepares JSON representations of the resulting new or changed records at  814 . The operation and updated records are committed to the distributed ledger platform in a form appropriate to the distributed ledger platform at  816  in order to preserve records of any changes. The distributed ledger platform then incorporates the operation and data into its distributed ledger at  818 . Also, if requested, the relational data management and organization system  100  monitors the distributed ledger network for progress of the operation into acceptance by the distributed ledger at  820 . Finally, the relational data management and organization system  100  informs the caller (UI  106 , user application  200 , or user smart contract) of the success of the operation at  822 . This process may be repeated for each new SQL DML write operation. 
     On the other hand,  FIG.  9    is a logical flow diagram of an example of a successful SQL DML read operation from a distributed ledger using the relational data management and organization system  100  in sample embodiments. As illustrated, the SQL query may be received by the relational data management and organization system  100  in at least three ways: the user may input an SQL query into ELEMENT UI  106  at  900 ; a user application may pass an SQL query via the ELEMENT SDK  200  at  902 ; or a smart contract may execute an SQL query at  904 . The received SQL query is parsed into a DML read operation at  906 . The relational data management and organization system  100  then creates a JSON representation of the SQL operation at  908 . The JSON representation (ELEMENT SQL) is then processed by Fabric/Node.js® operations that preserve the distributed ledger&#39;s identity, privacy, and consensus provisions. Such operations include confirming that the invoking identity has at least DML read authority at  910 . The relational data management and organization system  100  then retrieves data from the distributed ledger platform as required to execute the read operation at  912  and executes the operation requested and creates JSON representations of the query result at  914 . Unless intentionally suppressed, the relational data management and organization system  100  logs the JSON representation of the operation to the distributed ledger platform in a form appropriate to the distributed ledger platform at  916  in order to preserve records. The distributed ledger platform then incorporates the log of the operation into its distributed ledger at  918 . Finally, the relational data management and organization system  100  returns the JSON representation of the query result to the caller (UI  106 , user application  200 , or user smart contract) at  920 . This process may be repeated for each new SQL DML read operation. 
       FIG.  10    is a block diagram illustrating the successful execution of Data Definition Language (DDL) writes in the Fabric realization. Such operations modify or extend the schema of an existing relational data management and organization system database. The swimlanes on the left portion of the diagram represent components responsible for DDL operations. Activities within each lane are specific to the marked component and describe the component&#39;s possible contribution to the process. Like previous figures, the flow of the process is denoted by bold arrows between steps which may be causally connected. Additionally, regular arrows connect the activities to the data objects they may create or modify, which are depicted in the object model (denoted by Data) on the right. 
     DML Write operations may be identified and handled by the ELEMENTDB_Console  108 . For example, the ELEMENTDB_Console  108  may receive an SQL command and identify it as DDL at  1000 . Handling of the SQL command may include parsing by the Element SQL DDL parser  110  at  1002  to convert the SQL description of the operation to a form that may be processed and represented on the distributed ledger platform. The converted form may be further processed by a FabricService component at  1004  into a Fabric transaction containing the desired operation including an updated JSON representation of database attributes (schema)  1005  that may exist as data within a deployed Fabric Service Layer. The FabricService component may also cause the resulting Fabric transaction to be submitted over a network connection to a Fabric Peer Node in the channel associated with the relational data management and organization system database at  1006 . Normal processing by the Fabric network would then incorporate that transaction into a block and append that block to previous ones  1007  in the ledger  1020  for that channel. It is implicit in such appending that the block will be identically appended to other Peer Nodes in the channel. Because the changed relational data attributes may be represented as a piece key-value-pair distributed ledger data, Fabric&#39;s System Chaincode may subsequently update the world state database entry at  1008 , for with this more recent relational database attributes, overwriting the prior attributes which would have been stored under the same key. In cases where there are index changes indicated by the DDL operation, the relational management and organization system may effect them in practice by direct modification of the world state database&#39;s indexing, for example a CouchDB® instance&#39;s index collection  1030  at  1010 . The index collection  1030  contains the indexes that have been defined for the relational data management and organization system database upon which the operation is being executed. These changes may be requested by the FabricService, received by the world state database&#39;s indexing implementation, and subsequently applied to the «world state» database at  1012 , causing the application of the updated indexing to subsequent query operations involving the world state database. 
     Computer Embodiment 
       FIG.  11    is a block diagram of a typical, general-purpose computer  1100  that may be programmed into a special purpose computer suitable for implementing one or more embodiments of the relational data management and organization system  100  disclosed herein. The relational data management and organization system  100  described above may be implemented on any general-purpose processing component, such as a computer with sufficient processing power, memory resources, and communications throughput capability to handle the necessary workload placed upon it. The computer  1100  includes a processor  1102  (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage  1104 , read only memory (ROM)  1106 , random access memory (RAM)  1108 , input/output (I/O) devices  1110 , and network connectivity devices  1112 . The processor  1102  may be implemented as one or more CPU chips or may be part of one or more application specific integrated circuits (ASICs). 
     The secondary storage  1104  is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM  1108  is not large enough to hold all working data. Secondary storage  1104  may be used to store programs that are loaded into RAM  1108  when such programs are selected for execution. The ROM  1106  is used to store instructions and perhaps data that are read during program execution. ROM  1106  is a non-volatile memory device that typically has a small memory capacity relative to the larger memory capacity of secondary storage  1104 . The RAM  1108  is used to store volatile data and perhaps to store instructions. Access to both ROM  1106  and RAM  1108  is typically faster than to secondary storage  1104 . 
     The devices described herein may be configured to include computer-readable non-transitory media storing computer readable instructions and one or more processors coupled to the memory, and when executing the computer readable instructions configure the computer  1100  to perform method steps and operations described above with reference to  FIG.  1    to  FIG.  10   . The computer-readable non-transitory media includes all types of computer readable media, including magnetic storage media, optical storage media, flash media and solid-state storage media. 
     It should be further understood that software including one or more computer-executable instructions that facilitate processing and operations as described above with reference to any one or all of steps of the disclosure may be installed in and sold with one or more servers and/or one or more routers and/or one or more devices within consumer and/or producer domains consistent with the disclosure. Alternatively, the software may be obtained and loaded into one or more servers and/or one or more routers and/or one or more devices within consumer and/or producer domains consistent with the disclosure, including obtaining the software through physical medium or distribution system, including, for example, from a server owned by the software creator or from a server not owned but used by the software creator. The software may be stored on a server for distribution over the Internet, for example. 
     Also, it will be understood by one skilled in the art that this disclosure is not limited in its application to the details of construction and the arrangement of components set forth in the description or illustrated in the drawings. The embodiments herein are capable of other embodiments, and capable of being practiced or carried out in various ways. Also, it will be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” or “having” and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless limited otherwise, the terms “connected,” “coupled,” and “mounted,” and variations thereof herein are used broadly and encompass direct and indirect connections, couplings, and mountings. In addition, the terms “connected” and “coupled” and variations thereof are not restricted to physical or mechanical connections or couplings. Further, terms such as up, down, bottom, and top are relative, and are employed to aid illustration, but are not limiting. 
     The components of the illustrative devices, systems and methods employed in accordance with the illustrated embodiments may be implemented, at least in part, in digital electronic circuitry, analog electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. These components may be implemented, for example, as a computer program product such as a computer program, program code or computer instructions tangibly embodied in an information carrier, or in a machine-readable storage device, for execution by, or to control the operation of, data processing apparatus such as a programmable processor, a computer, or multiple computers. 
     A computer program may be written in any form of programming language, including compiled or interpreted languages, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program may be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network. Also, functional programs, codes, and code segments for accomplishing the techniques described herein may be easily construed as within the scope of the present disclosure by programmers skilled in the art. Method steps associated with the illustrative embodiments may be performed by one or more programmable processors executing a computer program, code or instructions to perform functions (e.g., by operating on input data and/or generating an output). Method steps may also be performed by, and apparatus may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit), for example. 
     The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP), an ASIC, a FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. 
     Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random-access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example, semiconductor memory devices, e.g., electrically programmable read-only memory or ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory devices, and data storage disks (e.g., magnetic disks, internal hard disks, or removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks). The processor and the memory may be supplemented by or incorporated in special purpose logic circuitry. 
     Those of skill in the art understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof. 
     Those of skill in the art further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure. A software module may reside in random access memory (RAM), flash memory, ROM, EPROM, EEPROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor may read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. In other words, the processor and the storage medium may reside in an integrated circuit or be implemented as discrete components. 
     As used herein, “machine-readable medium” means a device able to store instructions and data temporarily or permanently and may include, but is not limited to, random-access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, other types of storage (e.g., Erasable Programmable Read-Only Memory (EEPROM)), and/or any suitable combination thereof. The term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store processor instructions. The term “machine-readable medium” shall also be taken to include any medium, or combination of multiple media, that is capable of storing instructions for execution by one or more processors, such that the instructions, when executed by one or more processors cause the one or more processors to perform any one or more of the methodologies described herein. Accordingly, a “machine-readable medium” refers to a single storage apparatus or device, as well as “cloud-based” storage systems or storage networks that include multiple storage apparatus or devices. The term “machine-readable medium” as used herein excludes signals per se. 
     The above-presented description and figures are intended by way of example only and are not intended to limit the illustrative embodiments in any way except as set forth in the appended claims. It is noted that various technical aspects of the various elements of the various exemplary embodiments that have been described above may be combined in numerous other ways, all of which are considered to be within the scope of the disclosure. 
     Accordingly, although exemplary embodiments have been disclosed for illustrative purposes, those skilled in the art will appreciate that various modifications, additions, and substitutions are possible. Therefore, the disclosure is not limited to the above-described embodiments but may be modified within the scope of appended claims, along with their full scope of equivalents.