System or method for implementing the right to be forgotten on a metadata-driven blockchain using secret sharing and consensus on reads

Abstract

A method for providing the right to forget data in a blockchain, executed by a system organized by a host organization, the system providing a blockchain interface to a blockchain on behalf of multiple tenants of the host organization, each tenant acting as a node in the blockchain network. The method includes: receiving a request including a requester identifier, the request to access transaction data designated as private; requesting access to transaction data including the requester identifier from a node in the blockchain network; receiving at least one shared secret from a node in the blockchain network, the shared secret indicating a consensus for the requester to access the transaction data; and denying access to the transaction data in response to receiving insufficient shared secrets from the nodes indicating that the transaction data is permanently inaccessible.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the priority of U.S. Application No. 16 / 667,846, filed on October 29, 2019, which claims the benefit of U.S. Provisional Application No. 62 / 851,589, filed on May 22, 2019, and both applications are incorporated herein by reference. Technical Field

[0003] The embodiments disclosed herein generally relate to the field of distributed ledger technology and blockchain platforms. More specifically, the disclosed embodiments relate to systems, methods, and devices for implementing access restrictions related to reading data from a blockchain using distributed ledger technology (DLT) in a metadata - driven blockchain platform in conjunction with a cloud computing environment. Background Art

[0004] A blockchain is a continuously growing list of records / blocks that are linked and secured using cryptographic techniques. In particular, each block of the blockchain can include the cryptographic hash of the immediately preceding block, a timestamp of the current block, and transaction data (e.g., addition / modification of information associated with peers in the blockchain network). Additionally, the blockchain can be shared and managed via a peer - to - peer network by a system that verifies / confirms new blocks to be added to the chain, such that a block in the blockchain cannot be changed without changing all subsequent blocks, which requires network consensus. This architecture allows for securing the information stored in the blocks using cryptographic techniques; sharing / distributing information using a peer - to - peer network; trusting through the consensus of block addition; and immutability of the information stored within the blocks (e.g., each peer in the blockchain network can maintain a ledger of all verified / confirmed transactions in the network) through the use of cryptography, linking / concatenation of blocks, and peer distribution. A blockchain can be used to store many different types of data, including financial data. Such financial data can be stored in a blockchain that serves as a distributed ledger.

[0005] The distributed ledger of a blockchain is shared by all participants of that blockchain. Distributed ledger technology (DLT) helps to address and overcome many types of drawbacks of traditional financial systems; however, the technology can still be extended to introduce more benefits to those who utilize such DLT and related blockchain platforms. Currently available DLT and blockchains that utilize such DLT technology store data in a fixed, immutable, and static manner. Thus, once data is written to the blockchain, it is fixed there, completely without context, metadata, or any other information that describes the stored data, describes the shape of the data, or describes the type of the data. Therefore, it can be very difficult to convert the data retrieved from the blockchain back into a format acceptable for business objectives due to the lack of context of other metadata that describes the stored data.

[0006] In addition, currently available DLTs and blockchains that utilize such DLT technologies require any record on the blockchain to be updated or modified such that it is entirely rewritten onto the blockchain, resulting in a significant increase in the total amount of data stored on the blockchain, which may be unsustainable and at least resource-intensive. Other envisioned methods only write the modified portion of the record onto the blockchain, which results in inefficient data retrieval because the complete record is now split across multiple blocks of the blockchain and thus any retrieval of the modified record requires searching, checking, and retrieving data from multiple blocks of the blockchain.

[0007] In addition, currently available DLTs and blockchains store data on the blockchain such that any node in the network can access it. Data on the blockchain is never deleted. Due to these characteristics, DLTs and blockchains are not suitable for applications that require permanent deletion of data or require restricted access rights to data stored on the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The following drawings use the same reference numerals to refer to the same elements. Although the following drawings depict various exemplary embodiments, alternative embodiments are within the spirit and scope of the appended claims. In the figures:

[0009] Figure 1A An exemplary architecture in accordance with the described embodiments is depicted;

[0010] Figure 1B Another exemplary architecture in accordance with the described embodiments is depicted, with additional details of the blockchain protocol block operating in conjunction with a block validator;

[0011] Figure 1C Another exemplary architecture in accordance with the described embodiments is depicted, where additional details of the blockchain metadata definition manager are elaborated in more detail;

[0012] Figure 1D Another exemplary architecture in accordance with the described embodiments is depicted, which more particularly depicts the integration of the host organization service with the blockchain service interface;

[0013] Figure 1E Another exemplary architecture in accordance with the described embodiments is depicted, which depicts an exemplary data flow utilizing the blockchain service interface;

[0014] Figure 2A Another exemplary architecture in accordance with the described embodiments is depicted, with additional details of the blockchain and a forked blockchain;

[0015] Figure 2B Another exemplary architecture in accordance with the described embodiments with additional details of a side chain is depicted;

[0016] Figure 3A depicts an exemplary architecture according to the described embodiments;

[0017] Figure 3B depicts another exemplary architecture according to the described embodiments;

[0018] Figure 3C depicts another exemplary architecture according to the described embodiments;

[0019] Figure 3D depicts another exemplary architecture according to the described embodiments;

[0020] Figure 4A depicts another exemplary architecture according to the described embodiments, with additional details of smart contracts implemented on a blockchain created using a smart flow contract engine;

[0021] Figure 4B depicts another exemplary architecture according to the described embodiments, with additional details of smart contracts implemented on a blockchain created using an Apex transformation engine;

[0022] Figure 4C depicts another exemplary architecture according to the described embodiments, with additional details of an SQL filter and query transformer for persistent storage of records to a blockchain using an Apex transformation engine;

[0023] Figure 5A depicts another exemplary architecture according to the described embodiments;

[0024] Figure 5B depicts another exemplary architecture according to the described embodiments for performing dynamic metadata validation of stored data;

[0025] Figure 5C depicts another exemplary architecture according to the described embodiments for storing related entities;

[0026] Figure 6A depicts another exemplary architecture according to the described embodiments for obtaining stored records from addressable blocks using an indexing scheme;

[0027] Figure 6B depicts another exemplary architecture according to the described embodiments for building and maintaining an index from records in a blockchain;

[0028] Figure 6C depicts another exemplary architecture according to the described embodiments for forming an address for obtaining information from an index using an addressing structure;

[0029] Figure 6D depicts another exemplary architecture for obtaining information from an index using an address according to the described embodiments;

[0030] Figure 6E depicts another exemplary architecture for incrementally updating stored records of blockchain assets by using an index to store current updates according to the described embodiments;

[0031] Figure 7A depicts another exemplary architecture according to the described embodiments;

[0032] Figure 7B depicts another exemplary architecture according to the described embodiments;

[0033] Figure 7C depicts another exemplary architecture according to the described embodiments;

[0034] Figure 8A depicts another exemplary architecture according to the described embodiments;

[0035] Figure 8B depicts another exemplary architecture according to the described embodiments;

[0036] Figure 8C depicts another exemplary architecture according to the described embodiments;

[0037] Figure 8D depicts another exemplary architecture according to the described embodiments;

[0038] Figure 8E depicts another exemplary architecture according to the described embodiments;

[0039] Figure 8F depicts another exemplary architecture according to the described embodiments;

[0040] Figure 9A depicts another exemplary architecture according to the described embodiments;

[0041] Figure 9B depicts another exemplary architecture according to the described embodiments;

[0042] Figure 9C depicts another exemplary architecture according to the described embodiments;

[0043] Figure 10 is a flowchart of an embodiment of a process for reading consensus;

[0044] Figures 11A to 11C is a flowchart related to a set of processes for implementing the right to be forgotten within a blockchain service interface;

[0045] Figure 11D is a schematic diagram of an exemplary implementation of the European Union's General Data Protection Regulation (GDPR);

[0046] Figures 12A to 12C is a flowchart related to a set of processes for implementing an access control function within a blockchain service interface;

[0047] Figure 12D is a schematic diagram of an exemplary implementation of an access control process.

[0048] Figure 13 depicts a flowchart showing a method for implementing efficient storage and verification of data and metadata within a blockchain using distributed ledger technology (DLT) according to the described embodiments;

[0049] Figure 14 shows a diagram of a system in which the embodiments can be operated, installed, integrated, or configured according to the described embodiments;

[0050] Figure 15A depicts another exemplary architecture according to the described embodiments;

[0051] Figure 15B depicts another exemplary architecture according to the described embodiments;

[0052] Figure 15C depicts another exemplary architecture according to the described embodiments;

[0053] Figure 16 depicts a flowchart showing a method for implementing a declarative and metadata-driven blockchain platform using distributed ledger technology (DLT) in combination with a cloud-based computing environment according to the described embodiments;

[0054] Figure 17 depicts a flowchart showing a method for implementing a declarative, metadata-driven, cryptographically verifiable multi-network (multi-tenant) shared ledger in combination with a cloud-based computing environment according to the described embodiments;

[0055] Figure 18A shows a block diagram of an environment in which an on-demand database service can operate according to the described embodiments;

[0056] Figure 18B shows another block diagram of an embodiment of the Figure 10 elements according to the described embodiments and various possible interconnections between these elements; and

[0057] Figure 19 FIG. shows an illustration of a machine in the example form of a computer system according to some embodiments. DETAILED DESCRIPTION

[0058] Systems, methods, and apparatus are described herein for implementing access control and the right to be forgotten based on a consensus process for reads in a metadata-driven blockchain platform. In some embodiments, the metadata-driven blockchain platform uses distributed ledger technology (DLT) in conjunction with a cloud-based computing environment.

[0059] Figure 1A An exemplary architecture 100 is depicted in accordance with the described embodiments.

[0060] In one embodiment, a hosted computing environment 111 is communicatively coupled through a host organization 110 with a plurality of user client devices 106A-C (e.g., mobile devices, smartphones, tablets, PCs, etc.). In one embodiment, a database system 130 includes databases 155A and 155B, e.g., storing application code, object data, tables, data sets, and underlying database records including user data representative of customer organizations 105A-C (e.g., users of such a database system 130 or tenants of a multi-tenant database type database system or affiliated users of such a database system). According to certain embodiments, such databases include various database system types, including, for example, a relational database system 155A and a non-relational database system 155B.

[0061] In certain embodiments, a client-server computing architecture may be used to supplement the features, functions, or computing resources of the database system 130, or alternatively, a computing grid or a pool of worker servers, or some combination of hosted computing architectures may be combined with the database system 130 to provide some or all of the computing workload and processing required by the host organization 110.

[0062] The database system 130 described in the illustrated embodiment includes a plurality of underlying hardware, software, and logical elements 120 that implement database functionality and a code execution environment within the host organization 110.

[0063] According to one embodiment, database system 130 utilizes underlying database system implementations 155A and 155B to service database queries and other data interactions with database system 130, and the database system communicates with database system 130 via query interface 180. The hardware, software, and logical components 120 of database system 130 are separate and distinct from customer organizations (105A, 105B, and 105C), which utilize network services and other services provided by host organization 110 by communicatively engaging with host organization 110 via network 125. In this manner, host organization 110 can implement on-demand services, on-demand database services, or cloud computing services for subscribing customer organizations 105A-C.

[0064] In one embodiment, each customer organization 105A-C is an entity selected from the group consisting of: a separate and distinct remote organization, an organizational group within host organization 110, a business partner of host organization 110, or a customer organization 105A-C that subscribes to cloud computing services provided by host organization 110.

[0065] Further depicted is that host organization 110 receives inputs and other requests 115 from customer organizations 105A-C via network 125 (e.g., a public network, the Internet, or a similar network). For example, an input search query, database query, API request, interaction with a displayed graphical user interface, and display at user client devices 106A-C, or other inputs may be received from customer organizations 105A-C for processing against database system 130, or such queries may be constructed from the inputs and other requests 115 for execution against database 155 or query interface 180, and according to the query, results 116 are then returned to the initiator or requester, e.g., a user of one of user client devices 106A-C at customer organization 105A-C.

[0066] In one embodiment, requests 115 are received or submitted to network server 175 within host organization 110. Host organization 110 can receive various requests processed by host organization 110 and its database system 130. Input requests 115 received at network server 175 can specify which services from host organization 110 will be provided, e.g., query requests, search requests, status requests, database transactions, graphical user interface requests and interactions, processing requests to obtain, update, or store data on behalf of a customer organization 105A-C, code execution requests, etc. Network server 175 can be responsible for receiving requests 115 from various customer organizations 105A-C via network 125 on behalf of query interface 180, and for providing a network-based interface or other graphical display to end-user client devices 106A-C or the machine that initiated such data requests 115.

[0067] Certain requests 115 received at the host organization can be directed to the blockchain, for which the blockchain service interface 190 of the host organization 110 operates as an intermediary.

[0068] The query interface 180 is capable of receiving and executing requested queries against the databases and storage components of the database system 130 and returning a result set, response, or other requested data to advance the described methods. The query interface 180 additionally provides the function of passing queries from the web server 175 into the database system 130 for execution against the database 155 to process search queries, or into other available data stores of the host organization's computing environment 111. In one embodiment, the query interface 180 implements an application programming interface (API) through which queries can be executed against the database 155 or other data stores. Additionally, the query interface 180 provides interoperability with the blockchain service interface 190, thereby allowing the host organization 110 to transact with the database system 130 via the query interface 180, or to conduct blockchain transactions on a connected blockchain where the host organization 110 is a participating node or communicates with a participating node 133, or the host organization 110 can conduct transactions involving data persisted by the database system 130 (accessible via the query interface 180) and data persisted by the connected blockchain (e.g., accessible from the participating node 133 or directly from the connected blockchain, where the host organization operates a participating node on such a blockchain).

[0069] In certain embodiments, the application programming interface (API) of the query interface 180 provides an API model through which programmers, developers, and administrators can interact with the blockchain service interface 190 or the database system 130 or both, depending on the needs and specific requirements of the API caller.

[0070] The host organization 110 can implement the request interface 176 via the web server 175 or receive request packets or other requests 115 as a stand-alone interface from the user client devices 106A-C. The request interface 176 further supports the return of response packets or other replies and responses 116 in the output direction from the host organization 110 to the user client devices 106A-C. The authenticator 140 operates on behalf of the host organization to verify, authenticate, and otherwise certify users attempting to gain access to the host organization.

[0071] The blockchain service interface 190 is further described within the host organization 110, which includes a blockchain consensus manager 191 that facilitates consensus management for both private and public blockchains, on which tenant, customer organizations, or the host organization 110 itself operate as participating nodes on the supported blockchains. Additionally, a blockchain metadata definition manager 196 is depicted, which enables the blockchain service interface 190 to define and create metadata that is then pushed to or transacted on the blockchain engaged via the blockchain service interface. For example, via the blockchain metadata definition manager 196, any customer organization 105A-C of the host organization can define and create metadata and then record or transact that metadata on the blockchain for use by that customer organization 105A-C and other participating nodes on the blockchain, regardless of whether those participating nodes 133 are also customer organizations 105A-C of the host organization 110. For example, once the metadata is defined and created via the blockchain metadata definition manager 196 and pushed to the blockchain, any participating node 133 that can access the blockchain on which the metadata definition resides can then create data records and store information on the blockchain that adopts the defined metadata definition and thus conforms to the newly created metadata definition. In this way, all participating nodes can utilize the information stored in accordance with the newly created metadata definition because there is a standardized and customizable way to store such data.

[0072] In one implementation, the blockchain consensus manager 191 and the blockchain metadata definition manager 196 work together to achieve consensus regarding read functionality, as further described below with reference to Figure 10 FIGs. 12. Read consensus is a specific type of consensus used to control read access to data stored on the blockchain. The data is stored in an encrypted format, where the encryption key is distributed as a shared secret with other nodes in the blockchain platform. When a request to access the data is made, the nodes 133 of the network perform a read consensus operation. The read consensus process checks the credentials or any configured criteria determined to be necessary, which are provided in the access request. Each node that approves the read access responds with a portion of its shared secret that enables the requesting node to generate the key based on the shared secret to decrypt the data on the blockchain and access the data. A threshold number of secrets must be returned to access the encrypted data. The threshold number can be configured and / or determined by the shared secret algorithm used by the read consensus process (e.g., Shamir's secret sharing algorithm).

[0073] In a further embodiment, the permissions manager 181 operates to enforce access controls and privileges defined in the metadata for data stored on the blockchain. The permissions manager 181 may impose restrictions on access records, objects, fields, or similar granular levels of access control (including read and write access controls). The permissions manager 181 may enforce management of blockchain data based on metadata that defines access permissions. Access permissions may utilize unique user identifiers (UUTDs) or similar entity identifiers. The metadata may define a list of entities authorized to read or write data on the blockchain. The metadata may also define a set of owners who control the read consensus process for managing access to the access-controlled information. In some embodiments, the permissions manager 181 may implement a right to be forgotten process (e.g., compliant with the European Union's General Data Protection Regulation (GDPR)) or a similar process to "erase" data from the blockchain. Reference is made herein Figure 10 to FIGS. 12 for further discussion and description of the operation of the permissions manager 181 and the read consensus process of the blockchain consensus manager 191, including the right to be forgotten and access privileges.

[0074] As shown herein, the blockchain service interface 190 communicatively couples the host organization 110 with other participating nodes 133 (e.g., via the network 125), enabling the host organization 110 to participate in available blockchain protocols by acting as a blockchain protocol-compatible node, which in turn allows the host organization 110 to access information within such a blockchain and enables the host organization 110 to provide blockchain services to the other participating nodes 133 for any number of blockchain protocols supported and provided by the host organization 110 to customers and subscribers. In certain embodiments, the host organization 110 provides the blockchain protocol, and then the host organization also operates as a participating node on that protocol. In other embodiments, the host organization only operates as a participating node to enable the host organization 110 to interact with blockchain protocols provided by others.

[0075] According to certain embodiments, the blockchain metadata definition manager 196 also allows non-subscribers of the host organization (e.g., entities that are not customer organizations 105A-C) to define using the blockchain metadata manager 196 and a graphical user interface (GUI) associated with the blockchain metadata definition manager 196 via a publicly available API interface for such non-subscribing customers, and then metadata definitions can be created and defined, which are then pushed to the blockchain via the host organization's blockchain service interface 190.

[0076] A blockchain is a continuously growing list of records, grouped into blocks, which are linked together and secured using cryptography. Each block typically contains a hash pointer as a link to the previous block, a timestamp, and transaction data. By design, blockchains are inherently resistant to data modification. A blockchain system is essentially an open, distributed ledger that records transactions between two parties in an efficient and verifiable way, which is also immutable and permanent. A distributed ledger (also known as a shared or common ledger, or distributed ledger technology (DLT)) is a consensus of replicated, shared, and synchronized digital data that is geographically distributed across multiple nodes. These nodes can be located in different sites, countries, institutions, user communities, customer organizations, host organizations, hosted computing environments, or application servers. There is no central administrator or centralized data storage.

[0077] Blockchain systems use peer-to-peer (P2P) network nodes, and consensus algorithms ensure the replication of digital data across nodes. Blockchain systems can be public or private. Not all distributed ledgers must use blockchain to successfully provide secure and efficient distributed consensus: blockchain is just considered a data structure of distributed ledgers.

[0078] P2P computing or networking is a distributed application architecture that divides tasks or workloads among peers. In an application that forms a peer-to-peer network node, peers are participants with equal privileges and equal capabilities. Peers directly provide a portion of their resources (e.g., processing power, disk storage, or network bandwidth) to other network participants without centralized coordination by a server or host. Peers are both providers and consumers of resources, which is in sharp contrast to the traditional client-server model, where resource consumption and supply are separated. Thus, a peer-to-peer network is designed around the concept that peer nodes act as both clients and servers to other nodes on the network.

[0079] To be used as a distributed ledger, a blockchain is typically managed by a peer-to-peer network that collectively adheres to a protocol for validating new blocks. Once recorded, the data in any given block cannot be retroactively changed without changing all subsequent blocks, which requires collusion by a majority of the network. In this way, blockchains are secure by design and are an example of a distributed computing system with high Byzantine fault tolerance. Thus, a decentralized consensus is achieved with blockchains. This makes blockchains suitable for recording events, medical records, insurance records, and other record management activities, e.g., identity management, transaction processing, record provenance, or voting.

[0080] Autonomously manage a blockchain database using a peer-to-peer network and a distributed timestamp server. In a blockchain, records are authenticated through collaboration among nodes in the form of blocks, which is for collective self-interest. Thus, the uncertainty of participants regarding data security is minimized. The use of a blockchain eliminates the characteristic of digital asset reproducibility. It is confirmed that each unit of value (e.g., an asset) is transferred only once, solving the double-spending problem.

[0081] Each block in a blockchain holds a batch of valid transactions ("block"), which are hashed and encoded into a Merkle tree. Each block includes the hash of the previous block in the blockchain, linking the two. The linked blocks form a chain. This iterative process confirms the integrity of the previous block all the way to the first block in the chain, sometimes called the genesis block or root block.

[0082] By storing data on a network, a blockchain eliminates the risks associated with centralized storage and control of data by a single institution. While the host organization 110 provides extensive data processing and storage services, including the ability to provide large amounts of data to a single responsible agent (e.g., the host organization 110), what differentiates blockchain services is that the host organization 110 is not the single authorized institution for such services, but rather is one of many nodes of an available blockchain protocol via the blockchain service interface 190, or operates as a blockchain protocol manager and provider, while other participating nodes 133 communicating with the host organization 110 via the blockchain service interface 190 jointly operate as a repository for information stored within the blockchain by implementing a compatible distributed ledger technology (DLT) based on the available blockchain protocol provided by the host organization 110.

[0083] Decentralized blockchains can use special messaging and distributed networks. Blockchain networks lack centralized vulnerability points that computer hackers might exploit. Similarly, there is no single point of failure. Blockchain security methods include the use of public-key cryptography. The public key is an address of the blockchain. Value tokens sent across the network are recorded as belonging to that address. The private key is like a password that gives the owner access to their digital assets or a means to interact with the various functions supported by the blockchain in other ways. The data stored in a blockchain is generally considered incorruptible. This is where the advantage of a blockchain lies. While centralized data is more controllable, information and data manipulation are common. By decentralizing this data, a blockchain makes the data transparent to all relevant parties.

[0084] Each participating node 133 of a specific blockchain protocol within the decentralized system has a copy of the blockchain of that specific blockchain protocol. Data quality is maintained by large-scale database replication and computational trust. There is no centralized official copy of the database, and by default, no user and no participating node 133 is more trusted than any other node, although this default can be changed by certain dedicated blockchain protocols, which will be described in more detail below. Blockchain transactions are broadcast to the network using software, and any participating node 133 (including the host organization 110 operating as a node) receives such transaction broadcasts. Broadcast messages are delivered on a best-effort basis. Nodes verify transactions, add them to the blocks being constructed, and then broadcast the completed blocks to other nodes. Blockchains use various timestamping schemes (e.g., proof-of-work) to serialize changes. Alternative consensus can be used in conjunction with the various blockchain protocols provided and supported by the host organization, and such consensus mechanisms include, for example, proof-of-stake, proof-of-authority, and proof-of-nothing.

[0085] Open blockchains are more user-friendly than traditional ownership records, which, while open to the public, still require physical access to view. Because most early blockchains were permissionless, there has been some debate over the specific accepted definition of a so-called "blockchain", e.g., whether a private system with verifiers assigned and authorized (permissioned) by a central authority is considered a blockchain. The concept of a permissioned validator is different from the permissioned access control process described in this document. Proponents of permissioned or private blockchains argue that the term "blockchain" can apply to any data structure that groups data into timestamped blocks. These blockchains serve as a distributed version of multi-version concurrency control (MVCC) in a database. Just as MVCC prevents two transactions from simultaneously modifying an object in a database, a blockchain prevents two transactions from using the same output in the blockchain. Regardless of the semantics or specific terminology applied to different types of blockchain technologies, the approach described in this document regarding "blockchains" extends traditional blockchain protocol implementations to provide additional flexibility, open up new services and use cases for the described blockchain implementations, and depending on the specific blockchain protocol provided or supported by the blockchain service interface 190 of the host organization 110, both private and public mechanisms are described and used as needed for the different implementations supported by the host organization 110.

[0086] The advantages of open, permissionless, or public blockchain networks are that they do not need to guard against bad actors and generally do not require access control, although, as discussed in this document, implementation schemes provide blockchain access control for specific cases applicable to permissioned or public blockchains. This means that applications can use the blockchain as a transport layer and be added to the network without the approval or trust of others. In contrast, permissioned (e.g., private) blockchains use an access control layer to manage who has the right to access the network. These implementation schemes also provide access control for entities inside or outside private or public blockchains. Different from public blockchain networks, the validators on private blockchain networks are reviewed by the network owner or one or more members of the consortium. They rely on known nodes to verify transactions. Permissioned blockchains are also called "consortium" or "hybrid" blockchains. Today, many companies use blockchain networks with private blockchains or blockchain-based distributed ledgers, independent of public blockchain systems.

[0087] Figure 1B Depicts another exemplary architecture 101 according to the described implementation scheme, with additional details of the blockchain protocol block 160 operating in conjunction with the block validator 192. The blockchain consensus manager 191 implements read consensus, and the permission manager 181 supports access control and similar operations, as further described below with reference to Figure 10 Figures 12.

[0088] In particular, the blockchain protocol block 160 is described herein as being verified by the block validator 192 of the host organization 110, where the blockchain protocol block includes additional details of its various sub-components and certain optional elements that can be used in conjunction with the blockchain protocol block 160 according to the specific blockchain protocol used via the blockchain service interface 190.

[0089] According to a specific implementation scheme, the blockchain protocol block 160 described herein defines a specific structure for how to organize the basic blocks of any given blockchain protocol supported by the host organization 110.

[0090] According to certain implementation schemes, the blockchain metadata definition manager 196 shown herein can utilize a specific blockchain implementation provided by the host organization 110. Thus, the applicable blockchain protocol is defined by the host organization 110. Alternatively, the blockchain metadata definition manager 196 can utilize any publicly accessible blockchain in which the host organization operates as a participating node to establish access, or the blockchain metadata definition manager 196 can utilize private blockchains, including those not provided by the host organization 110, as long as the host organization can authenticate with such private blockchains and access the blockchain by operating as a participating node on the private blockchain.

[0091] As will be described in more detail below, the blockchain metadata definition manager 196 implements a specialized metadata definition and creation scheme, which may include using GUIs and other user-friendly interfaces provided by the host organization via APIs or via the host organization's interfaces. For example, users and customer organizations can interact with the host organization via their web server 175. More specifically, the services and applications provided by the host organization, including using the GUIs provided by the blockchain metadata definition manager 196, can be accessed by the tenants of the host organization through the cloud computing platform and, in some embodiments, by non-tenants and non-subscribers of the host organization 110, both of whom can utilize the GUIs and the functions provided by the blockchain metadata definition manager 196.

[0092] According to some embodiments, it may be necessary for the host organization to provide a customized blockchain protocol implementation to support the specialized metadata definition and creation scheme implemented by the blockchain metadata definition manager 196. However, in embodiments where the metadata can be defined and stored in the blockchain with the permission of the host organization 110, any blockchain used to store such data will not be affected because the blockchain does not know what type of metadata the host organization has defined or created and transmitted to the blockchain. In other words, although the host organization 110 facilitates the definition and creation of such metadata and transmits this information to the blockchain, it does not matter to the blockchain what application chooses to use this data. The host organization facilitates a platform in which applications can choose to use only data that conforms to the defined and created metadata, thus allowing the transferability of such data and many other benefits.

[0093] Regarding the blockchain protocol block 160 (whether it is an existing and already available blockchain protocol or a customized implemented blockchain protocol), the prior hash 161 is the result of an irreversible mathematical calculation using the data from the prior block 159 as input. The prior block 159 in turn utilizes the data from n previous blocks 158 to form an irreversible mathematical calculation, thereby forming the prior hash of those corresponding blocks. For example, according to one embodiment, the irreversible mathematical calculation utilized is the SHA 256 hash function, although other hash functions can also be utilized. According to such an embodiment, a change in the data in any of the prior blocks 159 or n previous blocks 158 in the chain causes an unpredictable change in the hash of those prior blocks and thus invalidates the current or present blockchain protocol block 160. The prior hash 161 creates a link between the blocks, chaining them together to form the current blockchain protocol block 160.

[0094] When block validator 192 calculates the prior hash 161 of prior block 159, the hash must meet specific criteria defined by data stored as proof criteria 165. For example, in one implementation, the proof criteria 165 is a number that the calculated hash must be less than. Since the output of a hash function is unpredictable, it is not possible to know what input will result in an output less than the proof criteria 165 before calculating the hash. The nonce 162 is used to vary the data content of the block, allowing the hash function to produce a large number of different outputs in pursuit of an output that meets the proof criteria 165, thus making the computational cost of generating a valid block with nonce 162 very high (and thus statistically impossible), where the nonce results in a hash value that meets the criteria of the proof criteria 165.

[0095] The payload hash 163 provides the hash of the data stored in the block payload 169 portion of the blockchain protocol block 160 and does not need to meet any specific proof criteria 165. However, when calculating the hash for the purpose of storing it as the prior hash 161 of the next or subsequent block, the payload hash is included as part of the input. The timestamp 164 indicates the time at which the blockchain protocol block 160 was created within a certain margin of error. According to certain blockchain protocol implementations provided via the blockchain service interface 190, the distributed network of users (e.g., blockchain protocol nodes) checks the timestamp 164 against their own known time and will reject any block with a timestamp 164 that exceeds the error threshold. However, this functionality is optional and may be required by some blockchain protocols and not used by others.

[0096] The blockchain protocol proof 166 defines the required size and / or data structure of the block payload 169 and demonstrates compliance with a specific blockchain protocol implementation, and thus demonstrates that the blockchain protocol block subscribes to, implements, and adheres to the specific requirements and configuration options of the indicated blockchain protocol. The blockchain protocol proof 166 can also indicate the version of a given blockchain protocol, and the blockchain protocol can allow limited backward and forward compatibility of blocks before nodes will start rejecting new blockchain protocol blocks for non - compliance.

[0097] Depending on the specific blockchain protocol used, block type 167 is optional. In the case of a specific blockchain protocol that needs to be exposed via the blockchain service interface 190, block type 167 must be indicated as one of an enumerated list of allowed block types 167, which will be described in more detail below. Some blockchain protocols use multiple different block types 167, all of which can have different payloads, but have a structure, declared block type 167, and blockchain protocol proof 166 demonstrating compliance with these requirements that are known a priori based on the blockchain protocol used. For a given declared block type 167, a non - conforming or invalid block type or unexpected structure or payload will cause the block to be rejected by network nodes.

[0098] In the case of using a variable - sized block payload 169, block type 167 can indicate the permissibility of such variable - sized block payload 169 and indicate the index of the first byte in the block payload 169 and the total size of the block payload 169. Block type 167 can be used to store other information related to the reading, accessing, and proper processing and interpretation of the block payload 169.

[0099] The block payload 169 data stored within a block can relate to any number of transaction data, depending on the specific implementation and blockchain protocol used, including payload information related to, for example, financial transactions, ownership information, data access records, document version control, medical records, voting records, compliance and certification, educational transcripts, purchase receipts, digital rights management records, or literally any kind of data that can be stored via the payload of a blockchain protocol block 160, which is essentially any data that can be digitized. Depending on the specific blockchain protocol chosen, the payload size can be fixed - sized or variable - sized, and in both cases, it will be used as at least a part of the input to the hash that generates the payload hash 163.

[0100] Depending on the particular blockchain protocol selected, various proof standards 165 can be used, such as, proof of work, hash value requirements, proof of stake, cryptographic keys, or some other indicator such as consensus or proof of consensus. In the case of leveraging consensus-based technologies, the blockchain consensus manager 191 provides consensus management on behalf of the host organization 110. However, the host organization 110 can operate as just one of many nodes of a given blockchain protocol that is accessed by the host organization 110 via the blockchain service interface 190, or, the host organization 110 can define and provide a particular blockchain protocol to customers and subscribers (and potentially to unauthenticated public node participants) via the blockchain service interface 190 as a cloud-based service. Such proof standards 165 can be applied as rules that require a hash value to be less than, greater than, the proof standard, or can require a particular bit sequence (e.g., 10 zeros, or a defined binary sequence), or a required number of leading or trailing zeros (e.g., an input hash that results in 20 leading or trailing zeros, which is computationally infeasible if there is no known valid input).

[0101] Depending on the particular blockchain protocol implementation, the hash algorithms for the prior hash 161, payload hash 163, or authorization hash 168 can all be of the same type or different types. For example, allowed hash functions include MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-515, SHA-515 / 224, SHA-515 / 256, SHA-3, or any suitable hash function resistant to preimage attacks. Nor is it required that a hash be computed only once. The result of one hash function can be reused multiple times as the input to another or the same hash function in order to produce a final result.

[0102] Figure 1C Another exemplary architecture 102 is depicted in accordance with the described embodiments, where additional details of the blockchain metadata definition manager 196 are elaborated upon in more detail.

[0103] As can be seen herein, there is a blockchain service interface 190 that includes the blockchain metadata definition manager 196. The integration builder 153, as well as the blockchain consensus manager 191 and block validator 192 are also depicted as interacting with various elements of the blockchain metadata definition manager 196, with the integration builder being capable of establishing network members to participate in the metadata definition and creation scenario.

[0104] Inside the blockchain metadata definition manager 196 there are various further elements, including a trust layer 154 and a central trust interface 152 that is capable of interacting with the tenants and customer organizations of the host organization and non-subscribers of the services of the host organization. Also depicted is a metadata layer 156 that has knowledge of all currently defined metadata definitions that are created and pushed to an accessible blockchain, followed by a network organization 157 layer or shared ledger that serves as an interface to various accessible blockchains. A state ledger 179 maintains the state of the accessible blockchain and any connected or disconnected state, while a history block 177 maintains the transaction history and records of the platform. An integration platform layer 151 provides an interface to other components within the host organization 110 to engage with the components of the blockchain metadata definition manager 196, while an access control layer 147 will be described in more detail below, but provides certain access rights and restrictions for private and permissioned blockchains that are not fully open to public access.

[0105] Finally, various block ledger clients are described, including a customer 114 of the host organization who has a full platform license as a subscribing customer of the host organization, while the next block ledger client at block 117 with partner #1 of the host organization only has a basic license and a block ledger license with limited user capabilities provided by the host organization, followed by a last block ledger client at block 119 that has partner #2 of the host organization, which is strictly limited to a community license available to all parties without subscribing to any user services required by a subscription provided by the host organization.

[0106] From a high level, the depicted architecture provides similar services to a public blockchain, except that according to this particular implementation, the shared ledger 157 operates the blockchain inside the host organization and defines the blockchain protocol of the hosted network organization or the so-called "shared ledger 157" shown herein. The depicted shared ledger 157 thus allows customers and non-customers to interact with organizations and customers and non-subscribing customers, but not necessarily third-party instances, since this particular implementation operates the shared ledger 157 inside the host organization. In this way, the functionality provided by public and private blockchains can still be achieved and utilized. However, since the shared ledger 157 is entirely inside the host organization 110, it is possible to use distributed ledger technology (DLT) to operate the shared ledger, which is modified to rely on the trust layer 154 of the host organization 110 as a central trust authority (and provides verification of trust via the central trust interface 152), rather than more customarily using a blockchain consensus manager 191 as in other related implementations described herein.

[0107] Regardless of the trust authority (e.g., whether it is the host organization 110 or the consensus-reached distributed nodes managed by the blockchain consensus manager 191), all data is transparent and cryptographically verifiable, and the data and users do not belong to one party, although it is hosted within the host organization, and the history 177 and the state ledger 179 provide an enhanced audit trail. The integration builder 153 allows the execution of smart contracts that run on shared data as well as on data owned by the network organization 157 itself, e.g., metadata definitions that are accessible to all members but still owned by the host organization.

[0108] In this particular implementation, as described above, since trust is established by the host organization itself via the trust layer 154, consensus is not required, although consensus can be optionally utilized depending on the implementation.

[0109] According to a particular implementation, there is a multi-tenant ledger platform that operates at the network level, which provides the same amount of transparency and provenance available via blockchain but is completely within the control of the host organization 110 and thus provides certain benefits, e.g., establishing central trust by the host organization 110.

[0110] This architecture represents a compromise between centralized and decentralized databases, specifically deviating from the basic principles of blockchain, which utilizes distributed ledger technology and thus operates as a distributed database. However, described herein is the host organization 110 operating as a central party by and through the blockchain service interface 190, which provides trust on behalf of all tenants, as opposed to blockchain where trust is passed by the network and specifically by nodes distributed across the entire consensus-reached network.

[0111] The data and information saved via the shared ledger 157 of the host organization are entirely owned by the network, specifically by the established network members, yet the infrastructure is owned by the central party, in this case, the host organization 110 owns, controls, and manages the computing infrastructure and resources for operating the shared ledger 157. Thus, if any established network member hosts the host organization as the central party, this system and architecture apply to that particular established network member. However, it is worth noting that the established network member must place its trust in a third party, in this case, the host organization 110. If this is not possible or is not allowed based on various data security requirements, regulations, or other considerations, the distributed ledger technology (DLT) that requires distributed node consensus managed by the blockchain consensus manager 191 is more suitable for those parties.

[0112] According to certain embodiments, a tenant-centric network organization or tenant-centric shared ledger 157 is provided, also within the host organization 110 (specifically, the blockchain service interface 190 of the host organization), where all users are controlled by each respective customer organization rather than by a centralized customer. In other words, there may be tenant-specific customer control such that any user of a given instance of the shared ledger 157 is controlled by the tenant or customer organization that has permissions to that instance of the shared ledger 157. In this way, there can be multiple instances of the shared ledger 157, each instance having a set of users controlled by a specific customer organization, without having to negotiate or rely on any other customer organization, tenant, or any other entity to approve or deny user inclusion. This includes the ability of the customer organization of the tenant to determine on its own which users are allowed in its instance of the shared ledger 157, without having to go through the host organization, even though the instance of the shared ledger 157 is hosted within the host organization. This is because the host organization 110 effectively delegates full control of user inclusion for each respective instance of the shared ledger 157 to the customer organization for which that particular shared ledger 157 operates.

[0113] According to some embodiments, the shared ledger 157 embodies a Merkle directed acyclic graph (DAG) or “Merkle-DAG,” which is a data structure similar to a local Merkle tree, except that the Merkle DAG structure does not need to be balanced and allows its non-leaf nodes to contain data. In this way, the Merkle-DAG is similar to a local Merkle tree in that they both embody a hash tree. While Merkle trees link transactions in sequence, the difference with the Merkle-DAG is that transactions are linked by hashes. Thus, in the Merkle-DAG structure, addresses are represented by Merkle hashes. The resulting Merkle hash spiderweb links data addresses together through the Merkle graph. Thus, the directed acyclic graph (DAG) part of the Merkle-DAG can be used to model information, for example, to model storing specific data at specific addresses.

[0114] According to another embodiment, data is encrypted and cryptographically verifiable within each instance of the shared ledger 157. For example, leveraging an extension of the blockchain service interface 190 platform, any tenant having an instance of the shared ledger 157 can cryptographically verify any stored encrypted data within the instance of the shared ledger 157.

[0115] As described above, for many customers, leasing or subscribing to cloud-based computing infrastructure and software is more preferable than owning, operating, maintaining, and configuring such computing infrastructure themselves. When certain customers and partners only require transparency of their data and ledger (e.g., not necessarily requiring consensus among distributed nodes), this solution represents a substantial improvement over competitors. Although blockchain technology presents many advantages, many of which are described in more detail elsewhere in this document, the reality is that some customers simply do not care about the decentralization of data and ledger, and thus, significant benefits can be obtained from leveraging an instance of a shared ledger 157 that operates entirely within a host organization 110 with a central trust interface 152 and thus does not require participation in other consensus mechanisms common to distributed blockchain ledgers.

[0116] According to one embodiment, the shared ledger 157 provides an immutable audit trail that cannot be altered by any party, including the host organization 110, and thus provides greater security, transparency, and assurance compared to the standard audit trails provided by competing solutions. Therefore, when using the shared ledger 157, it brings added value to tenants and customer organizations compared to standard centralized systems.

[0117] In addition, because the shared ledger 157 is multi-tenant aware (e.g., each tenant or customer organization can utilize its own instance of the shared ledger 157) and metadata-driven, with executable smart contracts via triggers, there are multiple advantages for tenant subscribers of the host organization in addition to the platform benefits provided by the host organization.

[0118] Consider an example of a market where a large retailer wishes to leverage blockchain to manage its supply chain from clothing to fresh produce. Such an example might start with cotton as the raw material for clothing and leafy greens as packaged products sold in stores. Eventually, the large retailer might evolve to a full blockchain solution, but initially, many customers might prefer to use a fully controlled single point of trust and hosted solution, e.g., the shared ledger 157 provided by the host organization. The reason for starting with a hosted shared ledger solution initially might be to enable single sign-on or a single authentication portal via their current host organization, which already provides them with cloud-based services, and this would enable the large retailer to experiment with distributed ledger technology (DLT) while allowing the large retailer to view its verified ledger information from the single sign-on portal.

[0119] Such a structure would thus allow large retailers, for example, to place their trust in the immutability of data as it is stored within the immutable shared ledger 157 (albeit within the host organization 110). This is possible because even the host organization cannot change the audit trail of the shared ledger 157. This is in contrast to the use of previous cloud-based platforms, which provided a standardized audit trail but which, because the audit trail was not immutable to all parties, could theoretically be manipulated by malicious actors, although this was highly unlikely. However, the shared ledger 157 that utilizes the modified DLT technology is designed to be immutable in terms of its audit trail and, thus, a higher level of trust can be appropriately placed in the central trust authority, e.g., the host organization, given its lack of ability to change the historical records stored within the shared ledger 157.

[0120] The same logic may apply to a company that wishes to use such a ledger within a company and its subsidiaries as doing so would allow for better integration and data sharing between the company and its subsidiaries while benefiting from the immutability of the shared ledger in addition to what competing solutions can offer, e.g., on-premises and remotely operated databases or strictly on-demand cloud-based solutions.

[0121] For example, consider a mortgage department that wishes to share sales lead information with its commercial banking division or a healthcare company with multiple divisions across the country that are not well integrated between divisions, resulting in duplicate operating centers, e.g., a claims processing group in Northern California and another claims processing group in Southern California, which currently lack full integration but could migrate to a hosted shared ledger 157 solution to achieve greater integration with a trusted audit trail through the immutability of the records written to the platform, thereby improving the usability and transparency of the data used by the various divisions of a large healthcare provider.

[0122] Accordingly, in accordance with certain embodiments, there is an operation of a system of a host organization, including operating an interface to a shared ledger on behalf of multiple authorized network participants of the shared ledger, wherein the shared ledger stores data via multiple distributed shared ledger nodes; generating a network organization within the shared ledger to store data on behalf of a founder organization that is the first of the multiple authorized network participants; receiving an input from a creator organization that defines multiple partner organizations as additional authorized network participants of the network organization, wherein all authorized network participants have read access to data stored by the network organization via the shared ledger without replicating the data; receiving an input from the creator organization that defines the permissions for each partner organization to interact with the network organization within the shared ledger; writing metadata to the shared ledger that at least defines the authorized network participants of the network organization and the permissions defined for each partner organization; receiving requests to interact with the network organization from authorized network participants; and conducting a transaction with the shared ledger when the request is satisfied.

[0123] In accordance with an operation of another embodiment, the shared ledger includes a declarative, metadata-driven, cryptographically verifiable multi-network (multi-tenant) shared ledger that operates on a relational database system within the host organization; wherein the method further includes: assigning a unique network ID to each partner organization and the founder organization; and partitioning the tables of the relational database system on which data of the network organization is stored according to the network IDs.

[0124] In accordance with an operation of another embodiment, the relational database system invariantly stores an audit log that records all insertions, deletions, and updates that affect data stored within the network organization via the multiple shared ledger nodes.

[0125] In accordance with an operation of another embodiment, conducting a transaction with the shared ledger when the request is satisfied includes at least: (i) obtaining the metadata of the network organization from the shared ledger; (ii) verifying that each request originates from an authorized network participant of the network organization; (iii) verifying that each request specifies an interaction with the founder organization or an interaction with a partner organization that complies with the permissions defined by the obtained metadata of the network organization; and (iv) conducting a transaction with the network organization via the shared ledger to fulfill the request based on a successful verification.

[0126] In accordance with an operation of another embodiment, the permissions defined for each partner organization by the metadata include one or more of the following: write access to the metadata at the request of a partner organization, write access to the metadata granted by the founder organization; and write access to data stored by the network organization at the request of a partner organization, write access to the data granted by the creator organization.

[0127] According to the operation of another embodiment, the permissions defined by the metadata for each partner organization include the permission to create a new user associated with a partner organization.

[0128] According to the operation of another embodiment, the permissions defined by the metadata of each partner organization include the permission to add a new partner organization as an authorized network participant of the network organization.

[0129] According to the operation of another embodiment, the permissions defined by the metadata further include one or more of the following: the permission for the founder organization to modify the metadata granted by the founder organization; the permission for the founder organization to modify the data stored in the network organization granted by the founder organization; the permission for the founder organization to delete a partner organization from the network organization and delete the deleted partner organization as an authorized network participant of the network organization; the permission for the founder organization to add a new partner organization as an authorized network participant of the network organization; the permission for the founder organization to declare new business logic common to all authorized network participants of the network organization; and the permission for the founder organization to declare new business rules common to all authorized network participants of the network organization granted by the founder organization.

[0130] According to the operation of another embodiment, the data stored by the network organization in the shared ledger includes one or more of the following: application data records common to all authorized network participants of the network organization; business data records common to all authorized network participants of the network organization; business logic jointly declared by all authorized network participants of the network organization; and declarative business rules common to all authorized network participants of the network organization.

[0131] According to another embodiment, such an operation may further include: receiving a request from an authorized network participant to store localized data through the shared ledger; storing the localized data through the shared ledger; and wherein the stored localized data is only accessible by the authorized network participant that initiated the request to store the localized data, and wherein the stored localized data is not made public to other authorized network participants.

[0132] According to the operation of another embodiment, the stored localized data includes at least one of the following: a modification to data stored by the network organization, which is only accessible by the authorized network participant who initiated the request to store the localized data; a modification to an application data record shared by all authorized network participants of the network organization, wherein the modification is only accessible by the authorized network participant who initiated the request to store the localized data; a modification to a business data record shared by all authorized network participants of the network organization, wherein the modification is only accessible by the authorized network participant who initiated the request to store the localized data; a modification to the business logic shared by all authorized network participants of the declared network organization, wherein the modification is only accessible by the authorized network participant who initiated the request to store the localized data; and a modification to the business rules shared by all authorized network participants of the declared network organization, wherein the modification is only accessible by the authorized network participant who initiated the request to store the localized data.

[0133] According to the operation of another embodiment, the stored localized data includes a new user account of the authorized network participant who initiated the request to store the localized data and user permissions defined for the new user account; and wherein each authorized network participant has different user controls without affecting the data stored by the network organization in the shared ledger.

[0134] According to the operation of another embodiment, the authorized network participant who initiated the request to store the localized data is a customer organization having multiple users within the host organization; wherein the stored localized data includes a new user account of the authorized network participant who initiated the request to store the localized data; and wherein the new user account is different from any user account associated with the multiple user accounts of the customer organization.

[0135] According to the operation of another embodiment, the authorized network participant who initiated the request to store the localized data is a customer organization having a leasehold within the host organization; wherein the stored localized data includes a customer organization-specific workflow to be executed against the CRM data of the customer organization based on changes affecting the data stored by the network organization.

[0136] According to the operation of another embodiment, all changes affecting the data and metadata stored by the network organization are cryptographically verifiable, providing a complete audit log that includes at least which data changed, when the data changed, and who changed the data.

[0137] According to the operation of another embodiment, each authorized network participant is a tenant of the host organization.

[0138] In operation according to another embodiment, the founding organization is the first of a plurality of tenants of the host organization that has requested the generation of the network organization; and wherein each partner organization is a tenant of the host organization different from the founding organization and has been added by the founding organization as an authorized network participant in the shared ledger.

[0139] In operation according to another embodiment, the system of the host organization includes hardware, software, and logic components to implement cloud-based functionality for providing on-demand services, on-demand database services, and cloud computing services to subscribing customer organizations; and wherein the founding organization and each partner organization are selected from the subscribing customer organizations; and wherein the cloud-based functionality is accessible by the subscribing customer organizations via the public Internet.

[0140] In operation according to another embodiment, the network organization is represented by the host organization as one of a plurality of customer organizations of the host organization.

[0141] In operation according to another embodiment, the shared ledger includes a relational database system internal to the host organization; wherein a copy of the data stored by the network organization is accessible from each of a plurality of data centers of the host organization via one or more of a plurality of shared ledger nodes; and wherein the method further includes: determining that a first of the plurality of shared ledger nodes is inaccessible based on an outage at one of the plurality of data centers of the host organization or in response to non-responsiveness from a first of the plurality of shared ledger nodes; and after the determination, transacting with the network organization from a second of the plurality of shared ledger nodes to the shared ledger storage.

[0142] In operation according to another embodiment, the shared ledger implements distributed ledger technology (DLT) data storage internal to the host organization; wherein a copy of the data stored by the network organization is accessible from each of a plurality of shared ledger nodes distributed across a plurality of geographically dispersed data centers of the host organization; and wherein the DLT data storage stores all data in the assets added to the DLT data storage immutably.

[0143] In operation according to another embodiment, a data deletion transaction at the network organization is represented by a new asset specifying the data to be deleted from the network organization without removing any data from the DLT data storage; wherein a data update transaction at the network organization is represented by a new asset specifying the current version of the data updated at the network organization without removing any data from the DLT data storage; and wherein all previous versions of the data transacted to the network organization are maintained immutably by the DLT data storage and are accessible via an audit log of the DLT data storage, the audit log including any data specified as having been deleted and all previous versions of the data transacted to the network organization having been affected by one or more updates.

[0144] In operation according to another embodiment, the host organization operates as a central trusted authority to verify any transactions for authorized network participants of the network organization against the DLT data store.

[0145] In operation according to another embodiment, the DLT data store is implemented via a hardware and software infrastructure that operates entirely under the exclusive control of the host organization.

[0146] In operation according to another embodiment, the interface to the shared ledger includes a blockchain service interface to the blockchain on behalf of authorized network participants of the shared ledger; wherein each authorized network participant operates as a participating node on the blockchain and transacts with the blockchain via the blockchain service interface operated by the host organization.

[0147] In operation according to another embodiment, a copy of the data stored by the network organization is accessible from any authorized network participant operating as a participating node on the blockchain and also from any other participating node on the blockchain; wherein the blockchain stores all records added to the blockchain immutably; and wherein the data stored by the network organization affected by deletions and updates can still be accessed from the blockchain via the audit log of the blockchain as non-updated versions of the data.

[0148] In operation according to another embodiment, the host organization operates a participating node on the blockchain; and the blockchain operates outside the host organization, outside the exclusive control of the host organization.

[0149] In operation according to another embodiment, the network organization includes one of a plurality of different network organizations operating via a shared ledger; or alternatively, wherein the network organization operates on a single shared ledger instance of the host organization and wherein different network organizations operate on other shared ledger instances within the host organization independent of the single shared ledger instance on which the network organization operates.

[0150] In operation according to another embodiment, the data stored by the network organization is associated with a first declared application and a second declared application, both of which are used by the founder organization and a plurality of partner organizations; and wherein the permissions defined by the metadata specify different access rights to the data stored by the network organization based on whether each partner organization accesses the data using the first declared application or the second declared application.

[0151] According to the operation of another embodiment, the metadata written to the shared ledger further defines a plurality of entity types and a plurality of field definitions for each of the plurality of entity types; and wherein the method further includes: generating a virtual table within the database system of the host organization; constructing the virtual table at the database system of the host organization based on the metadata written to the shared ledger, wherein the entity types from the metadata written to the shared ledger are represented as tables within the virtual table, and wherein one or more new field definitions for each of the plurality of entity types are represented as columns within the tables at the virtual table.

[0152] According to the operation of another embodiment, the virtual table includes a materialized view hosted at the database system of the host organization, the materialized view being structured based on the metadata declared for the new application; wherein the materialized view hosted in the database system of the host organization does not store any data associated with the new application; and wherein requests for read-only access to the materialized view are processed by converting a read-only SQL query into a shared ledger transaction to obtain the requested data from the shared ledger.

[0153] According to the operation of another embodiment, the metadata written to the shared ledger further defines a plurality of entity types and a plurality of field definitions for each of the plurality of entity types; and wherein the method further includes: obtaining metadata from the shared ledger, including the plurality of entity types, one or more new field definitions for each of the plurality of entity types, and any field types applied to the one or more field definitions; generating a materialized view of the data stored via the shared ledger within the virtual table at the host organization by constructing the virtual table based on the defined metadata; wherein the materialized view represents the structure of the relevant data stored by the shared ledger without storing the data in the materialized view of the host organization.

[0154] According to another embodiment, such an operation may further include: receiving, at the host organization, an SQL statement from a user device, wherein the SQL statement points to the materialized view and requests an SQL update or SQL insert to data saved to the blockchain and associated with the new application; processing the SQL statement for the materialized view by converting the SQL statement requesting the SQL update or SQL insert into a corresponding shared ledger transaction to update or add data associated with the new application at the shared ledger; and issuing, to the user device, a confirmation, based on the corresponding shared ledger transaction accepted by the shared ledger, of the successful processing of the SQL statement for the materialized view and the successful update or addition of data associated with the new application at the shared ledger.

[0155] According to another embodiment, such an operation may further include: receiving, at a host organization, an SQL statement that points to a materialized view; wherein the SQL statement specifies one or more of the following: (i) a selection from the SQL statement, (ii) an insertion into the SQL statement, and (iii) an update to the set SQL statement; and wherein the received SQL statement is processed by converting the SQL statement into a corresponding shared ledger transaction and executing the corresponding shared ledger transaction against the shared ledger to effectuate the SQL statement that points to the materialized view at the host organization.

[0156] According to a particular embodiment, there is a non-transitory computer-readable storage medium having instructions stored thereon that, when executed by a processor of a system having at least a processor and a memory, cause the system to perform operations including: operating an interface to a shared ledger on behalf of a plurality of authorized network participants of the shared ledger, wherein the shared ledger stores data via a plurality of distributed shared ledger nodes; generating, within the shared ledger, a network organization to store data on behalf of a founder organization that is the first of the plurality of authorized network participants; receiving an input from the creator organization that defines a plurality of partner organizations as additional authorized network participants of the network organization, wherein all authorized network participants have read access to the data stored by the network organization via the shared ledger without replicating the data; receiving an input from the creator organization that defines the permissions for each partner organization to interact with the network organization within the shared ledger; writing metadata that at least defines the authorized network participants of the network organization and the permissions defined for each partner organization to the shared ledger; receiving requests to interact with the network organization from authorized network participants; and transacting with the shared ledger when the requests are satisfied.

[0157] According to another embodiment, there is a system that executes at a host organization, where the system includes: a memory storing instructions; a processor to execute the instructions; where the processor executes a shared ledger interface of a shared ledger on behalf of multiple authorized network participants of the shared ledger, where the shared ledger stores data via a plurality of distributed shared ledger nodes; where the processor generates a network organization within the shared ledger to store data on behalf of a founder organization that is the first of the multiple authorized network participants; a receiving interface for receiving an input from the creator organization that defines a plurality of partner organizations as additional authorized network participants of the network organization, where all authorized network participants have read access to the data stored by the network organization via the shared ledger without replicating the data; the receiving interface further receives an input from the founder organization that defines the permissions for each partner organization to interact with the network organization within the shared ledger; where the shared ledger interface is metadata to the shared ledger that at least defines the authorized network participants of the network organization and the permissions defined for each partner organization; the receiving interface further receives requests to interact with the network organization from authorized network participants; and where the shared ledger interface is also used to transact with the shared ledger when a request is satisfied.

[0158] Notably, the shared ledger provides a decentralized ability similar to that of a blockchain, although as described above, the shared ledger can run on a shared ledger instance within the host organization, on a public blockchain outside the host organization, on a private blockchain outside the host organization or a private blockchain implemented by the host organization, or the shared ledger can run on a distributed relational database system.

[0159] One problem with traditional solutions is that whenever two or more organizations agree to share data, ultimately at least one organization has to go back to the founder organization of the data repository to seek help to change access permissions or make any changes to the structure of the shared data. Worse still, in some cases, the creator organization of the data repository has to go to another third party for help, for example, to delegate certain administrative permissions.

[0160] The shared ledger enables the creator organization to specify which other entities can operate as partner organizations and further allows the creator organization to delegate enhanced administrative permissions to themselves and other partner organizations. For example, a partner organization can create users or modify metadata that defines the structure of network organization data stored or retained by the shared ledger. Additionally, according to certain embodiments, the shared ledger implements a declarative, metadata-driven, cryptographically verifiable multi-network (multi-tenant) shared ledger that allows data to be shared between the creator organization and partner organizations without having to replicate any data to achieve the sharing capability or benefit from the distributed nature of the distributed nodes of the shared ledger.

[0161] Take, for example, the loyalty reward program implemented by credit card companies such as American Express. Amex may want to share data with multiple different partner organizations in order to gather information in a centralized location, thus benefiting Amex as the founding organization and the partner organizations. Using previous solutions, whenever a partner organization needed to add a user to the system for data access, each partner organization constantly had to go back to Amex for help, or make any changes to the data stored in the system, and so on.

[0162] However, by using the shared ledger, founding organizations such as Amex can delegate certain rights to partner organizations. For example, Amex can allow partner organizations to create their own user accounts, or modify the business logic shared by the founding organization and partner organizations, or create localized data specific to one of the partner organizations (e.g., a CRM flow executed for one of the partner organizations), without affecting the common data pool in the shared ledger shared by all partner organizations and the founding organization, or perform certain data modification operations, such as allowing certain applications of a partner organization to have write access to the shared data, and so on.

[0163] According to a particular embodiment, the host organization implements, manages, maintains, and controls the entire computing infrastructure of the shared ledger, but allows the creator organization to assign certain permissions to themselves (e.g., the creator organization can assign privileges to the creator organization) or partner organizations on behalf of the partner organizations and the creator organization of a given network organization, such as write access to the stored data or write and update access to the stored metadata that defines the structure of the stored data.

[0164] According to a particular embodiment, each of the creator organization and partner organizations is an existing customer organization or tenant of the host organization and is thus able to define their own access control for themselves and their users by participating in the shared ledger as authorized network participants without having to request administrative support from the host organization.

[0165] In addition, since the shared ledger provides all information in an encrypted manner, an audit trail or fully transparent audit log is created, allowing the founding organization and potential partner organizations to view who changed which data at what time, thus allowing full traceability of the changer, the changed content, the location of the change, the time of the change, and the reason for the change, which may be required by laws, accounting principles, or contractual obligations.

[0166] Notably, in the case of a shared ledger, there is only a single repository for the data of the host organization, and the data is not replicated for each partner node (although some distributed technologies do provide separate data repositories distributed across multiple nodes). However, it is worth noting that no synchronization mechanism is provided because the data is always saved via the shared ledger rather than being replicated elsewhere and referenced as in many previous solutions to data sharing problems.

[0167] According to some embodiments, some or all partners can create their own business rules and business logic, which are then written into a common data pool stored in the shared ledger by the network organization. In other embodiments, partners can write their own partner-organization-specific rules and business logic, which are saved via the shared ledger but not placed in the network organization's common data pool and thus are not made public to other partner organizations or the founding organization. This may occur when a partner organization creates a CRM data stream to be executed based on modifications to the data stored by the network organization in the shared ledger, in which case the common data pool is referenced by the partner organization's CRM data stream, but the CRM data stream itself is only useful to that particular partner organization. However, it is worth noting that general business rules and logic for all authorized network participants are not only feasible but are likely to arise on any given network organization with data shared by multiple different entities.

[0168] In addition, although the data is saved within the shared ledger, according to some embodiments, provisions are made to create a data-less virtual table within the host organization as a "materialized view" in which the creator organization or and partner organizations can issue and process SQL-based queries against the materialized view as if it were a traditional relational database table, although some embodiments of the shared ledger can be saved to a non-relational data store, such as a DLT-based data store or blockchain (private or public) within the host organization, and in other cases, the shared ledger can be allowed to persist to a relational database provided it is cryptographically verifiable.

[0169] Using such an implementation, a materialized view can be provided for each authorized network participant (e.g., the creator and partners), and then from the perspective of such a participant, SQL transactions to be processed against the materialized view are allowed, and then the host organization provides the necessary transformation from the received SQL statements to the necessary shared ledger transaction commands, which can be a blockchain, DLT data storage, or even another relational database storage.

[0170] According to some implementations, the shared ledger is multi-tenant aware and multi-network aware, each authorized network participant is assigned a unique network ID, and wherein all data stored within the network organization via the shared ledger is then segmented by the network ID and / or referenceable via the network ID, thereby allowing reference to data specific only to one or more designated authorized network participants.

[0171] According to another implementation, the same common data pool of the network organization can be subject to different access rights based on the declared application used to access such data. For example, in the case where Amex is the founder organization and Chevron is the partner organization, a first application program for inventory management used by the network organization may allow Chevron to have only read access to the common data pool. However, the same partner organization, Chevron, when accessing the same common data pool using a different application program, e.g., a customer reward points application program, is allowed to have write access to some of the data stored by the network organization, thereby allowing different permissions based on the declared application rather than just based on a specific partner organization.

[0172] Figure 1D Another exemplary architecture 103 according to the described implementation is depicted, which more specifically depicts the integration of the host organization service with the blockchain service interface 190.

[0173] Specifically, an integration builder 153 and an accessible cloud platform 186 are now depicted, each of which is joined to the blockchain metadata definition manager 196 of the blockchain service interface. The integration builder 153 provides various functions that together allow entities and metadata to be defined into a shared ledger 157 hosted within the host organization or into a blockchain accessible via the host organization, even if such a blockchain is a public blockchain not ultimately controlled by the host organization.

[0174] Specifically depicted at the integration builder 153 is a clickable blockchain connector 131, which allows a user to click and drag components to link their application to an available blockchain within the host organization or accessible via the host organization, thereby specifying the link between the application and the blockchain without the user having to write code to establish the link.

[0175] The network formation manager 132 allows a user to define what entities (such as applications, etc.), partners, tenants, users, customer organizations, etc. can access information written to the blockchain via their applications.

[0176] The entity definition settings GUI 136 allows a user to define an application or entity that will apply specified metadata without writing code. For example, this can be a new entity specified at the entity definition settings GUI 136, or this can be an existing application that will be compatible with the metadata definition specified and established via the metadata definition GUI 134.

[0177] Finally, the blockchain asset or coin deployment 135 allows a user to deploy their specified entity to the connected blockchain using the defined metadata and any associated applications, partners, customer organizations, tenants, users, etc. specified via the network formation manager 132 for use by an application or anyone with connectivity and the appropriate related access rights. Once the entity and metadata defined via the GUI are deployed to the blockchain, they can be utilized by any application or entity that has access rights and related access rights to the relevant blockchain. In other words, the blockchain asset or coin deployment 135 component is used to "publish" or "go live" the defined entity and metadata.

[0178] An accessible cloud platform 186 is further described, through which information stored outside the linked blockchain but accessible via the host organization can be linked through defined entities.

[0179] Thus, if a user creates a new application and defines metadata for that application, and deploys the defined entity and metadata to a selected blockchain, it also allows access to, reference of, reading from, and writing to data stored on various accessible cloud platforms 186 that are accessible via the host organization, and these data are not persistently stored within the selected blockchain being discussed for that specific application.

[0180] For example, an application on the shared ledger 157 or another blockchain accessible via the host organization can obtain data from the commercial cloud 171 provided by the host organization, or obtain data from the marketing cloud 172 provided by the host organization, or can reference information from third - party and externally - linked clouds 173, such as the externally - linked clouds described herein as 173A, 173B, and 173C, which can actually correspond to, for example, the Amazon AWS cloud service interface, or the Microsoft Azure cloud service interface, or the Oracle cloud service interface, etc. As long as such third - party clouds are externally linked via the host organization service 107, they can be referenced by entities and applications that store their data within a blockchain accessible via the host organization or hosted within the host organization.

[0181] A more detailed breakdown of the network organization's shared ledger 157 is further described. As previously mentioned, it can provide certain distributed ledger technology (DLT) capabilities to customer organizations that wish to avoid a full deployment to a public blockchain, but provides an internally hosted ledger capability (within the host organization), which achieves central trust authorization through the trust layer 154 without the need for consensus. Optionally, the shared ledger 157 can allow customer organizations to refer to the consensus management protocol 157A for testing or verification purposes, where the customer organization can simply provide their own consensus for any transaction, as they are allowed to do so within the internally hosted shared ledger 157, for which the customer organization has its own instance and thus has ultimate authority. This is functionally similar to relying on the central trust interface 152, but allows customer organizations to utilize DLT-based consensus management, as observable in a public blockchain, while retaining control over the consensus management decisions. Later, if the customer organization converts its application to a public blockchain, its migration path will be simplified because the consensus management component has already been integrated.

[0182] The consent management 157B allows customer organizations to utilize the shared ledger 157 to define which entities, users, partners, customer organizations, etc. are authorized to reference, read, write, update, or delete transactions associated with a defined application, and allows those same entities, users, partners, customer organizations, etc. to grant permissions to reference their data. The metadata definition deployment 157C module allows the defined metadata to be written to the blockchain under discussion or to the shared ledger 157 as an asset or coin. Subsequently, entities, applications, and any code that interacts with information for which metadata has been defined must conform to the defined metadata, and compliance can be enforced via the execution of smart contracts that perform metadata compliance verification.

[0183] Figure 1E Another exemplary architecture 104 according to the described embodiments is depicted, which depicts an exemplary data flow utilizing the blockchain service interface 190.

[0184] In particular, as shown herein, partner users interact with the blockchain service interface 190, specifically with the blockchain explorer, through which accessible blockchains can be discovered and referenced. As shown by element 178, partner users can then update and read data from the blockchain via the REST API (if the permissions are appropriate). The blockchain stores information on the defined entity applications in accordance with the metadata definitions described previously.

[0185] The REST API 178 or "Representational State Transfer" API is a software architectural style that defines a set of constraints for creating and consuming web services. A web service that conforms to the REST architectural style is called a RESTful web service (RWS), which provides interoperability between computer systems over the public Internet. RESTful web services allow a requesting system to access and manipulate the textual representation of a web resource by using a uniform and predefined set of stateless operations, while other supported web services (e.g., SOAP web services) expose their own arbitrary set of operations.

[0186] Such web services can include any application entity that can be identified, named, addressed, or processed in any way allowed by the application over the public Internet. The so-called RESTful web services allow requests to be made to the URIs of resources, and then the requests will in turn elicit response payloads formatted in HTML, XML, JSON, or some other chosen format. By leveraging stateless protocols and standard operations, RESTful systems are designed to achieve fast performance, reliability, and growth capabilities by reusing components that can be managed and updated without affecting the entire system, even while the system is running, thus allowing for more complete interoperability between the described blockchain and the connected elements (e.g., partner users, host organization users, and integration builder 153).

[0187] As shown herein, there are blockchain events that are transformed into platform events and transmitted to the accessible cloud platform 186.

[0188] Host organization users can interact with such an accessible cloud platform 186 to create and record data, and, where appropriate, the data and events can be pushed back to the blockchain through configured virtual objects that communicate with the REST API to write information to the blockchain or reference information from the blockchain, or update the status information of the managed events within the blockchain.

[0189] Here, a blockchain administrator is additionally described, who can, for example, define metadata at the integration builder 153 by using the previously described GUI, thus allowing the blockchain administrator to define network participants recorded in the global application register, or deploy applications that are then referenced by the REST API at the blockchain service interface, and define metadata and permissions for the deployed entity applications, thereby ensuring that the information of the deployed applications must conform to the metadata defined for such information associated with the application when written to the blockchain. Such compliance can be enforced by the smart contracts described within the blockchain at the blockchain service interface 190 herein.

[0190] As described above, the blockchain can be an internally hosted blockchain, e.g., a shared ledger 157 that is internally hosted and fully controlled by the host organization, or the blockchain can be any public blockchain that is accessible via the host organization.

[0191] Figure 2A Depicted is another example architecture 200 with additional details of a blockchain and a forked blockchain according to the described embodiments. In this example architecture, the blockchain consensus manager 191 and the permission manager 181 operate to support read consensus and access control processes, as further described with respect to Figure 10 FIGs. 6 to 12.

[0192] More specifically, the main blockchain (e.g., the consensus blockchain) is now described, which starts with an origin block 141 (sometimes referred to as the root block), followed by a series of standard blocks 142, each standard block having a header formed at least in part based on the hash of the header of the block preceding it. Also depicted is a forked blockchain formed by an initial fork root block 144, followed by a series of standard blocks 142. Since each block in the blockchain contains the hash of the previous block stored in the previous hash, a link is effectively created via the blockchain from each block back through the chain, and is a key component that makes malicious modification of the chain extremely difficult or computationally infeasible.

[0193] As shown, the main blockchain includes a single fork that originates from a fork block 143. As shown herein, the origin block 141 is a special block that starts the main blockchain and is different from other blocks in that it is the first block in the main blockchain and thus, by definition, cannot include the hash of any previous block. The origin block 141 marks the start of the main blockchain for a particular blockchain protocol being used. The blockchain protocol manages the way the main blockchain grows, what data can be stored, and the creation of forked blockchains, and the validity of any block and any chain can be verified via the host organization's block validator 192 or any other participating network node of the blockchain according to the rules and requirements set forth by the blockchain protocol proof 166 embedded in the origin block 141, and then must be authenticated and adhered to by each subsequent block in the main blockchain or any forked blockchain.

[0194] The blockchain protocol proof 166 within each block in the origin chain defines a default set of rules and configuration parameters that allows for the creation of forks and the modification of the rules and configuration parameters in those forks (if any). Some blockchain protocol implementations do not allow for changes or non - compliance with the default rule set established via the blockchain protocol proof 166. Thus, any forks would be the result of a pending consensus of multiple competing and potentially valid primary blockchains. Once an agreement is reached (usually after one or two cycles of new block formation), the branch with the agreement is adopted and the fork is truncated, returning to a single primary consensus blockchain. Conversely, in other implementations, the creation of a forked blockchain may be allowed to continue indefinitely alongside the primary blockchain, as long as the forked blockchain complies with the blockchain protocol proof 166 and the allowed changes to the rules and configuration parameters of the forked blockchain within that blockchain protocol.

[0195] The fork block 143 anchors the forked blockchain to the primary blockchain such that both the primary blockchain and the forked chain are considered valid and allowed chains according to what is permitted by the blockchain protocol proof 166. Typically, in a blockchain, all non - consensus forks are eventually ignored or truncated except for one chain representing the longest chain with consensus and are thus considered invalid. However, the fork block 143 extends beyond the normal specification of the previous blockchain protocol by operating as a standard block 142 and behaving as if it were a standard block 142, while also including a reference to the fork hash 149 of the first block identifying the allowable forked blockchain, herein represented as the fork root block 144 of the valid forked blockchain. The fork root block 144 of the forked blockchain is followed by standard blocks, each with a header based on the hash of the previous valid block, and will continue indefinitely.

[0196] According to one particular implementation, the forked blockchain utilizes some changes to the rules and configuration parameters that are default used within the primary consensus blockchain, resulting in the need for a valid forked blockchain. Thus, the changes to the rules and configuration parameters are encoded within the new blockchain protocol proof 166 of the fork root block 144, as described above, which must remain within the valid range of the original rules and configuration parameters as specified by the blockchain protocol proof 166 of the original origin block 141 for the primary blockchain. Since the fork root block 144 must continue to carry the original blockchain protocol proof 166, the forked blockchain protocol proof can be stored in the block payload 169 section of the fork root block 144, thereby establishing the rules and allowed configuration parameters for the subsequent standard blocks 142 in the forked blockchain.

[0197] For example, a forked blockchain can be used to support declarative intelligent actions enabled by a host organization, where the forked blockchain of a public or private blockchain is customized via a new blockchain protocol proof 166 to support the declarative establishment of intelligent actions defined by an administrator and its required information capture provisions, as well as the ability to map data captured through transactions utilizing such declarative intelligent actions back to the cloud platform entities provided by the host organization.

[0198] When the new blockchain protocol proof 166 is applied to a valid fork, its rules and configurations are applied to all subsequent standard blocks of that fork and all subsequent sub-forks, where additional forks are allowed and enforced by participating nodes as if the forked blockchain were the original main blockchain. Such a fork may be desirable for a particular customer attempting to apply a specialized set of rules or configurations for a particular group, such as a workgroup, a particular transaction sub-type, or some other variant of the main blockchain that does not require or desire a fully independent "sidechain". A forked blockchain is different from a sidechain in that it remains part of the same blockchain protocol and is permanently connected to the main blockchain at the fork block 143, with the returned fork hash 149 returned and written immutably to the main consensus blockchain, where it will be retained via the chain hash scheme of all subsequent standard blocks of the main blockchain. Very simply put, the forked blockchain is explicitly connected to the main blockchain via the fork block 143. In contrast, a sidechain can be an entirely different blockchain protocol for which an agreed exchange rate or conversion factor is applied to all information or values transferred between the main blockchain and any sidechain, without any explicit reference or fork hash 149 embedded in the main blockchain.

[0199] Thus, a sidechain is a mechanism by which declarative intelligent actions of assets, tokens, values, or payload entries from one blockchain can be securely used in a completely independent blockchain via a predefined exchange or conversion scheme, yet can be allowed to move back to the original chain if desired. By convention, the original blockchain is referred to as the main chain or main blockchain, while any additional blockchain that allows users to transact using tokens, values, or payloads of the main chain is referred to as a sidechain. For example, there may be a private blockchain with a defined link to a public blockchain, thus allowing tokens, values, or payload data to move securely between the public blockchain and the private blockchain.

[0200] For example, consider a host organization using a pre-existing blockchain to implement the services provided by the blockchain metadata definition manager 196. Leveraging an existing blockchain may be advantageous, but then creating a dedicated sidechain or a forked blockchain specifically for the services provided by the blockchain metadata definition manager 196 that still complies with the blockchain protocol proof 166 required by the main (consensus) blockchain. In other cases, a modified distributed ledger technology can be used, e.g., Figure 1C the shared ledger 157 in Figure 1A , which is a hosted ledger that is entirely under the control of the host organization. Thus, it may not be necessary to sidechain from the main chain. Other examples can include the host organization providing and defining the blockchain protocol for a public blockchain. In this case, the host organization can define the blockchain protocol to be used in such a way that the extensibility capabilities of the blockchain metadata definition manager 196 (e.g., see

[0201] ) are native to the protocol and thus do not require a sidechain. Or, conversely, the host organization can define and operate a public blockchain that has a limited subset of functions available to the public and then extend the capabilities of the blockchain metadata definition manager 196 by separating a sidechain from the public blockchain to provide enhanced functionality.

[0202] Under normal operating conditions, even traditional blockchains naturally fork from time to time. However, for previously known blockchains, ultimately only a single branch may form the main consensus chain, and all other forks must be ignored or truncated, and only the main consensus blockchain is considered valid. By selecting the longest chain, consensus can be reached on which chain is valid. Thus, the longest chain represents the most work put into the blockchain to complete. Therefore, it is necessary to utilize the forked block 143 described herein to allow the creation of an allowed forked chain via the forked hash 149 and prove it as an authorized fork, thereby preventing participating nodes from ignoring or truncating the fork. Since each node can independently verify the forked blockchain, it will not be ignored, just as a verified main blockchain is not ignored after consensus is reached.

[0203] According to the described embodiments, Figure 2B Another example architecture 201 with additional details of a sidechain is depicted. In this example architecture, the blockchain consensus manager 191 and the permission manager 181 operate to support the read consensus and access control processes as described with respect to Figure 10as further described with reference to FIGS. 1-12.

[0204] More specifically, a mechanism is described herein by which a symmetric two-way fixed transfer from a parent blockchain 188 (e.g., the main chain) to a side chain 189 can be performed. The side chain can be a different blockchain protocol supported and provided by the host organization 110, or the side chain can be an external blockchain, public or private. The side chain exchange manager 193 of the host organization 110 participates as a node therein to allow access to and trading capabilities on the side chain.

[0205] In any case, according to the described embodiments, an inter-chain transfer between the parent blockchain 188 and the side chain 189 can be performed permissively according to the rules and conditions of each respective blockchain. It is noted that, as described herein, the perspective of each blockchain is interchangeable such that the side chain 189 described herein can consider itself the primary or parent blockchain and consider the described parent blockchain 188 a child blockchain or side chain. In any case, each blockchain operates independently but has a defined exchange mechanism through which assets, coins, tokens, value, or other payload information can be exchanged between them, which is created by transactions using the stated smart operations.

[0206] As shown herein, at operation 121, the side chain exchange manager 193 of the host organization can send parent chain assets as an output of the parent blockchain 188.

[0207] A simplified payment verification (SPV) proof 182 associated with the parent blockchain 188 assets is generated as an output and transmitted to the side chain 189. The SPV proof can include a threshold level of work and can be generated over a predetermined period of time, which can also be referred to as the confirmation period 122. The confirmation period 122 for the transfer between the chains can be the duration for which coins, tokens, or other exchange values are locked on the parent blockchain 188 before being successfully transferred to the side chain 189. This confirmation period can allow sufficient work to be created so that a denial of service attack becomes more computationally difficult in the next waiting period.

[0208] For example, consider an exemplary confirmation period that may be on the order of 1-2 days. In such an example, the confirmation period can be implemented as a per-side-chain security parameter that trades off cross-chain transfer speed in exchange for higher security. In cases where it is possible to achieve a sufficiently difficult proof of work condition, other shorter confirmation periods can be used to ensure sufficient security to protect the integrity of the blockchain and eliminate the possibility of fraudulent transactions.

[0209] Outputs created on the parent blockchain 188 can be specified via rules and configuration parameters (e.g., stored in the blockchain protocol proof section of each block of the parent blockchain 188) such that in addition to the rules governing transfers within the parent chain, any spending, transfer, or consumption of assets received by the output in the future is subject to additional conditions. For example, any release of assets received by the output may require additional conditions to verify the proof from the destination chain, e.g., rules for verifying the destination chain proof show that the destination chain has released the assets and show where the assets have been released. After an output is created on the parent blockchain 188, the user waits for a confirmation period while in-chain transfers 123 continue to occur. After waiting for the confirmation period 122, a transaction is created on the sidechain 189 with reference to the output from the parent blockchain 188.

[0210] The sidechain using the sidechain validator service (e.g., the block validator 192 of the host organization) is then provided with an SPV proof that shows that the parent chain assets were created and obstructed by sufficient work within the parent chain. The sidechain validator service (e.g., the block validator 192, if performed by the available service of the host organization) will then verify that the SPV proof associated with the parent blockchain 188 assets meets the required work threshold level indicated by the SPV proof and then generate sidechain 189 assets corresponding to the parent blockchain 188 assets.

[0211] At operation 124, the generated sidechain 189 assets can also maintain a predetermined contention period during which, if a reorg proof associated with the parent blockchain 188 assets is detected in the parent blockchain, the transfer will be invalidated.

[0212] The contention period at operation 124 can be a duration during which newly transferred tokens, coins, value, or payload data are not spent, accessed, or consumed on the sidechain 189. The predetermined contention period is implemented to prevent any possibility of double spending in the parent blockchain 188 by transferring previously locked coins, tokens, value, or payload data during a reorg. If at any point during this delay, a new SPV proof (referred to as a "reorg proof") is published that contains a chain with more aggregated work that does not include the block that created the SPV lock output 121, the transfer is retroactively invalidated. If no reorg proof is detected, the sidechain assets can be released. All participating nodes on the sidechain have an incentive to produce a reorg proof if possible because the result of an accepted false proof reduces the value of all sidechain tokens, coins, or the trust in the authenticity of the payload data stored on the sidechain 189.

[0213] Similar to the above, the exemplary competition period 124 can also be on the order of 1 - 2 days. To avoid these delays, as long as there is a liquid market, users can use atomic swaps for fungible transfers. If the assets being exchanged are unique or less common tokens, values, or payload data, atomic swaps will not be feasible and a sidechain transfer must be made, although it may require a 1 - 2 day waiting period.

[0214] Upon final release of the sidechain assets, the sidechain assets corresponding to the mainchain assets can then be transferred or consumed within the sidechain one or more times by in - chain transfers 123 of sidechain 189. While locked on the main blockchain 188, the assets can be freely transferred within the sidechain and do not require any further interaction with the main blockchain 188, thus allowing the sidechain 189 to operate completely independently again. Although as described above, the sidechain assets retain their identity as mainchain tokens, coins, values, or payload data and can, therefore, be transferred back to the originating main blockchain 188 from which the sidechain assets originated if needed. In some embodiments, the transfer is only classified as a single - hop such that the assets cannot be transferred to sidechain 189 and then again to another sidechain, where the need to prevent confusion of origin exists. This limitation depends on the particular blockchain protocol chosen and the defined exchange protocol (e.g., fixed conditions) established between the main blockchain 188 and the sidechain 189.

[0215] In the case where it is necessary to redeem the sidechain assets in the main blockchain 188, the sidechain assets can be sent to the output of the sidechain, as shown in operation 127. Accordingly, an SPV proof 182 associated with the sidechain assets is generated and transmitted to the main blockchain 188. The mainchain validator service (e.g., the block validator 192 of the host organization 110) can verify the SPV proof 182 associated with the sidechain assets. The verified SPV proof 182 associated with the sidechain 189 assets can include, for example, verifying that the SPV proof 182 associated with the sidechain assets meets the work threshold level indicated by the SPV proof 182 associated with the sidechain assets.

[0216] As previously mentioned, in step 126, the mainchain assets associated with the sidechain assets can remain in a second predetermined competition period, during which, if a re - organization proof 183 associated with the sidechain assets is detected in the sidechain, the release of the mainchain assets is rejected in operation 128, where the competition period ends. If no re - organization proof 183 associated with the sidechain assets is detected, the mainchain assets can be released.

[0217] If the verification fails, at operation 129, a new second SPV proof 184 associated with the sidechain asset can be received and verified by the parent blockchain 188 during a third predetermined competition period. If no reorg proof associated with the sidechain asset is detected during the third predetermined competition period, the parent blockchain 188 assets can be released, after which the parent chain assets can be freely transferred within the parent chain via the intra-chain transfer 123 shown at the far right of the parent blockchain 188 process.

[0218] Since a fixed sidechain may carry assets from many different blockchains, making assumptions about the security of other external blockchains can be problematic. Thus, according to some embodiments, different assets are required to be non-fungible in the sidechain (unless by an explicit transaction). Otherwise, a malicious user may potentially execute a fraudulent transaction by creating a valueless chain of assets, and then proceed to move the valueless assets from their valueless chain into the main blockchain 188 or a sidechain 189 with which the main blockchain 188 interacts and exchanges. This assumes that the valueless chain ensures a fixed exchange protocol with the sidechain. However, since the rules, configuration options, and security schemes of the sidechain 189 are not controlled by the parent blockchain 188 (assuming the sidechain is an external sidechain and not another blockchain protocol provided by the host organization 110), it cannot be deterministically known that the sidechain 189 with which it interacts does not contain such vulnerabilities. To eliminate such potential security vulnerabilities, according to the fixed exchange protocol, it may be required that the sidechain 189 treats assets from separate parent blockchains as completely separate asset types, as shown in the block type section of the blockchain protocol block of element 167 of Figure 1B as shown.

[0219] Using symmetric two-way fixed sidechain transfers, both the parent blockchain 188 and the sidechain 189 can perform SPV verification services on data with respect to each other, especially in the case where the parent blockchain 188 is provided by the host organization and the sidechain is an external sidechain for which the host organization is merely a participating node via the sidechain exchange manager (node) 193. Since the parent blockchain 188 clients (e.g., participating nodes) do not observe each sidechain, the user imports the proof-of-work from the sidechain into the parent chain to prove ownership. In symmetric two-way fixing, the situation is reversed.

[0220] By using such fixed sidechain transactions, independent blockchains become flexible enough to support many assets, including assets that did not exist when the chain was initially created. Each of these assets can be tagged with the transfer blockchain to ensure that the transfer can be correctly unwound (e.g., turned back).

[0221] According to certain embodiments, the duration of the competition period is based on the relative hashing power of the parent chain and the side chain such that the receiving side chain (or the parent blockchain with an incoming transfer) can unlock tokens, coins, value, or data payloads given an SPV proof of the one-day value of its own proof-of-work, which can, for example, correspond to several days of the proof-of-work of the sending blockchain. The security parameters implemented by the blockchain protocol of a particular side chain can thus be adjusted to the implementation of each particular side chain.

[0222] According to the described embodiments, the block validator 192 can require, utilize, or apply various types of consensus management to the blocks that need to be verified.

[0223] When a block containing a particular asset or transaction is to be added to the blockchain, the transaction type database is queried using the type of the particular asset or transaction to be added to the blockchain to determine the corresponding consensus protocol type to be used to submit the particular asset or transaction or the block containing the particular asset or transaction to the blockchain. For example, in the database, the transaction type of "loan" can be associated with the consensus protocol type of "Proof of Stake" (PoS), the asset type of "document" can be associated with the consensus protocol type of "Byzantine Fault Tolerance" (BFT), the asset or transaction type of "currency" can be associated with the consensus protocol type of "Proof of Work" (PoW), and the default transaction type used in the case of a transaction type not enumerated in the database can be associated with the default consensus protocol type, for example, PoS. Another transaction type can correspond to an asset type in which metadata is stored, perhaps typed as "metadata", while a closely related transaction type stores "related entities" as metadata within the blockchain, having the transaction type of "metadata" if it shares the same type as ordinary metadata, or the transaction type of "related entities" if separated. Additionally, the "stored record" transaction type can be used to store records with multiple different data elements embedded therein, which are typically defined by metadata specified by the application developer.

[0224] For example, when a block or a transaction within a block with a particular transaction type corresponding to an intelligent action utilizing a claim is to be added to the blockchain, the consensus protocol type used to submit the block or transaction therein to the blockchain is PoS, when a block or a transaction with a particular asset including the type "document" is to be added to the blockchain, the consensus protocol type used to submit the block or transaction therein to the blockchain is BFT, and when a block or a transaction of a particular transaction with a transaction type not specified in the database is to be added to the blockchain, the default consensus protocol type of PoS will be used to submit the block or transaction therein to the blockchain.

[0225] The selected consensus protocol type can be communicated to the nodes in the consortium for validating requests to add new blocks or transactions therein to the blockchain. According to some implementations, when the nodes in the consortium reach a consensus according to the selected consensus protocol to add a block or transaction therein to the blockchain and communicate it to the host, the host organization 110 receives verification of the request to add the new block or transaction therein to the blockchain.

[0226] Any relevant factors can be used to determine which nodes participate in the consensus protocol, including for example the selected consensus protocol itself, the computing resources of a particular node, the stake of a particular node in the consortium or the selected consensus protocol, the relevant (domain) knowledge a particular node has, whether that knowledge is internal (on-chain) or external (off-chain) to the blockchain or consortium, the previous or historical performance of a particular node (both in terms of speed and accuracy), or the non-participation in the selected consensus protocol, the block number of the new block added to the blockchain, the number of transactions in the new block, the size of the block, and the fiduciary or non-fiduciary nature of the assets or transactions in the block added to the blockchain.

[0227] According to a particular implementation, the host organization 110 receives weighted votes from each of one or more nodes in the peer network in response to the request, or in response to a voting request issued by the blockchain platform host, to validate or add a new block or transaction to the blockchain. These nodes are informed of the request via a blockchain protocol packet broadcast by the node that generated the request, or via communication with other nodes in the consortium or the blockchain platform host, which provides notification of the request in combination or in association with the voting request sent by the blockchain platform host. Then, when the sum of the received weighted votes exceeds a threshold, the host organization responsively validates or receives verification of the request to add the new block or transaction therein to the blockchain.

[0228] According to another implementation, a consortium of nodes participates in a private or permissioned blockchain, where each node is assigned a weight that will give its vote, e.g., based on domain (general) knowledge about the transaction or type of transaction, the new block that the node can add to the blockchain. Within such a permissioned blockchain, some nodes can be given a weight of zero, while other nodes can be given such a large weight that when combined with a limited number of other high-weight nodes, their vote approaches or even controls, depending on the particular implementation.

[0229] Before a node adds a transaction to a new block of a blockchain or before a new block including the transaction can be added to the blockchain, other nodes in the consortium vote on adding the transaction to a new block of the blockchain and / or adding the new block to the blockchain. When a majority of nodes agree that the transaction and / or new block is valid and can thus be accepted as a valid block on the main blockchain, the transaction and / or new block is added and accepted to the main blockchain, sometimes referred to as the main chain or the consensus chain. For example, while an invalid block may be added to the blockchain, such an invalid block actually creates a side chain where consensus is not reached and thus will never be accepted as a valid block added within the main or primary blockchain. Nodes are weighted such that a "majority" can be obtained or rejected based on the votes of one or more nodes participating in the private blockchain, i.e., a majority can be obtained from less than all the nodes participating in the blockchain.

[0230] According to this embodiment, the parties in the consortium agree on assigning a weight w to each node in the consortium, for example, based on the domain knowledge of a party and / or other criteria, including, for example, a party's participation in another blockchain or side chain. The total weight W of the nodes in the consortium is equal to the sum of the individual node weights w 1 +w 2 +...w n , where n is the number of nodes in the consortium. In one embodiment, the weight w of any one component or the ratio w / W can exceed or not exceed a certain threshold. The weight of each node is attributed to the vote of the corresponding node. If the sum of the weights of the voting nodes exceeds a certain threshold, the transaction / new block is verified and added to the blockchain. In particular, if the total weight W attributed to the votes reaches or exceeds the threshold (e.g., a plurality, majority, supermajority expressed as a percentage of w / W or an absolute value of w, whatever the consortium agrees on) to reach blockchain consensus, the transaction / new block is added. In this embodiment, the nodes in the blockchain do not need to unanimously agree to add a transaction and / or new block to the blockchain, and in fact, after the threshold is met, the nodes do not need to start or continue participating in the voting process.

[0231] In one embodiment, at least a minimum number of nodes k vote on adding a transaction to a new block of the blockchain or adding a new block including the transaction to the blockchain to mitigate the risk of fraud or double-spending or to prevent one node with a large weight w or a small group of nodes with a collective large weight from controlling the outcome of the vote. In one embodiment, the number of nodes k or the ratio k / n participating in the vote must meet a minimum threshold.

[0232] Figure 3A Depicts an example architecture 300 according to the described embodiment. In this example architecture, the blockchain consensus manager 191 and the permission manager 181 operate to support the read consensus and access control processes, as regardingFigure 10 which is further described with reference to FIGS. 1-12.

[0233] As depicted herein, there is again a host organization 110 that includes a hosted computing environment 111 having a processor and memory (e.g., within the execution hardware, software, and logic 120 of a database system 130) for operating a blockchain service interface 190 that includes a blockchain consensus manager 191 and a blockchain metadata definition manager 196. An index 316 is also depicted that provides an addressing capability for data, metadata, and records written to or transacted on the blockchain.

[0234] A plurality of tenant organizations 305A, 305B, and 305C (sometimes also referred to as customer organizations) are also depicted, each having tenant client devices 306A, 306B, and 306C via which tenants and their users can interact with the host organization 110 and its services. For example, a tenant organization can submit queries or data 311 to the host organization to request data from the blockchain or to store data on the blockchain, both of which can utilize the depicted index 316.

[0235] According to certain embodiments, the index 316 implements a Merkle tree index or a Merkle directed acyclic graph or “Merkle-DAG” tree index. In cryptography and computer science, a hash tree or Merkle tree is a tree in which each leaf node is labeled with the hash of a data block and each non-leaf node is labeled with the cryptographic hash of the labels of its children. Such a tree allows for the efficient and secure verification of the contents of a large data structure and thus provides significant efficiency in retrieving data from a large data structure. According to such embodiments, implementing the index 316 via a Merkle tree or Merkle-DAG tree recursively defines the index as a binary tree of hash lists where the parent node is the hash of its children and the leaf nodes are the hashes of the original data blocks. A Merkle-DAG tree allows for unbalanced trees and allows for data in the leaf (terminal) nodes.

[0236] Implementing the index 316 via a Merkle tree provides a way to prove the integrity and validity of the data stored in the index, requires relatively little memory or disk space because the proofs are computationally easy and fast, and furthermore, proving and managing the Merkle tree index only requires transmitting very little or a minimal amount of information over the network and is thus more operationally efficient in terms of network resource consumption. Although many blockchains rely heavily on the use of Merkle trees for block verification, the index 316 implemented using a Merkle tree is independent of the blockchain's block verification function and is used herein as a robust and efficient means of storing index 316 information.

[0237] Figure 3BDepicts another example architecture 301 according to the described embodiments. In this example architecture, the blockchain consensus manager 191 and the permission manager 181 operate to support the read consensus and access control processes, as further described with respect to Figure 10 FIGS. 1 through 12.

[0238] There is also a host organization 110 that includes a hosted computing environment 111 having a processor and a memory (e.g., within the execution hardware, software, and logic 120 of the database system 130) for operating a blockchain service interface 190 that includes a blockchain consensus manager 191 and a blockchain metadata definition manager 196. An index 316 is also depicted that provides an addressing capability for data, metadata, and records written or transacted onto the blockchain 399.

[0239] As shown, the index 316 is stored in the database system 130 of the host organization. However, the Merkle tree index 316 can also be written and stored on the blockchain itself, such that participating nodes of the blockchain that do not have access to the query interface 180 of the host organization can obtain the Merkle tree index 316 (when stored on the blockchain), and then directly reference the addressable blocks on the blockchain using the addresses obtained from the Merkle tree index 316 to obtain the desired records, data, or metadata, without having to traverse the entire blockchain or search the blockchain for the desired records.

[0240] As shown, another index 316 is shown in the last standard block 142 of the blockchain 399. Only one index 316 is required, but the index 316 can be allowed to be stored in either location.

[0241] The Merkle tree index 316, described in more detail below, shows a level 0 Merkle root with the hash ABODE, followed by a hash layer with two hash nodes, the first hash node having the hash ABC and the second hash node having the hash DE, followed by data blocks within the data leaves identified by the hashes A, B, C, D, and E, each data block containing addressing information for the addressable blocks on the blockchain.

[0242] Storing data and metadata on the blockchain 399 in combination with the use of the Merkle tree index 316 via the blockchain metadata definition manager 196 is more efficient than previously known data storage schemes because it is not necessary to search multiple blocks 141 and 142 of the blockchain to obtain data records. Instead, the index 316 is first searched to obtain the address of the desired block, which is very fast and efficient, and then the address obtained from the index 316 is used to directly obtain the record from the addressable blocks on the blockchain 399.

[0243] Due to the use of traditional techniques for storing data within a blockchain, the amount of data in the blockchain has grown explosively in terms of the total amount of stored data, creating scalability issues and resulting in problematic inefficiencies. The total amount of data stored in the blockchain often grows explosively or unsustainably over time because each time a stored record is updated or modified, the entire modified record needs to be rewritten back into the blockchain, and then that record becomes the latest record. However, all previous versions and copies remain within the blockchain, leading to the storage of a large number of duplicate data entries. The benefit of this approach is that the entire record can be retrieved from a single block of the blockchain without having to consult previous blocks of the blockchain for the same record. But this storage scheme is very inefficient in terms of storage.

[0244] Alternatively, according to traditional methods, only the modifications to the records stored within the blockchain can be stored, resulting in the modified data being written into new blocks on the blockchain, and the unmodified data can be retrieved from previous blocks of the blockchain. This approach reduces the total amount of data stored in the blockchain. Unfortunately, any data retrieval for the modified records requires checking and retrieving from multiple blocks of the blockchain, thus alleviating the problems of data redundancy and unsustainable growth, but trading this problem for the unpleasant problem of inefficient data retrieval.

[0245] In this way, the data management of the records and information stored in the blockchain 399 is improved. Additionally, metadata can be stored within the blockchain to provide additional information and context about the stored records, where each data record and the metadata describing such a data record are more easily retrievable by using the index 316. This metadata allows an enterprise or other entity to convert the data records retrieved from the blockchain back into a usable format, which is much easier than traditional methods that lose this context and metadata for any record written into the blockchain.

[0246] Figure 3C Depicts another exemplary architecture 302 according to the described embodiments. In this example architecture, the blockchain consensus manager 191 and the permission manager 181 operate to support read consensus and access control processes, as further described with respect to Figure 10 FIG. 12.

[0247] There is also a host organization 110, which includes a managed computing environment 111 having a processor and a memory (e.g., within the execution hardware, software, and logic 120 of the database system 130) for operating a blockchain service interface 190 including a blockchain consensus manager 191 and a blockchain metadata definition manager 196. The manager utilizes an index 316 to identify addressable blocks of the blockchain 399, and stores the required records via the blockchain. An exemplary stored record 390 at the second to last block of the blockchain 399 is also described.

[0248] Here, the stored record 390 stores student information, including a student first name 315A, a student last name 315B, a student phone number 315C, and a student ID 315D.

[0249] Once the stored record 390 is transacted to the blockchain, e.g., by adding an asset to the blockchain containing the stored record 390, the student data is persistently stored by the blockchain and can be accessed by participating nodes accessing the blockchain 399. However, when such data is retrieved, the stored record itself does not describe how to use such data, any specific format of such data, or how to verify such data. Therefore, it is further allowed to store metadata within the blockchain, which can then be used to define the format, verification means, and for such data. However, the storage of metadata only exacerbates the problem of searching for and retrieving data from the blockchain, as there are now the stored record 390 and the stored metadata 391 associated with that record. Thus, the indexing scheme implemented by the blockchain metadata definition manager 196 in combination with the use of the index 316 provides an organizing method that provides more efficient storage, retrieval, and verification of data stored on the blockchain.

[0250] According to one embodiment, the stored record 390 is thus converted into a more efficient format for storage within the blockchain. Consider a stored record 390 that stores student information. Initially, the stored record 390 may include only the student's first name 315A and the student's last name 315B and is then stored. Subsequently, the student record is updated to include the student's phone number 315C, and thus, the stored record 390 is updated and rewritten in its entirety to the blockchain, creating a second copy of the stored record 390, although updated, or alternatively, only a new portion is created and the student's phone number 315C is written back to the blockchain, referencing the previous record. In this case, the total storage amount is reduced, but retrieving the entire record requires searching the blockchain and finding multiple blocks to reconstruct the entire stored record 390 from those blocks. Even worse, if a student ID 315D is subsequently assigned, the stored record 390 needs to be updated again, resulting in writing another complete stored record 390 to the blockchain, causing three different versions and copies to now exist on the blockchain, or as before, only writing the new portion of the stored record to the blockchain 399. In this case, the stored record 390 is split into at least three blocks of the blockchain.

[0251] This splitting is problematic because if looking up student information, it may result in the first block containing the student's first and last names, the second block containing the student's last name as changed due to an update, the third block containing only the student's phone number, and so on. Therefore, it is necessary to traverse the blocks of the blockchain to pick up all the pieces in order to reconstruct the record before the entire stored record 390 can be used for any application that requires the data.

[0252] Figure 3D Another example architecture 303 according to the described embodiment is depicted. In this example architecture, the blockchain consensus manager 191 and the permission manager 181 operate to support the read consensus and access control processes as further described with respect to Figure 10 Figures 11 to 12.

[0253] According to one embodiment, the blockchain metadata definition manager 196 writes data or metadata to the blockchain by adding assets to the blockchain either in association with blockchain transactions or via new transactions with the blockchain. According to a particular embodiment, the transaction has a specific transaction type, for example, defined as a blockchain storage transaction type, which triggers the execution of a smart contract to perform the verification of the transaction and specifically the verification of the data or metadata within the assets being added to or transacted on the blockchain.

[0254] For example, such a smart contract 363 can be executed via a blockchain service interface 190 of a host organization that performs verification and then trades new assets onto the blockchain based on successful verification of data or metadata stored within the assets of the blockchain. As shown herein at element 363, the smart contract executes and verifies transactions of the blockchain. Subsequently, a valid transaction 364 is added to or traded onto the blockchain 399.

[0255] Figure 4A Depicted is another exemplary architecture 400 according to the described embodiments, having additional details of smart contracts implemented with a blockchain created using a smart flow contract engine 405. In this example architecture, a blockchain consensus manager 191 and a permissions manager (not shown) operate to support read consensus and access control processes, as further described with respect to Figure 10 FIGs. 6 through 12.

[0256] Specifically, depicted herein within the host organization is a blockchain service interface 190, which now includes a smart flow contract engine 405 and additionally includes a GUI manager 410.

[0257] Since blockchain uses a distributed ledger, the creation and execution of smart contracts can be technically complex, especially for novice users. Thus, a smart flow visual designer allows for easier implementation of smart contracts. The resulting smart flow contracts have mathematically verifiable auto-generated code, such as created by a blockchain transformer 430, relieving customers and users from having to worry about the programming languages used in any given blockchain protocol. Additionally, the smart flow contract engine implements a visual designer that coordinates with the blockchain transformer 430 to generate the necessary native code that can be executed on each participating node of the blockchain, further allowing for easy handling and verification of smart contracts. According to certain embodiments, each smart flow contract utilizes a verifiable encryption scheme based on mathematical code.

[0258] The process designer provides a simple, intuitive, web-based interface for users to design applications and customize processes through a GUI-based guided process design experience. The process designer can even enable novice users to create complex functionality without coding expertise or familiarity with blockchain.

[0259] The GUI manager 410 presents a process designer GUI 411 to the user device, through which the user can interact with the host organization. The smart flow contract engine 405 collaborates with the GUI manager to interpret the various rules, conditions, and actions provided by the user to generate a smart flow contract, which is then transformed or written to the target blockchain protocol.

[0260] Through the Process Designer GUI 411, a user can fully define how a particular process, event, protocol, contract, purchase, or some other transaction needs to occur, including dependencies, checks, required process inputs and outputs, triggers, etc., using visual flow elements.

[0261] Using the Process Designer GUI 411, the user simply drags and drops operation blocks and defines various conditions, "if, then" events, e.g., if this event occurs, then take this action. As described herein, there are various user-defined smart contract blocks, including user-defined conditions 421, events to monitor 422, "if, then, else" triggers 423, and asset identifiers 424.

[0262] Once the user has completed defining the flow including all its operation blocks, conditions, triggers, and events, the Smart Flow Contract Engine then takes each individual block and transforms it into the native target blockchain protocol via the Blockchain Transformer 430, and then generates a transaction to write the transformed smart flow contract to the blockchain 440 via the Blockchain Service Interface 190.

[0263] Once the transaction is on the blockchain, each participating node of the blockchain will have a copy of the smart contract, so if any given event occurs, all participating nodes can view the corresponding triggers or rules or conditions, and some of those nodes can then take action based on the events defined in the smart contract.

[0264] The blockchain service interface 190 of the host organization provides access to different blockchains to customers, users, and subscribers, some of which are managed by the host organization 110, e.g., private blockchains, and others are public blockchains accessible through the host organization 110, and the host organization participates as a node on such public blockchains. In any case, each blockchain uses a different blockchain protocol and has different rules, configurations, and possibly different languages, and the interface must communicate with the corresponding blockchain through these languages. Thus, the Blockchain Transformer 430 described herein transforms the user-defined smart contract blocks into the native or required language and structure of the target blockchain 440, on which the final smart contract will be written or transacted.

[0265] Once the smart contract is transacted and broadcast to the blockchain, it is executed within the blockchain, and then the provisions set forth by the user-defined smart contract blocks are executed and implemented.

[0266] According to one embodiment, the Salesforce.com visual process designer is utilized to generate user-defined smart contract blocks, which are then transformed into blockchain smart contracts. According to other embodiments, different visual process designers are utilized, and the Blockchain Transformer 430 transforms the user-defined smart contract blocks into blockchain smart contracts.

[0267] The resulting local blockchain protocol smart contract elements 435 can be included in the code, structure, or language specified by the blockchain 440 into which the smart contract will be written. For example, if the smart contract will be written to Ethereum, the blockchain converter 430 must convert the user-defined smart contract blocks into the "Solidity" programming language compliant with Ethereum. Solidity is a high-level contract-oriented language specifically designed for implementing smart contracts on Ethereum. Influenced by C++, Python, and JavaScript, the language is aimed at the Ethereum Virtual Machine (EVM). Smart contract elements include support for voting, crowdfunding, blind auctions, multi-signature wallets, and many other functions.

[0268] Conversely, if the smart contract is to be written to Hyperledger, the language is different, using the Go programming language, which allows the use of the distributed ledger blockchain for smart contracts and other functions.

[0269] Although smart contracts are beneficial and are supported by many blockchain protocols, they can be difficult to implement to meet the requirements of programming in different languages depending on the specific blockchain targeted. Therefore, users must not only understand the programming structure but also the special syntactic nuances of the programming language required by the blockchain protocol in question.

[0270] By leveraging the Smart Flow Contract Engine 405, even novice users can create a compatible smart contract by generating smart contract elements with the Process Designer and then using the blockchain converter 430 to actually render the local blockchain programming language code containing the user-defined smart contract elements. Subsequently, the blockchain service interface 190 processes the smart contract to blockchain transactions.

[0271] For example, consider a vendor selling products to Home Depot and wanting to enter into a smart contract with Home Depot using Ethereum. The vendor logs into the host organization, assuming he is an authenticated user and has access to the cloud subscription service, and then accesses the Smart Flow Contract Engine 405 through which the user can generate any flow he desires. When done, the user instructs the blockchain service interface 190 to execute the smart contract via the Process Designer GUI 411, causing the Smart Flow Contract Engine to convert the user-custom designed smart flow contract into "Solidity" code compliant with Ethereum. Subsequently, the smart contract is written to the blockchain for execution. The vendor does not need to know how to program or even understand the details of the blockchain transactions. Instead, the cloud-based service accessible through the host organization 110 eliminates the complexity of the process and presents the user with a simple Process Designer GUI 411 through which all necessary operations can be performed.

[0272] According to such an implementation, writing a smart contract to a blockchain requires storing the metadata defining the smart contract on the blockchain, as supported by a particular blockchain protocol. According to one implementation, when a transaction occurs on a blockchain having the metadata of a smart contract, the smart contract is executed, and then various user-defined smart contract events, conditions, and operations are realized.

[0273] According to certain implementations, user-defined smart contracts that have been transformed and transacted onto a blockchain trigger events within a host organization.

[0274] For example, consider an agreement between Walmart and Nestle where goods must always be transported in a climate-controlled trailer within a temperature range of 35 to 39 degrees Fahrenheit. Additionally, if the temperature exceeds 39° at any time, then payment is void.

[0275] Within a host organization, a customer relationship management (CRM) platform defines and manages various relationships and interactions among customers, suppliers, leads, vendors, etc. The term CRM generally refers to a CRM system, which is a tool that helps businesses with contact management, sales management, workflows, productivity, etc.

[0276] In the above example of Walmart and Nestle, the CRM system will have the shipping requirements. Since the host organization monitors the shipment via the CRM system and subscribes to shipment events, such as temperature data, the CRM system will monitor and become aware of temperature-related events for a particular shipment, and then that event can be automatically linked back to the smart contract. More specifically, since the host organization operates as a participating node of the blockchain on which the smart contract is being executed, the host organization is able to see the terms and conditions of the smart contract accessible via the blockchain as well as the CRM requirements for the shipment, such as the required temperature range.

[0277] Therefore, once a smart contract condition violation occurs, the host organization will synchronize the violation with the CRM system (which is not part of the blockchain) according to the terms of the executed smart contract to stop payment related to that particular shipment.

[0278] According to one implementation, the blockchain sends an event that the host organization's CRM system will listen for, and then based on what is specified by a user-defined smart contract flow, some substantial action is taken based on that event. In terms of the above example, the substantial action is to stop paying the shipping fee according to the smart contract regarding the blockchain.

[0279] Each party participating in the execution of the smart contract will likely subscribe its respective CRM system to blockchain events associated with the execution of the smart contract, and thus, both parties may be aware of the event.

[0280] According to one embodiment, logic is written into the CRM system to facilitate specific actions in response to blockchain events. In other words, non-blockchain actions can be carried out based on the blockchain smart contract being executed.

[0281] Figure 4B Depicts another example architecture 401 according to the described embodiment, with additional details of a blockchain-implemented smart contract created using the Apex transformation engine 455. In this example architecture, the blockchain consensus manager 191 and the permission manager (not shown) operate to support the read consensus and access control processes, as further described with respect to Figure 10 FIGs. 6 to 12.

[0282] As described herein, there is an Apex transformation engine 455 within the blockchain service interface 190.

[0283] Apex is a programming language provided by the Force.com platform for developers. Apex is similar to Java and C# in that it is a strongly typed, object-oriented language that uses dot notation and curly brace syntax. Apex can be used to perform programming functions in most processes of the Force.com platform, including custom buttons and links, event handlers for record insertion, update, or deletion, custom controllers via scheduling or via Visualforce pages.

[0284] Developers of the Salesforce.com host organization often utilize Apex to implement SQL programming, database interaction, custom events for GUI interfaces, report generation, and numerous other functions. Thus, there is a large number of developers associated with the host organization 110 who are very familiar with Apex and prefer to program in the Apex language rather than having to use a less familiar programming language.

[0285] The problem is that smart contracts must be written in the native language of the blockchain protocol in order to execute the smart contract on the corresponding blockchain.

[0286] For example, as described above, if a smart contract is to be written for Ethereum, the smart contract must be written using the Ethereum-compliant "Solidity" programming language.

[0287] Like smart contracts, Apex is also a type of metadata. Thus, the Apex transformation engine 455 allows developers familiar with Apex to program their smart contracts for the blockchain using the Apex programming language rather than using the native smart contract protocol programming language.

[0288] As described herein, developers write their smart contracts using the Apex programming language and then provide Apex input 456 to the Apex conversion engine 455 via the depicted Apex code interface, e.g., by uploading a text file in which the developer's Apex code is embedded.

[0289] The Apex conversion engine 455 parses the Apex input 456 to identify the Apex-defined smart contract blocks and breaks them down in preparation for conversion. As described herein, there are also Apex-defined conditions 471, Apex events 472 to be monitored, "if-then-else" Apex triggers 473, and, as previously described, asset identifiers 424 that are not Apex-specific.

[0290] The Apex-defined smart contract blocks are then provided to the Apex block converter 480, which converts them into native blockchain protocol smart contract elements 435 of the target blockchain protocol. Once converted, the process is as described above, where the converted smart contract is transacted and broadcast 445 to the blockchain 440 for execution.

[0291] Unlike the visual flow GUI, since Apex is procedural, users writing Apex code can write programs to execute on the smart contract and are not limited by the functions available within the visual flow GUI.

[0292] According to a particular implementation, the Apex input 456 is first converted into JavaScript and subsequently into a specific blockchain API interface suitable for the target blockchain protocol on which the smart contract will execute.

[0293] According to another implementation, listening events can be written and provided in the Apex input 456 using the Apex language; however, such listening events will be executed by the host organization. Thus, the Apex block converter 480 isolates any identified Apex listeners 478 and returns them to the host organization 110 implemented in an appropriate CRM system or other event monitoring system where they may be located. In this way, developers can write the Apex input 456 as a single program without having to separately create the smart contract and the associated listening events in separate systems.

[0294] Figure 4C Another example architecture 402 according to the described implementation is depicted, which has additional details of an SQL filter and query converter that uses the Apex conversion engine 455 for persistent storage of records to the blockchain. In this example architecture, the blockchain consensus manager 191 and the permissions manager 181 operate to support the read consensus and access control processes, as further described with respect to Figure 10 FIG. 12.

[0295] As can be seen herein, there is now an Apex transformation engine 455 that will receive SQL filters or SQL queries submitted by a query interface 180 for a host organization 110. However, for records persisted by a blockchain 440, the query interface 180 needs to delegate some work to a blockchain service interface 190.

[0296] The problem is that since a blockchain is not a relational database system, it simply has no ability to receive, process, or transact SQL-based queries or filters. However, the host organization 110 provides on-demand and cloud-based services to its users, at least in part, on the premise of providing greater technical capabilities to the users (e.g., allowing the use of the blockchain 440) but using simplified tools, so as not to burden the users of the host organization with the technical complexity.

[0297] Therefore, the host organization implements the Apex transformation engine 455 described herein, which operates in conjunction with an Apex code interface 454 to receive an SQL filter / query 457 from the query interface 180 of the host organization 110.

[0298] The SQL filter / query 457 is transmitted into the Apex transformation engine 455 as part of its block for transforming SQL query and filter terms defined in Apex. The engine is now described as including an SQL term mapper 458 that can read, parse, and analyze the input SQL filter / query 457 into its components, so that appropriate asset identifiers 424 that actually store various payload data in the assets of the blockchain can be referenced, and thus the underlying data records can be retrieved from the blockchain 440.

[0299] The parsed terms and appropriate asset identifiers 424 are then transmitted through an Apex block converter 480 and then converted into a local blockchain protocol for payload data retrieval at an element 459.

[0300] Then, by transacting a blockchain read request 461 onto the blockchain 440, the local blockchain protocol for payload data retrieval at the element 459 can be executed against the blockchain 440, resulting in the return of payload data retrieved from the blockchain at an element 462.

[0301] The record set represented by the payload data retrieved from the blockchain 462 is not in a suitable format for the SQL filter / query 457; however, it does include the data necessary to ultimately implement the received SQL filter / query 457. In other words, the payload data retrieved from the blockchain's assets includes data representing the records being queried, although in a format that is completely incompatible with the blockchain's format, typically the data is hashed or serialized and thus needs to be converted back to a readable format based on the metadata 489 describing the storage data structure retrieved from the blockchain.

[0302] Next, the payload data retrieved from the blockchain 462 is returned to the Apex transformation engine 455, which converts the data from the blockchain into a readable format. Next, the transformed records are transmitted to the database system 130 within a temporary view 463 of the returned record set, at which point the SQL query / filter (e.g., element 457) is applied to the temporary view 463 at the database system 130, either using the original SQL filter / query terms or using the transformed and optimized SQL filter / query terms, in order to return the originally requested record set in response to the input SQL filter / query.

[0303] In this way, the user can thus issue SQL queries / filters against the data stored on the blockchain 440 without the user having to know how to interact with the blockchain or how to transact with the blockchain, in fact, without even the user having to know that the data is stored on the blockchain 440.

[0304] According to one embodiment, an SQL filter / query 457 request is used to query or filter data stored on the blockchain, and more specifically, the requested filtering is accomplished based on the relationships between data elements stored within the blockchain.

[0305] However, it is noted that since the blockchain is not a relational database system, there is no "relationship" structure between the data elements of the payload data stored in the blockchain assets.

[0306] However, such an SQL filter / query 457 request can be implemented by the host organization 110 based on defined metadata 489, which is declared, defined, and stored into the blockchain as blockchain transaction metadata to describe, for example, the structure and relationships of the data written to the blockchain by the declared application. Such metadata can be defined through the creation and declaration of an application according to related embodiments, as described in more detail below.

[0307] In this way, entities that are related to each other can be defined, similar to the way entities are related to each other in a relational database system, except that such records are written to a DLT platform such as blockchain 440. It should be noted that the records within a blockchain are not inherently related to each other like in a relational database, but rather the data and the metadata that define these records need to be retrieved.

[0308] Thus, according to such an implementation, the Apex transformation engine 455 represents the relationships between the entities defined for the blockchain transformation, which in turn allows the database system 130 and / or the query interface 180 of the host organization to perform the necessary JOIN operations on the data to form a unified table or a JOIN table view, and then SQL filter / query 457 requests can be applied to it.

[0309] According to a specific implementation, any transaction written to the blockchain causes the leaf nodes to persist the data as a database representation stored off-chain, which can then be associated by the Apex transformation engine 455 with the RDBMS format.

[0310] According to such an implementation, the relational table is then created by the Apex transformation engine based on the payload data retrieved from the blockchain and the metadata 489 that was transacted on the blockchain and retrieved simultaneously with the retrieved payload data.

[0311] According to the described implementation, whenever the metadata that defines the structure of such data changes, the metadata change is updated by transacting the new metadata definition to the blockchain. Thus, any such change to the metadata is automatically translated into any RDBMS-formatted table constructed from the retrieved data, because the Apex transformation engine retrieves and references the updated metadata definition.

[0312] According to such an implementation, once the RDBMS-formatted table is constructed by the Apex transformation engine, an SQL filter / query 457 request is made on the database system 130 of the host organization 110 for the constructed RDBMS table. According to another implementation, the RDBMS table is first established by retrieving the metadata 489 from the blockchain, but the payload data is not retrieved. Subsequently, the SQL filter / query 457 request is applied to the RDBMS-formatted table, and based on this query, the Apex transformation engine identifies the appropriate asset identifier 424 for storing the payload data on the blockchain 440, and the corresponding block number of the data on the blockchain is identified before subsequently retrieving the payload data from the blockchain and populating the retrieved data into the structured but empty previously formatted RDBMS table. Then, the retrieved payload data is populated into the empty RDBMS table to facilitate the application of the SQL filter / query 457 request to the now-populated RDBMS table to fulfill the request.

[0313] In this way, it is possible to query the data of the blockchain using SQL queries and to filter using SQL based on relationships, although the authoritative source of the data is ultimately the payload data of the assets written to the transactions on the blockchain 440 rather than a relational database system.

[0314] By creating a separate table view that has the block ID and block number saved to the blockchain for any changes, a faster lookup can be performed using that separate view while verifying that the reference data is up-to-date by checking the data of the blockchain using the block ID, without having to perform a time-intensive search on the blockchain for the data in question, since the block ID allows direct reference to a single block.

[0315] It should be clear that, according to such an implementation, there are two queries. A first SQL-based query is performed on a temporary view in the database system through an RDBMS-formatted table, followed by a fast lookup of the block ID and block number. Then, the Apex transformation engine returns to the blockchain to verify that the queried data is current and accurate based on a table lookup of the block ID and block number, which are maintained by the Apex transformation engine as asset identifiers 424.

[0316] Furthermore, since the data is represented in RDBMS format, it also allows JOINs to be performed on the data stored within the blockchain. Such JOINs are important because they allow analysis to be performed on the data stored in the blockchain that would otherwise not be possible.

[0317] According to such an implementation, the RDBMS-formatted table representation in the database system 130 is not an immutable table. However, it is restricted in such a way that no entity has the right to change the RDBMS-formatted table except for the transaction replay mechanism of the Apex transformation engine discussed below.

[0318] Therefore, only the blockchain monitoring / event listener component can update the table and perform the necessary synchronization from the authoritative source of the blockchain back to the RDBMS-formatted table and the temporary view in the database system 130 of the host organization whenever the event listener observes a change in the metadata or a change in the persistent data stored on the blockchain.

[0319] According to a further implementation, there are additionally: a transaction replay mechanism for handling SQL filter / query 457 requests when the blockchain is inaccessible; and a recovery mechanism for recovering blockchain data in the event that the blockchain becomes permanently inaccessible or the data on the blockchain is highly unlikely to be corrupted.

[0320] According to such an implementation, the playback mechanism allows the SQL filter / query 457 requests to be processed by the host organization 110 without verifying the data stored within the blockchain, to verify that the temporary host organization's view of the data is up-to-date.

[0321] When the blockchain 440 is inaccessible, SQL filter / query 457 requests may be received. Therefore, the Apex transformation engine, together with the host organization's database system 130, records all transactions that add, update, or delete data for the temporary view. When such changes are transacted on the blockchain, these changes are recorded as a series of updates and maintained within the host organization. These changes represent a non-authoritative source but can still be referenced.

[0322] Therefore, in the case where the blockchain 440 is inaccessible, the database system 130 can replay the recorded changes to the data to update the temporary view of the data at the host organization with the replayed add, delete, and update transactions, thus synchronizing the temporary view with the authoritative source of the same data stored on the blockchain. Once the replay is complete, the SQL filter / query 457 requests can be processed against the temporary view of the data without the need for intermediate operations by the Apex transformation engine to locate the asset identifier 424 for the data stored on the blockchain to verify and confirm that the data is up-to-date.

[0323] Therefore, SQL-based language queries and filters can be used to query the blockchain and satisfy the SQL filter / query 457 requests, even in the case where the blockchain is temporarily inaccessible.

[0324] Such a transaction playback mechanism allows the RDBMS formatted tables and temporary views to self-heal and return to a fully recovered state at the blockchain level without reference to the blockchain. For example, the host organization's system will recognize that the blockchain nodes are down or inaccessible, and therefore, will replay all observed transactions and reapply the metadata to determine the correct state, similar to the way all participating nodes on the blockchain would self-update, except that the nodes do not reference the blockchain and may be much slower than directly obtaining the status data and current information from the blockchain. Despite the speed loss, the benefit is that valid data can still be obtained even though the blockchain nodes are down.

[0325] According to another implementation, in the case where the blockchain 440 becomes permanently inaccessible, there is a recovery and restoration mechanism for the data stored on the blockchain. Although this scenario is unlikely to occur, it does provide an opportunity to perform data recovery if necessary. It also allows the ability to perform data migration from the blockchain 440, where the data is saved as the authoritative source to a new blockchain if the host organization or user wishes to relocate their data.

[0326] The operation of this implementation is similar to the playback of all recorded transactions described above, with the addition of the extra content that once the playback is complete, all metadata 489 and the records from the temporary view at the database system 130 of the host organization are then written onto the restored blockchain 440 or written into a new blockchain repository, thereby creating a new asset on the blockchain, in which the records are persisted as payload data, and updating the block ID and asset identifier 424 of such data, so as to fully recover or repair all the data on the blockchain 440 after a catastrophic failure or according to an intentional data migration.

[0327] According to a specific implementation, the event listener of the host organization identifies changes in the metadata, and this event listener looks for changes in the blockchain that affect any asset storing such metadata. Thus, once the metadata is submitted to the blockchain based on the consensus on the transaction assets, the blockchain service interface will obtain the updated version of the metadata, such that the RDBMS formatted tables for the temporary view within the host organization 110 can be rebuilt based on the new version of the metadata. For example, the metadata is transformed into SQL data definition language, and then based on the metadata, the empty RDBMS data tables or the RDBMS data representations of the tables to be populated are rebuilt or reorganized according to the new metadata using the transformed SQL data definition language.

[0328] According to the described implementation, whenever a blockchain event occurs, encrypted data is returned, and then the data is saved in the metadata format. The encrypted data is converted into a format that other systems can understand, for example, using SQL data definition or REST standards or some other standardized decryption format for other systems to reference and use. Then, this data is pushed out to other systems that rely on the data stored in the blockchain, and this data is now inaccessible, such that these systems can also synchronize any other databases with a temporary view of the data, or synchronize any list of entities of the events from the blockchain that affect this data. For example, the analysis engine can continuously listen to the data feed from the event listener to understand the changes in the blockchain, so that the analysis engine can be fed. Similarly, the AI engine can listen to the feed so that training data, etc. can be input to the AI.

[0329] Figure 5A Another exemplary architecture 501 according to the described implementation is depicted. In this example architecture, the blockchain consensus manager 191 and the permission manager 181 operate to support the read consensus and access control processes, as further described with respect to Figure 10 FIGs. 11 to 12.

[0330] Traditional solutions allow for the storage of free-form text within the assets of a blockchain transaction. For example, such data is stored within the payload portion of the asset. However, since such data is not verified, there is a risk that corrupted or incorrect data is written to the blockchain and subsequently retrieved assuming such data is valid.

[0331] By executing a smart contract to perform transaction verification for entities or assets transacted on the blockchain, it is possible to enforce various masks, data structures, data types, data formats, or other requirements before such data is written to the blockchain 399.

[0332] According to such an implementation, the blockchain metadata definition manager 196 performs smart contract verification 563 and rejects 565 the transaction if the data to be written to the blockchain does not meet the requirements set forth by the executed smart contract. For example, the transaction is sent back to the query interface to notify the initiator of the transaction. Otherwise, assuming the transaction complies with the smart contract execution, the transaction is verified 564 and written to the blockchain.

[0333] According to one implementation, the smart contract applies data masking to verify the compliance of data or metadata to be written to the blockchain. In other implementations, the smart contract enforces rules applied to the data as part of the verification process.

[0334] According to one implementation, the smart contract is executed as part of a predefined smart contract system that executes with any blockchain that allows the use of smart contracts, and the smart contract performs the necessary data verification.

[0335] According to one implementation, the data or metadata to be written to the blockchain 399 is converted to JSON format to improve storage efficiency. JavaScript Object Notation (JSON) provides an open standard file format for transmitting data objects consisting of property-value pairs and array data types or any other serializable values using human-readable text. This is a very common data format used for asynchronous browser-server communication, including as an alternative to XML in some AJAX-style systems. Additionally, since JSON is a language-independent data format, it can be verified by smart contracts on a variety of different smart contract execution platforms and blockchain platforms regardless of the underlying programming language used by such platforms.

[0336] Thus, as described herein, the data or metadata to be written to the blockchain can be converted to JSON format 566 (e.g., within the database system 130 of the host organization 110), and then the verified and converted JSON data is transacted onto the blockchain.

[0337] Figure 5BDepicts another example architecture 502 for performing dynamic metadata verification of stored data according to the described embodiments. In this example architecture, the blockchain consensus manager 191 and the permission manager 181 operate to support the read consensus and access control processes, as further described with reference to Figure 10 FIG. 12.

[0338] According to certain embodiments, it is desired to improve the efficiency of data stored on the blockchain 399. Accordingly, all new transactions having data to be written to the blockchain perform a data consolidation 569 process before writing the new data to the blockchain. This is performed by first obtaining the old data, e.g., from a previously written storage record of the blockchain, e.g., pulling the obtained data 566 into the database system 130 of the host organization, and then merging the obtained data 566 with the new valid data 567 that has been checked by an executed smart contract, resulting in consolidated data 568. The consolidated data 568 is then written to the blockchain, e.g., by embedding the consolidated data 568 into a new asset added to the blockchain, or by updating an existing asset and replacing the payload portion of the existing asset with the consolidated data 568, thereby storing the entire updated and verified record on a block of the blockchain for more efficient retrieval.

[0339] According to one embodiment, the data consolidation 569 process is performed by a static library (protobuf) generator 599, which also reduces the total size of the data in addition to merging the obtained data 566 with the newly verified data 567. For example, via performing dynamic static library generation on the obtained data 566 with the new valid data 567, the data becomes very small and efficient.

[0340] Protocol buffers (referred to as static libraries or static libraries f) provide a means for serializing structured data, thereby converting the obtained data 566 and the newly verified data 567 into a consolidated serialized byte stream at the static library generator 599. This has the additional benefit of allowing the consolidated data to be encrypted and provided in a byte stream format that can be easily used by any other application that later retrieves the stored data. The static library generator 599 utilizes an interface description language that describes the structure of the data to be stored with the program, and the program generates source code according to this description for generating or parsing the byte stream representing the structured data represented by the obtained data 566 and the newly verified data 567.

[0341] This method can store and exchange various structured information. For example, software developers can define data structures (e.g., retrieved data 566 and newly verified data 567), and then the static library generator 599 serializes the data into a binary format that is compact, forward and backward compatible, but not self-describing (i.e., without an external specification, there is no way to tell the name, meaning, or full data type of the fields), thus providing a layer of encryption and data security for the stored data.

[0342] In this way, the static library generator 599 improves the efficiency of network communication and enhances the interoperability with other languages or systems that may reference this data in the future.

[0343] Therefore, consider the example of a student storage record with a student's first name, last name, phone number, and student ID described previously.

[0344] According to a specific implementation, the process starts with generating metadata for the student record from a static library provided and defined by an application attempting to store data on the blockchain, resulting in protocol buffer student record metadata or serialized (e.g., JSON) compatible student record metadata. Next, the student data in the storage record is verified against the metadata to ensure compliance (e.g., by executing a smart contract), and then a static library for the student data in the storage record is generated, resulting in protocol buffer student record data. Next, the protocol buffer or serialized metadata describing the student record and the protocol buffer or serialized data of the student record are both written to the blockchain. Thus, the protocol buffer or serialized version of the stored data leads to more efficient storage of such data on the blockchain. According to such an implementation, the metadata defined by the application for verification purposes is also stored in its protocol buffer or serialized version, resulting in efficient storage of the protocol buffer or serialized metadata on the blockchain.

[0345] According to such an implementation, the data merging 569 process includes adding new fields and new data to the stored record, which is then rewritten to the blockchain 399, and subsequently the new fields are dynamically verified using the metadata.

[0346] For example, according to such an implementation, the process includes obtaining the acquired data 566, adding in a new field, for example, adding a newly assigned universal ID for the student (such as a Universally Unique Identifier (UUID) or a Globally Unique Identifier (GUID), as a 128-bit number for identifying information within the host organization) to the previously stored first name, last name, and phone number of the student, so as to generate the merged data 568. Subsequently, by executing a smart contract, the process dynamically validates the merged data 568 based on the metadata. If the metadata has been previously written to the blockchain, there is no need to update or store the metadata again, which may be the case for the merged data 568, and the merged data will constitute an updated record. Therefore, only the merged data 568 is written to the blockchain. If the data is new (e.g., not acquired and not merged), the process dynamically validates the new data using the metadata provided by the application, and then stores the new data and the metadata to the blockchain.

[0347] The metadata defined by an application attempting to store data to the blockchain can specify, for example, that a student record has three mandatory fields and one optional field, e.g., the mandatory first name, last name, and student ID, and the optional student phone number, thus allowing the validation of the data to be written to the blockchain. The metadata can further define the format, data masking, or restrictions of the data fields, e.g., the name cannot have numbers, the phone number must have a certain number of digits, etc.

[0348] Multiple different applications can store data to the blockchain, and each of the multiple different applications defines different metadata for their respective stored records, thus allowing the smart contract to perform different types of data validations based on the different defined metadata for the corresponding applications. For example, a student record with a student name, phone number, UUID will have different metadata, requiring different data validations for a credit card record with a credit card number, expiration date, security code, etc. In any case, the same process is applied because the dynamically applied metadata validation process is independent of the underlying data as long as such data conforms to the metadata defined for the data record to be stored.

[0349] Figure 5C Another example architecture 503 for storing related entities according to the described implementation is depicted. In this example architecture, the blockchain consensus manager 191 and the permission manager 181 operate to support the read consensus and access control processes, as further described with respect to Figure 10 FIG. 12.

[0350] In the example of the saved student record as described above, there is a student record saved to the blockchain, for example, with a student first name, a student last name, a student phone number, and a student ID. Metadata defined by the application attempting to store the student record is also stored, and this metadata is used for the dynamic verification of the student record.

[0351] According to a further embodiment, related entities are stored on the blockchain and linked to previously stored records. For example, consider a student record stored on the blockchain for which a new student transcript is provided.

[0352] As described herein, a process 579 of linking related entities is performed, wherein the retrieved data 572 is modified to add a UUID field identifying the related entity, providing a link between the related entity 571 and the data record previously stored on the blockchain and retrieved 572 for modification. This now results in data with a UUID field 574 that has not yet been stored. Next, the data with the UUID field 574 that links and identifies the new related entity 571 is then written and stored within the blockchain, resulting in the stored record now having the original data of the stored record, as well as the UUID field 574 that links and identifies the new related entity. Next, the related entity 571 is written to the blockchain as metadata with the same UUID data field, thereby allowing the related entity 571 to be subsequently retrieved from the blockchain by first referring to the UUID in the stored record and then retrieving the linked related entity 571 stored as metadata in the blockchain.

[0353] Thus, if a student record defines a student's name, phone number, and student ID, the student's transcript can be stored on the blockchain as metadata. A new UUID is automatically generated for the transcript to be stored, and then in the student record, the related entity field in the student record is updated to store the new UUID generated for the transcript, thereby linking the student record updated with the related entity field identifying the transcript UUID to the separately stored transcript written as stored metadata in the blockchain. In this way, any number of related entities can be added to the blockchain, each related entity stored as metadata within the blockchain and linked to another stored record via the data field of the related entity. Multiple related entity fields can be added to any record, each field linked and identifying the related entity in question using a different UUID. For example, if a student has a transcript and a medical record, each is saved separately as metadata to the blockchain, each uniquely identified by a separate UUID, and each UUID is updated as a separate related entity field in the student's stored record. As previously described, the updated record with the related entity field having the UUID identifying the separately stored related entity can be stored in its protocol buffer or serialized version.

[0354] Figure 6A depicts another example architecture 601 for obtaining stored records from addressable blocks using an indexing scheme according to the described embodiments. In this example architecture, the blockchain consensus manager 191 and a permissions manager (not shown) operate to support read consensus and access control processes, as further described with respect to Figure 10 FIGS. 3 through 12.

[0355] Using a Merkle tree index 616 or a Merkle DAG tree index allows obtaining stored records from the blockchain by going to a specific block of the blockchain based on the Merkle tree index, thus allowing for a more efficient way of obtaining stored records. For example, if the Merkle tree index identifies the address of one of the many addressable blocks 618 on the blockchain, obtaining the stored record does not require traversing the blockchain to find the stored record in question, but rather allows directly obtaining the stored record from the block identified by the Merkle tree index.

[0356] Thus, as described herein, the process performs a query 651 on the index 616 to identify the address of the desired data, and then performs a query on a specific block 617 to obtain the stored data from the addressable block 618 based on the address, without having to traverse the blockchain or traverse the tree to find the data.

[0357] According to certain embodiments, the index 616 is stored as an entity within the blockchain 399. For example, the index can be stored as an asset on the blockchain. Additionally, by storing the stored records in the Merkle tree index 616 and the Merkle tree index itself being stored on the blockchain, any data can be obtained from the index 616 by going to the specific block having the index. Thus, if the index is known, there is no need to query 651 the index 616 for that address, but rather go directly to a node to look for the known address within the index and receive back whatever is there. If the address points to a leaf within the index 616, the data stored in that leaf is returned based on a direct query of that address in the index 616. If the address points to a node that has a subtree below it, e.g., additional nodes or simply multiple leaves, the entire subtree is returned. For example, if the address ABC is used, the entire node having the hash ABC is returned, including the three leaves below that node, including the leaf having the hash A, the leaf having the hash B, and the leaf having the hash C.

[0358] If the index 616 stores the addressing information of a specific block within the blockchain, based on the returned addressing information, a specific block of the blockchain can be examined to obtain the stored record to be obtained. Alternatively, if the addressing is stored in the index 616 together with the latest information of the stored record, using the address to index 616 will return the addressing information of the block on the blockchain where the stored record is located as well as return the latest information of that stored record, thus eliminating the need to further query the blockchain.

[0359] Figure 6B depicts another example architecture 602 for building and maintaining an index from records in a blockchain, according to the described embodiments. In this example architecture, a blockchain consensus manager 191 and a permissions manager (not shown) operate to support read consensus and access control processes, as further described with respect to Figure 10 FIGs. 11-12.

[0360] According to a particular embodiment, it is desirable to be able to access data records stored within a blockchain extremely quickly by using an index 616. As described above, the index 616 can store only the addresses of addressable blocks on the blockchain, in which the underlying stored records are held, thereby allowing the records to be retrieved from the blockchain using the addresses obtained from the index 616. Alternatively, the most recent information (i.e., the most recent and current version of a particular record stored on the blockchain) can be stored in the index along with the addressable blocks of the blockchain, where the underlying stored records are held by the blockchain. Specifically, this results in duplicate records being persisted. The most recent and current version of the record is held within the blockchain and is considered the authoritative record; however, for query speed improvement, a second copy of the same record is held within the index 616 along with the address on the blockchain that maintains the authoritative version of the record.

[0361] According to such an embodiment, therefore, the index 616 can be built or generated by a host organization by referring to the underlying stored records within the blockchain.

[0362] As shown herein, in blockchain 399, there are multiple stored records in different addressable blocks of the blockchain. Stored record 691 is located in root block 684. Stored record 692 is located in block 685A, stored record 693A is located in block 685B, and the final updated record 693B is stored in block 685C. The updated record does not consider the previously stored record 693A and is no longer current.

[0363] Any of these stored records can be retrieved from the blockchain by traversing or searching the blockchain for the relevant record, locating the relevant record, and then retrieving the stored record from the located block.

[0364] Building index 616 improves the retrieval efficiency of the process by at least providing the addresses of the blocks within the blockchain that store the storage records. As described above, index 616 with such addressing information can be examined to return the addressable blocks of the blockchain for the stored records, and then the stored records can be retrieved from the blockchain without having to traverse or cross multiple blocks of the blockchain. For example, index 616 can be examined to update the location of record 693B, where the index returns the location of addressable blockchain block 685C, and then block 685C can be directly queried to obtain the most recent and up-to-date version of the authoritative storage record, which is the updated record 693B at standard block 685C.

[0365] Alternatively, the content or data of the updated record 693B that identifies the most recent version of the authoritative storage record 693B and the location of the addressable blockchain block 685C can be saved in index 616, so that nothing needs to be retrieved from the blockchain at all. Although this results in an additional copy of the updated record 693B being stored in index 616, it greatly improves the speed at which the data of the updated record 693B can be retrieved. This is especially true in the case where index 616 itself is stored within the host organization rather than being written to the blockchain. In such an implementation, index 616 is examined within the host organization 110, and the location of the stored record as well as the content or data of the stored record are returned, where such data corresponding to the data copy of the stored record from the blockchain is returned from index 616 stored in the host organization. Subsequently, the application that receives such information is then examined to verify the information stored within the blockchain by retrieving the stored record from the blockchain using the location of the stored record within the blockchain returned by index 616, or the application can simply utilize the copy of the data returned from index 616 itself, depending on the data consistency requirements and concerns of that particular application.

[0366] Thus, as can be observed herein, the data leaf of index 616 now includes not only the addressing information that provides the location of the block in question within the blockchain, but also a copy of the storage record within the blockchain, thus providing duplicate locations from which such data can be retrieved. A copy of the storage record can be retrieved from the blockchain itself, but a copy of the storage record in the blockchain can also be retrieved from index 616.

[0367] As described herein, leaf hash A now has a link to position 684, thus providing the location or addressing information of block 684 on blockchain 399 that stores storage record 691. However, leaf hash A now additionally has a copy of storage record 691 saved within index 616 itself, thus allowing direct access to the stored data on addressable block 618 from index 616 stored on the host organization without having to obtain the storage record from the blockchain, even though the blockchain has the authoritative copy of storage record 691. By identifying the records to be indexed (e.g., all student records), then searching for and obtaining those records from the blockchain, and recording the locations of those records within index 616 as well as the copies of the obtained storage records, such an index 616 can be established and used to very quickly obtain the record content. Leaf hash B is also depicted as having a link to blockchain block position 685A and a copy of storage record 692 located within index 616, and because storage record 693A is updated and thus overridden by storage record 693B, leaf hash C is constructed to have a link to blockchain block position 685C and a copy of storage record 693B from the blockchain to be saved within index 616 stored at host organization 110 (e.g., within database system 130 of host organization 110). In an alternative embodiment where index 616 is saved within the blockchain, since only index 616 needs to be obtained, as described above, there will be replicated copies of the storage records within index 616, thus still improving the access efficiency.

[0368] Then index 616 can be searched faster than the blockchain, or if the hash or address is known for a leaf or node within index 616, then that address can be used to directly go to the leaf or node within index 616, from which all content can be obtained. For example, if the address or hash points to a leaf, the location information of the addressable block within the blockchain will be returned along with the persistent copy of the record stored at that blockchain location. If the address or hash points to a node with child nodes or multiple sub - leaves below, then the entire subtree will be returned, thus providing the content of multiple records within the corresponding leaves (endpoints) of the returned subtree.

[0369] Figure 6C Another example architecture 603 according to the described embodiments is depicted for forming an address for obtaining information from an index using an addressing structure. In this example architecture, blockchain consensus manager 191 and permission manager 181 operate to support read consensus and access control processes, as further described with respect to Figure 10 FIGs. 12.

[0370] The structuring of the addresses within the Merkle tree index allows for very fast access to a particular node or leaf that provides location information of the stored records within a block on the blockchain and, according to some embodiments, a copy of the stored records. In the absence of structured addresses, one would have to start from the root of the Merkle tree index 616 and then traverse through each level until the desired node or leaf is found. Although such traversal of the index 616 is faster than traversing or going through the blocks of the blockchain, even faster access is achieved by directly referencing a single leaf or node (and thus a child node or leaf) via the structured address, as described by the addressing structure 640 shown herein.

[0371] This document specifically describes an addressing data structure 640 that utilizes an indexing scheme of the Merkle tree index 616, which is divided into four main parts that make up a hexadecimal string. The first part provides an exemplary 6 - 10 bit (although the size may vary) application namespace, within which a particular application can be encoded. For example, the student record discussed above can be defined and used in conjunction with a student record lookup API or interface (e.g., student lookup database) encoded as "SLDB", which converts to the hexadecimal "534c4442". Following this application namespace field is an exemplary 3 - 4 bit entity type identifier (although the size may vary) to identify the type or kind of information being stored, such as the stored records or metadata entities or related entities stored as metadata, etc. For example, the information can be the content of a student record, which can be encoded as SR that converts to the hexadecimal "5352", or the information can be the metadata defining the student record, which can be encoded as MD that converts to the hexadecimal "4d44", or the information can be a related entity. Some related entities are stored as metadata with the same type identifier (e.g., MD / 4d44), or alternatively, can be stored as metadata with a unique entity type identifier, e.g., RE for a related entity encoded as convertible to the hexadecimal "5245".

[0372] Next, in the addressing structure 640 are exemplary 10 - 20 bit names of entities or data records (although the size may vary) to specify what is being stored (not the content, but the name of the stored information). Thus, the metadata defining a student record could be encoded as SRAMD which converts to hexadecimal "5352414d4420" (e.g., for student record application metadata), or the information stored could be the student record itself and thus named STUDREC which converts to hexadecimal "5354554452454320" (e.g., for student record), or the information stored could be the related entity storing the student transcript named TRNSCRPT which converts to hexadecimal "54524e5343330", or the information stored could be the stored student medical record named MEDREC which converts to hexadecimal "4d454452454320", and this information could be the related entity. Depending on the use of the application and the way such data is parsed, any extra space in the various parts of the addressing structure can be padded with leading zeros.

[0373] Finally, within the content or payload section of the addressing structure is the actual information to be stored, e.g., the content of the stored record (e.g., the values making up the student record) or the metadata defining the record (e.g., metadata used to define, validate, construct, mask, or type the actual stored content). Similarly, metadata can be stored within the payload or content section of the addressing structure 640 that identifies related entities via a UUTD corresponding to a UUID field within the stored record (e.g., a student record can include a related entity field with the UUID of the student transcript, thus linking the student record to the transcript stored separately within the related entity metadata storage asset for the student on the blockchain).

[0374] Within the payload or content section of the addressing structure 640, application developers using an indexing scheme have almost unlimited flexibility in what can be stored, up to the imposed size limits, e.g., for the very small, efficient, though restrictive 70 - bit total limit of the addressing structure 640, up to n bits where more information can be stored (e.g., hundreds or thousands of bits depending on usage).

[0375] Since the information is stored as a hexadecimal string, the information can be easily protocol - buffered, serialized, encrypted and decrypted, and effectively transmitted and utilized by heterogeneous applications over the network without regard for any specialized format.

[0376] Figure 6DDepicts another exemplary architecture 604 for obtaining information from an index using an address according to the described embodiments. In this example architecture, the blockchain consensus manager 191 and the permissions manager 181 operate to support read consensus and access control processes, as further described with respect to Figure 10 FIGs. 1 through 12.

[0377] As described herein, the query interface 180 provides an address 653, via which a query 652 is performed on the index using the address, thereby allowing a leaf or subtree of the index 616 to be directly retrieved from the index 616 based on the data retrieved by querying via the address.

[0378] Consider a query 652 for an address of the index 616 using the index scheme and address structure from the above example.

[0379] For example, the application namespace of a student record lookup API or interface is encoded as "SLDB" (e.g., student lookup database), converted to hexadecimal "534c4442", then the type or kind of information stored is encoded as MD (for metadata), converted to hexadecimal "4d44", followed by the metadata defining the student record, which is encoded as SRAMD, converted to hexadecimal "5352414d4420".

[0380] This results in an address of 534c4442 + 4d44 + 5352414d4420 or 534c44424d445352414d4420. There is no need to define the address of the content or payload as this is the data being retrieved; however, such data can be written to the index using the above address concatenated with the hexadecimal representation of the content or payload.

[0381] However, a query of the index 616 using the address 534c4442 + 4d44 + 5352414d4420 provides a fully qualified address all the way to the leaf in the Merkle tree index where the payload or content to be retrieved is located. In this case, the payload or content is the metadata of an application called "SLDB" (e.g., student lookup database), which defines the encoding of the student records of the application.

[0382] Similarly, if one wants to retrieve a student record, using the address 534c4442 (for student lookup database) + 5352 (for SR or student record) + 5354554452454320 to query index 616 provides a fully qualified address all the way to the leaf in the Merkle tree index, where the student record payload or content to be retrieved is located. In this case, the payload or content is the student record information of an application called "SLDB" (e.g., student lookup database), defined by the metadata obtained above. If the UUID or student ID of the student is used as the leading part of the stored student record payload, the address can be further qualified to retrieve only the content of the specific record of that particular student.

[0383] Another benefit of this indexing scheme is the ability to query information using non-fully qualified addresses or partial addresses. For example, continuing the above example, a developer can trigger the index to return all metadata for a specific application by submitting a partial address to index 616, in order to directly retrieve it by specifying its address and the entity type identifier of its metadata. Thus, such a partial address forms a hexadecimal string corresponding to the application namespace part of "SLDB" (e.g., student lookup database), which is converted to hexadecimal "534c4442", followed by the type or kind of the stored information encoded as MD (for metadata), converted to hexadecimal "4d44", resulting in 534c4442 + 4d44 or simply 534c44424d44.

[0384] Querying index 616 using this partial address for direct retrieval will cause the index to return all metadata of the "SLDB" (e.g., student lookup database) application, regardless of what this metadata is named or how many leaves or subtrees are consumed to store this data. More specifically, querying index 616 using the partial address will return the entire subtree under the node of the Merkle tree index hashed with the hexadecimal string 534c4442 + 4d44. Similarly, all student records (via the entire returned subtree) can be retrieved by specifying a partial address for direct retrieval. For example, a query to index 616 specifies the address 534c4442 (for student lookup database) + 5352 (for SR or student record) without any specifically named student record.

[0385] If the content or payload information in the index includes the location information of the stored record within the blockchain and the content of the stored record copied from the blockchain to the index 616, there is no need to obtain any further content from the blockchain. If only the location information of the content within a specified block of the blockchain is provided (thus resulting in a much smaller storage capacity and faster retrieval due to the smaller index), the blockchain service interface 190 will then utilize the location information to directly obtain the content of the stored record from the specified block of the blockchain, without having to traverse or search through multiple blocks of the blockchain to locate the specified stored record.

[0386] Figure 6E Depicts another exemplary architecture 605 according to the described embodiments for using an index to store current updates for blockchain assets that incrementally update stored records. In this example architecture, the blockchain consensus manager 191 and the permissions manager 181 operate to support read consensus and access control processes, as further described with respect to Figure 10 FIGs. 6 through 12.

[0387] In some cases, it is desirable to store information within the blockchain. However, given that blockchain storage is very unsuitable for storing information that is updated multiple times at a high frequency, the amount and frequency of information updates to the stored records make the use of the blockchain impractical.

[0388] As shown herein, an input data stream 681 with many updates is received at the host organization, and the updates are written to the index 616, resulting in the storage of data stream updates via the index, as shown by element 682. Periodically, incremental updates are periodically written to the blockchain, for example, by transacting with the blockchain to add new assets with stored records, where the incremental updates are taken from the index 616 and pushed into the blockchain as stored records. For example, the stored record 684A is initially stored on the blockchain 399 with an initial batch of data from the data stream. Next, more data stream updates are first written to the index 616 at the host organization, and after a period of time, the incremental updates are then written to the blockchain again, resulting in repeated incremental updates, shown here as incremental update 684B, then incremental update 684C, then incremental update 684D, and so on.

[0389] For example, consider storing the information stream from IoT devices (Internet of Things) that report various telemetry data, such as status, errors, location, events, configuration changes, etc. If the collection of such data is scaled up to a large number of hundreds of IoT devices, the blockchain may be overwhelmed by the frequency of data storage requests.

[0390] However, storing the information in the index 616, especially when the index is stored in the host organization, overcomes this problem because the database system 130 of the host organization is readily adaptable to the high frequency of database updates and interactions.

[0391] Thus, if it is still desired to make such data available on and stored on the blockchain, the frequency problem can be overcome by first writing many updates (e.g., from IoT devices or other such updates) directly to the index 616 within the host organization 110 and then periodically writing incremental updates to the blockchain to persistently store the data within the blockchain. For example, IoT device data streams can be collected by the host organization 110 into the index and then once every 24 hours (or some other period), incremental updates to the IoT device data streams (measured from the last update to the blockchain to the currently available data) are then pushed, flushed, added, or transacted onto the blockchain. Thus, the most recent block of the blockchain then persistently stores the most recent portion of the IoT device data stream and is thus directly accessible from the blockchain or obtainable from the index 616 at the host organization.

[0392] In some embodiments, the index clears or flushes the incremental data by storing the incremental updates to the blockchain and then the index removes the stored content or payload portion from the index 616 and only retains the block location information on the blockchain by which to locate the underlying stored record. In other words, once the incremental information is written to the blockchain, the index 616 can be cleared such that the location of the stored record having the incremental information located on a particular block of the blockchain is retained, but the index 616 itself no longer retains the content of such stored records because they are available within the blockchain and because such data that grows very quickly may slow down the index in an undesirable manner.

[0393] Pushing the entire change (e.g., all IoT data streams ever collected) all at once to the blockchain is problematic because all the data prior to the incremental update is replicated again and again within the blockchain. Thus, only pushing the incremental changes or updates to the blockchain provides for an efficient use of the blockchain for storage purposes and an efficient use of the index 616, which buffers the incoming data streams or incoming high-frequency updates, and the index 616 allows for quick identification of the location information that indicates where the incremental information is stored on the blockchain (e.g., within which block).

[0394] Figure 7A Another example architecture 701 in accordance with the described embodiments is depicted.

[0395] Many customer organizations and enterprises operate in a network-centric manner because the market requires them to solve customer problems. Therefore, it is necessary for enterprises (sometimes including unrelated enterprise organizations) to share data with each other on behalf of their customers.

[0396] However, it is understandable that different enterprises fundamentally lack trust in each other. Therefore, many enterprises find that they now need to share data to satisfy their customers; however, they cannot trust that other enterprises sharing data with them are trustworthy.

[0397] Distributed ledger technology and blockchain platforms specifically address the trust issue, as described above. This is true because data written on a blockchain is immutable and thus can provide updates, but historical data is always accessible. In addition, all participating nodes of the blockchain contribute to the consensus cooperatively based on an agreed consensus model. The exception to this is the modified DLT technology discussed above, for which the shared ledger (e.g., Figure 1C element 157 in and the following etc.) is internally hosted by a host organization, and the host organization operates it as a single and centralized trust authority, or alternatively, the trust determination for it is delegated to a customer organization operating a modified DLT shared ledger instance 157, according to which the customer organization then determines itself who has access rights, e.g., what partner organizations or users etc. obtain the customer organization's consent to access the data in the modified DLT shared ledger.

[0398] Therefore, it is particularly considered to utilize DLT technology and blockchain technology to address the trust issue among enterprises that wish to share data.

[0399] Although the trust issue has been basically solved, there are still two obstacles preventing the adoption of this technology.

[0400] First, adopting blockchain is technically complex and very difficult for most enterprises to implement alone. Even for a technical assessment of such data, professional computer programmers and developers with sufficient skills in this specific professional field and an understanding of the enterprise's needs (usually provided by technical business analysts) are required, and then additional computing infrastructure needs to be procured, the blockchain platform and protocols themselves need to be developed, or existing public or private blockchains that meet the enterprise's needs need to be identified and participated in. These developers must understand how to package and trade assets (sometimes called "coins") into the blockchain and how to transfer these assets (with the information they are interested in embedded) between nodes and make this data available to other participating nodes of the blockchain for information sharing. In addition, such a blockchain needs to have a consensus model acceptable to enterprises. For these reasons alone, although the prospect of adopting blockchain technology is promising, it remains an insurmountable burden for many enterprises.

[0401] Second, even assuming the above obstacles are overcome, there are still significant problems with data standardization between applications for information written, stored, or saved on a blockchain. For example, even assuming an enterprise manages to transact information to a blockchain and makes that data accessible to another enterprise, there is no guarantee that the information written to the blockchain by the first enterprise will be understood by the second enterprise. Therefore, due to the lack of standardization of data written on various available blockchain platforms, data transferability between enterprises wishing to share data presents another significant problem.

[0402] Consider Figure 7A the following exemplary description, where there are two enterprises 705A and 705B that manage to agree to share data with each other and successfully implement the computing architecture required for transactions with blockchain 399.

[0403] With all data sharing protocols in place, enterprise 705A creates an asset via Application #1 executed at its user client device 706A and, as shown, embeds a customer record into that asset 714, which will subsequently be transacted on blockchain 399. As shown herein, Application #1 creates the asset using the following information:

[0404] Data format used:

[0405] First_Name = John

[0406] Last_Name = Doe

[0407] Phone_Number = --#

[0408] E_Mail_Address = J.Doe@Email.com

[0409] Notably, for this record, there are four fields, including "First_Name" and "Last_Name", followed by "Phone_Number", which uses a specific format mask and has the required hyphen "-" between certain digits, and finally an email address with the field identifier "E_Mail_Address".

[0410] Then, the individual fields are populated with data.

[0411] The created asset is then transacted onto blockchain 399, as depicted by the asset 715 written on the blockchain, and at some later time, enterprise 705B chooses to obtain the information via its own Application #2.

[0412] As shown herein, enterprise 705B transacts with a blockchain and an asset, and the acquired asset 716 is successfully transferred to Application #2 executing on user client device 706B.

[0413] All seems well until Application #2, using its own understanding of the data, interprets asset 717 via the code executing on Application #2, expecting the following information:

[0414] Expected data format:

[0415] Customer_Name = “John Doe”

[0416] Phone = #m#

[0417] email = “J.Doe@Email.com”

[0418] RETRIEVAL ERROR:

[0419] -->No Data Found in Asset

[0420] As expected, Application #2 encounters the error message “No data found in the asset.”

[0421] This is the result when Application #2 looks for the field named “Customer_Name” but there is no such field. Application #2 also looks for the field “Phone” and does not find such a field, and finally searches for “email” and again does not find such a field.

[0422] Although a human reader can easily understand that “First_Name” with the value “John” represents a sub - part of the field “Customer_Name”, this logic is not available in application programs and computing programs, which simply search for the field names they are instructed (e.g., programmed) to search for, namely “Customer_Name”, rather than the combination of “First_Name” and “Last_Name”.

[0423] Although the conversion between these two field types is trivial for any programmer, the fact remains that the two applications of the corresponding enterprise are completely incompatible, and if they are to be made compatible, custom conversions of these fields need to be programmed.

[0424] Fundamentally, the non-transferability of this date is due to the lack of data standardization. Both of these two different application entities are capable of writing to and retrieving from the blockchain, and there are also agreements among enterprises to share such data. However, these two entity applications lack the ability to share data because the name of the customer is not defined. One application expects this to be a combination of the "First_Name" and "Last_Name" fields, while the other application expects the field "Customer_Name" to be used as a single field for the full name of the customer.

[0425] Figure 7B Depicts another exemplary architecture 702 according to the described embodiments.

[0426] Specifically, the blockchain administrator now defines metadata for the data used by the application, and the application then standardizes the data written to the blockchain on behalf of two enterprises (Enterprise 705A and Enterprise 705B).

[0427] As described herein, the blockchain administrator defines metadata through the GUI of the integration builder or through the API of the integration builder, and the defined metadata 721 is then pushed to the designated blockchain 799.

[0428] Now, when conducting transactions on the blockchain, there is a clearly defined metadata that stipulates the requirements for declaring the application "Application XYZ", especially the requirements for "Customer_Record". Now, according to the defined metadata, the structure of the metadata is as follows:

[0429] Requirements of the defined metadata

[0430] Declared Appli cation=ApplicationX YZ

[0431] Customer_Record

[0432] First_Name=$string

[0433] Last_Name=$string

[0434] Phone_Number=$NumericString

[0435] E_Mail_Address=$email String

[0436] Because the defined metadata 721 is traded onto the blockchain 799, any application that is permitted to access the data records on the blockchain 799 will be able to read and write data according to the requirements specified by the defined metadata 721. This could be the specifically stated application “Application XYZ”, or it could be other applications that utilize the data generated or managed by the stated application. Any application can read out the defined metadata 721 and operate according to the requirements.

[0437] Figure 7C Depicts another exemplary architecture 703 according to the described embodiments.

[0438] In particular, it is now described that enterprises 705A and 705B are able to share data traded on the blockchain 799, and because the defined metadata 721 specifies the requirements for formatting such data, the data written to and retrieved from the blockchain 799 will embody a known format and can therefore be transferred between various enterprises.

[0439] As shown herein, the blockchain administrator defines metadata through the blockchain service interface 190, which is traded onto the blockchain, and then later, enterprise 705A creates an asset 714 through Application #1 and writes the asset with customer record details to the blockchain. Subsequently, enterprise 705B retrieves the asset from the blockchain, and when the asset is interpreted 717 via Application #2 executed in enterprise 705B, the data is successfully interpreted and understood by the application because there is a known and defined metadata structure for the customer record data.

[0440] Thus, according to certain embodiments, there are operations performed by a system organized by a host that declare a new application and trade the defined metadata of the new application onto a blockchain. For example, such operations can include operating a blockchain interface to the blockchain on behalf of multiple tenants of the host organization, where each of the multiple tenants operates as a participating node capable of accessing the blockchain. Such operations can also include receiving a first input from a user device communicatively coupled to the system that declares the new application. Such operations can also include receiving a second input from the user device that adds multiple network participants to the new application, where the network participants are granted access rights to the new application. Such operations can also include receiving a third input from the user device that declares multiple entity types of the new application. Such operations can also include receiving a fourth input from the user device that declares one or more new field definitions for each of the multiple entity types. Such operations can further include generating a blockchain asset encoded with the defined metadata of the new application, at least (i) the declared multiple network participants, (ii) the declared multiple entity types, and (iii) the one or more new field definitions declared for each of the multiple entity types. Such operations can also include trading the blockchain asset encoded with the defined metadata of the new application onto the blockchain.

[0441] According to operations of another embodiment, the blockchain asset has a defined transaction type; and wherein the defined transaction type of the blockchain asset encoded with the defined metadata associates the defined metadata of the new application with a smart contract to perform data validation on any data traded for the new application on the blockchain; wherein the smart contract validates that the data traded for the new application on the blockchain complies with the metadata defined for the new application traded on the blockchain.

[0442] According to another embodiment, such operations can further include: receiving, at the blockchain, a transaction specifying data for the new application; triggering the smart contract based on the received transaction specifying data for the new application; executing the smart contract to validate that the specified data for the new application complies with the defined metadata of the new application; and wherein, if the specified data does not comply with the defined metadata of the new application, the transaction is rejected.

[0443] According to the operation of another embodiment, trading blockchain assets to the blockchain includes: adding a transaction to a new block on the blockchain, where the new block designates metadata defined for a new application as the payload data of the transaction; having participating nodes of the blockchain reach a consensus on the added transaction, where, before the added transaction is accepted by the participating nodes of the blockchain as part of the main chain of the blockchain, the added transaction undergoes a consensus protocol by the participating nodes of the blockchain; and where, according to a successful consensus on the added transaction, the defined metadata of the new application is saved in the accepted transaction on the new block of the blockchain.

[0444] According to another embodiment, such an operation may further include: receiving a new input at the system, where the new input declares a second new application; and receiving an additional input at the system, selecting one of the plurality of entity types declared for the first new application as the entity type selected for the second new application, where the selected entity type inherits one or more new field definitions specified via metadata defined for the corresponding one or more entity types associated with the first new application.

[0445] According to the operation of another embodiment, at least one of the plurality of entity types declared for a first new application is specified as the selected entity type for a plurality of differently declared applications; and where a single instance of the defined metadata corresponding to a respective one of the plurality of entity types declared for the first new application and all one or more new field definitions associated with the respective entity type declared for the first new application controls (i) the respective one of the plurality of entity types declared for the first new application and (ii) the entity types selected for all of the plurality of differently declared applications that have selected the respective entity type declared for the first application.

[0446] According to the operation of another embodiment, receiving a fourth input from a user device that declares one or more new field definitions for each of the plurality of entity types further includes receiving a fourth input that defines a field definition type for each of the one or more new field definitions; and where each field definition type is selected from the group including integer, boolean, number, alphanumeric, date, hyperlink, calculation, or custom.

[0447] According to another embodiment, such an operation may further include: authenticating at the host organization that the user device is associated with one of a plurality of tenants; and where one of the plurality of tenants is a subscriber to a cloud-based on-demand service provided by the host organization over the public Internet.

[0448] According to another embodiment, such an operation may further include: executing an event listener to monitor any changes to the blockchain associated with the new application; and triggering an event when the event listener observes a change to the blockchain associated with the new application.

[0449] According to another embodiment, such an operation may further include: receiving a fifth input from a user device, declaring an event and one or more monitored event conditions for the declared new application; wherein the declared event specifies one of the following: (i) a processing flow to be executed at a host organization in response to an event occurring on the blockchain, or (ii) a database transaction to be executed for a database system within the host organization in response to an event occurring on the blockchain; and monitoring any changes to the blockchain that satisfy the specified event and one or more event conditions via an event listener.

[0450] According to the operation of another embodiment, each network participant is granted access to the new application and the data on the blockchain associated with the new application.

[0451] According to the operation of another embodiment, each of the plurality of network participants selects from a group including: a user of the host organization associated with one of the plurality of tenants of the host organization; a partner user corresponding to one of the plurality of tenants of the host organization; a customer organization corresponding to one of the plurality of tenants of the host organization; a non-user of the host organization; a partner organization that is not one of the plurality of tenants of the host organization; and one or more participating nodes on the blockchain that correspond to a tenant of the host organization or a customer organization that subscribes to cloud computing services from the host organization; and one or more participating nodes on the blockchain that do not subscribe to cloud computing services from the host organization.

[0452] According to the operation of another embodiment, receiving the first input from the user device of the declared application further includes: receiving, with the first input of the declared new application, one or both of the specified administrative control of the declared new application or the ownership of the declared new application.

[0453] According to another embodiment, such an operation may further include: receiving an instruction to deploy the declared new application and the metadata defined for the new application to the blockchain; and wherein trading the blockchain asset encoded with the metadata defining the new application to the blockchain includes deploying the new application and the defined metadata to the blockchain via the blockchain in response to receiving the deployment instruction.

[0454] According to the operation of another embodiment, receiving an input that defines each of (i) the declared plurality of network participants, (ii) the declared plurality of entity types, and (iii) one or more new field definitions declared for each of the plurality of entity types includes receiving, via an API at a blockchain metadata definition manager exposed by the host organization, the input as programming code.

[0455] According to another embodiment, such an operation may further include: transmitting a GUI from a blockchain metadata definition manager to a user device, where the GUI prompts for definition inputs for each of (i) a plurality of declared network participants, (ii) a plurality of declared entity types, and (iii) one or more new field definitions declared for each of the plurality of entity types; wherein the inputs are received in the GUI via one or more interactive click events, drag events, drop-down selection events, text input events, and touch events; and wherein receiving the inputs includes receiving the inputs sent from the GUI to the user device.

[0456] According to an operation of another embodiment, the blockchain protocol of the blockchain is defined by a host organization, and further, wherein the host organization allows multiple tenants of the host organization operating as participating nodes on the blockchain to access the blockchain; or alternatively, wherein the blockchain protocol of the blockchain is defined by a third-party blockchain provider different from the host organization, and further, wherein the host organization also operates as a participating node on the blockchain, and the host organization accesses the blockchain via the participating node.

[0457] According to another embodiment, such an operation may further include: receiving, at a receiving interface, an SQL query requesting data associated with a new application; transforming the SQL query into native blockchain executable code via an Apex transformer engine at the host organization; executing the native blockchain executable code against the blockchain to obtain the requested data; and returning the requested data in response to receiving the SQL query.

[0458] According to another embodiment, such an operation may further include: generating a virtual table within a database system of the host organization; and constructing the virtual table at the database system of the host organization based on the metadata declared for the new application; wherein the entity types are represented as tables in the virtual table, and further, wherein one or more new field definitions declared for each of the plurality of entity types of the new application are represented as columns within the tables in the virtual table.

[0459] According to an operation of another embodiment, the virtual table includes a materialized view hosted at the database system of the host organization, the materialized view being structured based on the metadata declared for the new application; and wherein the materialized view hosted in the database system of the host organization does not store any data associated with the new application; and wherein requests for read-only access SQL queries are processed against the materialized view by converting the read-only SQL query into a blockchain transaction to obtain the requested data associated with the new application from the blockchain.

[0460] According to another embodiment, such operations may further include: obtaining metadata defined for a new application from a blockchain, including multiple entity types declared for the new application, one or more new field definitions declared for each of the multiple entity types, and any field types applied to the one or more new field definitions; generating a materialized view of data saved together with the blockchain within a virtual table at a host organization by structuring the virtual table based on the metadata defined for the new application; wherein the materialized view represents a data structure associated with the new application, and this data structure is saved to the blockchain without storing the data associated with the new application in the materialized view of the host organization.

[0461] According to another embodiment, such operations may further include: receiving, at a host organization, an SQL statement from a user device, wherein the SQL statement points to the materialized view and requests an SQL update or SQL insert for data saved to the blockchain and associated with the new application; processing the SQL statement for the materialized view by converting the SQL statement requesting the SQL update or SQL insert into a corresponding blockchain transaction to update or add data associated with the new application in the blockchain; and issuing an acknowledgement to the user device confirming that the SQL statement for the materialized view has been successfully processed according to the corresponding blockchain transaction accepted by the blockchain consensus, and that the data associated with the new application has been successfully updated or added in the blockchain.

[0462] According to another embodiment, such operations may further include: receiving, at a host organization, an SQL statement pointing to the materialized view; wherein the SQL statement specifies one or more of the following: (i) selection from the SQL statement, (ii) insertion into the SQL statement, and (iii) update settings of the SQL statement; and wherein the received SQL statement is processed by converting the SQL statement into a corresponding shared ledger transaction and executing the corresponding blockchain transaction against the blockchain to implement the SQL statement pointing to the materialized view at the host organization.

[0463] According to another embodiment, such operations may further include: wherein the metadata defined for the new application represents a user-specified relationship between two or more of the multiple entity types by linking assets of the blockchain together.

[0464] According to another embodiment, such operations may further include: declaring, at a host organization, new business logic for the new application within a table structure that has one or more relationships between elements of the new business logic and one or more of the multiple entity types of the new application; and defining new business logic, with all relationships in the metadata saved to the blockchain.

[0465] According to another embodiment, such an operation may further include: executing an event listener to monitor any changes to the defined metadata of a new application on the blockchain; and triggering an event when the event listener observes a change in the metadata of the new application on the blockchain; and wherein the triggered event automatically pushes a metadata update to the host organization to update the materialized view of the data associated with the new application by reconstructing the materialized view at the host organization based on the metadata update triggered by the event listener.

[0466] The operation according to another embodiment, triggering an event based on a change in the metadata of a new application via an event listener further includes: triggering one or more of the following: a business user-defined processing flow for execution in response to a change in the defined metadata persisted to the blockchain; a business user-defined data acquisition operation for execution in response to a change in the defined metadata persisted to the blockchain; a business user-defined data filtering operation for execution in response to a change in the defined metadata persisted to the blockchain; an administrator-defined processing flow for updating a data analysis feed in response to a change in the defined metadata persisted to the blockchain; and an administrator-defined processing flow for updating an artificial intelligence (AI) training data stream in response to a change in the defined metadata persisted to the blockchain.

[0467] According to a particular embodiment, there is a non-transitory computer-readable storage medium having instructions stored thereon that, when executed by a processor of a system having at least a processor and a memory, cause the system to perform an operation including the following operations: operating a blockchain interface to the blockchain on behalf of multiple tenants of a host organization, wherein each of the multiple tenants operates as a participating node capable of accessing the blockchain; receiving a first input from a user device communicatively coupled to the system, declaring a new application; receiving a second input from the user device of multiple network participants adding the new application, wherein the network participants are granted access rights to the new application; receiving a third input from the user device of multiple entity types declaring the new application; receiving a fourth input from the user device, declaring one or more new field definitions for each of the multiple entity types; generating a blockchain asset encoded with the defined metadata of the new application as the new application, at least (i) the declared multiple network participants, (ii) the declared multiple entity types, and (iii) the one or more new field definitions declared for each of the multiple entity types; and trading the blockchain asset encoded with the defined metadata of the new application onto the blockchain.

[0468] According to another embodiment, there is a system that executes at a host organization, where the system includes: a memory that stores instructions; a processor that executes the instructions; where the processor executes a blockchain service interface on behalf of multiple tenants of the host organization, and each of the multiple tenants operates as a participating node capable of accessing the blockchain; a receiving interface for receiving a first input from a user device communicatively coupled to the system, the received first input declaring a new application; the receiving interface further receives a second input from the user device to add multiple network participants to the new application, where the network participants are granted access rights to the new application; the receiving interface further receives a third input from the user device declaring multiple entity types of the new application; the receiving interface further receives a fourth input from the user device declaring one or more new field definitions for each of the multiple entity types; a blockchain service interface for generating a blockchain asset encoded with metadata that is the definition of the new application, at least (i) the declared multiple network participants, (ii) the declared multiple entity types, and (iii) the one or more new field definitions declared for each of the multiple entity types; and where the blockchain service interface also trades the blockchain asset on the blockchain, the asset having metadata with the definition of the new application encoded therein.

[0469] According to an embodiment of the system, the receiving interface is further configured to receive a fifth input from the user device declaring an event and one or more monitored event conditions for the declared new application; where the declared event specifies one of the following: (i) a processing flow executed at the host organization in response to an event occurring on the blockchain, or (ii) a database transaction executed against a database system within the host organization in response to an event occurring on the blockchain; and where the system further includes an event listener, where the event listener monitors any changes to the blockchain that satisfy the specified event and the one or more event conditions, and triggers the declared event in response to the monitored changes on the blockchain.

[0470] Figure 8A Another exemplary architecture 801 according to the described embodiment is depicted.

[0471] As shown herein, there is a GUI 810 that executes at a computing device 899 (e.g., the user device of a blockchain administrator), and the GUI 810 is pushed to the computing device 899 by a blockchain metadata definition manager 196 of the host organization.

[0472] As shown herein, a blockchain administrator can view the deployed applications as shown at the top of the GUI 810, and by clicking the "New" button at the GUI 810, the blockchain administrator is provided with the ability to claim new applications. Although this document describes claiming new applications via the GUI 810, the blockchain administrator can also utilize the API provided by the blockchain metadata definition manager 196 to create new applications.

[0473] Figure 8B Depicts another exemplary architecture 802 according to the described embodiments.

[0474] In addition to claiming or creating new applications, the blockchain administrator is also able to define which participants are authorized to access the data associated with that particular application, thereby defining network participants for the newly claimed application.

[0475] Figure 8C Depicts another exemplary architecture 803 according to the described embodiments.

[0476] The GUI 810 is depicted again. However, now it depicts the blockchain administrator viewing and editing the entities of the application by clicking on "Bank Record Application".

[0477] Thus, the blockchain administrator can first claim or create a new "application", and then once created, the blockchain administrator can edit or view the application, and can create or claim new "entities" within the application, where each declarative entity defines metadata for specific custom fields, and the application can ultimately store information conforming to the defined metadata within such custom fields, and other applications can also interact with and reference such data, and may update, add, or delete such data, again, subject to the defined metadata, provided there is sufficient permission.

[0478] For example, this document defines an "Auto_Claim" "claim" entity name for a bank record application. Therefore, any application that wishes to write claim-related information to the blockchain, at least to the extent that the bank record application will use such information, is required to comply with the requirements of the defined "Auto_Claim" entity.

[0479] Figure 8D Depicts another exemplary architecture 804 according to the described embodiments.

[0480] This document describes the GUI 810, which is generated by the blockchain administrator clicking the "New" button on the previous screen to claim and create new entities within the newly created application or within the viewed application.

[0481] As shown herein, a "New Entity Definition" GUI is presented, where a blockchain administrator can now create a new entity by entering an entity name, an entity label, and selecting an owner for the entity, which by default is the user creating the entity. Then click Save to create and claim this new entity. The blockchain administrator can alternatively change the status to "Deployed", and once saved, the entity will be transacted to the blockchain, while in draft status, it will only be retained in the blockchain metadata definition manager 196 of the host organization.

[0482] According to a particular implementation, each GUI has a corresponding API through which it interacts with the blockchain metadata definition manager 196.

[0483] Figure 8E Another exemplary architecture 805 according to the described implementation is depicted.

[0484] Clicking on an existing entity, including the entity just created on the Figure 8D previous GUI 810 shown, will result in the presentation of a field definition GUI through which the blockchain administrator can now create any number of fields to be stored within that particular entity.

[0485] By analogy, it may be helpful to think of a claim application as a computer program, although the application runs via the cloud, the claimed entity is a table comparable to a table in a relational database, the last claimed field is a column identifier or a fillable field in the table, and finally, the collection of fields will thus form a record. Although the comparison is not exact, the relationship between the various declarative elements and the metadata defined for them should help illustrate its use.

[0486] Because the defined metadata precisely specifies what data is allowed and the format and type of that data, any permitted application can successfully write information to the blockchain in the predictable and predefined format specified by the metadata. Additionally, applications sharing with them can also successfully retrieve information from the blockchain, knowing based on the defined metadata what the information should look like and how it should be structured, and thus how to interpret the information.

[0487] Because information is defined in the blockchain through metadata, all participants know the meaning of each data element based on the defined metadata. Therefore, for the participant network, all participating nodes can share information via the blockchain.

[0488] Furthermore, participants are not limited to the existing metadata transacted on the blockchain, but they can create additional elements, create new metadata definitions, change metadata definitions, etc.

[0489] For example, Bank Wells Fargo may decide that as a participant, they need a new entity with fields X, Y, and Z. Thus, the participant can define the metadata of the new entity with fields X, Y, and Z (via an API or GUI), and then trade the new entity onto the blockchain.

[0490] Then, the new entity will be subject to consensus by other participating nodes. If other participating nodes do not agree, no consensus can be reached, regardless of the change. However, if consensus is reached, the new entity with fields X, Y, and Z is traded onto the blockchain by writing the defined metadata of the new entity into the blockchain within the consensus block, or in other words, once consensus is reached, the entity that has been written into the blockchain becomes part of the "main" chain of the blockchain, which is accepted as the main chain by all participants.

[0491] According to another embodiment, a smart contract is executed for a transaction on the blockchain that attempts to write or update data on the blockchain for an entity with defined metadata. For example, there may be a trigger that causes the smart contract to be executed, in which case the smart contract obtains or applies the defined metadata to verify that each field within the entity has a data type, data naming compliance, and a date mask that complies with the requirements of the defined metadata.

[0492] In the case where the smart contract enforces the defined metadata, any non-compliant transaction is prohibited from being traded on the blockchain, or if written to the blockchain, the transaction will never be accepted into the block on the main chain because the failure of the smart contract verification will prevent the transaction from reaching consensus for acceptance.

[0493] Thus, by using the described GUI, business users lacking programming and program development expertise can still declare new applications and new entity names, and declaratively create new field definitions for these entity names. For those with stronger technical expertise, they can utilize the API to interact with the blockchain metadata definition manager 196 if they so prefer.

[0494] Regardless of the method chosen, the blockchain administrator can declaratively create new applications, new entities, and new field definitions without having to write any code, and the blockchain metadata definition manager 196 will then trade the metadata defined for the new applications, new entities, and / or new field definitions onto the blockchain for voting and consensus.

[0495] The defined metadata cannot be used until consensus is reached. However, once traded on the blockchain and consensus is reached, other participating nodes or participants on the blockchain can interact with all the data of the declared application, and the execution of the smart contract of the blockchain service interface 190 will enforce or compel compliance with these interactions.

[0496] Figure 8F Depicts another exemplary architecture 806 according to the described embodiments.

[0497] Generated code representing declarative operation creation for a blockchain administrator is described herein for defining an application, declaring entities, and declaring various defined fields, resulting in API-compliant code represented in the defined metadata, even though the blockchain administrator has not written any code. In other embodiments, a programmer or developer may choose to utilize the API to generate the code, in which case the GUI will reflect the coded entities and coded defined fields as if they were originally declared via the GUI.

[0498] Thus, the disclosed platform allows for the creation of the necessary code to transact with the blockchain, interact with the blockchain, define and declare an application and the entities of that application (which, as described below, may be described as tables in a database system via a materialized view), and further define and declare new field definitions for each entity, and also define the allowed network participants that can utilize the declared application.

[0499] In this way, the declarative metadata platform performs all the heavy lifting on behalf of the blockchain administrator, allowing non-programmers to create all the code necessary to interact with the blockchain for a new declarative application using only click operations via a series of GUIs.

[0500] Furthermore, the structure of the application, the allowed network participants, and the new declarative entities and new declarative field definitions are presented in a way that is familiar to the blockchain administrator, as the various elements can be thought of as database tables, columns, fields, and records, etc., even though no database entries and database tables are created. Instead, this information is transacted as assets on the blockchain, while allowing the blockchain administrator to click through the entire process without the need for the blockchain administrator to know or be required to understand how to transact on the underlying blockchain or how to add, update, or transfer assets on the blockchain. Thus, the practice of the disclosed embodiments greatly reduces the complexity for non-programmer users operating as blockchain administrators.

[0501] However, for more complex users with programming knowledge and an understanding of blockchains, the same code can be written and generated via the APIs presented by the blockchain service interface 190, specifically the blockchain metadata definition manager 196 provided by the host organization.

[0502] Figure 9A Depicts another exemplary architecture 901 according to the described embodiments.

[0503] As shown herein, a blockchain administrator trades defined metadata 910 to the blockchain, which will presumably be accepted once consensus is reached, and partner users will then trade transactions 915 that conform to the metadata to the blockchain.

[0504] This document further describes a materialized view 920 that allows a host organization user 926 to interact with data traded from an accessible cloud platform 186 available to the host organization 110 via a metadata-compatible transaction 915 to the blockchain.

[0505] In computing, a materialized view 920 is a database object that contains the result of a query. For example, a materialized view 920 can be a local copy of data located remotely, or it can be a subset of rows and / or columns of a table or join result, or it can be a summary using an aggregation function.

[0506] The process of setting up a materialized view is sometimes called materialization. In a sense, data materialization is a form of caching query results, similar to other forms of precomputation, where a database administrator utilizes materialized views for optimization for performance reasons.

[0507] In any database management system that follows the relational model, a view is a virtual table that represents the result of a database query. Whenever a query or update processes the virtual table of a normal view, the database management system converts these into queries or updates on the underlying base tables.

[0508] In contrast, a materialized view takes a different approach, as the query result is cached as a concrete ("materialized") table that can be updated separately from the original base table. This approach allows for more efficient access at the cost of additional storage and some data potentially becoming stale. Materialized views are particularly suitable for data warehouse scenarios where frequent queries on the actual base tables can be expensive.

[0509] In the example described herein, the accessible cloud platform 186 typically utilizes information stored in the database 130 of the host organization 110. However, in cases where some information is traded to the blockchain and thus stored in the blockchain, the materialized view allows the accessible cloud platform 186 to interact with the data stored in the blockchain via the materialized view 920. In this way, both the host organization user 926 and the accessible cloud platform 186 can interact with the blockchain data as if it were data stored within the database 130 of the host organization, simply by referring to the materialized view.

[0510] Thus, according to certain embodiments, any time information is transacted onto the blockchain, the smart contract triggers and executes a verification scheme for the data transacted onto the blockchain to ensure that it conforms to the defined metadata 910, and the smart contract additionally generates a materialized view 920 to create a referenceable copy within the database 130 of the host organization 110, thereby allowing the standard query interface of the host organization to reference the information within the materialized view, which in turn corresponds to the information transacted onto the blockchain.

[0511] Thus, any entity declared and created for the blockchain and for which data is subsequently written or processed onto the blockchain will automatically have an equivalent entity (e.g., a table in a relational database) created within the database of the host organization 110 within the materialized view, and when defined fields are created and accepted onto the blockchain, those corresponding columns will subsequently be created within the host organization's database system 130, and then when the data is transacted onto the blockchain, the corresponding entity table within the host organization's database system 130 will be populated into the materialized view, such that users and processes interacting with the data from the host organization side can access the information from the materialized view.

[0512] Thus, developers and users can interact with the declarative application, which uses the data and defined metadata stored on the blockchain, without knowing that they are actually using the blockchain, nor requiring these users to know how to interact with the blockchain.

[0513] According to certain embodiments, no new tables are created within the database 130 of the host organization, and thus there is no need to synchronize any data between the database 130 of the host organization and the blockchain. Instead, the materialized view at the host organization's database 130 represents a conduit, pipeline, or view of the data persisted by the blockchain external to the host, but while the materialized view is referenceable, it is not a copy that is synchronized back to the blockchain and does not allow updates or modifications. The materialized view only allows read-only references from the host organization's database 130. All modifications, updates, changes, etc. must be transacted on the blockchain, and then the refreshed materialized view will extract those changes from the blockchain and reflect those modifications in the database 130. While this arrangement incurs additional overhead, this arrangement clearly obviates the need to synchronize data within the materialized view, as such data is completely non-authoritative.

[0514] Thus, developers, programs, processes, and users can interact with blockchain data by referencing the materialized view 920 using standard SQL queries. For example, when specifying an entity name as the table name of the materialized view 920, a SELECT specified from $Table_Name WHERE... will cause the database 130 of the host organization to return database query results, even though the authoritative copy of the data resides within the blockchain itself. While this structure does create some duplicate data and can thus be said to result in wasted storage, this structure has the benefit of greatly simplifying queries originating from any accessible cloud platform 186 that can utilize standard SQL without having to identify the blockchain or construct more complex blockchain transactions to obtain data, as the replication of data to the materialized view 920 is automatically performed by a smart contract trigger. According to such an implementation, SQL commands to update, create, or delete records are not allowed to be executed against the materialized view. However, such SQL commands to update, create, or delete records will be accepted and transformed to the apex transformation engine and the Apex code interface 454 (shown at Figure 4B ), transformed into locally blockchain-executable compatible code to perform the equivalent actions of the SQL update, create, or delete commands, but as a blockchain transaction, and then transacted against the blockchain, submitted to reach consensus, and then, assuming the vote or consensus is successful, accepted into the blockchain. Also note that a smart contract will be executed to verify the transaction against the blockchain to enforce data compliance with the defined metadata retained in the blockchain.

[0515] For example, an SQL query submitted from a host organization user may request an update to the customer record of John Doe for a specified application. Since such information is stored in the blockchain, SQL cannot be executed against the database system 130 of the host organization. Additionally, the blockchain does not accept an SQL query that requests "please return all data for customer record John Doe". Information about the blockchain is unreadable, and such queries are not allowed.

[0516] Therefore, the Apex code interface 454 will convert the received SQL code into native blockchain code to transactionally update the payload data on the blockchain for the customer record John Doe of the specified application. Note that when this occurs, the latest information for the customer record John Doe will now be reflected as the latest information on the blockchain and in any materialized views of the same data. However, the old information for the customer record John Doe remains within the blockchain because blockchain records are immutable, thus creating an immutable audit trail that can be referenced at any time. Therefore, any party with access to this data can look back at previous blocks of the blockchain to determine what information was previously recorded for the customer record John Doe, or in the case of deleting the customer record John Doe, this change will again be reflected by the blockchain, but the old records themselves remain unchanged within the previous blocks of the blockchain, although the application will understand that this information is indicated as "deleted". Therefore, according to the inherent design of DLT blockchain technology, deleted records will not be referenced as live data but will always remain available.

[0517] In an alternative embodiment, the Apex code interface 454 (as Figure 4B shown) is used to convert an SQL database query into a native blockchain protocol, allowing the converted SQL query to be subsequently executed against the blockchain and a result set to be generated, which is then converted back into an SQL-compliant format and returned in response to the SQL query. In other embodiments, the smart contract engine executes transactions against the blockchain to obtain defined entities and defined fields and converts them into materialized views, which are then stored in the host organization database system 130. Subsequently, an unconverted SQL query can be executed to directly obtain blockchain data from the materialized views.

[0518] Because the application itself is declarative, and the declared entities and the defined fields declared by these entities are also declarative, all data structures are fully customizable and can be customized according to the specific needs of the business, provided that network participants or participating nodes running on a specific blockchain reach a consensus on the blockchain.

[0519] Figure 9B Depicts another exemplary architecture 902 according to the described embodiments.

[0520] As shown herein, the defined metadata 910 has now been deployed to the blockchain, as shown by element 911. Accordingly, the declaratively defined applications, their entities, and field definitions can now be used by any authorized network participant. In many cases, the authorized network participant will be a host organization user 926, who can access the various cloud services of the host organization 110. Accordingly, once deployed to the blockchain, the host application 921 is presented for use by customers.

[0521] However, in some cases, partner users need to access the software as authorized network participants. The problem is that such partner users who have been authorized as network participants and thus granted the right to interact with the declared application are not necessarily customers of the host organization and may not wish to force them to become subscription customers of the host organization.

[0522] According to some embodiments, in order to deploy a declared application for use by non-customers of a host organization, there are two requirements. First, according to some embodiments, the blockchain administrator must define the permitted network participants, which can be done by defining the Internet Protocol (IP) addresses for those network participants. The IP address can correspond to a host organization user identified by the IP, or the network participant can be a non-customer of the host organization, also identified by the IP. In this way, the participating nodes on the blockchain can be identified that are permitted to access the application and use the application and can communicate with each other and share data with each other, assuming they can be correctly identified by the IP addresses of the added network participants defined by the blockchain administrator for that particular application.

[0523] In some embodiments, some or all of the added network participants are non-users or non-subscribers of the host organization and thus cannot authenticate to the host organization and thus cannot identify themselves to the host organization via authentication credentials. Accordingly, according to such embodiments, the identified network participants who are non-customers of the host organization and wish to use the application as permitted network participants (defined by the blockchain administrator) but are non-customers of the host organization go through a two-step authentication process. First, they must provide their IP, which must correspond to the added network participant. Then, the non-customer will be presented with a challenge for which they need to return a public key. The blockchain administrator will have provided the public key to the non-customer in advance so that they can successfully pass the authentication challenge.

[0524] Once the non-customer has both provided their IP and responded to the challenge with the public key, that public key is utilized whenever the non-customer attempts to negotiate trust between the participating nodes on the blockchain for the declared application.

[0525] Accordingly, in certain embodiments, the deployable installation package 925 is transmitted to partner users, where the deployable installation package 925 is non-customer-run software that allows them to access the declared application.

[0526] In certain embodiments, the deployable installation package 925 is a general software package that does not include the functionality of the declared application, but rather provides non-customer partner organizations with access to the host organization's blockchain service interface, such that the non-customer partner organizations can then transact with the blockchain through the declared application that the host organization has added the specific non-customer partner organization to as an authorized network participant.

[0527] In such an embodiment, once the general deployable installation package 925 is installed and executed, the non-customer partner organization will be prompted to share a public key, which will be sent to them individually by the blockchain administrator, who adds the non-customer partner organization as an authorized network participant for the specific declared application.

[0528] In one embodiment, when adding a non-customer partner organization as an authorized network participant, the deployable installation package 925 issues a challenge based on the IP address of the non-customer partner organization, which has been configured by the blockchain administrator as part of the metadata of the declared application.

[0529] Accordingly, the same general deployable installation package 925 will operate differently depending on its execution location. If the deployable installation package 925 is executed from a system with an IP address that is not within the configured IP range or does not correspond to an authorized network participant, the deployable installation package 925 will simply indicate at execution that the location associated with that IP address is not an authorized network participant for any declared application.

[0530] If the same deployable installation package 925 is transmitted to different people who are authorized network participants for different declared applications, the deployable installation package 925 will prompt the user to enter the shared public key for the different declared application when it is executed, and thus the correct shared public key needs to be provided, and the deployable installation package 925 is executed from an IP address that has been configured to correspond to an authorized network participant.

[0531] In this way, the deployable installation package 925 can be shared, distributed, or even published via the host organization's support page, without any unauthorized users being granted the declared application in question, as long as they cannot spoof the IP and provide the correct shared public key in response to the challenge.

[0532] In certain embodiments, a user-based authentication challenge can additionally be provided for known users without such users or the non-customer partner organizations associated with the users subscribing to any services from the host organization.

[0533] While users of the claiming application can interact with the claiming application using the API and thus indirectly interact with the blockchain through the claiming application, they are not required to do so.

[0534] Instead, according to a particular implementation, the deployable package 925 provides a user interface dynamically generated from metadata stored on the blockchain for a claiming application whose executor of the deployable package 925 is an authorized network participant.

[0535] Therefore, the deployable package 925 does not need to have any dedicated UI. Instead, any GUI, API, or UI required by the claiming application will be dynamically constructed by the deployable package 925 based on the relevant metadata of the claiming application.

[0536] In this way, non-customer partner organizations that have not subscribed to any services from the host organization can still utilize the blockchain service interface of the host organization (through the claiming application) and utilize, interact with, and store data on the blockchain accessible through the blockchain service interface of the host organization.

[0537] According to a particular implementation, once the deployable package 925 is executed, the user can authenticate to the claimed application through the dynamically constructed UI, which will associate the public key provided by the user in response to an initial query and then continue to generate a GUI display screen based on the defined metadata of the claimed application, including any defined entities and any defined field definitions. Non-customers of the host organization can input data for transactions on the blockchain via the display screen, update such data on the blockchain, and retrieve data from the blockchain, including data written to the blockchain by another organization, but share data associated with the claimed application with that other organization, thus forming a common set of data on the blockchain for all authorized network participants using the new claimed application.

[0538] Therefore, the GUI allows the blockchain administrator to define applications, define entities, define fields for each entity, define permitted network participants, and then allow host organization users and non-customer users to access the hosted software, where all declarative metadata resides within the blockchain. Such a blockchain can operate entirely outside the host organization and even be uncontrolled by the host organization as long as the host organization can access the blockchain. In an alternative implementation, the declarative metadata resides in a modified DLT that operates within the host organization and the host organization is its single central trust authority.

[0539] In the case where the declarative metadata is hosted on an accessible blockchain outside the host organization, such as the blockchain 999 shown herein, the claiming application interacts with the information on the blockchain by transacting with the blockchain to obtain payload data from assets, update assets, create assets, etc.

[0540] However, it is worth noting that the authoritative copy of the data is hosted outside the host organization on an accessible blockchain 999 and is not stored in any table within the host organization's database 130. The materialized view discussed above is an optional feature, but even if used, the information in the materialized view is not the authoritative copy. Any transaction that modifies the data associated with the application must not only comply with the defined metadata but also be updated on the blockchain 999. If the modified DLT runs internally, the application-related data must be updated as the authoritative source within the modified DLT. Thus, such application data is saved by the accessible blockchain 999 as the ultimate authoritative copy of the data. Therefore, even if the materialized view is deleted or corrupted, or becomes out of sync with the accessible blockchain, it will not affect the operation of the claiming application because the data of the application and the structure and metadata that define such data are stored by the accessible blockchain 999.

[0541] Figure 9C Depicts another exemplary architecture 903 according to the described embodiments.

[0542] As shown herein, there is an event listener 960 in the blockchain service interface 190 that accepts a defined trigger 961 from the blockchain administrator and then operates to listen for a specified event that occurs on the blockchain. In response, it triggers or fires an event, shown herein as event trigger 962, in order to push a transaction to the host organization, or initiate the execution of a flow or data processing flow, or any defined operation specified by the blockchain administrator. While this is a mechanism similar to that used to automatically trigger the execution of a smart contract to enforce data compliance with the defined metadata, the event listener and the defined trigger 961 allow the blockchain administrator to define any executable operation to occur based on their own custom criteria, regardless of the operation performed by the smart contract execution.

[0543] Thus, according to certain embodiments, any time a change occurs within an accessible blockchain that matches a defined trigger 961 owned by the event listener 960, the event listener will trigger one or more events (event trigger 962) back to the accessible cloud platform 186, and the blockchain administrator can write any kind of flow, such as creating a smart contract to be executed or some other flow defined by the blockchain administrator, by submitting code to the blockchain service interface 190 via an API or via a GUI that allows the blockchain administrator to create the flow (e.g., via an integration generator and associated GUI), and then the flow will cause an update within the accessible cloud platform 186 defined by the event trigger 962 in response to changes occurring on the blockchain monitored by the event listener 960. According to one embodiment, in response to the event trigger 962, a database transaction is executed within the database 130 of the host organization or within the accessible cloud platform. In another embodiment, based on changes that have occurred within the blockchain as monitored by the event listener 960, a GUI is triggered and pushed to a user client device that presents information.

[0544] Figure 10 is a flowchart of an embodiment for reading a consensus process. This process can be implemented by the blockchain consensus manager 191 or a similar component of the blockchain service interface 190. The read consensus process can be triggered by a node 133 in the blockchain network attempting to access data in the blockchain to read the data, where the data is protected by a permission scheme or similar mechanism to control access to the data. This process is independent of the access control layer 147 in the blockchain service interface 190. If the data to be accessed is managed by the read consensus process, the read consensus process must be satisfied for the requesting node to access the data from the encrypted blockchain. A request to read data in the blockchain can have any granularity level at which fields, records, metadata, or similar data in the blockchain can be protected individually by the process.

[0545] When data is first stored in a blockchain where read access is to be restricted, the transaction is received by the blockchain service interface 190 (block 1001). The blockchain consensus manager 191 determines whether to confirm the transaction to the blockchain according to the consensus protocol of the blockchain network. In the case where the transaction is to be committed, the blockchain consensus manager 191 generates a key to encrypt the data to be stored (block 1003). This key is used to encrypt the data, and this key will also be recovered and used to decrypt the data for access. The key used for encryption is converted into a set of shared secrets (block 1005). Any secret sharing process or protocol can be used (e.g., Shamir's secret sharing algorithm), which can convert the key into a set of shared secrets, the number of which is equal to the number of nodes participating in the consensus in the blockchain network. Similarly, any secret sharing algorithm with a desired threshold or configurable threshold can be selected to generate the shared secrets. Using such a shared secret algorithm ensures that data can only be accessed when a threshold number of shared secrets are provided by other nodes in the blockchain network to reconstruct the key required for decryption. The threshold can be fixed or configurable. The threshold can be any value, for example, a number equal to half or two-thirds of the number of participating nodes.

[0546] Since each shared secret is generated by the secret sharing algorithm, the shared secret designated for a specific node in the blockchain network is encrypted using the public key of that node (block 1007). Thus, only the associated node can decrypt the shared secret allocated to it and provide it in the case of an authorized read request as part of the read consensus process. When the transaction is submitted to the blockchain for consensus, these encrypted shared secrets are stored as metadata of the relevant transaction data (block 1009).

[0547] Subsequently, after the protected data is stored on the blockchain, any node (block 1011) attempting to service a request to access the protected data must initiate a read request that is broadcast to other nodes in the blockchain network. The read request identifies the data to be accessed and may include information about the node or entity requesting access to the data (e.g., a set of certificates for the entity) (block 1013). Each node then performs its read consensus process and determines whether the credentials or other criteria for accessing the requested data are met. Each node that determines that the criteria for reading the data are met provides its share of the secret to the requesting node (block 1015). The requesting node may collect the shares of the secret and determine whether a defined threshold number of shares of the secret have been provided (block 1017). If the threshold number of shares of the secret is not returned, the read consensus process rejects the read request and cannot be completed (block 1019). In some embodiments, the read consensus process may have a time limit or window within which the process must receive the threshold number of shares of the secret. If the threshold number of shares of the secret is provided by other nodes, the requesting node may use a secret sharing algorithm to convert the shares of the secret into a key for decrypting the requested data and may then decrypt and access the requested data (block 1021). After the data has been accessed, the requesting node may discard the key such that the key must be requested and recombined again for subsequent accesses.

[0548] When the encrypted data from an initial transaction is stored on the blockchain, the associated metadata including the share of the secret for each node in the blockchain network is also stored on the blockchain. The metadata format may be defined and organized as detailed herein in connection with other disclosed embodiments. The metadata may identify the share of the secret, the owner of the transaction data, the permissions or privileges of access control associated with the transaction data, the privacy information associated with the transaction data, the ownership information of the transaction data, and similar information. The metadata may define these attributes of the transaction at the object, record, field, or similar component level that is consistent with the transaction data format. The owner of the transaction data may be a user, node, or similar entity that operates on and utilizes the blockchain network. Further embodiments of the access control process and the right to be forgotten process are defined hereinafter that utilize this additional detailed metadata and the principles of the read consensus process.

[0549] Figures 11A to 11C is a flowchart related to a set of processes for implementing the right to be forgotten function within the blockchain service interface 190. The right to be forgotten function utilizes aspects of the read consensus process to enable an entity to designate data as private data and, upon the entity's request, have the blockchain "forget" the private data. This function helps the blockchain implementing the right to be forgotten function to comply with GDPR standards. Figures 11A to 11CThe flowchart describes three related aspects of the right to be forgotten process, namely, the initial storage of private data, also known as private information or PI information, the request for data to be "forgotten", and the access request. Together, these functions provide the blockchain with the ability to "forget" data by encrypting the private data and then deleting the encryption key upon request by the controlling entity to ensure that the data cannot be accessed again. Thus, the right to be forgotten function can effectively designate data as being "forgotten" by the blockchain because even if the data exists in encrypted form on the blockchain, it cannot subsequently be accessed.

[0550] In Figure 11A it, the right to be forgotten process is initiated by a node that receives, at the blockchain interface, a transaction to be stored on the blockchain, where the transaction includes a unique user identifier (UUID) of the entity associated with the data (block 1101). Additionally, the received transaction includes an indicator of the aspects of the data that are to be designated as private. The entire data or any aspect of the data at any granularity level can be designated as private, for example, an object, a record, a data field, and / or metadata. When it is determined, based on the consensus of the nodes in the blockchain, that the transaction is to be committed to the blockchain, the object and metadata format of the transaction data for storing the data on the blockchain is determined, where the object and metadata will include the owning entity UUID or a similar identifier and a set of indicators to identify the object, record, field, or similar component of the data that is designated as private (block 1103).

[0551] The blockchain consensus manager 191 or the permission manager generates a key to encrypt the data to be stored (block 1105). The key is used to encrypt the data and will be used to decrypt the data to access the data. The key is then converted into a set of shared secrets (block 1107). Any secret sharing process or protocol can be used (e.g., Shamir's secret sharing algorithm), which can convert the key into a set of shared secrets, the number of which is equal to the number of nodes participating in the consensus in the blockchain network. Similarly, a secret sharing algorithm with a desired threshold or a configurable threshold can be selected to generate the shared secrets. Using such a shared secret algorithm ensures that the data can only be accessed when a threshold number of shared secrets are provided by other nodes in the blockchain network to reconstruct the key required for decryption. The threshold can be fixed or configurable. The threshold can be any value, for example, a number equal to half or two-thirds of the number of participating nodes.

[0552] Since each shared secret is generated by a secret sharing algorithm, the shared secret designated for a particular node in the blockchain network is encrypted using the public key of that node (block 1109). Thus, only the associated node can decrypt the shared secret assigned to it and provide it, in the case of an authorized read request, as part of the read consensus. When a transaction is submitted to the blockchain for consensus, these encrypted shared secrets are stored as metadata for the associated transaction data (block 1111).

[0553] Figure 11B is a flowchart of a process for servicing requests to "forget" private data in a blockchain network. The permissions manager 181 receives a request from an entity to forget the designated data associated with a UUID (block 1121). The permissions manager 181 or a related component may authenticate the request to verify that sufficient credentials have been presented to ensure that the requester is authorized to initiate the process of forgetting the identified data. The requester may present a security token, password, encryption key, and / or similar credentials to verify authorization. If authenticated, the request is processed to add the UUID and / or identifier of the data to be forgotten (block 1123). The process may be configured to "forget" all data associated with the UUID or specific objects, records, or fields identified by the request. The UUID and any data identification information can then be recorded in a list of "forgotten" items. If there are any keys or shared secrets specific to or associated with the UUID or the identification information, the node may delete that local information (block 1125). Additionally, the node may broadcast or otherwise synchronize the list of forgotten UUIDs and / or information with other nodes of the blockchain.

[0554] Figure 11CIt is a flowchart of a process for servicing requests to access "forgotten" private data in a blockchain network. Subsequently, after the private data is stored in the blockchain, any node (block 1131) attempting to service a request to access protected data performs an initial check (block 1133) on the requester's UUID and / or the identification information of the requested data against the list of forgotten UUIDs / data. If the UUID or the requested data is listed as "forgotten", the request to access the data is rejected (block 1135). If the UUID or the requested data is not found on the list, the permission manager 181 must initiate a read request, which is broadcast to other nodes in the blockchain network, and identify the data to be accessed, and include information about the node or entity requesting access to the data (i.e., a set of certificates of the UUID and possibly the entity) (block 1137). Then, each node performs its consensus process for the private information and determines whether the credentials or other criteria for accessing the requested data are met. Each node that determines that the criteria for reading the data are met provides its shared secret to the requesting node (block 1139). Then, the requesting node can collect the shared secrets and determine whether a defined threshold number of shared secrets have been provided (block 1141). If the threshold number of shared secrets is not returned, the consensus process rejects the read request and cannot be completed (block 1143). In some embodiments, the consensus process can have a time limit or window within which the process must receive the threshold number of shared secrets. If the threshold number of shared secrets is provided by other nodes, the requesting node can use a shared secret algorithm to convert the shared secrets into a key, and then can decrypt and access the requested data (block 1145). After the data has been accessed, the requesting node can discard the key, such that the key must be requested and recombined again in a subsequent access.

[0555] Figure 11D It is a schematic diagram of an example implementation of the GDPR. In Figure 11D In the example shown, private information (PI information) can be directly stored in the blockchain or in a distributed storage. A node attempting to add PI information to the blockchain can interact with the REST API to create / update the PI information. The metadata associated with the PI information, the PI metadata, is defined via the metadata API of the blockchain platform. In turn, the REST API manages the creation of keys for records with PI information and the storage of the PIN information in the blockchain or in a distributed memory (as shown). The hashes of non-PI data and PI data can be stored in the blockchain via the REST API. The metadata can be stored in the blockchain via the metadata API as separate metadata and / or as part of the consent and GDPR model.

[0556] In the case of distributed storage, the hash of the PI data is stored on the blockchain, while the actual PI data is stored outside the blockchain. Deleting the PI information at the off-chain storage location will only leave the hash of the PI information on the blockchain. A hash is a one-way function and cannot be used to obtain the PI information after deletion. In some cases, the hash can be stored together with the ciphertext for further protection.

[0557] Figures 12A to 12C is a flowchart related to a set of processes for implementing an access control function within the blockchain service interface 190. The access control function utilizes various aspects of the read consensus process to enable entities to specify data access control, thereby enabling read and write permissions for the blockchain. Figures 12A to 12C The flowchart of describes three related aspects of access control, namely the initial storage of data with a set of permissions, write requests for the data, and read requests for the data. These functions together provide the blockchain with the ability to implement data access control by encrypting the data and then using smart contracts to control writes to the data, while using consensus reads to control reads of the data. These access control functions apply to both permissioned (i.e., private) and public blockchains and are independent of the access control layer associated with permissioned blockchains.

[0558] In Figure 12A , the access control process is initiated by a node that receives, at the blockchain interface, a transaction to be stored on the blockchain, where the transaction includes a unique user identifier (UUID) of the entity associated with the data and an indication of the ownership and access privileges (i.e., permissions) of the data (block 1201). In addition,...

Claims

1. A method for providing the right to forget data in a blockchain, executed by a system organized by a host organization, the system providing a blockchain interface to the blockchain on behalf of multiple tenants of the host organization, the multiple tenants acting as nodes in a blockchain network, the method comprises: Receiving a request including an identifier of a requester, the request to access transaction data designated as private; Determining whether the identifier of the requester or the identifier of the transaction data is included in a list that indicates a request has been received to forget data associated with the requester or to forget the transaction data; When the identifier of the requester or the identifier of the transaction data is included in the list, denying access to the transaction data because inclusion in the list indicates the transaction data is permanently inaccessible; and In response to determining that the identifier of the requester or the identifier of the transaction data is not included in the list, performing the following operations: Requesting access to the transaction data from the nodes in the blockchain network, the access request including the identifier of the requester; In response to receiving a number of shared secrets insufficient to establish consensus by the blockchain network, denying access to the transaction data; and In response to receiving a number of shared secrets sufficient to establish consensus by the blockchain network, decrypting the transaction data.

2. The method according to claim 1, further comprises: Determining that the identifier of the requester is on the list.

3. The method according to claim 1, further comprises: Receiving a request to forget data associated with a unique user identifier; and Adding the unique user identifier to the list.

4. The method according to claim 1, wherein the transaction data is decrypted in response to receiving a threshold number of shared secrets.

5. The method according to claim 1, wherein a decryption key is recovered from the received shared secrets.

6. The method according to claim 1, wherein access to the transaction data is denied in response to the number of received shared secrets being below a threshold for recovering an encryption key.

7. The method according to claim 1, further comprises: Defining an object and metadata of the transaction data to be stored in the blockchain, including private information identifying the object and fields.

8. A computer system of a host organization, configured to execute a method for providing the right to forget data in a blockchain, the computer system providing a blockchain interface to the blockchain on behalf of multiple tenants of the host organization, each tenant acting as a node in a blockchain network, the computer system comprises: A computer-readable medium having stored therein the blockchain interface and a permission manager; and A processor to execute the blockchain interface and the permission manager, the permission manager: Receiving a request including an identifier of a requester, the request to access transaction data designated as private; Determining whether the identifier of the requester or the identifier of the transaction data is included in a list that indicates a request has been received to forget data associated with the requester or to forget the transaction data; When the identifier of the requester or the identifier of the transaction data is included in the list, access to the transaction data is denied because inclusion in the list indicates that the transaction data is permanently inaccessible; and In response to determining that the identifier of the requester or the identifier of the transaction data is not included in the list, perform the following operations: Request access to the transaction data from the nodes in the blockchain network, the access request including the identifier of the requester; In response to receiving a number of shared secrets insufficient to establish consensus by the blockchain network, deny access to the transaction data; and In response to receiving a sufficient number of shared secrets to establish consensus by the blockchain network, decrypt the transaction data.

9. The computer system according to claim 8, wherein the permission manager further: Determine that the identifier of the requester is on the list.

10. The computer system according to claim 8, wherein the permission manager further: Receive a request to forget data associated with a unique user identifier and add the unique user identifier to the list.

11. The computer system according to claim 8, wherein in response to receiving a threshold number of shared secrets, the transaction data is decrypted.

12. The computer system according to claim 8, wherein a decryption key is recovered from the received shared secrets.

13. The computer system according to claim 8, wherein denying access to the transaction data is in response to the number of received shared secrets being below a threshold for recovering the encryption key.

14. The computer system according to claim 8, wherein the permission manager further: Define the object and metadata of the transaction data to be stored in the blockchain, including private information identifying the object and fields.

15. A computer-readable medium having a set of instructions stored therein, which when executed, cause a computer system of a host organization to perform a set of operations of a method for managing read access to data in a blockchain, the computer system providing a blockchain interface to the blockchain on behalf of a plurality of tenants of the host organization, the plurality of tenants acting as nodes in the blockchain network, the set of operations including: Receive a request including an identifier of a requester, the request to access transaction data designated as private; Determine whether the identifier of the requester or the identifier of the transaction data is included in a list that indicates that a request to forget data associated with the requester or to forget the transaction data has been received; When the identifier of the requester or the identifier of the transaction data is included in the list, deny access to the transaction data because inclusion in the list indicates that the transaction data is permanently inaccessible; and In response to determining that the identifier of the requester or the identifier of the transaction data is not included in the list, perform the following operations: Request access to the transaction data from the nodes in the blockchain network, the access request including the identifier of the requester; Denying access to the transaction data in response to receiving a number of shared secrets insufficient for the blockchain network to establish consensus; and Decrypting the transaction data in response to receiving a number of shared secrets sufficient for the blockchain network to establish consensus.

16. The computer-readable medium according to claim 15, the set of operations further comprises: Determining that the identifier of the requester is on the list.

17. The computer-readable medium according to claim 15, the set of operations further comprises: Receiving a request to forget data associated with a unique user identifier; and Adding the unique user identifier to the list.

18. The computer-readable medium according to claim 15, wherein the transaction data is decrypted in response to receiving a threshold number of shared secrets.

19. The computer-readable medium according to claim 15, wherein a decryption key is recovered from the received shared secrets.

20. The computer-readable medium according to claim 15, wherein denying access to the transaction data is in response to the number of received shared secrets being below a threshold for recovering the encryption key.

Images