SQL Processing Engine for Blockchain Ledger

Abstract

Receive a Structured Query Language (SQL) request applied to a subset of blocks stored on a blockchain ledger, store in a cache a portion of the blocks stored on the blockchain ledger, identify one or more blocks to which the SQL request is applied and that are not stored in the cache, retrieve from the blockchain ledger the identified one or more blocks not stored in the cache, perform an SQL operation that combines one or more blocks in the cache to which the SQL request is applied and the one or more blocks retrieved from the blockchain ledger, and send the combined blocks to a computing system associated with the received SQL request.

Description

Technical Field

[0001] This application generally relates to a system for querying blockchain data, and more particularly to an SQL processing engine that can utilize a cache table to store blocks in a blockchain ledger and respond to SQL queries with partial predicate pushdown. Background Art

[0002] A centralized database stores and maintains data in a single database at one location, such as a database server. This location is typically a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe. The information stored in a centralized database can generally be accessed from multiple different points. For example, multiple users or client workstations can work on a centralized database simultaneously based on a client / server configuration. A centralized database is easy to manage, maintain, and control due to its single location, and is particularly suitable for security needs. In a centralized database, data redundancy is minimized because the single storage location for all data also means that there is only one master record for a given dataset.

[0003] However, centralized databases have significant drawbacks. For example, a centralized database has a single point of failure. In particular, if there is no fault tolerance consideration and a hardware failure (such as a hardware, firmware, and / or software failure) occurs, then all the data in the database will be lost and the work of all users will be interrupted. In addition, a centralized database is highly dependent on network connectivity. Therefore, the slower the connection, the longer the time required for each database access. Another drawback is that when a centralized database encounters high traffic due to its single location, bottlenecks occur. In addition, a centralized database provides limited access to data because the database only maintains one copy of the data. Therefore, multiple devices cannot access the same data block simultaneously without causing serious problems or risking overwriting the stored data. Moreover, since the database storage system has minimal or even no data redundancy, it is difficult to retrieve accidentally lost data unless it is retrieved manually from backup storage. Therefore, a solution that overcomes these drawbacks and limitations is needed.

[0004] Recently, blockchain has gained popularity as a storage mechanism that can mitigate the disadvantages of traditional database storage. However, one advantage of traditional databases over blockchain is the ability to process SQL queries that provide efficient database retrieval operations. At the same time, when a blockchain receives a query request for a block, in the absence of an index, the entire ledger must be scanned / accessed. Therefore, a solution that overcomes these drawbacks and limitations is needed. Summary of the Invention

[0005] An exemplary embodiment provides a system that includes a network interface, a cache, and a processor. The network interface is configured to receive a Structured Query Language (SQL) request applied to a subset of blocks stored in a blockchain ledger. The cache is configured to store a portion of the blocks stored in the blockchain ledger. The processor is configured to identify one or more blocks to which the SQL request is applied and that are not stored in the cache, and retrieve the identified one or more blocks not stored in the cache from the blockchain ledger. The processor is further configured to perform SQL operations to merge one or more blocks from the cache to which the SQL request is applied and the one or more blocks retrieved from the blockchain ledger, and control the network interface to send the merged blocks to a computing system associated with the received SQL request.

[0006] Another exemplary embodiment is a method that includes one or more of the following: receiving a Structured Query Language (SQL) request applied to a subset of blocks stored in a blockchain ledger, storing a portion of the blocks stored in the blockchain ledger in a cache, identifying one or more blocks to which the SQL request is applied and that are not stored in the cache, retrieving the identified one or more blocks not stored in the cache from the blockchain ledger, performing SQL operations to merge one or more blocks from the cache to which the SQL request is applied and the one or more blocks retrieved from the blockchain ledger, and sending the merged blocks to a computing system associated with the received SQL request.

[0007] Receive a Structured Query Language (SQL) request applied to a subset of blocks stored in a blockchain ledger, store a portion of the blocks stored in the blockchain ledger in a cache, identify one or more blocks to which the SQL request is applied and that are not stored in the cache, retrieve the identified one or more blocks not stored in the cache from the blockchain ledger, perform SQL operations to merge one or more blocks from the cache to which the SQL request is applied and the one or more blocks retrieved from the blockchain ledger, and send the merged blocks to a computing system associated with the received request. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 A diagram showing a system including an SQL processing engine for a blockchain according to an exemplary embodiment.

[0009] Figure 2A An example of a blockchain architecture configuration according to an exemplary embodiment is shown.

[0010] Figure 2B Illustrates a blockchain transaction flow between nodes according to an exemplary embodiment.

[0011] Figure 3A Illustrates a permissioned network according to an exemplary embodiment.

[0012] Figure 3B Illustrates another permissioned network according to an exemplary embodiment.

[0013] Figure 3C Is a diagram illustrating a permissionless network according to an exemplary embodiment.

[0014] Figure 4A Is a diagram illustrating a cache table storing block data in tabular format according to an exemplary embodiment.

[0015] Figure 4B Is a diagram illustrating a process of retrieving and combining block data in a cache table and a blockchain ledger according to an exemplary embodiment.

[0016] Figure 5 Is a diagram illustrating a method of processing SQL commands using a cache table for a blockchain according to an exemplary embodiment.

[0017] Figure 6A Illustrates an example system configured to perform one or more operations described herein according to an embodiment.

[0018] Figure 6B Illustrates another example system configured to perform one or more operations described herein according to an embodiment.

[0019] Figure 6C Illustrates another example system configured to use smart contracts according to an embodiment.

[0020] Figure 6D Illustrates another example system configured to use a blockchain according to an exemplary embodiment.

[0021] Figure 7A Illustrates a process of adding a new block to a distributed ledger according to an embodiment.

[0022] Figure 7B Illustrates the content of a new data block according to an exemplary embodiment.

[0023] Figure 7C Illustrates a blockchain for digital content according to an exemplary embodiment.

[0024] Figure 7D Illustrates a block that can represent the structure of a block in a blockchain according to an exemplary embodiment.

[0025] Figure 8A is a diagram showing an example blockchain for storing machine learning (artificial intelligence) data according to an exemplary embodiment.

[0026] Figure 8B is a diagram showing an example quantum-secure blockchain according to an exemplary embodiment.

[0027] Figure 9 shows an example system supporting one or more exemplary embodiments. Detailed Description

[0028] It is readily understood that the components generally illustrated and exemplified in the accompanying drawings herein can be arranged and designed in a variety of different configurations. Accordingly, the following detailed description of embodiments of at least one of a method, apparatus, non-transitory computer-readable medium, and system as shown in the drawings is not intended to limit the scope of the claimed application but merely represents selected embodiments.

[0029] Features, structures, or characteristics described throughout the specification can be combined or removed in any suitable manner in one or more embodiments. For example, the use of phrases such as "exemplary embodiment", "some embodiments", or other similar language throughout the specification refers to the fact that a particular feature, structure, or characteristic described in connection with that embodiment can be included in at least one embodiment. Thus, the phrases "exemplary embodiment", "in some embodiments", "in other embodiments", or other similar language that appear throughout the specification do not necessarily all refer to the same set of embodiments, and the described features, structures can be combined or the features removed in any suitable manner in one or more embodiments.

[0030] In addition, although the term "message" may have been used in the description of embodiments, the present application can be applied to many types of networks and data. Further, although certain types of connections, messages, and signaling may be depicted in exemplary embodiments, the present application is not limited to a certain type of connection, message, and signaling.

[0031] Exemplary embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide a Structured Query Language (SQL) processing engine that can utilize a cache table to more efficiently retrieve blocks from a blockchain ledger. When an SQL query for a subset of blocks is received, the SQL processing engine can identify and retrieve the portion of the subset stored in the cache table and retrieve any non-cached blocks from the blockchain ledger. Additionally, the SQL processing engine can use a union command to combine the cached and non-cached blocks and return the combined data in response to the SQL query.

[0032] In one embodiment of the present application, a decentralized database (such as a blockchain) is used, which is a distributed storage system including a plurality of nodes communicating with each other. The decentralized database includes an append-only but immutable data structure, similar to a distributed ledger that can maintain records among untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and without consensus among the distributed peers, a single peer cannot modify the database records. For example, the peers can execute a consensus protocol to verify blockchain storage transactions, group the storage transactions into blocks, and build a hash chain on the blocks. This process forms a ledger by sorting the storage transactions as needed to maintain consistency. In various embodiments, a permissioned and / or permissionless blockchain can be used. In a public or permissionless blockchain, anyone can participate without a specific identity. Public blockchains typically involve native cryptocurrencies and use consensus based on various protocols (such as Proof of Work (PoW)). On the other hand, a permissioned blockchain database provides secure interactions among a group of entities with common goals but not fully trusting each other - such as enterprises exchanging funds, goods, information, etc.

[0033] This application can utilize a blockchain with any programmable logic, called "smart contract" or "chaincode", which is customized for a decentralized storage solution. In some cases, there may be dedicated chaincodes for managing functions and parameters, called system chaincodes. This application can further utilize such smart contracts: they are trusted distributed applications that utilize the tamper-proof property of the blockchain database and the underlying protocol between nodes called endorsement or endorsement policy. Blockchain transactions associated with this application can be "endorsed" first and then "committed" to the blockchain, while unendorsed transactions are not considered. The endorsement policy allows the chaincode to specify endorsers in the form of a set of peer nodes required for endorsement of a transaction. When a client sends a transaction to the peers specified in the endorsement policy, the transaction is executed to verify the transaction. After verification, the transaction enters the ordering phase, where a consensus protocol is used to generate a sequenced list of endorsed transactions, which are grouped into blocks.

[0034] This application can utilize nodes as communication entities of the blockchain system. A "node" can perform logical functions, i.e., multiple nodes of different types can run on the same physical server. Nodes are grouped in trust domains and are associated with logical entities that control them in various ways. Nodes can include different types, such as client or submitting-client nodes, which submit transaction-invocations to endorsers (such as peers) and broadcast transaction proposals to the ordering service (such as ordering nodes). Another type of node is a peer node that can receive transactions submitted by clients, submit the transactions, and maintain the state and a copy of the blockchain transaction ledger. A peer can also act as an endorser, although this is not required. The ordering service node or orderer is a node that runs a communication service for all nodes and implements delivery guarantees, such as broadcasting to each peer node in the system when a transaction is committed and the world state of the blockchain is modified, which is another name for the initial blockchain transaction that typically includes control and setup information.

[0035] This application can utilize a ledger that is an ordered, tamper-proof record of all state transitions of a blockchain. State transitions may be generated by chaincode invocations (i.e., transactions) submitted by parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each party (e.g., peer node) can maintain a copy of the ledger. A transaction can cause a set of asset key-value pairs to be submitted to the ledger as one or more operands, such as create, update, delete, etc. The ledger includes a blockchain (also called a chain) for storing immutable ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0036] This application can use a chain that is a transaction log, structured as hash-linked blocks, where each block contains a series of N transactions, where N is equal to or greater than 1. The block header includes the hash of the transactions in the block, as well as the hash of the header of the previous block. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Thus, it is impossible to tamper with the ledger data without breaking the hash links. The hash of the most recently added blockchain block represents every transaction on the chain that has preceded it, which makes it possible to ensure that all peer nodes are in a consistent and trusted state. The chain can be stored on the peer node file system (i.e., local, attached storage, cloud, etc.), efficiently supporting the append-only nature of the blockchain workload.

[0037] The current state of the immutable ledger represents the latest values of all keys contained in the chain transaction log. The current state represents the latest key values known to a channel and is thus sometimes referred to as the world state. Chaincode invocations execute transactions against the current state data of the ledger. To make these chaincode interactions effective, the latest values of the keys can be stored in the state database. The state database can be just an indexed view of the chain transaction log and can thus be regenerated from the chain at any time. The state database can be automatically restored (or generated as needed) when the peer node starts up and before accepting transactions.

[0038] Some benefits of the SQL processing engine described and depicted herein include increasing the speed of accessing blockchain data by storing previously accessed blockchain data in a cache. The cache can be structured (e.g., as a relational database table with columns and rows) in a way that enables querying using SQL commands (e.g., SELECT, etc.). In addition to accelerating access to blockchain data by using the cache, the SQL processing engine can mitigate the major drawback that the cache does not contain the most up-to-date data. This mitigation is achieved through partial predicate pushdown - which enables the SQL processing engine to retrieve only a specific subset of blocks (e.g., blocks not in the cache) - and then merging them with the blocks in the cache using, for example, the SQL UNION construct command. Additionally, the SQL processing engine can be implemented in a broader solution that allows querying blockchain data (e.g., blocks identified by unique aliases such as block indices) using an SQL language that permits the use of SQL commands including SELECT, FROM, WHERE, etc.

[0039] The SQL processing engine produces an improvement in the computer functionality for querying blockchains by increasing the speed of SQL processing for retrieving data from the ledger while maintaining the availability of the entire data set (i.e., including "up-to-date" blocks that are not necessarily in the cache). The SQL processing engine also does not require a pre-existing index.

[0040] The execution model of SQL queries requires the entire data set to be loaded (which may later be filtered out) into the engine memory. Due to the technical characteristics of the distributed ledger, this requirement would be prohibitively expensive in terms of the performance of the blockchain. To mitigate this cost, the SQL processing engine performs partial predicate pushdown, which identifies and filters out a portion of the blocks stored in the cache, such that only the non-cached blocks are queried from the blockchain ledger. At the same time, the blocks from the cache can be easily retrieved without accessing the blockchain ledger.

[0041] Exemplary embodiments describe a system that can extend the way of querying a blockchain with SQL based on an SQL processing system that implements a cache table in an SQL format. For example, the cache table can be a ledger block cache implemented in an SQL format (tables, columns, rows, etc.) and can store data retrieved from a blockchain ledger. When an SQL processing engine receives an SQL query for blockchain data (blocks, etc.), the SQL processing engine can retrieve / fetch any block in the requested block from the cache. For any remaining blocks that are not cached, the SQL processing engine can perform predicate pushdown on the parts of the blocks that have been cached, so that only the uncached blocks are identified and retrieved from the blockchain ledger. This can significantly reduce the processing time and prevent the system from having to scan the entire blockchain ledger to find the necessary data. In addition, the SQL processing engine can perform an SQL UNION operation to merge the blocks from the cache that satisfy the entire SQL request with the blocks from the blockchain ledger. The merged blocks can be further processed by the SQL processing engine, such as sending the merged blocks to an application, etc.

[0042] Figure 1 FIG. shows a system 100 according to an exemplary embodiment, including an SQL processing engine 120 for querying data from a distributed ledger of a blockchain 130. Referring to Figure 1 , the SQL processing engine 120 can be implemented in an off-chain manner from the blockchain 130. For example, the SQL processing engine 120 can be a service, program, application, etc. running on a computing system such as a server, cloud platform, database, user device, etc. The SQL processing engine 120 can include one or more cache tables 122, which are stored in the SQL processing engine 120 or remotely stored but accessible to the SQL processing engine 120 via a network. In this example, the SQL processing engine 120 can execute in isolation from the blockchain 130 (which includes peer nodes). At this time, the SQL processing engine 120 is said to be "off-chain" and can be executed on any computing system with network access to the peer nodes in the blockchain network.

[0043] An application 110 (or other entity not shown) can query data from the blockchain 130. For example, the application can submit an SQL query requesting a specific subset of data blocks from the blockchain 130. In response to receiving the SQL query, the SQL processing engine 120 can identify a portion of the blocks that have been cached in the cache table 122 and retrieve this portion of the blocks locally (or via remote storage). For any uncached blocks in the SQL request, the SQL processing engine 120 can retrieve the uncached blocks from the distributed ledger of the blockchain 130. Additionally, the SQL processing engine 120 can combine the cached blocks from the cache table 122 with the uncached blocks from the blockchain 130, for example, through an SQL union command, and send the combined data block as an SQL response to the application 110.

[0044] Here, the application 110 can be an analytics application connected to the SQL processing engine 120 via a network. The application 110 can pass the SQL query to the SQL processing engine 120. If the query involves blockchain data, the SQL processing engine (without using the cache table) will scan the entire ledger to extract all blocks into the SQL engine memory, where all blocks can be processed. However, in the example of using the cache table, the query will be redirected by the SQL engine to an SQL VIEW that consists of the result of an SQL UNION operation on the cached data and a subset of the blocks extracted from the ledger that are not in the cache. The subset is extracted using a query with a WHERE clause such as "WHERE ORDINAL > MAX(CACHE_TABLE_ORDINAL)", and the above partial predicate pushdown technique is applied to the query to actually extract only those blocks (instead of extracting the entire ledger again).

[0045] The SQL processing engine 120 can periodically scrape or otherwise extract blocks from the blockchain 130 and store the block data in the cache table 122 in tabular format. As an example, the SQL processing engine can cache the data obtained from the blockchain 130 via an INSERT SQL statement for the cache table 122 when explicitly instructed. Before populating the cache table 122 with the INSERT statement, a data model (such as the one shown, etc.) can be used to create the cache table. The data inserted into the cache table 122 can be sourced from a federated view of the blocks from the blockchain application in the SQL solution. Figure 4A The data inserted into the cache table 122 can be sourced from a federated view of the blocks from the blockchain application in the SQL solution.

[0046] An entity that retrieves data from the blockchain 130 for storage in the cache table 112 can be an end user who manually executes an INSERT statement to insert data into the cache. As another example, an automated process can execute an INSERT statement to insert data into the cache based on certain predefined criteria (e.g., periodically, etc.). This does not necessarily occur every time an application accesses the ledger (e.g., it is up to the end user to decide whether to use this feature). Due to the immutability of data in the blockchain ledger, there is no need to remove old data from the cache or directly update old data in the cache. If the storage device of the cache reaches its capacity, data can be removed from the cache to free up space for more actively used data. However, the present invention does not relate to any system or method for managing the storage of the cache.

[0047] Figure 2A Illustrates a blockchain architecture configuration 200 according to an embodiment. Referring to Figure 2A , the blockchain architecture 200 can include certain blockchain elements, e.g., a set of blockchain nodes 202. The blockchain nodes 202 can include one or more nodes 204 - 210 (these four nodes are merely illustrative). These nodes participate in many activities, such as the blockchain transaction addition and verification process (consensus). One or more of the blockchain nodes 204 - 210 can endorse transactions according to an endorsement policy and can provide an ordering service for all the blockchain nodes in the architecture 200. The blockchain nodes can initiate blockchain verification and seek to write to the immutable blockchain ledger stored in the blockchain layer 216, a copy of which can also be stored on the underlying physical infrastructure 214. The blockchain configuration can include one or more application programs 224 that are linked to an application programming interface (API) 222 to access and execute the stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which can be created according to a custom configuration sought by the participants and can maintain their own state, control their own assets, and receive external information. This can be deployed as a transaction and installed on all the blockchain nodes 204 - 210 by attaching to the distributed ledger.

[0048] The blockchain foundation or platform 212 can include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and the underlying physical computer infrastructure, which can be used to receive and store new transactions and provide access to auditors seeking to access data entries. The blockchain layer 216 can expose an interface to provide the required access to the virtual execution environment for processing program code and participating in the underlying physical infrastructure 214. The cryptographic trust service 218 can be used to verify transactions such as asset exchange transactions and keep information confidential.

[0049] Figure 2A The blockchain architecture configuration of can process and execute program / application code 220 and the provided services through one or more interfaces opened by blockchain platform 212. The code 220 can control blockchain assets. For example, the code 220 can store and transmit data, and can be executed by nodes 204 - 210 in the form of a smart contract, and associate the chain code with conditions or other code elements subject to its execution constraints. As a non - restrictive example, a smart contract can be created to execute reminders, updates, and / or other notifications (depending on changes, updates, etc.). The smart contract itself can be used to identify rules related to authorization, access requirements, and ledger usage. For example, a smart contract can read a read set 226 from the blockchain, which can be processed by one or more processing entities (e.g., virtual machines) included in blockchain layer 216. The write set 228 can include the execution results of the smart contract for the read data. The underlying physical infrastructure 214 can be used to retrieve any data or information described herein.

[0050] Smart contracts can be created through high - level applications and programming languages and then written into blocks in the blockchain. Smart contracts can include executable code registered, stored, and / or replicated to the blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code, and the execution of smart contract code can occur in response to the satisfaction of conditions related to the smart contract. The execution of a smart contract can trigger a trusted modification to the state of the digital blockchain ledger. The modification to the blockchain ledger resulting from the execution of a smart contract can be automatically replicated in the distributed network of blockchain peers through one or more consensus protocols.

[0051] Smart contracts can write data to the blockchain in the form of key - value pairs. In addition, smart contract code can read the values stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. The code can be used to create temporary data structures in a virtual machine or other computing platform. The data written to the blockchain can be public and / or encrypted and maintained as private data. The temporary data used / generated by the smart contract is saved in memory by the provided execution environment and deleted once the data required by the blockchain is identified.

[0052] The chaincode can include the code interpretation of the smart contract and has additional functions. As described herein, the chaincode can be program code deployed on a computing network and executed and verified together by the chain validators during the consensus process. The chaincode receives a hash and retrieves from the blockchain a hash associated with a data template created using a previously stored feature extractor. If the hash of the hash identifier matches the hash created from the stored identifier template data, the chaincode will send an authorization key to the requested service. The chaincode can write data related to the encryption details to the blockchain.

[0053] Figure 2B An example illustrating the blockchain transaction flow 250 between blockchain nodes according to an embodiment. Refer to Figure 2B , the transaction flow can include a transaction proposal 291 sent by the application client node 260 to the endorsing peer node 281. The endorsing peer node 281 can verify the client signature and execute a chaincode function to initiate the transaction. The output can include the chaincode result, a set of key / value versions read in the chaincode (read set), and a set of key / values written in the chaincode (write set). If approved, the proposal response 292 is sent back to the client 260 along with the endorsement signature. The client 260 assembles the endorsements into a transaction payload 293 and broadcasts it to the ordering service node 284. Then, the ordering service node 284 delivers the ordered transactions as blocks to all peers 281 - 283 on the channel. Before committing to the blockchain, each peer 281 - 283 can verify the transaction. For example, the peer can check the endorsement policy to ensure that the correct assignment of specified peers has signed the result and verified the signature against the transaction payload 293.

[0054] Refer again to Figure 2B , the client node 260 initiates the transaction 291 by constructing a request and sending it to the peer node 281 (endorser). The client 260 can include an application that utilizes a supported software development kit (SDK) that utilizes available APIs to generate transaction proposals. A transaction proposal is a request to call a chaincode function so that data can be read and / or data can be written to the ledger (i.e., write new key - value pairs for assets). The SDK can act as a filler to encapsulate the transaction proposal into a properly structured format (e.g., protocol buffers over a remote procedure call (RPC)) and obtain the client's cryptographic credentials to generate a unique signature for the transaction proposal.

[0055] In response, the endorsing peer 281 can verify that: (a) the transaction proposal is well formed, (b) the transaction has not been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (in this example, the client 260) is properly authorized to perform the proposed operation on the channel. The endorsing peer 281 can input the transaction proposal as an argument to the chaincode function being called. The chaincode is then executed against the current state database to produce a transaction result that includes a response value, a read set, and a write set. However, at this point, the ledger is not updated. In 292, the set of values, along with the signature of the endorsing peer 281, is passed back as a proposal response 292 to the SDK of the client 260, which parses the payload for use by the application.

[0056] In response, the application of the client 260 checks / verifies the endorsing peer signature and compares the proposal responses to determine if the proposal responses are the same. If the chaincode only queried the ledger, the application will check the query response and generally does not submit the transaction to the ordering service node 284. If the client application intends to submit the transaction to the ordering service node 284 to update the ledger, the application determines whether the specified endorsement policy has been met (i.e., all peers required for the transaction support the transaction) before submission. Here, the client can be only one of the multiple parties to the transaction. In this case, each client can have its own endorsing node, and each endorsing node needs to endorse the transaction. This architecture enables the endorsement policy to be enforced by the peers and supported during the commit validation phase even if an application chooses not to check the responses or otherwise forward unendorsed transactions.

[0057] After a successful check, in step 293, the client 260 assembles the endorsements into the transaction and broadcasts the transaction proposal and response within the transaction message to the ordering node 284. The transaction can include the read / write set, the endorsing peer signature, and the channel ID. The ordering service node 284 does not need to check the entire content of the transaction to perform its operation, but can simply receive the transactions from all channels in the network, sort them by channel and time, and create blocks of transactions by channel.

[0058] Deliver the blocks of the transaction from the ordering service node 284 to all the peer nodes 281 - 283 on the channel. Verify the transactions 294 within the block to ensure that any endorsement policies are satisfied and that the ledger state of the read set variables has not changed since the read set was generated by the execution of the transaction. Mark the transactions in the block as valid or invalid. Additionally, in step 295, each peer node 281 - 283 appends the block to the chain of the channel and, for each valid transaction, submits the write set to the current state database. Emit an event to notify the client application that the transaction (invocation) has been immutably appended to the chain and to notify whether the transaction verification was valid or invalid.

[0059] Figure 3A Illustrates an example of a permissioned blockchain network 300 that has a distributed, decentralized peer - to - peer architecture. In this example, a blockchain user 302 can initiate a transaction to the permissioned blockchain 304. In this example, the transaction can be a deployment, invocation, or query and can be issued using an SDK through a client - side application, directly through an API, etc. The network can provide access to regulators 306 such as auditors. A blockchain network operator 308 manages member permissions, such as registering the regulator 306 as an "auditor" and the blockchain user 302 as a "customer". Auditors can be restricted to querying the ledger, while customers can be authorized to deploy, invoke, and query certain types of chaincode.

[0060] A blockchain developer 310 can write chaincode and client applications. The blockchain developer 310 can directly deploy the chaincode to the network through an interface. To include credentials from a traditional data source 312 in the chaincode, the developer 310 can use an out - of - band connection to access the data. In this example, the blockchain user 302 connects to the permissioned blockchain 304 through a peer node 314. Before any transaction, the peer node 314 retrieves the user's registration and transaction certificates from an authentication authority 316 that manages user roles and permissions. In some cases, a blockchain user must possess these digital certificates to conduct a transaction on the permissioned blockchain 304. At the same time, a user attempting to use the chaincode may need to verify their credentials on the traditional data source 312. To confirm a user's authorization, the chaincode can use an out - of - band connection to the data through a traditional processing platform 318.

[0061] Figure 3BAnother example of a permissioned blockchain network 320 is shown, which has a distributed, decentralized peer-to-peer architecture. In this example, blockchain users 322 can submit transactions to the permissioned blockchain 324. In this example, a transaction can be a deployment, an invocation, or a query, and can be issued using an SDK through a client-side application, directly through an API, etc. The blockchain network operator 328 manages member permissions, such as registering a regulator 326 as an "auditor" and a blockchain user 322 as a "customer". Auditors can be restricted to only querying the ledger, while customers can be authorized to deploy, invoke, and query certain types of chaincode.

[0062] Blockchain developers 330 write chaincode and client applications. Blockchain developers 330 can directly deploy the chaincode onto the network through an interface. To include credentials from a traditional data source 332 in the chaincode, developer 330 can use an out-of-band connection to access the data. In this example, blockchain user 322 connects to the network through peer nodes 334. Before proceeding with any transaction, peer nodes 334 retrieve the user's registration and transaction certificates from a certification authority 336. In some cases, blockchain users must possess these digital certificates to conduct transactions on the permissioned blockchain 324. At the same time, users attempting to use the chaincode may need to verify their credentials on the traditional data source 332. To confirm a user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 338.

[0063] In some embodiments, the blockchain herein can be a permissionless blockchain. Contrary to a permissioned blockchain which requires permission to join, anyone can join a permissionless blockchain. For example, to join a permissionless blockchain, a user can create a personal address and start interacting with the network by submitting a transaction and thus adding an entry to the ledger. Additionally, all parties can choose to run a node on the system to help verify transactions.

[0064] Figure 3CProcess 350 shows the process of a transaction processed by a permissionless blockchain 352 including a plurality of nodes 354. Sender 356 desires to send a payment or some other form of value (e.g., a deed, medical record, contract, goods, services, or any other asset that can be encapsulated in a digital record) to receiver 358 via permissionless blockchain 352. In one embodiment, each of sender device 356 and receiver device 358 may have a digital wallet (associated with blockchain 352) that provides user interface control and display of transaction parameters. In response, the transaction is broadcast throughout blockchain 352 to nodes 354. Depending on the network parameters of blockchain 352, the nodes verify 360 the transaction based on rules established by the creator of permissionless blockchain 352, which may be predefined or dynamically assigned. For example, this may include verifying the identities of the parties involved, etc. The transaction may be immediately verified, or may be placed in a queue with other transactions, and nodes 354 determine whether the transaction is valid based on a set of network rules.

[0065] In structure 362, valid transactions are formed into a block and sealed with a lock (hash). This process may be performed by nodes in nodes 354. The nodes may utilize other software dedicated to creating blocks of permissionless blockchain 352. Each block may be identified by a hash (e.g., a 256-bit number, etc.) created by the network using an agreed-upon algorithm. Each block may include a block header, a pointer or reference to the hash of the previous block header in the chain, and a set of valid transactions. The reference to the previous block hash is associated with the creation of a secure and independent blockchain.

[0066] Before a block can be added to the blockchain, the blocks must be verified. Verification for permissionless blockchain 352 may include a Proof-of-work (PoW), which is a solution to a puzzle derived from the block header of the block.

[0067] By solving 364, the node attempts to solve the block by incrementally changing a variable until the solution meets a certain network-wide goal. This creates the PoW, thus ensuring the correct answer. In other words, the potential solution must prove that computational resources are exhausted when solving the problem..

[0068] Here, the PoW process, along with the blockchain, makes it extremely difficult to modify the blockchain because an attacker must modify all subsequent blocks for a modification to a block to be accepted. Additionally, as new blocks are mined, the difficulty of modifying a block increases and the number of subsequent blocks increases. By distributing 366, the successfully verified block is distributed via the permissionless blockchain 352, and all nodes 354 add the block to the majority chain that serves as the auditable ledger of the permissionless blockchain 352. Additionally, the value in the transaction submitted by the sender 356 is deposited or otherwise transferred to the digital wallet of the recipient device 358.

[0069] Figure 4A A cache table 400 storing block data in tabular format according to an exemplary embodiment is shown. Referring Figure 4A , the cache table 400 can be used for federated queries (i.e., the data source is not managed by the SQL processing engine 120 but is stored on the blockchain). Here, the cache table 400 can map the block attributes (the values of the block data) of the blockchain to columns and / or rows in a relational data model (such as an SQL table) presented inside the SQL processing engine. In this example, the columns 401, 402, 403, 404, and 405 of the cache table 400 include values of block attributes such as the sequence number value 401 (e.g., block number, block index, etc.), the channel ID 402, the computed hash of the data of the block 403, the previous hash of the previous block on the chain 404, the transaction count 405, etc. Other examples include filter values, metadata values, the timestamp of the block, computed hashes, etc. In this model, the sequence number column 401 stores (maps to) the value of the unique index of the block in the blockchain on the distributed ledger. Thus, the sequence number column 401 is the unique value of the corresponding block and can be used to identify the block.

[0070] As will be appreciated, a general SQL query against blockchain ledger data would require loading the entire ledger in the SQL processing engine. However, using predicate pushdown allows the SQL processing engine to perform "early" filtering of the query (i.e., before the SQL engine does its own work) in order to make decisions about which blocks to effectively extract from the blockchain into the SQL engine and which blocks are already stored in the cache table 400, resulting in significant performance improvements. Since most blockchain implementations provide a way to extract individual blocks based on their indexes, the SQL processing engine performs early filtering on the block index, for example, by analyzing the SQL query "WHERE" clause to find which blocks are requested / or rejected based on their indexes. As an example, the "WHERE ORDINAL > 100" clause indicates that the SQL processing engine should retrieve only the blocks with index > 100. This can be significantly beneficial when the distributed ledger holds more than 100 blocks (e.g., 1024 blocks, etc.) because the system does not need to scan the entire ledger for transaction data but only needs to retrieve specific blocks based on the block number or index.

[0071] This is not a trivial task because most "WHERE" clauses are complex boolean expressions that contain multiple columns and filtering operators (e.g., ORDINAL > 15 AND ARG_0 = "create_account" OR ORDINAL < 45 AND ARG_1 = "customer_name"). To achieve this, the SQL processing engine can traverse the WHERE clause expression tree and for each filtering operator (e.g., =, >, <), compute the list of blocks produced by that filter (e.g., ORDINAL <= 45 produces the list "blocks 0 to 45"). Filters that do not apply to the ORDINAL column produce the entire ledger. When boolean operators (e.g., "AND" in "ORDINAL > 15 AND ORDINAL < 45") are used in combination with the filtering operators, the lists of blocks from the two filtering operators are combined using appropriate mathematical set operations (e.g., UNION, INTERSECTION, etc.) depending on the boolean operator used. For example, "ORDINAL > 15 AND ORDINAL < 45" produces 2 lists (16 to the last and 0 to 44) that are "intersected" to provide the final list of "16 to 44".

[0072] Figure 4B A process 420 for retrieving and combining block data from the cache table 400 and the blockchain 440 according to an exemplary embodiment is shown. Refer to Figure 4B, the SQL processing engine 430 receives an SQL query 422 that includes SELECT, FROM, and WHERE clauses / commands. Here, the SQL processing engine 430 can identify which blocks identified in the SQL query 422 are stored in the cache table 400 and which blocks are not cached and must be retrieved from the blockchain 440. In Figure 4A the example, the cache table 400 stores block numbers 1 - 10 and 31 - 45.

[0073] Return Figure 4B , the SQL processing engine 430 can perform partial predicate pushdown to filter which blocks need to be retrieved from the blockchain 440. In this example, the SQL processing engine 430 can identify / detect that blocks 31 - 40 are cached and stored in the cache table 400. Thus, the SQL processing engine 430 can determine that the remaining blocks of the SQL query (i.e., 21 - 30) must be retrieved from the blockchain 440. For example, the SQL processing engine 430 can find out which data to retrieve from the blockchain source by performing the set difference of 1) the integer sequence from 0 to the ledger height and 2) the set of "ORDINAL" (ordinal) values in the cache. For example, if the cache contains blocks with the following "ORDINAL" values: (1 - 10 and 31 - 45) and the height of the ledger is 50, then the set difference will result in: (1 to 50) - (1 - 10 and 31 - 45) = (11 - 30 and 46 - 50). In this example, the SQL processing engine 430 can directly extract from the blockchain source the blocks with "ORDINAL" values in (11 - 30 and 46 - 50). Then, these block records can be combined with the block records from the cache via an SQL UNION operation to provide the complete set of block records to the application requesting the records.

[0074] Without predicate pushdown on the "ORDINAL" column, the SQL processing engine would need to pull / extract each block (over a computer network) from the blockchain, project the metadata of each block into the data model to produce corresponding records, scan each record to extract those records with "ORDINAL" column values that are included in the subset provided by the user, and return the extracted records to the end user. With predicate pushdown on the "ORDINAL" column, the SQL processing engine will (over a computer network) only pull / extract those blocks with "ORDINAL" column values that are included in the computed list.

[0075] Figure 5 illustrates a method 500 for processing SQL commands using a cache table for a blockchain according to an exemplary embodiment. Refer to Figure 5, the method may include, at 510, receiving a Structured Query Language (SQL) request for a subset of blocks stored on a blockchain ledger. The method may include, at 520, storing a portion of the blocks stored on the blockchain ledger in a cache. Here, the cache may store blocks before receiving the SQL request. In other words, when the SQL request is received at 520, the cached blocks may already exist in the cache.

[0076] At 530, the method may include identifying one or more blocks not stored in the cache that are suitable for the SQL request, and retrieving the identified one or more blocks not stored in the cache from the blockchain ledger. At 540, the method may include performing an SQL operation (such as SQL UNION, etc.) to merge one or more blocks in the cache that are suitable for the SQL request and the one or more blocks retrieved from the blockchain ledger. At 550, the method may include sending the merged blocks to a computing system associated with the received SQL request.

[0077] In some embodiments, the retrieving further includes retrieving one or more uncached blocks of a subset stored on the blockchain ledger. In some embodiments, the retrieving may further include performing predicate pushdown, where the one or more cached blocks are filtered out from the request to identify the one or more remaining uncached blocks. In some embodiments, the cache may include a columnar cache table that stores different types of block data in corresponding columns. In some embodiments, one of the columns in the columnar cache table includes a block index value corresponding to the block number of a block on the distributed ledger. In some embodiments, the method may further include, in response to receiving an SQL insert command that identifies indexes of multiple blocks, obtaining the multiple blocks from the blockchain ledger and storing the multiple blocks in the cache.

[0078] Figure 6A Illustrates an example system 600, which includes an underlying physical facility 610 configured to perform various operations according to an exemplary embodiment. Refer to Figure 6A, the underlying physical infrastructure 610 includes module 612 and module 614. Module 614 includes blockchain 620 and smart contract 630 (which can be located on blockchain 620), and this smart contract can execute any operation steps 608 (in module 612) included in any exemplary embodiment. The step / operation 608 can include one or more of the illustrated or described embodiments, and can represent output or write information written or read from one or more smart contracts 630 and / or blockchain 620. The underlying physical infrastructure 610, module 612, and module 614 can include one or more computers, servers, processors, memories, and / or wireless communication devices. Additionally, module 612 and module 614 can be the same module.

[0079] Figure 6B Illustrate another example system 640, which is configured to perform various operations according to an exemplary embodiment. Refer to Figure 6B , system 640 includes module 612 and module 614. Module 614 includes blockchain 620 and smart contract 630 (which can be located on blockchain 620), and this smart contract can execute any operation steps 608 (in module 612) included in any exemplary embodiment. The step / operation 608 can include one or more of the illustrated or described embodiments, and can represent output or write information written or read from one or more smart contracts 630 and / or blockchain 620. The underlying physical infrastructure 610, module 612, and module 614 can include one or more computers, servers, processors, memories, and / or wireless communication devices. Additionally, module 612 and module 614 can be the same module.

[0080] Figure 6C Illustrate an example system configured according to an exemplary embodiment to utilize a smart contract configuration between a contracting party and an intermediary server, where the intermediary server is configured to implement smart contract terms on a blockchain. Refer to Figure 6C , configuration 650 can represent a communication session, asset transfer session, or process driven by smart contract 630, which explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and results of the smart contract execution can be managed by server 654. The content of smart contract 630 can require digital signatures from one or more entities 652 and 656 among the parties participating in the smart contract transaction. The results of the smart contract execution can be written as a blockchain transaction to blockchain 620. Smart contract 630 resides on blockchain 620, and blockchain 620 can reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0081] Figure 6DIllustrate a system 660 including a blockchain according to an exemplary embodiment. Referring to the example of FIG. 6, an application programming interface (API) gateway 662 provides a common interface for accessing blockchain logic (e.g., smart contract 630 or other chaincode) and data (e.g., distributed ledger, etc.). In this example, the API gateway 662 is a common interface for performing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to a blockchain peer (i.e., server 654). Here, the server 654 is a peer component of the blockchain network that maintains a copy of the world state and the distributed ledger, thereby allowing clients 652 and 656 to query data about the world state and submit transactions to the blockchain network, where, depending on the smart contract 630 and the endorsement policy, the endorsement peers will run the smart contract 630.

[0082] The above embodiments can be implemented in the form of hardware, a computer program executed by a processor, firmware, or a combination of the above. The computer program can be embodied on a computer-readable medium - such as a storage medium. For example, the computer program can reside in a random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), registers, a hard disk, a removable disk, a compact disc read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

[0083] The exemplary storage medium can be coupled to the processor such that the processor can read information from the storage medium and write information to the storage medium. In an alternative, the storage medium can be a component of the processor. The processor and the storage medium can reside in an application specific integrated circuit ("ASIC"). In an alternative, the processor and the storage medium can reside as discrete components.

[0084] Figure 7A Illustrate a process 700 for adding a new block to a distributed ledger 720 according to an exemplary embodiment. Figure 7B Illustrate the content of a new data block structure 730 for a blockchain according to an exemplary embodiment. Refer to Figure 7A, a client (not shown) can submit transactions to blockchain nodes 711, 712, and / or 713. The client can be instructions received from any source for activities on blockchain 720. As an example, the client can be an application that acts on behalf of a requester, such as a device, person, or entity, to propose a transaction for the blockchain. Multiple blockchain peers (e.g., blockchain nodes 711, 12, and 713) can maintain the state of the blockchain network and a copy of the distributed ledger 720. Different types of blockchain nodes / peers can exist in the blockchain network, including endorser peers that simulate and endorse transactions submitted by the client, and committer peers that verify the endorsement, verify the transaction, and submit the transaction to the distributed ledger 720. In this example, blockchain nodes 711, 712, and 713 can perform the role of an endorser node, a committer node, or both.

[0085] The distributed ledger 720 includes a blockchain that stores immutable sequential records in blocks, and a state database 724 (current world state) that maintains the current state of the blockchain 722. Each channel can correspond to a distributed ledger 720, and each peer maintains its own copy of the distributed ledger 720 for each channel to which it belongs. The blockchain 722 is a transaction log constructed of hash-linked blocks, where each block contains a series of N transactions. A block can include various components such as Figure 7B shown in. The link of the block can be generated by adding the hash of the previous block's header to the current block's header (shown by the arrow in Figure 7A ). In this way, all transactions on the blockchain 722 are sorted and cryptographically linked together, thus preventing the blockchain data from being tampered with without breaking the hash link. Additionally, due to the link, the latest block in the blockchain 722 represents every transaction that preceded it. The blockchain 722 can be stored on a peer file system (local or attached storage) that supports append-only blockchain workloads.

[0086] The current state of the blockchain 722 and the distributed ledger 722 can be stored in the state database 724. Here, the current state data represents the latest values of all keys included in the chain transaction log of the blockchain 722. Chain code invocations execute transactions against the current state in the state database 724. To make these chain code interactions very efficient, the latest values of all keys are stored in the state database 724. The state database 724 can contain an indexed view of the transaction log of the blockchain 722, so the indexed view can be regenerated from the blockchain at any time. Before accepting a transaction, the state database 724 can be automatically restored (or generated as needed) when the peer starts up.

[0087] Endorsing nodes receive transactions from clients and endorse the transactions based on the simulation results. Endorsing nodes hold the smart contracts that propose the simulated transactions. When an endorsing node endorses a transaction, the endorsing node will create a transaction endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated transaction. The method of endorsing a transaction depends on the endorsement policy that can be specified in the chaincode. An example of an endorsement policy is "a majority of endorsing peers must endorse the transaction". Different channels can have different endorsement policies. The endorsed transactions are forwarded by the client application to the ordering service 710.

[0088] The ordering service 710 receives the endorsed transactions, orders them into a block, and delivers these blocks to the committing peers. For example, when a transaction threshold, timer timeout, or other condition is reached, the ordering service 710 can start a new block. In Figure 7A the example, the blockchain node 712 is a committing peer that has received a new data block 730 for storage on the blockchain 720. The first block in the blockchain can be called the genesis block, which includes information about the blockchain and its members, the data stored in it, etc.

[0089] The ordering service 710 can consist of a group of orderers. The ordering service 710 does not process transactions, smart contracts, or maintain a shared ledger. Instead, the ordering service 710 can accept the endorsed transactions and specify the order in which these transactions are committed to the distributed ledger 720. The architecture of the blockchain network can be designed such that the specific implementation of "ordering" (such as Solo, Kafka, BFT, etc.) becomes a pluggable component.

[0090] Transactions are written to the distributed ledger 720 in a consistent order. The order of the transactions is established to ensure that the updates to the state database 724 are valid when committed to the network. Different from cryptocurrency blockchain systems that sort by solving cryptographic puzzles, in this example, the parties of the distributed ledger 720 can choose the sorting mechanism that best suits the network.

[0091] When the sorting service 710 initializes a new data block 730, the new data block 730 can be broadcast to the committing peers (such as blockchain nodes 711, 712, and 713). In response, each committing peer validates the transactions in the new data block 730 by performing a check to ensure that the read set and write set still match the current world state in the state database 724. Specifically, the committing peer can determine whether the read data that existed when the endorser simulated the transaction is the same as the current world state in the state database 724. When the committing peer confirms the transaction, the transaction is written to the blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data in the read-write set. If the transaction fails, that is, if the committing peer finds that the read-write set does not match the current world state in the state database 724, the transaction sorted into the block will still be included in the block, but it will be marked as invalid, and the state database 724 will not be updated.

[0092] Reference Figure 7B , the new data block 730 (also referred to as a block) stored on the blockchain 722 of the distributed ledger 720 can include multiple data segments, such as a block header 740, block data 750, and block metadata 760. It should be recognized that Figure 7B the various described blocks and their contents shown in, for example, the new data block 730 and its contents, are merely examples and are not intended to limit the scope of the exemplary embodiments. The new data block 730 can store transaction information for N (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) transactions in the block data 750. The new data block 730 can also include a link in the block header 740 to the previous block (e.g., on the blockchain 722 in Figure 7B ). Specifically, the block header 740 can include the hash of the header of the previous block. The block header 740 can also include a unique block number, the hash of the block data 750 of the new data block 730, etc. The block number of the new data block 730 can be unique and can be assigned in various orders, such as in an incrementing / sequential order starting from zero.

[0093] The block data 750 can store the transaction information of each transaction recorded in the new data block 730. For example, the transaction data can include one or more of the following: transaction type, version, timestamp, channel ID of the distributed ledger 720, transaction ID, epoch, payload visibility, chain code path (deployment transaction), chain code name, chain code version, input (chain code and function), client (creator) identification—such as public key and certificate, client signature, endorser identity, endorser signature, proposal hash, chain code event, response status, namespace, read set (list of keys and versions read by the transaction, etc.), write set (list of keys and values, etc.), start key, end key, list of keys, Merkel tree query digest, and so on. The transaction data can be stored for each of the N transactions.

[0094] The block metadata 760 can store multiple metadata fields (e.g., in the form of a byte array, etc.). The metadata fields can include the signature at the time of block creation, reference to the last configuration block, transaction filter that identifies valid and invalid transactions within the block, the last offset of the ordering service that orders the block, and so on. The ordering service 710 can add the signature, the last configuration block, and the orderer metadata. Meanwhile, the committer of the block (such as the blockchain node 712) can add validity / invalidity information based on the endorsement policy, verification of the read / write set, etc. The transaction filter can include a byte array whose size is equal to the number of transactions in the block data 750 and a verification code that identifies whether the transaction is valid or invalid.

[0095] Figure 7C Illustrate an embodiment of the blockchain 770 for digital content according to the embodiments described herein. The digital content can include one or more files and related information. These files can include media, images, videos, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable and append-only characteristics of the blockchain play a role in protecting the integrity, validity, and authenticity of the digital content, making the digital content applicable to legal procedures where admissibility rules are applied, or to other scenarios where it is important to consider evidence or the submission and use of digital information. In this case, the digital content can be referred to as digital evidence.

[0096] The blockchain can be formed in various ways. In one embodiment, the digital content can be incorporated into the blockchain and accessed from the blockchain itself. For example, each block of the blockchain can store the hash value (hash value) of the reference information (such as block header, value, etc.) together with the related digital content. Then the hash value and the related digital content can be encrypted together. Therefore, the digital content of each block can be accessed by decrypting each block in the blockchain, and the hash value of each block can be used as the basis for referencing the previous block. This can be illustrated as follows:

[0097]

[0098] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store the cryptographic hash of the content of each block without storing any digital content. The digital content may be stored in another storage area or memory address in association with the hash value of the original file. The other storage area may be the same storage device as the one storing the blockchain, or a different storage area, or even a separate relational database. By obtaining or querying the hash value of the block of interest and then looking up the hash value stored corresponding to the actual digital content in the storage area, the digital content of each block can be referenced or accessed. This operation can be performed by, for example, a database gateway manager. This can be illustrated as follows:

[0099]

[0100] In Figure 7C the exemplary embodiment of, the blockchain 770 includes a number of blocks 7781, 7782,... 778 N , where N≥1. The cryptography used to link the blocks 7781, 7782,... 778 N can be any one of a plurality of keyed or unkeyed hash functions. In one embodiment, the blocks 7781, 7782,... 778 N are subject to a hash function that produces an n-bit alphanumeric output (where n is 256 or other number) from an input based on the information in the block. Examples of such hash functions include, but are not limited to, SHA (Secure Hash Algorithm)-type algorithms, Merkle-Damagard algorithms, HAIFA algorithms, Merkle-tree algorithms, algorithms based on random numbers, and algorithms of non-collision-resistant PRFs. In another embodiment, the blocks 7781, 7782,... 778 N can be cryptographically linked by a function different from the hash function. For the sake of illustration, the following description refers to a hash function, such as SHA-2.

[0101] Each block 7781, 7782,... 778 in the blockchain N contains a header, a file version, and a value. Due to the hashes in the blockchain, the headers and values of each block are different. In one embodiment, the value may be included in the header. As described in more detail below, the file version may be the original file, or a different version of the original file.

[0102] The first block 7781 in the blockchain is called the genesis block and includes a header 7721, an original file 7741, and an initial value 7761. The hashing scheme for the genesis block, as well as for all subsequent blocks, may vary. For example, all the information in the first block 7781 can be hashed together at once, or each or a portion of the information in the first block 7781 can be hashed separately and then the separately hashed portions can be hashed.

[0103] The header 7721 can include one or more initial parameters. For example, it can include a version number, a timestamp, a nonce, root information, a difficulty level, a consensus protocol, a duration, a media format, a source, descriptive keywords, and / or other information related to the original file 7741 and / or the blockchain. The header 7721 can be generated automatically (e.g., by blockchain network management software) or manually by blockchain participants. Different from the headers in other blocks 7782 to 778 in the blockchain, the header 7721 in the genesis block does not reference a previous block, simply because there is no previous block. N In the blockchain, the header 7721 in the genesis block does not reference a previous block, simply because there is no previous block.

[0104] For example, the original file 7741 in the genesis block can be data captured by a device, processed or unprocessed before being incorporated into the blockchain. The original file 7741 is received from a device, a media source, or a node through a system interface. The original file 7741 is associated with metadata that can be generated manually or automatically, for example, by a user, a device, and / or a system processor. The metadata can be included in the first block 7781 together with the original file 7741.

[0105] The value 7761 in the genesis block is an initial value generated based on one or more uniqueness attributes of the original file 7741. In one embodiment, the one or more uniqueness attributes can include the hash value of the original file 7741, the metadata of the original file 7741, and other information related to the file. In one implementation, the initial value 7761 can be based on the following uniqueness attributes:

[0106] 1) The hash value calculated by SHA-2 of the original file

[0107] 2) The initiating device ID

[0108] 3) The start timestamp of the original file

[0109] 4) The initial storage location of the original file

[0110] 5) The blockchain network member ID used by the software to currently control the original file and associated metadata

[0111] Other blocks 7782 to 778 in the blockchain NIt also has a header, a file, and a value. However, different from the header 7721 of the first block, the headers 7722 to 772 in other blocks N each contain the hash value of the previous block. The hash value of the previous block may be just the hash of the header of the previous block or the hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, it is possible to trace back block by block from the Nth block to the starting block (and the associated original file), as shown by arrow 780, to establish an auditable and immutable chain of custody.

[0112] Each of the headers 7722 to 772 in other blocks N may also include other information, such as version number, timestamp, nonce, root information, difficulty level, consensus protocol, and / or other parameters or information related to the corresponding file and / or blockchain.

[0113] The files 7742 to 774 in other blocks N can be equal to the original file or a modified version of the original file in the starting block, depending on the type of processing performed. The type of processing performed may vary from block to block. For example, the processing may involve any modification to the file in the previous block, such as revising information or otherwise changing the content of the file, removing information from the file, or adding or attaching information to the file.

[0114] In addition, or as an alternative, the processing may only involve copying the file from the previous block, changing the storage location of the file, analyzing one or more files in the previous blocks, moving the file from one storage or memory location to another storage or memory location, or performing operations on the blockchain file and / or its associated metadata. Processing involving analyzing a file may include (for example) appending, including, or otherwise associating various analysis, statistical, or other information associated with the file.

[0115] Each of the other blocks 7762 to 776 in other blocks N has a unique value and is different due to the processing performed. For example, the value in any one block corresponds to an updated version of the value in the previous block. The update is reflected in the hash of the block to which the value is assigned. Thus, the value of the block provides an indication of what processing has been performed in the block and allows tracing back through the blockchain to the original file. This tracing confirms the chain of custody of the file throughout the blockchain.

[0116] For example, consider a situation where a portion of a file in a previous block is revised, chunked, or pixelated to protect the identity of the person shown in the file. In such a case, the block containing the revised file will include metadata associated with the revised file, such as how the revision operation was performed, who performed the revision operation, the timestamp when the revision operation occurred, etc. The metadata can be hashed to form a value. Since the metadata of the block is different from the information that formed the value by hashing in the previous block, these values are different from each other and can be recovered upon decryption.

[0117] In one embodiment, when any one or more of the following occur, the value of the previous block (e.g., a new hash value is calculated) can be updated to form the value of the current block. In this embodiment, the new hash value can be calculated by hashing all or part of the information described below.

[0118] a) The hash value of a new SHA-2 calculation (if the file has been processed in any way) (e.g., if the file has been revised, copied, changed, accessed, or some other operation has been performed)

[0119] b) The new storage location of the file

[0120] c) Newly identified metadata associated with the file

[0121] d) Transferring the access or control of the file from one blockchain participant to another

[0122] Figure 7D Illustrate an example of a block that can represent the structure of a block in a blockchain 790 according to one embodiment. This block is the block Block i Includes a header 772 i , a file 774 i and a value 776 i .

[0123] The header 772 i Includes the hash value of the previous block Block i-1 and additional reference information, which can be, for example, any type of information discussed herein (e.g., header information including references, features, parameters, etc.). All blocks reference the hash value of the previous block, except for the starting block, of course. The hash value of the previous block can be just the hash of the header in the previous block, or it can be the hash of all or part of the information in the previous block - including the file and metadata.

[0124] The file 774 iIncludes multiple data, such as Data 1, Data 2, ……, Data N in sequence. These data are marked with metadata Metadata 1, Metadata 2, ……, Metadata N that describe the content and / or characteristics related to the data. For example, the metadata for each data may include information indicating the data timestamp, processing the data, keywords indicating the person or other content described in the data, and / or other characteristics that help determine the validity and content of the overall file—especially its use as digital evidence, such as as described in the embodiments discussed below. In addition to the metadata, each data can also be marked with references REF 1, REF 2, ……, REF N to the previous data to prevent tampering, gaps in the file, and sequential references through the file.

[0125] Once the metadata is assigned to the data (e.g., via a smart contract), the metadata cannot be changed without the hash changing, and a change in the hash is easily recognizable as invalid. Thus, the metadata creates a data log of information that can be accessed for use by blockchain participants.

[0126] Value 776 i is a hash value or other value calculated based on any type of information discussed previously. For example, for any given block i , the value of the block can be updated to reflect the processing performed for the block, e.g., a new hash value, a new storage location, new metadata for the associated file, transfer of control or access, identifiers, or other operations or information to be added. Although the value in each block is shown as being separate from the metadata and headers of the file's data, in another embodiment the value can be based in part or in whole on the metadata.

[0127] Once the blockchain 770 is formed, at any point in time, an immutable chain of custody for the file can be obtained by querying the blockchain for the transaction history of values across blocks. This query or tracking process can start by decrypting the value of the most recently included block (e.g., the last (Nth) block), then continue decrypting the values of other blocks until the starting block is reached, and then the original file is restored. Decryption may also involve decrypting the headers and files and associated metadata on each block.

[0128] Decryption is performed based on the type of encryption that occurred in each block. This may involve using a private key, a public key, or a public-private key pair. For example, when using asymmetric encryption, blockchain participants or processors in the network can generate a public-private key pair using a predetermined algorithm. The public key and the private key are related to each other by a certain mathematical relationship. The public key can be publicly distributed and used as an address (such as an IP address or a home address) to receive messages from other users. The private key is kept secret and is used to digitally sign messages sent to other blockchain participants. The signature is included in the message so that the recipient can verify it using the sender's public key. In this way, the recipient can be confident that only the sender could have sent this message.

[0129] Generating a key pair can be similar to creating an account on the blockchain without actually registering anywhere. Additionally, every transaction executed on the blockchain is digitally signed by the sender using their private key. This signature ensures that only the account owner can track and process the files on the blockchain (if within the permissions determined by the smart contract).

[0130] Figure 8A and 8B illustrates additional examples of use cases that can be combined and used with the blockchain described herein. Specifically, Figure 8A illustrates an example 800 of a blockchain 810 storing machine learning (artificial intelligence) data. Machine learning relies on large amounts of historical data (or training data) to build predictive models for making accurate predictions on new data. Machine learning software (such as neural networks, etc.) can typically sift through millions of records to find non-intuitive patterns.

[0131] In Figure 8A the example, the host platform 820 builds and deploys a machine learning model for predictive monitoring of an asset 830. Here, the host platform 820 can be a cloud platform, an industrial server, a web server, a personal computer, a user device, etc. The asset 830 can be any type of asset (such as a machine or a device, etc.), such as an airplane, a locomotive, a turbine, medical machinery and equipment, oil and gas equipment, a ship, a vehicle, etc. As another example, the asset 830 can be an intangible asset, such as stocks, currency, digital coins, insurance, etc.

[0132] The training process 802 of a machine learning model and the prediction process 804 based on the trained machine learning model can be significantly improved using blockchain 810. For example, in 802, historical data can be stored on blockchain 810 by the asset 830 itself (or through a medium, not shown), rather than requiring a data scientist / engineer or other user to collect the data. This can significantly reduce the collection time required by the host platform 820 when performing prediction model training. For example, using smart contracts, data can be directly and reliably transferred from its origin location directly to blockchain 810. By using blockchain 810 to ensure the security and ownership of the collected data, smart contracts can directly send data from the asset to the individual using the data to build a machine learning model. This allows for the sharing of data between assets 830.

[0133] The collected data can be stored in blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The recorded data is timestamped, cryptographically signed, and immutable. Thus, the recorded data is auditable, transparent, and secure. In some cases (i.e., supply chain, healthcare, logistics, etc.), adding IoT devices that write directly to the blockchain can increase the frequency and accuracy of the data being recorded.

[0134] In addition, training a machine learning model on the collected data can be refined and tested in several rounds by the host platform 820. Each round can be based on additional data or data not previously considered to help expand the knowledge of the machine learning model. In 802, different training and testing steps (and the data associated therewith) can be stored on blockchain 810 by the host platform 820. Each refinement of the machine learning model (e.g., changes to variables, weights, etc.) can be stored on blockchain 810. This can provide a verifiable proof of how the model was trained and what data was used to train the model. In addition, when the host platform 820 has implemented the finally trained model, the resulting model can be stored on blockchain 810.

[0135] After the model has been trained, it can be deployed to a real environment, where predictions / decisions can be made based on the execution of the finally trained machine learning model. For example, in 904, the machine learning model can be used for condition-based maintenance (CBM) of assets such as aircraft, wind turbines, and healthcare machines. In this example, the data fed back from the asset 830 can be input into the machine learning model and used to make event predictions such as failure events and error codes. The determinations made by executing the machine learning model at the host platform 820 can be stored on the blockchain 810 to provide an auditable / verifiable proof. As a non-limiting example, the machine learning model can predict a future failure of a part of the asset 830 and create an alert or notification to replace that part. The data behind such a decision can be stored by the host platform 820 on the blockchain 810. In one embodiment, the features and / or actions described and / or depicted herein can occur on or with respect to the blockchain 810.

[0136] New transactions of the blockchain can be aggregated into new blocks and added to the existing hash values. Then, they are encrypted to generate a new hash for the new block. When a transaction is encrypted, it is added to the next transaction list, and so on. The result is a blockchain in which each block contains the hash values of all the previous blocks. The computers storing these blocks regularly compare their hash values to ensure they are all consistent. Any computer that disagrees discards the record causing the problem. This method is beneficial for ensuring the tamper-proof nature of the blockchain, but it is not perfect.

[0137] One way for a dishonest user to game the system is to change the list of transactions in a way that is beneficial to themselves but keep the hash unchanged. This can be done by brute force, in other words, by changing the record, encrypting the result, and seeing if the hash values are the same. If not, then it has to be tried repeatedly until a matching hash is found. The security of the blockchain is based on the belief that an ordinary computer can only perform such a brute force attack on a completely unrealistic time scale, such as in the time of the age of the universe. In contrast, quantum computers are much faster (thousands of times faster), and thus pose a greater threat.

[0138] Figure 8B An example 850 of a quantum-secure blockchain 852 that implements quantum key distribution (QKD) to prevent quantum computing attacks is shown. In this example, blockchain users can use QKD to verify each other's identities. This uses quantum particles such as photons to send information, and an eavesdropper cannot copy the quantum particle without destroying it. In this way, the sender and the receiver can be confident in each other's identities through the blockchain.

[0139] In Figure 8BIn the example, there are four users 854, 856, 858, and 860. Each pair of users can share a secret key 862 (i.e., QKD) between them. Since there are four nodes in this example, there are six pairs of nodes, and thus six different secret keys 862 are used, including QKD AB , QKD AC , QKD AD , QKD BC , QKD BD and QKD CD . Each pair can create QKD by sending information using quantum particles such as photons, and an eavesdropper cannot copy QKD without disrupting it. In this way, a pair of users can be confident of each other's identity.

[0140] The operation of the blockchain 852 is based on two processes: (i) the creation of transactions, and (ii) the construction of blocks that aggregate new transactions. New transactions can be created in a manner similar to that of traditional blockchain networks. Each transaction can contain information about the sender, receiver, creation time, amount (or value) to be transferred, a list of reference transactions that prove the sender has the funds for the operation, etc. Then, the transaction record is sent to all other nodes, where it is entered into the unconfirmed transaction pool. Here, two parties (i.e., a pair of users among 854 - 860) authenticate the transaction by providing their shared secret key 862 (QKD). This quantum signature can be attached to each transaction, making it extremely difficult to tamper with. Each node checks the entries in its local copy of the blockchain 852 to verify that each transaction has sufficient funds. However, the transaction has not yet been confirmed.

[0141] A broadcast protocol can be used to create blocks in a decentralized manner. During a predetermined time period (e.g., seconds, minutes, hours, etc.), the network can apply the broadcast protocol to any unconfirmed transaction, thus achieving a Byzantine agreement (consensus) on the correct version of the transaction. For example, each node can have a private value (the transaction data for that particular node). In the first round, the nodes send their private values to each other. In subsequent rounds, the nodes transmit the information they received from other nodes in the previous round. Here, honest nodes are able to create a complete set of transactions within the new block. This new block can be added to the blockchain 852. In one embodiment, the features and / or actions described and / or depicted herein can occur on or with respect to the blockchain 852.

[0142] Figure 9Illustrate an example system 900 that supports one or more embodiments described herein. System 900 includes a computer system / server 902 that operates in conjunction with many other general purpose or special purpose computing system environments or configurations. Examples of computing systems, environments, and / or configurations suitable for computer system / server 902 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices, etc.

[0143] The computer system / server 902 may be described in the general context of computer system-executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system / server 902 may be used in a distributed cloud computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

[0144] As Figure 9 shown, the computer system / server 902 in the cloud computing node 900 is shown in the form of a general purpose computing device. Components of the computer system / server 902 may include, but are not limited to, one or more processors or processing units 904, a system memory 906, and a bus that couples various system components including the system memory 906 to the processor 904.

[0145] The bus represents any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0146] The computer system / server 902 generally includes various computer system-readable media. These media can be any available media accessible by the computer system / server 902, including volatile and non-volatile media, removable and non-removable media. In one embodiment, the system memory 906 implements the flowcharts in the other figures. The system memory 906 can include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 910 and / or cache memory 912. The computer system / server 902 can also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 914 can be provided for reading and writing data to and from a non-removable non-volatile magnetic medium (not shown, typically referred to as a "hard disk drive"). Although not shown, a disk drive for reading and writing removable non-volatile disks (e.g., "floppy disks") and an optical disk drive for reading or writing removable non-volatile optical media, such as disks of CD-ROM, DVD-ROM, or other optical media, can be provided. In such cases, each can be connected to the bus through one or more data media interfaces. As will be further depicted and described below, the memory 906 can include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the various embodiments of the present application.

[0147] A program / utility 916 having a set (at least one) of program modules 918 can be stored in the memory 906 by way of example and not limitation, as can an operating system, one or more application programs, other program modules, and program data. Each or some combination of the operating system, one or more application programs, other program modules, and program data can include an implementation of a network environment. The program modules 918 generally execute the functions and / or methods of the various embodiments of the present application as described herein.

[0148] Those skilled in the art will appreciate that aspects of the present application can be embodied as a system, method, or computer program product. Accordingly, aspects of the present application can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which embodiments are generally referred to herein as "circuits", "modules", or "systems" here. Aspects of the present application can take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0149] The computer system / server 902 can also communicate with one or more external devices 920, such as a keyboard, pointing device, display 922; one or more devices enabling a user to interact with the computer system / server 902; and / or any device enabling the computer system / server 902 to communicate with one or more other computing devices (e.g., network card, modem, etc.). Such communication can be carried out through the I / O interface 924. In addition, the computer system / server 902 can also communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), via the network adapter 926. As shown in the figure, the network adapter 926 communicates with other components of the computer system / server 902 via the bus. It should be understood that although not shown, other hardware and / or software components can be used in conjunction with the computer system / server 902. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0150] Although exemplary embodiments of at least one of the system, method, and non-transitory computer-readable medium are shown in the drawings and described in the foregoing detailed description, it should be understood that the present application is not limited to the disclosed embodiments, but is capable of many rearrangements, modifications, and substitutions as set forth and defined in the claims described below. For example, the functions of the systems in the various drawings can be performed by one or more of the modules or components described herein or in a distributed architecture, and can include a transmitter, a receiver, or a transmitter-receiver pair. For example, all or part of the functions performed by the individual modules can be performed by one or more of these modules. In addition, the functions described herein can be performed at different times and in relation to various events internal or external to the modules or components. In addition, information sent between the various modules can be sent via multiple protocols and / or via at least one of the following: a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device. Moreover, messages sent or received by any module can be sent or received directly and / or via one or more other modules.

[0151] Those skilled in the art will understand that a "system" can be embodied as a personal computer, server, console, personal digital assistant (PDA), cellular phone, tablet computing device, smart phone, or any other suitable computing device or combination of devices. Presenting the above functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but is intended to provide examples of many embodiments. In fact, the methods, systems, and devices disclosed herein can be implemented in localized and distributed forms consistent with computing technologies.

[0152] It should be noted that some of the system features described in this specification are presented as modules to more specifically emphasize their implementation independence. For example, a module can be implemented as a hardware circuit including a customized very large scale integration (VLSI) circuit or a gate array, such as off-the-shelf semiconductors like logic chips, transistors, or other discrete components. A module can also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

[0153] A module can also be implemented at least partially in software to be executed by various types of processors. The identified executable code units can, for example, include one or more physical or logical blocks of computer instructions, which can be organized, for example, as objects, procedures, or functions. However, the executable files of the identified modules do not need to be physically located together, but can include different instructions stored in different locations, which, when logically connected together, include the module and implement the stated purpose of the module. In addition, a module can be stored on a computer-readable medium, which can be, for example, a hard disk drive, a storage device, a random access memory (RAM), a magnetic tape, or any other such medium for storing data.

[0154] In fact, the modules of executable code can be a single instruction or multiple instructions, and can even be distributed over several different code segments, different programs, and several memory devices. Similarly, the operation data can be identified and shown within a module herein, and can be embodied in any suitable form and organized in any suitable type of data structure. The operation data can be collected as a single data set, or can be distributed over different locations including different storage devices, and can exist at least partially only as electronic signals on a system or network.

[0155] It is readily understood that, as generally described and illustrated in the accompanying drawings herein, the components of the present application can be arranged and designed in a variety of different configurations. Thus, the detailed description of the embodiments is not intended to limit the scope of the claimed present application, but merely represents selected embodiments of the present application.

[0156] Those of ordinary skill in the art will readily understand that the above can be implemented with steps in a different order and / or using hardware elements in a configuration different from the disclosed configuration. Thus, although the present application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructions will be obvious.

[0157] Although the preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely illustrative, and the scope of the present application is defined only by the appended claims, taking into account the full scope of various equivalents and modifications (such as protocols, hardware devices, software platforms, etc.).

Claims

1. A computing system, comprising: A network interface configured to receive a Structured Query Language (SQL) request applied to a subset of blocks stored in a blockchain ledger; A cache configured to store a portion of the blocks stored in the blockchain ledger; And A processor configured to identify one or more blocks to which the SQL request is applied and that are not stored in the cache, and retrieve the identified one or more blocks not stored in the cache from the blockchain ledger, Wherein the processor is further configured to perform an SQL operation that combines one or more blocks in the cache to which the SQL request is applied and the one or more blocks retrieved from the blockchain ledger, and control the network interface to send the combined blocks to a computing system associated with the received SQL request, and Wherein the processor is further configured to, in response to receiving an SQL insert command identifying indexes of multiple blocks, obtain the multiple blocks from the blockchain ledger and store the multiple blocks in the cache.

2. The computing system according to claim 1, wherein, The processor is configured to retrieve from the blockchain ledger one or more blocks of the subset that are not currently stored in the cache.

3. The computing system according to claim 2, wherein the processor is further configured to perform predicate pushdown, wherein the one or more cached blocks are filtered out of the request to identify the remaining one or more non-cached blocks.

4. The computing system according to claim 2, wherein The processor is further configured to combine the one or more blocks in the cache with the one or more non-cached blocks retrieved from the blockchain ledger by an SQL UNION operation.

5. The computing system according to claim 1, wherein the cache includes a columnar cache table in which different types of block data are stored in respective columns.

6. The computing system according to claim 5, wherein one of the columns in the columnar cache table includes a block index value corresponding to the block number of a block on the distributed ledger.

7. A computer-implemented method, comprising: Receiving a Structured Query Language (SQL) request applied to a subset of blocks stored in a blockchain ledger; Storing in a cache a portion of the blocks stored in the blockchain ledger; Identifying one or more blocks to which the SQL request is applied and that are not stored in the cache, and retrieving the identified one or more blocks not stored in the cache from the blockchain ledger; Performing an SQL operation that combines one or more blocks in the cache to which the SQL request is applied and the one or more blocks retrieved from the blockchain ledger; Sending the combined blocks to a computing system associated with the received SQL request, and It further includes, in response to receiving an SQL insert command identifying indexes of the multiple blocks, obtaining the multiple blocks from the blockchain ledger and storing the multiple blocks in the cache.

8. The method according to claim 7, wherein The retrieving includes retrieving, from the blockchain ledger, one or more blocks in the subset that are not currently stored in the cache.

9. The method according to claim 8, wherein the retrieving further includes performing predicate pushdown, wherein the one or more cached blocks are filtered out from the request to identify the remaining one or more non-cached blocks.

10. The method according to claim 8, further including combining, by an SQL UNION operation, the one or more blocks in the cache with the one or more non-cached blocks retrieved from the blockchain ledger.

11. The method according to claim 7, wherein the cache includes a columnar cache table, and different types of block data are stored in corresponding columns.

12. The method according to claim 11, wherein one column in the columnar cache table includes a block index value corresponding to the block number of the block on the distributed ledger.

13. A computer program product, including a computer-readable medium having computer-readable program instructions embodied therein, the program instructions, when read by a processor, causing the processor to perform the steps included in the method according to any one of claims 7 to 12.

14. An apparatus, including one or more modules configured to implement the corresponding steps included in the method according to any one of claims 7 to 12.

Images