System and method for supporting SQL-based rich queries in a hyper leisure fabric blockchain

Abstract

To provide systems and methods for supporting SQL-based rich queries in a permissioned blockchain ledger such as a blockchain fabric that are able to execute SQL queries to allow creation of complex smart contracts in an easier and more maintainable manner.SOLUTION: A method comprises: providing an enterprise-grade distributed ledger framework at one or more computers including a microprocessor; and running a distributed ledger fabric within the distributed ledger framework, where the distributed ledger fabric comprising at least a transaction manager and a validation tool. The method may also comprise associating a state of a world database with the distributed ledger fabric. The state of the world database comprises a versioned database and a relational database interface.SELECTED DRAWING: Figure 12

Description

Technical Field

[0001] Copyright Notice Part of the disclosure of this patent document contains materials protected by copyright. Since this patent document or patent disclosure is recorded in the patent file or record of the Patent and Trademark Office, the copyright owner does not object to reproduction by anyone, but retains all copyrights in other cases.

[0002] Priority Claim This application claims the benefit of priority based on U.S. Patent Application No. 16 / 261363, filed on January 29, 2019, entitled "Systems and Methods for Supporting SQL-Based Rich Queries in Hyperledger Fabric Blockchain", and U.S. Provisional Patent Application No. 62 / 711385, filed on July 27, 2018, entitled "Systems and Methods for Supporting SQL-Based Rich Queries in Hyperledger Fabric Blockchain", the entire contents of each application being incorporated herein by reference.

[0003] Field This disclosure generally relates to systems and methods for providing a distributed ledger. More particularly, this disclosure discloses systems and methods and their components for supporting SQL-based (or SQL-like) rich queries in a permissioned distributed ledger such as a Hyperledger Fabric blockchain.

Background Art

[0004] Background A distributed ledger is roughly referred to as a digital record of asset ownership. The ledger has no central administrator and no central data store. Instead, the ledger is replicated across many participating nodes that can be geographically distributed across multiple locations, multiple countries, or multiple facilities in a computing environment. A consensus protocol ensures the identity of each node's copy of the ledger with all other nodes' copies. Similarly, a set of copies may be regarded as a single shared ledger. Asset owners can use the distributed ledger to debit the accounts of some asset owners and evaluate the creditworthiness of the accounts of other asset owners, for example, based on cryptographic signature technology.

[0005] A blockchain is a data structure that can be used to implement an immutable distributed ledger. Multiple nodes follow a common protocol to package transactions from clients into blocks, and the nodes use a consensus protocol to agree on the next block. Since blocks have cumulative cryptographic hashes, it is difficult to tamper with the ledger. Each block has a reference value (hash value) of the previous block in time. Also, each block has its own hash value. The blockchain can be traversed backward (e.g., up the chain).

Summary of the Invention

Problems to be Solved by the Invention

[0006] Permissionless distributed ledgers enable anonymous participants to manage the ledger while avoiding control by any single entity. However, in the case of anonymity, identity (Identity), accountability, and auditability are difficult. In contrast, a permissioned distributed ledger enables credit levels and accountability by allowing explicitly permitted parties to manage the ledger. Permissioned ledgers support more flexible management and a wider choice of consensus mechanisms. Participants who prefer some transactions over others can easily operate two types of distributed ledgers. However, the accountability underlying permissioned ledgers provides an opportunity to impose constraints on participants.

[0007] Summary This specification describes a system and method for supporting SQL-based rich queries in a Hyperledger Fabric blockchain, according to one embodiment.

[0008] This specification describes a system and method for supporting SQL-based rich queries in a blockchain fabric. According to one embodiment, the systems and methods described herein can create complex smart contracts in an easier and more manageable way by executing SQL queries. Also, performance can be improved by returning data selection back to the storage engine (rather than executing at the smart contract level) and relying on a relational engine that supports concurrent read and write access to data. Also, the state of the world database can provide concurrent read / write access.

[0009] These and other advantages of the present disclosure will be apparent to those of ordinary skill in the art from the description of the various embodiments below, with reference to the accompanying drawings.

[0010] The Hyperledger project was achieved as a joint effort of the Linux Foundation project to create an open-source enterprise-class distributed ledger framework and codebase. Hyperledger Fabric is an implementation of a distributed ledger platform for executing smart contracts. Hyperledger Fabric utilizes container technology to host smart contracts called "chaincode" that includes the application logic of the system. In one embodiment, participants in Hyperledger replicate a copy of the ledger. In addition to sharing ledger information, the process of updating the ledger is also shared. Unlike other systems that use a participant's private program to update a related private ledger, the blockchain system uses a shared program to update the shared ledger. By coordinating the participant's business network through the shared ledger, the blockchain network can reduce the time, cost, and risk associated with distributing private information to the ledger (while increasing credibility), as well as the processing time. Hyperledger Fabric is private and permissioned. Members of the Hyperledger Fabric network are registered. Also, Hyperledger Fabric can provide the function of creating channels. Each channel can include an individual transaction ledger that is visible to a specific group of participants. This enables transaction privacy.

[0011]

[0012] In one embodiment, the distributed ledger protocol of Fabric is executed by peers. Fabric identifies two types of peers. Endorsing peers are nodes that participate in the execution of consensus, verification of transactions, and management of the ledger on the network. On the other hand, non-endorsing peers are nodes that function as proxies for connecting clients (that issue transactions) to endorsing peers. Non-endorsing peers handle transactions It does not execute but can verify transactions. Some features of Fabric include a permissioned blockchain with immediate finality that executes any smart contract called a chaincode. The smart contracts of chaincodes defined by users are encapsulated within containers, and the system chaincode is executed in a process similar to that of peers. The process for keeping ledger transactions in a synchronized state across the network (e.g., updating the ledger only when appropriate participants approve the transaction and, when updating the ledger, ensuring that the ledger is updated in the same order as similar transactions with similar transactions) may be referred to as consensus. Fabric implements the consensus protocol and security by supporting a Certificate Authority (CA) to authenticate TLS (Transport Layer Security) certificates, enrollment certificates, and transaction certificates.

[0013] According to one embodiment, Hyperledger Fabric can include the state of a world database. This database is typically a key-value store. The state of the world database is stored in a high-speed key-value store. A value is associated with a specific label (key). For example, a key-value database can associate a balance with a key or can associate a photo with a key. The persistence engine is very fast.

[0014] According to one embodiment, the smart contracts within the Hyperledger Fabric blockchain can only access very basic value lookup and data sorting mechanisms. Therefore, creating and managing smart contracts is difficult and often does not have sufficient performance.

[0015] According to one embodiment, since the supported underlying persistence engine operates only with systems such as level DB and CouchDB that do not support simultaneous R / W access, the blockchain must be forcibly locked for write access (commit) during the execution of the endorsement operation (transaction). This directly affects performance, especially when the execution of smart contracts requires a large amount of computing power.

Brief Description of the Drawings

[0016]

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7A

Figure 7B

Figure 8

Figure 9A

Figure 9B

Figure 10

Figure 11

Figure 12

[0017] Detailed Description According to one embodiment, this specification describes a system and method for supporting SQL-based rich queries in a blockchain fabric. According to one embodiment, the systems and methods described herein can create complex smart contracts in an easier and more manageable way by executing SQL queries. Also, performance can be improved by returning data selection back to the storage engine (instead of executing at the smart contract level) and relying on a relational engine that supports concurrent read and write access to data. Also, the state of the world database can provide concurrent read / write access.

[0018] According to one embodiment, an exemplary blockchain fabric that supports SQL-based rich queries in a blockchain fabric can be provided as a cloud service. According to one embodiment, an enterprise-class framework includes scalability, management, configuration, persistence, and compatibility of various client applications that use cloud technology. In certain embodiments, a permissioned blockchain ledger and a blockchain fabric are provided as a blockchain cloud service (BCS).

[0019] In the following description, the present disclosure is shown in the accompanying drawings by way of illustration and not limitation. The various embodiments referred to in this disclosure do not necessarily refer to the same embodiments, and such references mean at least one. Specific implementation examples are described, but these implementation examples are provided for the purpose of illustration. Those skilled in the art will recognize that other components and configurations can be used without departing from the scope and spirit of the present disclosure. The description of the present disclosure provides examples and embodiments that support and disclose the claimed methods.

[0020] Also, in certain cases, a complete description of the present disclosure is provided by describing a number of specific details. However, those skilled in the art will understand that the results and advantages of the methods taught in the present disclosure can be achieved and the ideas taught in the present disclosure can be implemented without these specific details. In some cases, well-known features are not described in detail so as not to obscure the present disclosure.

[0021] The teachings of the present disclosure are described using functional building blocks that show the performance of specific functions and their relationships. The boundaries of these functional building blocks are often arbitrarily defined in the present disclosure for the convenience of explanation. Thus, in alternative embodiments, functions performed by the same elements may be performed by different elements. Each of the functions performed Elements may be combined into one element. Alternative boundaries may be defined as long as the specific functions and their relationships can be properly executed. Accordingly, any of these alternative boundaries are included within the scope and spirit of the present disclosure.

[0022] Throughout the drawings and the detailed description, like reference numerals are used to denote like elements. Thus, if an element is described elsewhere, the reference numeral used in the drawings may or may not be referred to in the detailed description associated with that drawing.

[0023] Blockchain technology can dramatically improve enterprise business value by enabling near real-time distribution of transactions and secure, tamper-proof data sharing in the user ecosystem. Hyperledger Fabric blockchain incorporates modular architecture, horizontal / common industry technology support, and support for enterprise requirements.

[0024] Introduction According to one embodiment, Hyperledger Fabric is a platform for a distributed ledger solution supported by a modular architecture that provides a high degree of confidentiality, recoverability, flexibility, and scalability. Hyperledger Fabric supports pluggable implementations of different components and is designed to adapt to the complexity and congestion present in a practical ecosystem.

[0025] According to one embodiment, Hyperledger Fabric provides a flexible and scalable architecture, unlike alternative blockchain solutions.

[0026] Blockchain - Distributed Ledger According to one embodiment, a blockchain network can include a distributed ledger that records all transactions taking place on the network.

[0027] The blockchain ledger is often referred to as a distributed ledger because it is replicated by many network participants and managed through the collaboration of each network participant. Distribution and collaboration are attributes that reflect how businesses exchange goods and services in the real world.

[0028] In addition to distribution and collaboration, the information recorded on the blockchain is added only using cryptographic techniques. That is, once a transaction is added to the ledger, this transaction cannot be changed. Due to this immutability, since information cannot be retroactively changed, participants can easily determine the origin of the information. Therefore, the blockchain may be considered a proof system.

[0029] Blockchain - Smart Contract According to one embodiment, to support consistent updates of information and certain ledger functions (transactions, queries, etc.), the blockchain network controls access to the ledger by using smart contracts.

[0030] According to one embodiment, a smart contract is not only an important mechanism for encapsulating information and easily maintaining that information across the network, but may also be written so that participants can automatically execute specific parts of a transaction.

[0031] A smart contract may be written, for example, to vary the shipping cost according to the arrival time of the goods. Based on the conditions agreed upon by both parties and described in the ledger, when the goods are received, the corresponding funds are automatically transferred.

[0032] Blockchain - Consensus According to one embodiment, the process for maintaining ledger transactions in a synchronized state across the network (e.g., updating the ledger only when appropriate participants approve the transaction and, when updating the ledger, ensuring that the ledger is updated in the same order as similar transactions with similar transactions) may be referred to as consensus.

[0033] According to one embodiment, a blockchain may be considered as a shared and replicated transaction system. This transaction system is updated via smart contracts and is consistently maintained in a synchronized state via a collaborative process called consensus.

[0034] Advantages of Blockchain According to one embodiment, the currently available transaction network is the version of the network that existed when maintaining business records. Members of the business network conduct transactions with each other, but each member manages its own transaction records. Similarly, each time an item being sold is sold, the origin can be verified to ensure that the company selling the item holds a chain of title for verifying the ownership of the item.

[0035] Despite the current business network being modernized by computing systems, there is no unified system for managing the identities of network participants, it takes days to settle (worldwide) securities transactions (worth trillions of dollars), and contracts have to be manually signed and executed, so verifying the origin is difficult. Also, each database within the system contains unique information, representing one drawback.

[0036] According to one embodiment, the blockchain provides an alternative to many inefficient standard transaction systems by providing a standard way to establish identities, execute transactions, and store data on the network.

[0037] According to one embodiment, each participant in the blockchain network has a copy of their own ledger. In addition to sharing ledger information, the process of updating the ledger is also shared. Different from other systems that use the private programs of participants to update the relevant private ledgers, the blockchain system uses a shared program to update the shared ledger.

[0038] According to one embodiment, by coordinating the business networks of participants through the shared ledger, the blockchain network can increase credibility and visibility while reducing the time, cost, and risk associated with the distribution of private information, as well as the processing time.

[0039] Hyperledger Fabric Hyperledger Fabric, like other blockchain technologies, has a ledger, uses smart contracts, and is a system where participants manage transactions.

[0040] Hyperledger Fabric is different from some other blockchain systems because it is private and permissioned. Some blockchain networks use identities for authentication (allowing those who meet the criteria to participate in the network) instead of "proof of work". Members of the Hyperledger Fabric network register through a membership service provider.

[0041] Also, Hyperledger Fabric provides several pluggable options. The ledger data can be stored in multiple formats, the consensus mechanism can be switched in and out, and different MSPs (Membership Service Providers) can be supported.

[0042] Furthermore, Hyperledger Fabric enables participant groups to create separate transaction ledgers by providing the ability to create channels. This allows for the possibility that some participants on the network are competitors and do not disclose all transactions to all participants (e.g., offering a special price to some participants and not to others). When two participants create a channel, these two participants, excluding other participants, have a copy of the ledger for that channel.

[0043] Shared ledger According to one embodiment, Hyperledger Fabric has a ledger subsystem that includes two components, namely, the world state and the transaction log. Each participant has a copy of the ledger for all Hyperledger Fabric networks to which they belong.

[0044] The component called the world state describes the state of the ledger at a given point in time. The world state is the database of the ledger. The component called the transaction log records all transactions that have brought about the current value of the world state. The transaction log is the update history of the world state. Thus, the ledger is a combination of the world state database and the transaction log history.

[0045] The shared ledger has an exchangeable data store for the world state. By default, the shared ledger is a LevelDB key-value store database. The transaction log may not be pluggable. The transaction log simply records the values of the ledger database before and after being used by the blockchain network.

[0046] Smart contract The Hyperledger Fabric smart contract is written in chaincode and is called by an application outside the blockchain when that application needs to interact with the ledger. In most cases, the chaincode interacts only with the database component of the ledger, which is the world state, rather than the transaction log (e.g., querying the database).

[0047] Consensus According to one embodiment, transactions are executed among different sets of participants in the network and written to the ledger in the order in which they are executed. As a result, the order of transactions is established and malicious transactions that are inserted into the ledger incorrectly (or maliciously) can be rejected.

[0048] Hyperledger Fabric allows network entities (e.g., network users, peers, starters) to select a consensus mechanism that best represents the relationships among the participants. Similar to privacy, a wide range of networks is required, from highly structured networks in the relationships among participants to more peer-to-peer networks.

[0049] Chaincode According to one embodiment, chaincode can include software that defines one or more assets and transaction instructions (business logic) for changing the assets. The chaincode executes rules for reading or changing key-value pairs or other state database information. The functions of the chaincode are executed against the current state database of the ledger and are triggered by a transaction proposal. The execution of the chaincode results in a write set of key-values that is submitted to the network and applied to the ledger on all peers. Characteristics of the ledger

[0050] According to one embodiment, the ledger is a tamper-resistant record of a sequence of all state transitions within the fabric. The state transitions are the result of participants executing chaincode (transactions). Each transaction generates a set of asset key-value pairs that are committed to the ledger as creates, updates, or deletes.

[0051] The ledger consists of a blockchain that stores an immutable sequence of records in blocks, and a state database for maintaining the current state of the fabric. Each channel contains one ledger, and each channel contains a separate ledger of transactions visible to a specific group of participants. Each peer maintains a copy of the ledger for each channel to which it belongs as a member.

[0052] Channel Privacy According to one embodiment, Hyperledger Fabric utilizes a channel-specific immutable ledger and chaincode that can process and change (i.e., update key-value pairs) the current state of assets. The ledger exists within the scope of the channel. The ledger may be shared across the network (if all participants are operating on a single common channel) or privatized to include only a specific set of participants.

[0053] In the latter case, participants can separate / isolate transactions and ledgers by creating separate channels. To enable filling the gap between complete transparency and privacy, the chaincode may be installed only on peers that need access to the asset state to perform reads and writes (i.e., if the chaincode is not installed on a peer, the peer cannot properly interface with the ledger). To further obfuscate the data, values within the chaincode are (partially or fully) encrypted using a normal cryptographic algorithm such as AES (Advanced Encryption Standard) and then added to the ledger.

[0054] According to one embodiment, privacy can be improved by using "private collection", a concept smaller than channel privacy.

[0055] Security and Membership Services According to one embodiment, Hyperledger Fabric provides a transaction network in which all participants have known identities. Using a public key infrastructure, cryptographic certificates are created that are associated with organizations, network components, and end users or client applications. Thus, access to data can be controlled and managed on a wider network and channels. This "permissioned" concept of Hyperledger Fabric can address scenarios where privacy and confidentiality are important, along with the existence and characteristics of channels.

[0056] Consensus According to one embodiment, in a distributed ledger, consensus can include more than just an agreement on the order of transactions. This distinction is emphasized by the fundamental role in the entire transaction flow of Hyperledger Fabric from proposal and endorsement to ordering, verification, and commitment. Consensus is defined as a complete verification of the validity of a set of transactions including blocks. -ment from, ordering, verification, and commitment throughout the transaction flow of Hyperledger Fabric. Consensus is defined as a complete verification of the validity of a set of transactions including blocks.

[0057] Consensus is finally reached when the order and results of the transaction blocks meet explicit policy criteria checks. These checks and balances occur during the transaction and include the use of endorsement policies to determine specific members who must sign a particular transaction, and system chaincode to ensure the execution and compliance of these policies. Prior to commitment, peers can utilize this system chaincode to verify that endorsements are present and from appropriate entities. Also, a version check is performed while agreeing or consenting to the current state of the ledger before adding any block containing a transaction to the ledger. This final check provides protection against double - spending and other threats that could compromise data integrity and enables the execution of functions against non - static variables.

[0058] In addition to endorsement, verification, and version checks, continuous identity verification is performed on the transaction flow. Access control lists are implemented across the hierarchy of the network (from the ordering service to the channel), and as the transaction proposal passes through different architectural components, the payload is repeatedly signed, verified, and authenticated. Consensus is not limited to the order of a agreed - upon set of transactions; rather, it is a process achieved as a by - product of continuous verification performed on the transaction flow from proposal to commitment.

[0059] Blockchain Cloud Service - Architecture According to one embodiment, a system such as a cloud system (e.g., a blockchain cloud service (BCS)) can utilize the above-described Hyperledger Fabric as a starting point. Such a system enables the creation of new blockchain-based applications and / or the extension of existing SaaS, PaaS, and IaaS as well as on-premises applications by providing a highly advanced and unique enterprise-class distributed ledger cloud platform.

[0060] According to one embodiment, the system can remove barriers to the adoption and support of blockchain applications under development by supporting mission-critical enterprise requirements such as scalability, security, robustness, consistency, and performance. The system provides the BCS as a cloud PaaS (Platform as a Service), enabling users to deploy, configure, manage, and monitor the blockchain and reducing the cost of deploying the blockchain in the enterprise. Also, the system accelerates the development of blockchain applications and their integration with other platforms. With this system, SaaS cloud users can securely share data of enterprise processes such as procurement, payment, trade finance, accounting, HR, CX, etc. and execute distributed transactions using third-party applications and external distributed ledger technologies that use the blockchain cloud platform.

[0061] According to one embodiment, the system is a cloud service based on a PaaS manager (e.g., Oracle® PaaS Service Manager (PSM) platform). Typically, such a system is a cloud management service that operates in a computing space (e.g., an external computing space). In one embodiment, the system uses Oracle Identity Cloud Service (IDCS), Oracle Load Balancer as a Service (LBaaS), Oracle Event Hub Cloud Service, and Oracle Cloud Storage to utilize the features of the PSM platform that includes a hierarchical Oracle Application Container Cloud Service (ACCS). A blockchain for each client can be created and run as a tenant. The system can support multiple blockchains, and each blockchain is created and operates as each tenant within a multi-tenant environment. Thus, with this system, an application or a client application can implement a distributed ledger including smart contracts. The clients and users of such a system can be inside (blockchain credit) or outside the cloud. Some blockchain networks may include components outside the cloud environment or may be limited to a specific cloud.

[0062] According to one embodiment, this system is useful for a variety of applications, especially multi-party transactions that must solve credit and identity. Different from other blockchain systems, the system services of the present disclosure are not anonymous. In fact, identity and audit capabilities are basic integration elements. Thus, BCS may be applied, for example, in capital markets, cross-border transactions, financial services, asset transactions, legal regulations, healthcare records, publicity, logistics, change tracking, and forgery prevention.

[0063]

[0064] ​As described above, each party on the blockchain can access all databases and all histories (unless the ledger is created / privatized for a specific party). Each party cannot control data or information. Also, all parties can directly verify the records of their transaction counterparts without an intermediary. Communication occurs directly between peers without going through a central node. Each node stores information and transfers it to all other nodes. Once a transaction is entered into the database and the account is updated, the record is linked to the records of all previously entered transactions (hence the name "chain") and cannot be changed. If there is an error in a transaction, the error can be corrected using a new transaction. Both transactions are visible to the provided users. To add a new valid transaction, participants can agree on the validity of the transaction through a consensus mechanism. Blockchain participants can verify the origin of assets and the temporal changes in asset ownership. Documents can be authenticated using digital signatures, and digital signatures can be added to access control (changing permission levels) and programmability (executable business rules).

[0065] In many multi-party transactions, parties exchange money when receiving an asset or service. Usually, depending on the transaction time, one party must provide goods or money before the other party. In some environments, credit is resolved by an intermediary depositing funds until the conditions of the contract are met. This method resolves the credit between the parties. However, this method increases complexity and the cost of the transaction by adding another centralized entity that must be trusted. By using smart contracts as part of the system of the present disclosure, intermediaries can be eliminated. As a result, parties can conduct transactions that can be trusted on the blockchain without going through an intermediary.

[0066] According to one embodiment, the advantages of the system of the present disclosure, such as BCS, include distributing information within the system. The auditing ability can be utilized, access can be controlled, and some privacy can be managed. Also, the blockchain ledger is essentially immutable and cannot be rejected. The ledger is composed of multiple blocks. Each transaction block includes a block ID, a past hash, a data hash, a timestamp, a list of transaction IDs, operations (1 to n), a chain code ID, a chain code proposal, a response (r / w set, event, success or failure), and an endorser. Since each block includes a past hash and its own hash, once it is published / distributed, it is essentially ordered and immutable (note that the hash of the current block is the hash of the past block and other data within the current block, thus linking the blocks within the chain). Consensus can resolve conflicts. There is no need to give excessive authority to a centralized authority compared to a centralized database or an intermediary. Also, the distributed nature of the ledger makes it difficult to modify (even if it is algorithmically possible) by using distributed copies and consensus, thus strengthening the basic immutability of the blockchain recording technology. Therefore, since the order of transactions is fixed, if someone has a copy of the latest block of the chain, hacking the ledger is almost impossible.

[0067] ​In certain embodiments, as described below, the system of the present disclosure can be based on the Oracle PaaS Service Manager (PSM) platform and is enhanced by including a management console that simplifies / facilitates / automates the creation, monitoring, and configuration of a fabric-based blockchain. Also, a REST proxy service including one REST API is provided to simplify the contact between the application and the blockchain fabric. Developers can build smart contracts, deploy the smart contracts using the management console, and then use the application to call the smart contracts on the blockchain either asynchronously (by default) or synchronously (when an immediate response is required). The REST proxy service and API provide both synchronous and asynchronous capabilities depending on the requirements of the platform.

[0068] According to one embodiment, the Fabric CA server can provide the membership service of the fabric. The Fabric CA server can include the following three parts, namely, user authentication, authorization for accessing the blockchain (peers and orderer groups), and a CA server that distributes certificates to application clients, peers, and orderers. The Fabric CA can use the certificates to perform authentication and authorization. The certificates include the following two types, namely, registration certificates for authentication and transaction certificates for authorization. According to one embodiment, identity services such as IDCS can also provide authentication and authorization. According to one embodiment, identity services such as IDCS can also provide authentication and authorization.

[0069] Hyperledger Fabric As described above, in one embodiment, the system of the present disclosure can implement a Hyperledger fabric that provides a distributed ledger platform for executing smart contracts. The Hyperledger fabric utilizes container technology to host smart contracts called "chaincodes" that include the application logic of the system. In an alternative embodiment, the blockchain cloud service implements an alternative distributed ledger platform that includes, for example, the "Tendermint" ledger system described in U.S. Patent Application No. 15 / 169,622, "Accountability and Credit in a Distributed Ledger System," filed on May 31, 2016, and incorporated herein by reference.

[0070] The distributed ledger protocol of the Hyperledger fabric is executed by peers. One drawback of traditional blockchain technology is that all peers need to record all transactions. This substantially causes I / O and processor overhead and can be easily scaled according to enterprise-class systems. No. Hyperledger Fabric identifies two types of peers. A committer peer is a node on the network that verifies endorsements, validates transaction results before committing the transaction to the blockchain, and manages the ledger. On the other hand, a non-verifying peer is a node that functions as a proxy for connecting a (transaction-issuing) client to a verifying peer. A non-verifying peer (or endorser peer) does not execute transactions but can simulate and sign transactions. The separation of peer types / functions improves the scalability of the system. The ordering service can receive signed transactions, order them into blocks, and send the blocks to committer peers. In such a distributed ledger system, consensus is the process of forming an agreement on the next set of transactions to be added to the ledger. In Hyperledger Fabric, consensus involves three distinct steps, namely, transaction endorsement, ordering, and validation and commitment.

[0071] According to one embodiment, Hyperledger is a permissioned blockchain with immediate finality that executes any smart contract called a chaincode. The smart contract of the chaincode defined by the user is encapsulated within a container, and the system chaincode is executed in a process similar to that of a peer. Since the execution of the chaincode is split in the order of transactions, it limits the level of trust and verification required between nodes and reduces the network overhead.

[0072] According to one embodiment, channels within a hyperledger fabric enable multi-party transactions with the high levels of privacy and confidentiality required by competing businesses and regulated industries that exchange assets on a common network. Immutable shared ledgers encrypt all transaction histories for each channel and include query functions for efficiently resolving audits and disputes. The ledger is created within the scope of the channel. The ledger may be shared across the network (if all participants are operating on one common channel) or may be privatized to include only a specific group of participants.

[0073] According to one embodiment, a hyperledger fabric implements security by supporting a certificate authority (CA) for authenticating TLS certificates, enrollment certificates, and transaction certificates. Cryptographic certificates are created using a public key infrastructure to associate with organizations, network components, and end users or client applications. Thus, access to data can be controlled and managed on a wider network and channels. This "permissioned" feature of the hyperledger fabric meets the privacy and confidentiality requirements of multi-party enterprise systems along with the existence and capabilities of the channels.

[0074] According to one embodiment, a hyperledger fabric can change assets using chaincode transactions. As described above, chaincode is software that defines one or more assets and transaction instructions for changing the assets.

[0075] The integrated consensus mechanism plays a fundamental role in the transaction flow of the Hyperledger Fabric from proposal and endorsement to ordering, verification, and commitment. Consensus, as described above, is the verification of the validity of a set of transactions including blocks. Consensus is ultimately achieved when the order and outcome of the transaction blocks meet explicit policy criteria.

[0076] Figure 1A shows the transaction flow that takes place in the fabric of a system that provides blockchain services. More specifically, Figure 1A shows a blockchain cloud service (BCS) system according to one embodiment. In 1, the client 160 uses the Fabric SDK 162 to access and register with the Fabric certificate authorities 170, 172, 174. In 1.1, the Fabric CA sends a registration certificate to the client 160. In 2, the client 160 uses the Fabric SDK 162 to access the peer container 180 to request a signature from the endorser 182. In 2.1, the endorser 182 returns a signed RW set (read / write set). In 3, the Fabric SDK 162 of the client 160 submits a signed TX (transaction) including the RW set and the endorser's signature to the ordering service of the ordering container 190. In 4, the orderer 192 distributes the TX batch to the committer 184 within the peer container 180 Figure 1A shows the transaction flow that takes place in the fabric of a system that provides blockchain services. More specifically, Figure 1A shows a blockchain cloud service (BCS) system according to one embodiment. In 1, the client 160 uses the Fabric SDK 162 to access and register with the Fabric certificate authorities 170, 172, 174. In 1.1, the Fabric CA sends a registration certificate to the client 160. In 2, the client 160 uses the Fabric SDK 162 to access the peer container 180 to request a signature from the endorser 182. In 2.1, the endorser 182 returns a signed RW set (read / write set). In 3, the Fabric SDK 162 of the client 160 submits a signed TX (transaction) including the RW set and the endorser's signature to the ordering service of the ordering container 190. In 4, the orderer 192 distributes the TX batch to the committer 184 within the peer container 180 An order is a predetermined set of nodes that order transactions into blocks. The ordering service exists independently of the peer processes and orders the transactions of all channels on the network in a first-come, first-served manner. The committer 184 modifies the ledger 186 and the world state 188 in 5 and 5.1. Using the Fabric Certificate Authority 170, the signature and authorization of the peer container 180, the smart contract container 166 and the smart contract 168, and the order 192 can be verified. Further, the smart contract 168 can communicate with the endorser 182.

[0077] In one embodiment, the system uses a Kafka cluster as the ordering service It can be used as. Kafka is a distributed streaming service that supports the publication and subscription of semantics. The Kafka cluster runs on multiple servers and stores a series of records in categories called topics. Each record includes a key, a value, and a timestamp. Therefore, Kafka may be used as an ordering service that includes an ordering service node (OSN-n) and a Kafka cluster. The ordering service client may be connected to multiple OSNs. The OSNs do not communicate directly with each other. These ordering service nodes (OSNs) (1) perform client authentication, (2) enable the client to write to or read from Chain 1 using a simple interface, and (3) perform transaction screening and verification for configuration transactions to reconfigure an existing chain or create a new chain. Messages (records) within Kafka are written to topic partitions. The Kafka cluster may have multiple topics, and each topic may have multiple partitions. Each partition is a continuous, ordered, immutable sequence of records that are continuously added. After performing client authentication and transaction screening, the OSN can relay the incoming client transactions belonging to a specific chain to the partitions of the corresponding chain. The client transaction can then be executed in that partition and can return an ordered list of transactions common to all ordering service nodes.

[0078] According to one embodiment, each peer can become an endorser and a committer. A configuration item (e.g., CORE_PEER_ENDORSER_ENABLED) can make the peer an endorser. When a peer joins a channel, this peer becomes a committer of this channel. When a chain code is installed on a peer, this peer becomes a candidate endorser for this chain code. When a client proposes a transaction, the client can select a peer that becomes an endorser (from the candidate endorsers).

[0079] According to one embodiment, the ordering mechanism for the order to distribute blocks to peers is as follows. First, a peer (e.g., a leader peer) requests a new block from the order by sending its own version (the last block number). Next, the order checks the peer's version. a) If the peer's version is greater than the order's version, the order returns an error to the peer indicating that it has lost its ledger and cannot recover from the EventHub (in this scenario, the order cannot continue with proper operation). b) If the peer's version is less than the order's version, the order retrieves the block from the local ledger in RAM or a local file and returns it to the peer. c) If both have the same version, the order pauses until a new block becomes available. When a new block cut out from the EventHub becomes available, the order puts this block into the local block file or RAM, and then returns a distribution thread that reads this block from the ledger to the peer. The peer can obtain this block, commit it to the local ledger, and broadcast the latest version of the block to other peers.

[0080] BCS System Architecture Figure 1B shows the transaction flow that takes place in the fabric of a system that provides blockchain services. More specifically, Figure 1B shows a blockchain cloud service (BCS) system according to one embodiment. As shown, the blockchain cloud service components are created in a computing space 120 (e.g., an external computing space) on, for example, an Oracle PaaS service manager (PSM) platform. Access to the system is mediated by the PSM API 122 and the blockchain REST API 124. The external computing space 120 utilizes a load balancing as a service (LBaaS) 126 for incoming transactions​ Properly distribute to available resources.

[0081] According to one embodiment, BCS is an application container tier service built using the PSM platform on the application container cloud service 128. Each of the BCS entities operates on a separate container. Each BCS entity corresponds to an application container on a one-to-one basis. The blockchain cloud service implements the characteristics of the Hyperledger Fabric described above. In addition to the components for building a basic Fabric network, several components for leveraging the Hyperledger Fabric in the blockchain cloud service have been developed. These components need to be placed using separate behaviors and binaries. By using the cloud stack manager and granting users permissions, all services defined as a single unit called a stack by the blueprint can be automatically created.

[0082] In one embodiment, BCS provides a Hyperledger Fabric implementation for implementing a distributed ledger platform for executing smart contracts. BCS uses container technology to host smart contracts called "chaincode" that contain the application logic of the system.

[0083] According to one embodiment, the Fabric distributed ledger protocol is executed by peers. The Fabric identifies two types of peers. Verification peers are nodes on the network that are involved in consensus execution, transaction verification, and ledger management. On the other hand, non-verification peers are nodes that function as proxies for connecting clients (which issue transactions) to verification peers. Non-verification peers do not execute transactions but can verify transactions. Some important features of the Fabric include an instant finality and a permissioned blockchain that executes any smart contract called chaincode. The smart contract of the chaincode defined by the user is encapsulated within a container, and the system chaincode is executed in a process similar to that of the peers. The Fabric implements the consensus protocol and security by supporting a Certificate Authority (CA) for authenticating TLS certificates, enrollment certificates, and transaction certificates. The consensus protocol and security are implemented.

[0084] According to one embodiment, the BCS entity operates in a container instance hierarchically organized using ACCS128. The container is created and / or operated by the creation operation of the PSM. The Fabric CA container 130 is a container that provides the BCS Fabric CA (Certificate Authority) component. The BCS peer container 132 is a container in which a BCS peer network entity that manages the ledger component and executes the chaincode container operates to perform read / write operations on the ledger component. The BCS order container 134 is a container in which the BCS order for ordering transactions to the blockchain of all channels operates. The BCS chaincode execution container 139 is a container created and operated by the peer entity. In the container, the chaincode execution unit communicates with the parent peer entity and executes the encoding with the transaction instructions for changing assets and the assets within the blockchain.

[0085] According to one embodiment, the BCS chaincode builder container 140 is a container created and operated by a peer entity. The chaincode construction environment is installed and deployed in the container, and the chaincode execution unit is constructed in the container. The Fabric SDK client 106 provides functions for accessing BCS. Also, the blockchain cloud service utilizes the event hub cloud service 150, the cloud storage service 152, and the identity service 154. The Oracle (registered trademark) storage cloud service is used as the storage service of BCS.

[0086] According to one embodiment, Docker / Weave 141 is a container service. A container is a way of packaging software in a format that can be run independently on a shared operating system. Different from a VM, a container does not bundle a complete operating system. Instead, it bundles the libraries and settings necessary for the operation of the software. This enables the creation of an efficient and lightweight self - contained system, allowing the software to always operate in the same way regardless of the location where it is deployed.

[0087] According to one embodiment, each BCS instance is composed of different types of nodes. A BCS instance can include a small number (e.g., 0 or more) to a large number of peer nodes and can include a small number (e.g., 0) to a large number of order nodes. Each VM includes one BCS instance, and each BCS instance includes one to multiple Fabric CA nodes. Regarding the BCS gateway, a BCS instance can include a small number (e.g., 0) to a large number of BCS gateways. The BCS console is a component of the BCS instance. Each BCS instance includes only one BCS console.

[0088] According to one embodiment, as will be described in more detail below, the BCS management server (console) 136 is a BCS component for providing many monitoring functions, management functions, and display functions to the BCS stack instance. As will be described in more detail below, the BCS gateway (REST proxy) 138 is a new BCS component that provides a REST API interface to users / clients. The user / client executes transactions by accessing the fabric using the REST API interface.

[0089] According to one embodiment, the PSM console UI 102 of the public access client 100 enables the management of the platform service manager. The BCS console UI 104 enables the control of the BCS management server. Various different types of clients, including the fabric SDK client 106, the BCS REST client 108, and the fabric membership client 110, can access the BCS service.

[0090] According to one embodiment, a blueprint can be defined as an independent service type for each of the various types of containers listed above. The Oracle Cloud Stack Manager automates the creation of all independent service types in a single stack unit using the blueprint. The advantage of defining each BCS entity as a service type is to easily update and manage various execution entities. The application container tier service supports four operations, namely, CREATE_SERVICE, DELETE_SERVICE, SCALE_SERVICE, and Start / Stop / Restart. These operations can be applied to each service.

[0091] According to one embodiment, in a hyperledger fabric network, an ordering service component provides an ordering service in a crash fault-tolerant manner using Apache Kafka and supports multiple chains. Thus, in a BCS cloud service, the ordering service component uses an Oracle Event Hub Cloud Service (OEHCS) that (can distribute the power of Kafka as a processed streaming data platform and integrate with the remaining Oracle cloud).

[0092] FIG. 1C shows a BCS system according to an embodiment. More specifically, FIG. 1C shows a BCS runtime.

[0093] According to one embodiment, clients such as gateway-based application 103 and / or fabric-based application 105 can communicate with an AACS instance 128 via a network such as the Internet 107 and a front end such as a load balancer LBaaS 126 that includes a cloud gate (described later). Incoming calls can include REST communication (shown as a thick dashed line in the drawing) or, in certain situations, incoming gRPC communication (shown as a light dashed line in the figure). Incoming REST communication may be transferred to a gateway 138, a console 136, or an agent fabric CA 130 (described above) that (may include a REST API / REST proxy). REST communication transformed / converted to an internal call (gRPC) can interface with an instance of a blockchain fabric / hyperledger that (includes agent / peer 132, agent / order 134, chaincode 142, and chaincode builder 140). On the other hand, incoming gRPC communication is transferred directly to, for example, agent / peer 132 and agent / order 134 and can interface with a blockchain / hyperledger.

[0094] According to one embodiment, when a transaction is performed on an ACCS instance, the ACCS instance can persist the ledger to cloud storage via, for example, REST communication, or communicate with an event hub via REST communication.

[0095] According to one embodiment, although the drawings show only one ACCS instance, those skilled in the art will readily understand that there may be one or more ACCS instances with which clients (such as gateway-based application 103 and / or fabric-based application 105) can communicate via the BCS runtime described above.

[0096] FIG. 1D shows a BCS system according to one embodiment. More specifically, FIG. 1D shows the component concentration within the BCS system, i.e., the ratio of components for each BCS instance.

[0097] According to one embodiment, for each BCS instance 100a, order 101a may be provided in a 1:N ratio, fabric CA membership 102a may be provided in a 1:N ratio, BCS REST proxy 103a may be provided in a 1:N ratio, BCS console 104a may be provided in a 1:1 ratio, and peer container 105a may be provided in a 1:N ratio.

[0098] Each peer container can include an endorser that can simulate a transaction and a committer that is formed in the same peer container and can apply changes to the ledger.

[0099] According to one embodiment, the chain code 109a may be provided to peer containers in a 1:N ratio. Also, the storage 106a may be provided to peer containers and orders in an N:1 ratio. Similarly, the event hub 107a may be provided to peer containers and orders in an N:1 ratio. The IDCS 108a may be provided to the fabric CA membership in an N:1 ratio.

[0100] Blockchain Cloud Service (BCS) Gateway According to one embodiment, a BCS gateway (BCSGW) includes a network node that communicates with a fabric network using a fabric SDK. The BCS gateway enables interaction between a client application and the fabric elements of the BCS by providing an HTTPS REST API to client-side users.

[0101] FIG. 2 shows a gateway of a blockchain cloud service system according to one embodiment. As shown in FIG. 2, an end user 200 performs authentication and authorization by interacting with an application adapter 202 using HTTPS. The application adapter 202 accesses a public cloud 210 using HTTPS to an LBaaS such as a cloud gate 212 (i.e., LBaaS). A load balancing service (LBaaS) is executed for incoming transactions. The cloud gate 212 passes the transaction to the BCS gateway 222 using HTTPS. The BCS gateway provides an interface to the BCS fabric 220. This interface communicates using the gRPC remote procedure call protocol.

[0102] According to one embodiment, the cloud gate 212 is a reverse proxy "access enforcement module" or "policy enforcement point" that protects web browsers and REST API resources, for example, using the OAuth2 and OpenID Connect standards. IDCS protects its own management UI and REST API (referred to as the "IDCS web layer") by using the cloud gate internally. As another application, the cloud gate OTD is placed as an additional instance in a semi-supported / temporary setup known as non-IDCS or stand-alone.

[0103] According to one embodiment, OAuth / OpenID-based authentication supports the user browser flow of the (UI client) when the HTTP request includes a "user agent" header, that is, when the HTTP request is from a UI such as a browser or a mobile app. The cloud gate presents credentials (username / password) to the user, validates the credentials, and then creates an OAuth session cookie that can be used by subsequent HTTP requests from the browser and returns it to the user. Also, OAuth / OpenID-based authentication supports the resource server flow of the (program client). This flow is triggered when the HTTP request includes an authentication "bearer" token header. The cloud gate validates the token for authentication. For HTTP basic authentication, according to one embodiment, the credentials (username / password) must be included in the HTTP authentication "basic" header of each HTTP request. The cloud gate validates the credentials of each HTTP request. This method applies to both UI clients and program clients.

[0104]

[0105] According to one embodiment, the multi-token flow is a self-adaptive method that covers specific HTTP requests. When the HTTP request includes an authentication "basic" header, the cloud gate performs HTTP basic behavior. When the HTTP request includes an authentication "bearer" header, the cloud gate performs behavior similar to the resource server flow.

[0106] In one embodiment, the BCS console browser client utilizes the user browser flow. In an embodiment, the system can use the cloud gate multi-token authentication method for the BCS console and the gateway program client. The program client can call the BCS REST API via HTTP basic authentication.

[0107] According to one embodiment, the BCS gateway 222 communicates with a peer 224, which is a network entity that manages the ledger and executes the chain code container, to perform read / write operations on the ledger. The peer is owned and managed by members. The BCS gateway 222 and the peer 224 communicate with an orderer 226. The orderer provides an ordering service. The orderer is a predetermined set of nodes that order transactions into blocks. The ordering service exists independently of the peer process and orders the transactions of all channels on the network in a first-come, first-served manner. The peer 224 and the orderer 226 communicate with the Fabric certificate authority 228. Also, the BCS gateway 222 provides access to the BCS management server / console 230.

[0108] According to one embodiment, the BCS is deployed in a cloud system such as Oracle Cloud. The gateway can operate in the ACCS container. The gateway is stateless. The gateway can be updated by force-terminating the old gateway and starting a new gateway. The BCS gateway can permit client queries or call the Fabric chaincode via the RESTful protocol. The BCS gateway enables a client to access the Fabric network within the Oracle Cloud via the HTTPS / RESTful service. The BCS gateway is a network node that communicates with the Fabric network using the Fabric SDK. Communication within the Fabric uses gRPC as the communication protocol. The BCS gateway provides an HTTPS / RESTful API to the client-side clients. The REST API enables a client to call functions within the Fabric using the Fabric SDK.

[0109] According to one embodiment, the gateway may be provided to Fabric users in a one-to-one relationship. All gateway users belong to one organization, and all gateway users are mapped to one Fabric user within one gateway. One gateway constitutes only one Fabric user.

[0110] According to one embodiment, the IDCS issues a gateway certificate and a gateway user ("app adapter") certificate. These certificates are signed by the organizational CA. Since the gateway and the gateway user are deployed with the organizational CA, they can verify each other using HTTPS.

[0111] According to one embodiment, each end user accesses the BCSGW via an "app adapter". The authentication is in three steps. That is, the end user 200 is authenticated by the app adapter 202, and the app adapter 202 is authenticated by the BCS gateway 222 using a client certificate, and the BCS gateway is authenticated by the peer 224 and the orderer 226 within the fabric network 220.

[0112] According to one embodiment, one container runs one Tomcat server and deploys one BCS gateway mapped to one fabric user. Multiple app adapters can be connected to one gateway.

[0113] According to one embodiment, different gateways may be associated with different fabric users. The end users of the app adapters connected to one gateway may be mapped to one fabric user.

[0114] According to one embodiment, the BCSGW is run in the Oracle Cloud, and the configuration is set by the BCS console using a JSON file. The administrator user can expose parts of the peer, channel, and chaincode to the gateway. The administrator user starts the gateway via the console. The gateway does not refresh the configuration after startup. The administrator user can set the endorser of the chaincode. The end user is unaware of the policy, and the gateway does not check the chaincode policy.

[0115] According to one embodiment, the BCSGW is activated by the BCS console. The BCS console creates a BCSGW configuration file and uses the BCSGW package to start a new gateway. At startup, the startup script checks the BCSGW configuration file, modifies the configuration file for Tomcat (e.g., the Tomcat configuration file), and then starts Tomcat. Tomcat starts a thread of the BCSGW, and this thread creates channel objects by reading the configuration files of each channel and creates connections with the order, peer, and event hub. Different channels have different connections to the order / peer / event hub. The event hub is the second port of the peer. The gateway obtains the result of the transaction by connecting to this port. The Tomcat servlet container can listen for client requests. In the case of the chain code query method, the BCSGW sends the request to all peers of the channel and uses only the first result. In the case of the chain code call method, the BCSGW sends the request to all endorsers of the channel. If one of all the endorsers returns success, the BCSGW sends the transaction to all orders of the channel.

[0116] According to one embodiment, an asynchronous API can be supported. The peer can open two ports. One port is for exchanging events. The gateway can connect to the event port of the peer. The gateway only needs to connect to the event port of one channel. The normal client API is synchronous. The transaction may take several seconds, and the client needs to wait for the response. Sending asynchronous events to the client is not included in the V1 plan. In addition to the synchronous transaction API, the gateway provides an asynchronous transaction API for "asynchronous call". I

[0117] In one embodiment, the asynchronous API can operate as follows. After checking the parameters of the client request, the gateway returns a transaction ID to the client. Thus, the client can recognize that the started transaction has not ended. The gateway starts a background thread to continue processing the transaction. The client can track the unfinished transaction. The gateway can provide a "transaction" API for the client to query the transaction state using the transaction ID.

[0118] According to one embodiment, client login can be supported. The BCSGW can support the HTTPS protocol and reject insecure HTTP access. The BCSGW authenticates the application adapter or SALT using a certificate. The application adapter can authenticate the end user. Tomcat needs to be configured to use HTTPS client certificate authentication. The keystore file contains the BCSGW certificate and the CA certificate for the client to verify that it is provided by the BCS console. The BCS gateway provides a BCS REST interface for the client to access.

[0119] Persistence - Storage Cloud According to one embodiment, the Hyperledger Fabric project code includes blocks for storing the ledger in the local file system and other runtime data, such as block indexes, world state, history, and blocks for storing the ledger provider database (which holds all ledger IDs and recovery status) in a LevelDB stored in the same local file system. In ACCS, the container file system is transient. This means that if, due to some hardware failure, the container is stopped and a new container is restarted on a new VM, the contents of the file system may be lost. If all containers are lost, the ledger cannot be recovered. Therefore, the ledger data must be stored outside the ACCS container. For this reason, the persistence solution is provided as an object storage service used by the Hyperledger Fabric components described above.

[0120] According to one embodiment, in BCS, the persistence solution utilizes a storage cloud service, such as the Oracle Storage Cloud Service. The ledger is backed up to an object store. The ledger is not written to the container file system but is backed up to object storage. The index and world state are recorded using the container file system and can be recovered from the storage cloud service when the container is restarted. The Oracle Storage Cloud is an Infrastructure as a Service (IaaS) offering that provides an enterprise-class large-scale object storage solution for storing files and unstructured data.

[0121] Figure 3 shows the persistence of the blockchain cloud service system according to one embodiment. As shown in Figure 3, the ACCS instance 300 includes a plurality of containers. The containers include, for example, order containers 302 and 304 having ledger / blockchains 312 and 314. The ledgers / blockchains 312 and 314 are backed up to the object storage 320 via the REST interface. The object storage 320 may be, for example, a cloud storage service.

[0122] The object storage is used to persist the ledger of each order. The current mechanism for an order to distribute blocks to peers is as follows. First, a peer requests new blocks from the order by sending its own version (the last block number). Next, the order checks the peer's version. a) If the peer's version is greater than the order's version, the order returns an error to the peer indicating that the order's ledger is missing and cannot be recovered from the EventHub (in this scenario, the order cannot continue with proper operation). b) If the peer's version is less than the order's version, the order retrieves the block from the local ledger in RAM or a local file and returns it to the peer. c) If both have similar versions, the order blocks until a new block becomes available. When a new block cut from the EventHub becomes available, the order places this block in the local block file or RAM and then returns a distribution thread that reads this block from the ledger to the peer. The peer can obtain this block, commit it to the local ledger, and broadcast the latest version of the block to other peers.

[0123] According to one embodiment, by the above process, either the order or the event hub can persist all blocks. As described above, the event hub supports time-limited retention. If the event hub can perform block storage, the order can set the ledger type to RAM or a file. When the order is restarted and the ledger is lost, the order can reconstruct the ledger by replaying the records from the event hub and splitting the batch messages into blocks. If the event hub only supports time-limited retention, once the order is restarted and the ledger is lost, the first record in the event hub is not the true record of the ledger, so the ledger cannot be correctly reconstructed. In this case, since the first block containing the channel information is lost and the version number (the last block number) is also incorrect, the order cannot start the old channel.

[0124] According to one embodiment, each order can persist all channel IDs in object storage and save each block in oracle storage. The peer persists only the genesis block having the channel information. When other block data is lost, the peer can read other block data from the order.

[0125] According to one embodiment, the ACCS instance 300 can include a peer container 306 including a ledger 316 and an index 326, and a peer container 308 including a ledger 318 and an index 328. The peer generates five types of runtime data, namely, a transaction log (block file), a block file index (LevelDB), a ledger provider DB (LevelDB), a state database (LevelDB or CouchDB), and a history (LevelDB). All transaction data is stored in the transaction log as linked blocks in a local file and persisted in the Oracle Storage Cloud Service. The ledger provider DB persists all ledger IDs and statuses in the LevelDB. The ledger ID is a unique ID for identifying the channel to which the peer belongs and must be stored in the Oracle Storage Cloud Service. At runtime, the peer can automatically recover others and can be stored in the local file system.

[0126] According to one embodiment, the Oracle Storage Cloud Service provides a REST API for uploading a file to an object or downloading a file from an object. When creating a new block, first, write the block to the local block file as usual, but different in that only one block is written to each file. Next, upload this block file to the Oracle Storage as an object. If the upload fails, the changes to the local file are rolled back and an error is returned to the sender.

[0127] ​According to one embodiment, when an order updates the latest checkpoint of the block file index, it persists the information in the oracle storage and then updates the local-level DB. If this operation fails, an error can be returned to the sender. This information is used for the recovery of the block file index. In the oracle storage, each peer and order has a unique container name consisting of a combination of MSP ID and node ID. The object name is a combination of the channel name as a prefix and the block file name. For further details, refer to the naming rules of the oracle storage.

[0128] According to one embodiment, optionally, the ledger provider DB can be saved in the oracle storage. When the ledger provider DB is updated, the entire level DB can be replicated to the oracle storage cloud service. Since this file is very small and not updated frequently, the overhead due to replication can be ignored. When restarting the container, the container can be downloaded from the oracle storage cloud service. When restarting an order from a new container, first, the order downloads the channel ID from the storage object, and then the order retrieves the latest checkpoint from the storage according to the channel ID. Next, the order recovers the block index from the first block to the last block. During this period, the block files are downloaded one by one. Then, the order recovers the state DB and the history DB. When restarting a peer from a new container, first, the peer downloads the ledger provider DB, and then all ledger IDs can be obtained. Next, the peer retrieves the related genesis block from the storage according to the ledger ID. The peer starts with the settings in the genesis block and sends requests to the orenda to obtain other block data. After obtaining these blocks, the peer recovers the block index, the state DB, and the history DB.

[0129] According to one embodiment, the local block file functions as a read cache. The query first reads data locally and, if the data does not exist locally, downloads the data from the object storage. In addition to the ledger, it is necessary to persist the source code of the chain code in the oracle storage. After installing the chain code into the current fabric, the source code is encoded and stored on the peer. The peer checks the chain code container for each call or instance and, if the container does not exist, reconstructs the container from the source code. Therefore, each time a chain code is installed, the source code can be uploaded to the oracle storage, and when restarting the peer from a disk failure, the source code can be downloaded from the oracle storage.

[0130] BCS: Operation of the SDK-based configuration file and placement after creation According to one embodiment, the configuration file and placement functions place, generate, update, and retrieve the configurations related to the application when placing or updating an application including peers, orderers, CA servers, and chain codes. These functions reside in both the BCS console (Node.js) and the fabric containers (peer / orderer / chain code container ). When requested from the UI, these functions obtain / update the configurations and change the configurations by calling the SDK API if necessary. This component, as part of the BCS console backend, is the BCS console UI, IDCS b The hook end SDK provides an SDK to operate the UI and obtain / update the required settings by interacting with all BCS applications. This component also assists in creating BCS applications. The BCS creation component deploys the BCS application into the docker container of the VM created using PSM. This feature implements the SDK API of the BCS console UI, and the BCS creation component acquires, updates, and deploys the BCS application configuration in the later creation stage. The creation system deploys BCS applications such as CA servers, orders, peers, etc. into docker / swarm in the later creation stage. The VM performs later creation tasks and VM initialization tasks at startup by calling the startup script.

[0131] According to one embodiment, the configuration file is provided to fabric components including peers, orders, fabric CAs, and BCS gateways. The BCS application package, configuration, and chaincode are stored in the client's storage cloud service.

[0132] According to one embodiment, the creation system allocates all resources. The resources include VMs, networks, and storage.

[0133] According to one embodiment, the creation system stores all resource allocation information in the storage service. This information includes VM numbers and related network addresses / account credentials, the numbers and types of BCS applications in each VM, public IPs and internal IPs. Also, the creation system has sufficient internal IP addresses for containers (accessible between VMs).

[0134] According to one embodiment, when the BCS creation component completes the creation work, the VM startup script deploys the application container by starting and invoking the worm, and the container startup shell script executes the initial operations within the container.

[0135] According to one embodiment, when the BCS console operates, it obtains settings from the storage service, saves user input from the UI to the storage service, and then sends a restart command to the worm.

[0136] According to one embodiment, the necessary security certificates may be stored in the IDCS or obtained from the IDCS.

[0137] According to one embodiment, the BCS console backend can communicate with the BCS application using the worm.

[0138] According to one embodiment, when the BCS application container is started, the BCS application can determine the application type (peer, chaincode container, or others) by collecting the details of the settings and load the necessary settings.

[0139] According to one embodiment, this component updates the settings and provides the BCS application startup shell code. The operation of obtaining / updating the configuration file by BCS includes several steps. First, when the BCS console is started, it obtains the settings from the storage and saves the settings (shell and node.js) to the storage if an update is required. When the BCS application container is started, first, the startup script (within each Docker container) is started, then the settings regarding the type of the application are obtained, and the application certificate is obtained from the IDCS (shell). When the BCS console UI restarts the BCS application, it sends a message for restarting the application within the container to Docker / Swarm.

[0140] According to one embodiment, the BCS console is stateless. When started, it can collect all BCS instance settings, connect to the BCS application, and monitor the BCS application. The settings are obtained from the storage service via the backend API. When the settings are changed, the BCS console saves the settings to the storage service by calling the backend API and restarts the related applications. When a client changes a setting item via the BCS console UI, the UI encodes the setting into key / value data, and the backend code converts it into a file and saves it to the storage service. The BCS console can monitor, start, and stop the BCS application. The start command and stop command use the Docker / Swarm API to implement this function.

[0141] Fabric Network Deployment According to one embodiment, the Fabric network includes the following entities, namely, peers, clients, an ordering service, and a set of protocols to facilitate communication between these entities. An organization is a logical entity or enterprise that constitutes the parties to the Fabric network. The Fabric network has multiple participating organizations. A member is a legally independent entity that owns the unique root certificate of the network. Network components such as peer nodes and application clients are linked to members. Each organization may have one or more members. One organization can constitute both an orderer and a peer, or only an orderer or only a peer.

[0142] The first step for deploying a Fabric network is to define the participants. This step is performed outside the Fabric network's bandwidth. All participating organizations in the Fabric network negotiate and determine the network configuration, for example, the organizations that make up the orderer nodes or the organizations that make up the peer nodes. Each organization that makes up an orderer node publishes the root certificate of the orderer server. Each organization that makes up a peer node publishes the root certificate of the peer server. Each organization, including the client, publishes the root certificate of the client. The client can be split into different members from the peer in one organization.

[0143] As an example, assume that four banks (Bank 1, Bank 2, Bank 3, and Bank 4) deploy a blockchain network using an ordering service that includes orderer nodes owned by Bank 1 and Bank 2. Bank 1 constitutes only the orders of this network. Each bank is an organization in the Fabric network. That is, Bank 1 has one member, the order (root certificate 1). Bank 2 has three members, namely, the client (root certificate 21), the peer (root certificate 22), and the order (root certificate 23). Bank 3 has two members, namely, the client (root certificate 31) and the peer (root certificate 32). Bank 4 has two members, namely, the client (root certificate 41) and the peer (root certificate 42).

[0144] After defining the participants, create the orderer and peer certificates. Each orderer or peer requires a (private key and signature certificate) pair to identify itself. Each member uses the root certificate to configure and start its own Fabric CA server and can create the (private key and signature certificate) of each orderer / peer server of the member by requesting the CA server using the CLI or SDK. BCS provides a Fabric CA server that can create certificates. However, Fabric The CA server is not the only means to create certificates. Users can create certificates using other CA systems. Therefore, the Fabric CA server is not an essential component of the Fabric network.

[0145] After creating the orderer and peer certificates, the Fabric network is started by creating a system channel. Since there is only one system channel for the ordering service (and thus one Fabric network), the system channel created (more precisely, started) is the first channel. The system channel defines the following components of the Fabric network: namely, one ordering service and one or more consortia. One ordering service includes one or more orderer organizations (each organization includes an MSP ID and a certificate), the attributes of the ordering service (such as the type, e.g., solo or Kafka, the address of the orderer, batch size / timeouts), and the policies (for creating the channel). Each consortium includes one or more peer organizations, and each peer organization that wishes to participate in this Fabric network must be defined in one of the consortia. Each organization includes an MSP ID, a certificate, and an anchor peer.

[0146] After the system channel of the Fabric network is started, the genesis block (the first block in the chain) of the system channel is created. The administrator of the ordering service creates the genesis block for the system channel. The genesis block can be created (as a file) by the configuration file generation (configtxgen) tool or may be created (temporarily) at the time of orderer startup. When creating the genesis block using the configuration file generation tool, the configuration file configtx.yaml as input It must be created. This file includes the following information, namely, the root certificates of all orderer organizations within the fabric network, the root certificates of all peer organizations, the types of orders, addresses, batch timeouts, batch sizes, and the attributes of the ordering service including Kafka, policies, a channel reader for authenticating and verifying channel delivery requests, a channel writer for authenticating and verifying channel broadcast requests, a chain creator for evaluating chain creation requests, and an administrator for authenticating and verifying channel reconfiguration requests.

[0147] The administrator of the ordering service starts the order server using the configuration file and the genesis block. In other words, the system channel is created using the genesis block. To start the order server, a configuration file orderer.yaml including the listen address / port, ledger type, and local MSP (private key, signature certificate) is required. Each organization providing the ordering service starts its own order server (without specifying the genesis block).

[0148] Each organization constituting the peer node prepares a configuration file for each peer (default location / etc / hyperledger / fabric / core.yaml) for identifying the peer with the local MSP (private key, signature certificate) and specifying peer attributes such as the listen address / port, bootstrap peer, and gossip attributes, and then starts the peer server.

[0149] After starting the order and the peer, the channel administrator (who has the right to create channels) uses the Fabric CLI or SDK to request the order to create a channel including the following inputs, namely, one consortium (already defined in the system channel) and one or more peer organizations within the consortium. Each participating organization uses the Fabric CLI or SDK to make a part of the peers participate in the newly created channel.

[0150] Example: Fabric Network Placement on BCS Figure 4 shows an exemplary placement of the fabric on BCS.

[0151] More specifically, the drawings and description explain the steps for placing a fabric network on BCS. In this example, four entities A, B, C, and D wish to create and participate in a fabric network. The four entities discuss offline and determine the responsibilities of the various entities. Each entity creates one or more BCS instances on the OPC.

[0152] According to one embodiment, entity A provides both orderer and peer. Entity A creates two instances, namely orderer_organization1 401 for the orderer and peer_organization1 421 for the peer. Entity A is also involved in creating the fabric network (note that only the orderer can create the fabric network). The ordering service 400 includes orderer_organization1 401, orderer_organization2 402, and Kafka cluster 410.

[0153] According to one embodiment, entity B provides both orderer and peer. Entity B creates two instances, namely orderer_organization2 402 for the orderer and peer_organization2 422 for the peer.

[0154] According to one embodiment, entity C provides only the peer. Entity C creates the instance peer_organization3 423.

[0155] According to one embodiment, entity D provides only the peer. Entity D creates the instance peer_organization4 424.

[0156] According to one embodiment, the administrator of each BCS instance collects the current organization's CA certificate and administrator certificate from the BCS console. The administrator of each peer organization identifies the anchor peers of the current peer organization and collects the IP / ports of the anchor peers. The four entities exchange all the collected information with each other offline.

[0157] According to one embodiment, the administrator of the order_organization1 creates a Fabric network by creating a system channel from the BCS console using the information collected in the previous step, i.e., the CA certificate and administrator certificate of each organization, and the anchor peers of each peer organization. The backend operations include creating a genesis block by calling Fabric tools and creating a system channel by ordering using the genesis block.

[0158] According to one embodiment, the administrator of each peer organization participates in the Fabric network by updating the settings of all peer nodes to add the CA / admin certificates of other organizations collected from the BCS console and restarting all peer nodes.

[0159] According to one embodiment, a method is provided to enable a new organization to participate in an existing Fabric network within the system. Also, to create / participate in a Fabric network, for example, to protect offline actions before forming the Fabric, communication between participants can be facilitated and a user-friendly method can be provided.

[0160] Chaincode (Smart Contract) Container According to one embodiment, as described above, chaincode can include software that defines one or more assets and transaction instructions (business logic) for changing the assets. Chaincode reads key-value pairs or other state database information. Execute the rules for taking or changing. The functions of the chaincode are executed against the current state database of the ledger and are triggered by transaction proposals. The execution of the chaincode results in a set of key-value writes (write set) that are submitted to the network and applied to the ledger on all peers.

[0161] According to one embodiment, to support consistent updates of information and enable certain ledger functions (such as transactions, queries, etc.), the blockchain network uses smart contracts to provide controlled ledger access. Smart contracts not only encapsulate information and can easily replicate that information across the network, but may also be written so that participants can automatically execute specific parts of a transaction.

[0162] According to one embodiment, the Hyperledger Fabric smart contract is written in chaincode and is called by an application outside the blockchain when that application needs to interact with the ledger. In most cases, the chaincode interacts only with the database component of the ledger, which is the world state (e.g., searches the database), rather than the transaction log.

[0163] According to one embodiment, Hyperledger Fabric uses a Docker engine to build, deploy, and execute the chaincode. This section describes the architecture of Fabric and how to integrate it into the ACCS layering model of BCS.

[0164] According to one embodiment, the fabric arranges and manages user chain code as follows. First, build the chain code in a transient CC environment container. Next, transfer the chain code as source code to a builder container, compile it with the necessary libraries that are statically linked ("Java (registered trademark) build"), and return it as a binary to the peer. Static linking makes it possible to keep the actual chain code container as small as possible. Then, build and start the chain code image and container. The chain code container continues to operate until the peer stops or the channel ends. If the chain code container crashes or is forcefully terminated, it is restarted in the next call if the image exists. In this design, one peer and channel have one chain code docker container. The chain code is explicitly installed on the peer. That is, the chain code does not necessarily have to be installed on all peers participating in the channel.

[0165] According to one embodiment, the user can place a fabric network that can easily distribute components such as peers, orderers, and chain codes in an ACCS hierarchical container. Since the local block storage is not a reliable recovery method and the chain code binary of the ACLS container needs to be stored in cloud storage, the chain code runtime environment container (ccenv) is dynamically operated. When the chain code binary is built, it is uploaded to cloud storage to recover in case of container crashes.

[0166] According to one embodiment, the interaction of each chain code corresponds to various functions of the chain code. The only constraint is that it cannot be called or queried until the chain code is instantiated. Also, when called, an inactive chain code container is restarted.

[0167] FIG. 5 shows a chaincode architecture according to one embodiment. More specifically , FIG. 5 shows a chaincode architecture that enables a client 530 to install a chaincode and execute a transaction in an ACCS environment 500. In step 1, the client 530 installs the source code of the chaincode on peer 1 510. First, the chaincode is built in a transient CC environment container. When the client 530 executes "install", the client 530 starts a builder container that automatically starts a builder agent, waits for the builder container to finish initializing, and sends the source code of the chaincode to the builder container via the peer (step 2). The builder agent builds the chaincode (Java build). The chaincode is transferred to the builder container as source code, compiled with the necessary libraries that are statically linked ("Java build"), and returned to the peer as a binary. Static linking makes it possible to keep the actual chaincode container as small as possible. Once the chaincode package (tgz file) is built, it is uploaded to cloud storage 560 (step 3). The builder agent sends the cloud storage location to the peer for later reference (step 4.2).

[0168] According to one embodiment, the peer 510 then uses the PSM REST API to start the CC environment as an ACLS (Access Control List) container 520. It constructs and starts the chaincode image and the container. The chaincode container continues to operate until the peer stops or the channel ends. The peer 510 passes the chaincode ID, self IP (for chaincode registration), and cloud storage location to the ACLS container and starts (step 4.1). The peer waits for a timeout after the startup or setup period of the chaincode. The CC environment starts the chaincode. Once started, the chaincode registers itself with the peer (step 4.3). Thereby, the chaincode can be invoked in a transaction using the connection established at registration (step 5).

[0169] According to one embodiment, the builder container 550 includes a simple REST - type server. The builder container 550 includes a builder agent 553. When the builder container 550 is started, it listens for requests to build a chaincode. When the builder container 550 receives a build list, for example, a POST call with base64 - encoded source code in the body, the base64 decodes the source code and saves the chaincode source code to the local file system. The builder agent 553 performs a "Java build" on the source code. If the "Java build" is successful, the builder agent 553 packages the binary and uploads it to the cloud storage 560. Also, the builder agent sends the chaincode location to the peer. If the "Java build" fails, the agent sends the error and the reason to the peer.

[0170] BCS Management Console As described above, each instance of BCS includes a management console, and using the management console, it can manage and monitor the BCS instance including the BCS gateway, BCS nodes, and BCS channels.

[0171] According to one embodiment, a system for providing a management console can include a web application that operates in a script runtime environment, such as Node.js. The we b application can be built on a graphical user interface framework and a web framework and can include a plurality of custom functions or APIs for communicating with various nodes or services within the BCS instance. The web application can read information from various nodes or services within the BCS instance into view objects and display them in the console user interface. Also, the management console can provide an administrator with functions for starting, stopping, and updating one or more nodes within the BCS instance. A management REST API set may be provided by the script runtime environment or accessed by the script runtime environment to support functions similar to those provided by the web application.

[0172] According to one embodiment, the system can easily monitor and manage the associated BCS instance via a web interface provided by the web application or via a custom REST client application written using the management REST API set.

[0173] According to one embodiment, a BCS administrator can manage a plurality of components of a BCS instance, including one or more peer nodes, one or more orderer nodes, one or more fabric CA nodes, one or more BCS gateway nodes, channels, and one or more chaincodes, via the management console.

[0174] According to one embodiment, managing the BCS components can include performing one or more operations among operations including starting the components, stopping the components, adding the components, removing the components, viewing / editing component attributes, viewing component performance metrics, and viewing component logs.

[0175] FIG. 6 shows a system for providing a management console according to one embodiment. As shown, the BCS management console 136 may be provided as a component of the BCS instance within the application container cloud service 128. The BCS management console may be a web application that operates in a script runtime environment 605 that is a runtime environment provided by Node.js. It may be a web application that operates in the script runtime environment 605 that is a runtime environment provided by Node.js.

[0176] According to one embodiment, the management console can include a fabric node SDK 611, a plurality of fabric custom functions 613, and a plurality of ACCS APIs 615. Using the SDK, custom functions, and ACCS APIs, it can communicate with a fabric network 601 that may include a distributed streaming service (e.g., Kafka) 603. The management console further includes a view object 623, and the view object 623 can include information that needs to be displayed on the BCS console UI 104 or the REST client 604, or can include information that needs to be passed from the BCS console UI or the REST client to the management console. The fabric node SDK 611 can operate to map information from the fabric network to information from the BCS console UI or the REST client.

[0177] According to one embodiment, the BCS management console further includes a GUI framework (e.g., JET ) 617 and a web framework (e.g., express) 619. It can be cut. The GUI framework can provide various user interface (UI) components and elements that can be used in the management console web application. For example, using UI components and elements, forms can be created, data can be collected, and data can be visualized. The web framework can be written in JavaScript (registered trademark) and can provide a web application framework including a set of robust features for developing web applications and mobile applications.

[0178] Figures 7A-7B show examples of user interfaces within the BCS console UI according to one embodiment.

[0179] According to one embodiment, as shown in FIG. 7A, the BCS overview 711 can be displayed within the dashboard. The overview can include the number of organizations, the number of peers, the number of orders, the number of channels, and the number of chaincodes.

[0180] According to one embodiment, the health information 713 of the BCS instance can be displayed. The health information is visually shown and displayed numerically. The exemplary UI can also display the execution of transactions 714 and the ledger overview 715.

[0181] According to one embodiment, FIG. 7B shows information about all nodes within the BCS instance. For example, the exemplary UI shows a total of five nodes including two peers, one orderer, one Fabric CA, and one REST proxy (within the BCS gateway node). The overview UI 717 displays the name of the node 723, the routing information of the node 725, the type of the node 729, and the status information of the node 731. The exemplary UI includes a button 721 for the administrator to add a node and one or more drop-down lists 719 for sorting nodes.

[0182] Node management ​According to one embodiment, two entities, namely, the BCS administrator and the BCS user, can manage the BCS instance using the management console. There is only one BCS administrator account for each BCS instance. The BCS administrator account may be created when creating the BCS instance. The BCS administrator may be bundled with the Fabric CA administrator (i.e., the BCS administrator uses the Fabric CA administrator ID to perform all operations from the BCS console or via the BCS management REST API). There may be two or more BCS user accounts. The BCS user accounts may be created by the BCS administrator by registering the Fabric CA identities.

[0183] According to one embodiment, the nodes within the BCS instance may be displayed on one web page. The management console can support two modes. The first mode can present the name, type, access URL, and status of each node as a list. The second mode can present the channels that each peer participates in as a graph.

[0184] Furthermore, according to one embodiment, the BCS administrator can start and stop peer nodes, order nodes, Fabric CA nodes, and BCS gateway nodes via the management console, and can add and delete peer nodes, order nodes, and BCS gateway nodes. The Fabric CA nodes cannot be added or deleted.

[0185] According to one embodiment, when adding a node, the BCS administrator can set the attributes of the node. The newly added node can be automatically started as part of the addition operation. When deleting a node, the node is stopped and deleted from the BCS instance.

[0186] According to one embodiment, the BCS console UI can list all channels in which active peer nodes are participating and all chaincodes installed on the active peer nodes.

[0187] According to one embodiment, when managing peer nodes, the BCS administrator can add active peer nodes to an existing channel and view and edit the attributes of active order nodes. The BCS user can view some of the attributes of the active peer nodes.

[0188] Also, snapshots of performance metrics of active peer nodes, such as memory utilization rate, CPU utilization rate, network I / O, and disk I / O, may be displayed on the BCS console UI.

[0189] According to one embodiment, when managing order nodes, the BCS administrator can view the logs of active order nodes and view and edit the attributes of active order nodes. The BCS user can view some of the attributes of the active order nodes. Similar to the management of peer nodes, the BCS administrator can view snapshots of performance metrics of active order nodes, such as memory utilization rate, CPU utilization rate, network I / O, and disk I / O.

[0190] According to one embodiment, when managing Fabric CA nodes, the BCS administrator can view and edit the attributes of active Fabric CA nodes, obtain CA certificates from active Fabric CA nodes, and view the logs of active Fabric CA nodes. Also, the BCS administrator can view snapshots of performance metrics of active Fabric nodes, such as memory utilization rate, CPU utilization rate, network I / O, and disk I / O.

[0191] As described above, since the maximum allowable number of BCS gateway nodes, which can further include adding or deleting BCS gateway nodes, is specified when instantiating a specific BCS instance, the number of BCS gateway nodes that can be added to a BCS instance is limited by the set maximum allowable number of BCS gateway nodes.

[0192] According to one embodiment, each BCS gateway node can have a name that is a unique identifier for the entire gateway node. This name is referenced when configuring the BCS gateway node. Also, when creating a BCS gateway node, the network address can be determined and displayed.

[0193] According to one embodiment, the BCS administrator can define a BCS gateway configuration file and start the BCS gateway node when configuring the BCS gateway node. When creating a BCS instance, it may not be necessary to create a channel or deploy a chaincode. Therefore, the BCS gateway node does not function until one or more chaincodes are deployed via the management console and a valid BCS gateway configuration is defined.

[0194] Each BCS gateway node has a configuration page. In a specific embodiment, the following items can be configured on the configuration page. 1) Channel: Select the channel to be published via the current gateway node. 2) Chaincode: Select the instantiated chaincode to be published from the list of all chaincodes instantiated on each channel. 3) Endorser: Define the endorser peers for each chaincode. 4) Create a BCS gateway configuration according to the above settings. When a valid configuration file for the BCS gateway is created, the gateway can be started.

[0195] According to one embodiment, the BCS console enables viewing of BCS gateway properties using a list viewing function. The list viewing provides the following information for each BCS gateway. 1) Name: The global unique name specified when creating the gateway. 2) Fabric identifier: Each BCS gateway can be associated with the identification information of the fabric client registered when creating the BCS gateway. This fabric client can execute all operations (e.g., calls, queries) performed by the BCS gateway. 3) Network address: The access point has a public Internet network address. 4) Status: Operational or stopped.

[0196] According to one embodiment, the BCS administrator can view the logs of active BCS gateway nodes and view the following BCS gateway metrics via the management console. 1) Connected clients: Client name, address, logon time, etc. 2) Current transaction information: The current transaction information is available together with the status information, i.e., the status of the transaction. The current transaction information is useful when debugging frozen transactions. 3) Transaction statistics: The transaction statistics are available via the management console UI. For example, the transaction statistics can include the number of completed transactions, the number of received event notifications, and the number of sent event notifications. 4) Memory utilization rate. 5) CPU utilization rate. 6) Network I / O. 7) Disk I / O.

[0197] Channel management According to one embodiment, a BCS user can list all channels in which the current BCS instance is participating. A BCS administrator can create a channel by inputting a channel name, a consortium name, and one or more organization names. Also, the output can be displayed to indicate the success or failure of channel creation.

[0198] According to one embodiment, a BCS user can view the nodes and organizations participating in a channel. The management console can support two view modes, including a list mode and a topology mode. In the list mode, the participating local nodes and external organizations (indicated by anchor peers) may be shown as a list. In the topology mode, the participating local nodes and external organizations (indicated by anchor peers) may be shown as a topology diagram.

[0199] According to one embodiment, a BCS administrator can query the ledger of peers within a channel. The ledger can include a plurality of transaction blocks. Each transaction block can include a block ID, a previous hash, a data hash, a timestamp, a list of transaction IDs, operations (1 to n), a chain code ID, a chain code proposal, a response (r / w set, event, success or failure), and one or more endorsers. Also, the following statistical data, namely, the number of blocks and the number of calls, can be displayed.

[0200] According to one embodiment, a BCS administrator can list all chain codes instantiated in a channel. The listed items can include the chain code ID and the version. A BCS administrator can also view the following information of the instantiated chain code, namely, the path specified by the instantiated transaction, and the instance arguments. The listed items can include the chain code ID and the version. A BCS administrator can also view the following information of the instantiated chain code, namely, the path specified by the instantiated transaction, and the instance arguments.

[0201] According to one embodiment, the BCS administrator can update the chaincode instantiated on the channel. The update operation can use the following inputs, namely, the target end - of - service including the newly installed version of the chaincode, one or more orders, the chaincode version, and optional arguments that can be string arguments specific to the chaincode. The output of the update operation can be a success or a failure including an error message.

[0202] Chaincode Management According to one embodiment, the BCS administrator can list all the chaincodes installed on any peer of the current BCS instance. The listed items include the chaincode ID and version. Also, the BCS administrator can view the following information of the installed chaincode, namely, the local peer node that installed the chaincode, and the channel on which the chaincode was instantiated.

[0203] According to one embodiment, the BCS administrator can install the chaincode on one or more local peer nodes via the management console. The inputs for installation can include the target peer, the chaincode type such as Go language / Java, the chaincode ID which can be the name of the chaincode, the chaincode version, the chaincode path which can be the location of the source code of the chaincode, and an optional chaincode package. The output of the installation operation can be a success or a failure including an error message.

[0204] According to one embodiment, the BCS administrator can instantiate the installed chaincode on the channel with the following information as input: namely, the channel name, the target endorser including the installed chaincode of the new version, the orderer, the chaincode version, and optional arguments that can be string arguments specific to the chaincode, a specific format, or a default format if there is no specific format, and an endorsement policy.

[0205] Membership Management According to one embodiment, the BCS administrator can list all the IDs within the current BCS instance, register a new user / ID to the current BCS instance, revoke the registered ID, and delete a user from the current BCS instance. Also, as shown in Table 1, the BCS administrator can view / edit the following attributes of the identification information.

[0206]

Table 1

[0207] According to one embodiment, the BCS user can register or re-register itself via the management console, which enables the creation of the user's private key and certificate. Also, the BCS administrator can invalidate the previously registered ID via the management console, and the BCS user can change the password via the management console.

[0208] According to one embodiment, it is possible to start or stop the relevant BCS instance and start or stop the BCS management console.

[0209] According to one embodiment, the log level of the BCS management console can be set in two ways. That is, the log level can be changed at runtime using the BCS management console or the management REST API.

[0210] REST API As described above, different components within the fabric network communicate based on the gRPC protocol. Therefore, in the case of a BCS instance based on the fabric network, the client application needs to use the fabric SDK to call the chaincode within the BCS instance.

[0211] The fact that the client application communicates with the blockchain cloud service using the fabric SDK would partially negate the advantages of providing the blockchain framework as a cloud service. For example, one of the advantages is that the cloud service can be accessed from anywhere using an Internet connection.

[0212] According to one embodiment, the systems and methods described herein can provide a REST proxy in the BCS instance. The REST proxy can be used by a REST client to query via the chaincode, call transactions synchronously or asynchronously via the chaincode, obtain the transaction status, and provide a plurality of REST APIs for obtaining the version of the BCS proxy. The REST proxy can authenticate REST calls and convert REST calls into GRPC calls. Also, the REST proxy can provide REST APIs that support functions similar to those provided by the BCS management console.

[0213] According to one embodiment, the REST proxy provides a user interface for the client application to consume the BCS instance.

[0214] FIG. 8 shows a system for providing a REST proxy in a BCS instance according to one embodiment.

[0215] As shown in FIG. 8, the REST proxy 138 can include a REST authentication tool 827 and a protocol conversion tool 829. When the BCS REST API client 808 sends a REST call 815 to the REST proxy, the LBaaS 126 connected to the cloud gate 811 can determine whether a valid username and a valid password that enable REST to access the BCS instance are included in the REST call by authenticating the REST call.

[0216] According to one embodiment, when authenticating a REST call, the LBaaS transfers the REST call to the REST proxy, the REST proxy transfers the REST call 835 to the IDCS 813, and the IDCS 813 can determine whether the client application is properly permitted by the BCS.

[0217] According to one embodiment, when the client application is properly permitted, the REST proxy can convert / transform the REST call into a gRPC call 825 and send the gRPC call to the fabric network 601. When the REST call is converted / transformed into an internal call (gRPC), it can interface with a blockchain fabric / hyperledger instance.

[0218] According to one embodiment, the REST call may be converted by a protocol conversion tool that can be a Java application based on the Fabric Java SDK 831 with a gRPC library 833.

[0219] Furthermore, as shown in FIG. 8, the REST proxy can expose one or more functions provided by the REST API 823 to the management console by communicating with the management console using REST 821, as described above.

[0220] Exemplary REST API According to one embodiment, it is necessary to start and operate the REST proxy before calling the REST API of the BCS instance. The status of the REST proxy can be checked via the management console. If the REST proxy is not started and not operating, it is necessary to operate the REST proxy from the management console.

[0221] According to one embodiment, by calling the REST API, it is possible to interact with the smart contract (chain code) placed on the peer nodes within the BCS instance. The deployment process can be achieved via the management console.

[0222] According to one embodiment, for illustrative purposes, an exemplary REST API is provided. The examples used in this specification assume that the following exemplary chain codes are deployed to the BCS network.

[0223]

Table 2

[0224] According to one embodiment, the illustration includes a management console. If the REST proxy is not started and not operating, the REST proxy can be operated from the management console.

[0225] According to one embodiment, by calling the REST API, it is possible to interact with the smart contract (chain code) placed on the peer nodes within the BCS instance. The deployment process can be achieved via the management console.

[0226] According to one embodiment, for illustrative purposes, an exemplary REST API is provided. The examples used in this specification assume that the following exemplary chaincodes are placed in the BCS network.

[0227] According to one embodiment, the REST API provides the following functions, namely, query via chaincode, call of transaction via chaincode, asynchronous call of transaction via chaincode, acquisition of transaction status, and acquisition of BCS gateway version. To execute these functions, the client accesses the BCS gateway using HTTPS and utilizes the message format according to the API.

[0228] According to one embodiment, the query function via chaincode executes the query operation by calling the chaincode. The chaincode and the query arguments are specified via the REST API. The REST API for acquiring the transaction status acquires the status of the transaction by querying the channel. The channel and the transaction ID are specified via the REST API. The REST API for acquiring the BCS gateway version returns the gateway version information.

[0229] According to one embodiment, the REST API for calling a transaction via chaincode executes the transaction by calling the chaincode. The chaincode and the call arguments are specified via the REST API. This REST API executes the transaction in synchronous mode. This means that it returns one of the following responses: a response indicating that the transaction is successful, a response indicating that the transaction has failed, or a response indicating that the transaction has timed out.

[0230] According to one embodiment, a REST API for asynchronous invocation of a transaction via a chaincode executes the transaction by invoking the chaincode. The chaincode and the arguments of the invocation are specified via the REST API. This REST API executes the transaction in asynchronous mode. This means that a response / approval is returned immediately after the transaction is submitted without waiting for the end or timeout of the transaction. The result is provided later. The BCS instance management REST API supports functions similar to those provided by the BCS console (described later). This means that a response / approval is returned immediately after the transaction is submitted without waiting for the end or timeout of the transaction. The result is provided later. The BCS instance management REST API supports functions similar to those provided by the BCS console (described later).

[0231] Fabric Certificate Authority (Fabric CA) integrated with Identity Cloud Service (IDCS) According to one embodiment, the Fabric CA server provides a Fabric membership service. The Fabric membership service includes the following three parts: authentication of users, permission to access the blockchain (peers and orderer groups), and a CA server for distributing certificates to application clients, peers, and orderers. The Fabric CA performs authentication and authorization using certificates. The certificates include two types: enrollment certificates for authentication and transaction certificates for authorization. Also, IDCS provides authentication and authorization. However, this authorization is implemented by OAuth. That is, when a peer wants to access an orderer, it obtains the user's access token from IDCS and uses this token to access the orderer.

[0232] According to one embodiment, the Fabric CA uses a database or LDAP to store information about registered users of the Fabric CA, such as the user's name / password, the user's certificate, and the user's affiliation. End-users of the public cloud (OPC) use one centralized IDCS instance for managing employees to access all public cloud (OPC) instances used by the employees. The blockchain cloud service BCS is preferably integrated with the IDCS used for other cloud services. Thus, end-users can use one centralized IDCS instance for managing employees to access all public cloud (OPC) instances (including BCS) used by the employees.

[0233] In one embodiment, the blockchain cloud service (BCS) uses an Oracle Identity Cloud Service (IDCS) to centrally store user information. The BCS stores the information of Fabric CA users in the IDCS. Thereby, the Oracle BCS can use the IDCS to manage the information of BCS users centralized across multiple public cloud service instances. Thus, in one embodiment, the information and certificates of BCS Fabric CA users are stored in the Oracle IDCS. The Fabric certificate authentication framework is a Fabric Membership Service Provider (MSP) that includes a PKI private key, a signed certificate, and a CA certificate chain, and is set by the Fabric CA client / server.

[0234] According to one embodiment, the BCS utilizes the OPC user management. First, the BCS user must be an OPC user (with an IDCS ID). When a BCS instance is created, several types of applications including the BCS console, CA, and REST proxy are created. The console has the following two application roles, namely, console administrator and console user. The CA has four application roles, namely, fabric administrator, fabric client, fabric peer, and fabric order. The REST proxy has two application roles, namely, gateway administrator and gateway user.

[0235] According to one embodiment, in order to make an OPC user a BCS user, it is necessary to assign specific BCS application roles to the OPC user in the OPC user management console.

[0236] When creating a BCS instance, the creator needs to provide an existing OPC user / password, and this user is automatically assigned the BCS console management role and the fabric management role. Therefore, this user becomes the BCS administrator.

[0237] In the case of authentication of the BCS console / CA / REST proxy, the authentication is performed at the cloud gateway. In the case of peer / order, the authentication is performed based on signatures. In the case of the BCS console, after authentication, the console obtains the application role of the current user (by calling IDCS). If this user is not assigned the role of console administrator or console user, the connection is rejected. Otherwise, the console performs access control based on predefined rules. For example, ordinary users can only read information, while administrators can do anything.

[0238] According to one embodiment, in the case of the CA, after authentication, the CA obtains the application role of the current user. If the user is not assigned a fabric role, the registration request is rejected.

[0239] According to one embodiment, in the case of the REST proxy, after authentication, the REST proxy obtains the application role of the current user. If the user is not assigned the gateway administrator or gateway user role, the request is rejected. Otherwise, the console performs access control based on predefined rules. For example, a normal user can make calls / queries, and an administrator can change settings and obtain metrics.

[0240] According to one embodiment, the Fabric CA server provides a Fabric membership service. The Fabric membership service includes the following three parts, namely, user authentication, permission to access the blockchain (peers and orderer groups), and a CA server that can distribute certificates to application clients, peers, and orderers.

[0241] According to one embodiment, the Fabric CA uses certificates to perform authentication and authorization. The certificates include the following two types, namely, a registration certificate for authentication and a transaction certificate for authorization.

[0242] According to one embodiment, IDCS also provides authentication and authorization. However, this authorization is implemented by OAuth. That is, when a peer wants to access an orderer, it obtains the user's access token from IDCS and uses this token to access the orderer.

[0243] FIG. 9A shows a typical IDCS usage case for single sign-on according to one embodiment.

[0244] According to one embodiment, in an initial step, a web application 901 can be added to an IDCS 902. Next, a client such as a web browser 900 can request authentication (e.g., username and password) from the web application. Since the web application has already been added to the IDCS, the web application can instruct the web browser to send an authentication request to the IDCS. After receiving a response from the web application, the web browser can request authentication (e.g., username and password) from the IDCS.

[0245] Next, the IDCS can authenticate the request and, if the authentication is successful, return a token to the web browser. The web browser that has been authenticated and received the token can send a request to the web application. The web application can verify the token and inform the web browser that the authentication has been successful.

[0246] In the case of the scenario shown in FIG. 9A, the IDCS functions as an Identity Provider (IdP) that provides a service for identifying applications. All communication between all participants is based on HTTP. This use case is configuration-driven but is only applicable to HTTP-based applications.

[0247] FIG. 9B shows an IDCS usage case for fabric client authentication according to one embodiment.

[0248] According to one embodiment, a Fabric client 904 associated with a Fabric user whose (user's private key and certificate have already been stored in the client - side state store) has already been registered and enrolled can request a new client and can obtain the user information (user name) of the client. The Fabric SDK 905 can load the user from the state store and return a user object to the Fabric client. When the client receives the user object, it can send a transaction proposal to the Fabric SDK, and the Fabric SDK can sign the proposal using the same private key. Then, the signed proposal is sent to the peer 906, and the peer 906 can verify the signature using the membership service 907. The membership service can obtain the user's certificate from the IDCS 902 and can verify the user's signature using the certificate from the IDCS. Then, the membership service can return a proof that the signature has been verified to the peer.

[0249] Support for SQL - based rich queries in Hyperledger Fabric blockchain According to one embodiment, the system and method can support a relational engine for storing the world state of the blockchain. Calculating the Merkle tree stored in the transaction payload using SQL to query key / value pairs and verify the results at commit time.

[0250] According to one embodiment, the systems and methods described herein can create complex smart contracts in an easier and more manageable way by executing SQL queries. Also, performance can be improved by returning data selection to the storage engine (instead of executing at the smart contract level) and depending on a relational engine that supports concurrent read and write access to data.

[0251] FIG. 10 shows a system for supporting the state of a world database in a fabric blockchain, according to one embodiment.

[0252] According to one embodiment, the state of the world database 1000 can include a versioned database provider 1005 and a versioned database 1010. In a typical Hyperledger Fabric blockchain and other blockchain fabrics, the state of the world database includes a key / value pair database. That is, all "values" within the database are paired with a "key" used to retrieve this value.

[0253] According to one embodiment, the world state updates the version in response to all transactions that change the blockchain. The access to the state of the world database The session is controlled by the transaction manager 1015. That is, the transaction manager adjusts the write / read speed according to the state of the world database. The verification tool 1020 is an entity for verifying that data still matches when, for example, a smart contract attempts to commit a transaction. The execution of a transaction is divided between endorsement (e.g., execution) and verification (commitment). Execution (endorsement) is a simulation of what the transaction will be like if the transaction is committed, and this is part of the transaction that accesses the state of the world database. Verification is performed after commitment. A transaction collects multiple endorsements by executing chain codes on multiple nodes. When a transaction has collected sufficient endorsements to satisfy the policy on the ledger that the transaction attempts to update, it moves to the commit phase. Generally, there is a certain period between the two phases of a transaction. Verification takes in information from the endorsements and verifies that the information is still valid. If all the information is still valid, the transaction is committed and the world state is updated.

[0254] According to one embodiment, several operations 1030 can be executed in relation to the state of the world database. These operations include, but are not limited to, getting the state (GetState), getting multiple keys of the state (GetStateMultipleKey), getting the state range (GetStateRange), executing a query (ExecuteQuery), getting the latest savepoint (GetLatestSavepoint), and applying updates (ApplyUpdates). Similarly, several operations 1035 can be executed in relation to the transaction manager. These operations include, but are not limited to, the simulator (Simulator), query execution (QueryExecutor), validation and preparation (ValidateAndPrepare), and commit (Commit).

[0255] As an example, the state of the world database can indicate the current balance of bitcoins of all users. This current balance is a snapshot that matches the current state of the world database.

[0256] According to one embodiment, in a hyperledger, the state of the world database is incorporated into a persistence engine. This engine cannot be accessed externally but can be accessed internally by the blockchain. Smart contracts (transactions) within the blockchain can access the state of the world database.

[0257] According to one embodiment, for example, a smart contract may be written to transfer a certain amount of money from Party A to Party B over a certain period. Also, the smart contract may be written to ensure that Party B meets some condition, such as transferring the right to property to Party A, before the money is transferred. Further, the smart contract may be written to ensure that Party A has received the right before transferring funds from Party A to Party B.

[0258] According to one embodiment, the smart contract depends on the state of the world database. The smart contract can examine the current balance of account A, the current balance of account B, and the current rights of the property to be transferred. This information is obtained by checking the state of the world database. The smart contract is a stored procedure. The underlying data may be a set of underlying tables to be accessed.

[0259] According to one embodiment, the state of the world database is stored in a high-speed key-value store. Such a database operates to associate a value with a key when the label (key) is given. For example, the balance can be associated with a key. As another example, a photo (bitmap) can be associated with a key. Generally, such a persistence engine is very fast. However, according to one embodiment, since the system only supports a search mechanism, there are limitations to such a persistence engine. Such a persistence engine cannot provide rich queries such as comparisons between multiple values, for example. For example, a key-value persistence engine cannot process a query that requests the name of the account with the highest balance among 10,000 different accounts. Also, such a persistence engine cannot perform functions on values stored internally, such as the maximum value, minimum value, or average value. For example, a key-value persistence engine cannot provide the average balance of a user over a period of X months in response to a query. Instead, the script or smart contract has to be written to extract each value from the key-value pair and then execute a query on each of the extracted values. Due to these limitations of the key-value persistence engine, writing a smart contract is very difficult because the smart contract has to cope with the inherent limitations of the key-value store.

[0260]

[0261] ​Also, according to one embodiment, the key-value persistence engine cannot execute read transactions and write transactions simultaneously. During a read transaction, write operations are appropriately locked during reading so that the value does not change. Similarly, during a write operation, read operations are appropriately locked so that the value to be written is not accidentally read. Such read locks and write locks are a further limitation of conventional key-value store persistence engines.

[0262] According to one embodiment, the system and method can provide a relational database or other persistence engine that enables rich queries (e.g., SQL) instead of a key-value persistence engine.

[0263] According to one embodiment, providing access to a relational database in a blockchain fabric such as Hyperledger Fabric enables users and smart contracts to go beyond the limitations of key-value stores. Such databases can support MVCC (Multi-Version Concurrency Control), snapshots (enabling the creation of a snapshot of the data without the user / operation aborting the write to the database). This can enhance performance and operability and simplify the coding / writing of smart contracts and other transaction processes that need to query the persistence engine.

[0264] FIG. 11 shows a system for supporting SQL-based rich queries in a blockchain fabric according to one embodiment.

[0265] According to one embodiment, a system for supporting SQL-based rich queries in a blockchain fabric can include a state of a world database 1100 that can include a relational database interface 1102, a versioned database provider 1105, and a versioned database 1110. Also, a transaction manager 1115 and a verification tool 1120 can be provided. Similar to conventional systems, the state of the world interface, the transaction manager, and the verification engine are each updated.

[0266] According to one embodiment, the transaction manager and the verification engine (e.g., verification tool 112) are built against the same interface supported by Hyperledger Fabric but internally rely on the creation and commit of relational transactions. Similarly, the versioned database provider and the versioned database include a versioned database recognized by the transaction. This is similar to a versioned database but is saved per transaction. This allows transactions to be created in read / write mode, and the database can handle such situations internally without the need to lock read / write.

[0267] Also, according to one embodiment, a relational database interface 1102 is provided. The interface can include an abstraction that allows a user (e.g., a smart contract) to plug in a desired relational engine. By way of example, it includes Oracle, SQL, or any other database that supports SQL and transactions (e.g., SQLite). In one embodiment, it supports Berkeley DB, which enables a relational layer that allows a contract to interact with a versioned database in a relational manner. According to one embodiment, Berkeley DB It is an embedded database that can improve performance.

[0268] According to one embodiment, the transaction manager can recognize database transactions, unlike the lock approach used in databases such as LevelDB and / or CouchDB.

[0269] According to one embodiment, each channel can share a similar versioned database (e.g., SQLite). Each database contains a number of tables, and each table is mapped to a versioned database (e.g., Berkeley DB). The BDB can be configured to persist multiple databases as one file on the file system.

[0270] According to one embodiment, a channel can share one table (channel_height) that contains the current height / save point of all channels. The table has four columns including a key, a value, a block number, and a transaction number. The key describes the channel name. The block number and the transaction number describe the current height of the channel.

[0271] According to one embodiment, each channel is also associated with a "state" table of each (system and user) chain code instantiated on that channel. The table name is <channel name>_<chain code name>. The table has five columns including a key, a value, a Json value, a block number, and a transaction number. The "key" is the name of the key set in the world state. The "value" is the value of the key when it cannot be parsed as a valid Json value. The "Json value" is the value of the key when it can be parsed as a valid Json value. The "block number" and the "transaction number" represent the height corresponding to the stored key.

[0272] According to one embodiment, the table is created as soon as the channel is created and the chain code is deployed.

[0273] According to one embodiment, executing a rich query against the world state of a BDB is performed by a chain code using a shim API. The representation specified in the query result retrieval function (GetQueryResult()) may be a valid SQL SELECT representation.

[0274] According to one embodiment, the specified SQL SELECT representation is not restricted as long as the table that can be accessed by the representation represents the state of the world database of the channel / chain code combination to which the currently executing chain code is bound.

[0275] According to one embodiment, the user does not need to know the internal name used to represent the state of the world database associated with a particular channel / chain code pair. Instead, the user refers to the table name using the placeholder "STATE" (case-insensitive). For example, SELECT * FROM <state>The expression "WHERE key = 'key1'" (the keywords within the SQL expression are case-insensitive) searches for the value associated with "key1".

[0276] According to one embodiment, an attempt to execute a rich query that is not a selection expression, or an attempt to access a table other than the table associated with the channel / chaincode bound to the currently executing chaincode, returns an error.

[0277] According to one embodiment, similar to the fabric that supports queries executed against the CouchDB, the result is returned by the query result retrieval function (GetQueryResult()). This result is an iterator where each iteration executed contains a key and a Json payload. In the case of a BDB rich query result, the key name may be in the form of "_sqlresult_X" (X is the zero-based index of the returned iteration). The Json payload is the Json-formatted version of the result set returned by the query iteration. In other words, it is a json map where each attribute name corresponds to each column name in the returned SQL result set, and each attribute value corresponds to the returned value of the column in the current iteration.

[0278] According to one embodiment, an example of iterating through all the returned marble IDs of a given color (error handling omitted) is provided below.

[0279] [Number]

[0280] According to one embodiment, the system and method can perform a complete verification of rich query results at commit time. At endorsement time, a Merkle tree is calculated for all the results consumed from the GetQueryresult() call and stored along with all SQL expressions as part of the transaction payload. At commit time, the SQL expressions associated with the rich query executed at endorsement time are re-executed, and the Merkle tree hash is incrementally checked against the Merkle tree hash calculated at endorsement time. The verification tool consumes the query results until it reaches an index similar to the index consumed at endorsement time or until the iterator is exhausted. If the Merkle tree hashes match and the exhaustion state of the iterator matches at the end of the query, the rich query is valid. Otherwise, a flag indicating invalid due to a phantom read error is attached to the transaction.

[0281] According to one embodiment, BDB supports MVCC (Multi-Version Concurrency Control) and the snapshot isolation level of transactions. Thus, the system and method can utilize this capability to execute concurrent read / write transactions.

[0282] FIG. 12 is a flowchart showing a method for supporting SQL-based rich queries in a blockchain fabric according to one embodiment.

[0283] In step 1201, the method can provide an enterprise-class distributed ledger framework in one or more computers including a microprocessor.

[0284] In step 1202, the method can execute a distributed ledger fabric in the distributed ledger framework, and the distributed ledger fabric includes at least a transaction manager and a verification tool.

[0285] In step 1203, the method can associate the state of the world database with the distributed ledger, where the state of the world database includes a versioned database and a relational database interface.

[0286] Although various embodiments have been described above, these embodiments are presented by way of example and do not limit the present disclosure. These embodiments are selected and described to illustrate the features, principles, and practical applications of the present disclosure. The embodiments illustrate systems and methods. These embodiments improve the performance of the systems and methods using various features by providing new and / or improved functions and / or by providing performance advantages including, but not limited to, a reduction in resource utilization, an increase in capacity, an increase in throughput, an improvement in efficiency, a reduction in latency, an enhancement of security, and / or an improvement in ease of use.

[0287] In this specification, some embodiments are described with reference to flowcharts and / or block diagrams of methods showing architecture, functionality, process, and / or operation, apparatus (systems), and computer program products. Each block of the flowchart or block diagram represents an element, function, process, module, segment, or portion of one or more executable instructions for implementing the specified function. In some alternative embodiments, the functions shown in the block diagram or flowchart are executed in an order different from the order shown. For example, two blocks shown in succession may be executed substantially simultaneously, depending on the functions involved, or in the reverse order. Each block of the flowchart and / or block diagram, or a combination of blocks of the flowchart and / or block diagrams may be implemented by computer program instructions for performing the specified functions, and / or by dedicated hardware, and / or by a combination of hardware and computer program instructions.

[0288] In some embodiments, the feature is implemented on a computer that includes a processor, a computer-readable medium, and a network card / interface for communicating with other computers.

[0289] In some embodiments, the feature is implemented in a network computing environment that includes a computing system comprising various types of computer configurations, including personal computers, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, etc., interconnected by a network. The network may be a local area network (LAN), a switch fabric network (e.g., InfiniBand), a wide area network (WAN), and / or the Internet. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers.

[0290] In some embodiments, the features are implemented in a computing system that includes a back-end component (e.g., a data server), or a middleware component (e.g., an application server), or a front-end component (e.g., a client computer having a graphical user interface or a web browser that a user uses when interacting with an implementation of the subject matter described herein), or a computing system that includes any combination of back-end components, middleware components, or front-end components interconnected by a network. The computing system can include clients and servers that have a client-server relationship with each other. In some embodiments, the functionality is implemented in a computing system that includes a distributed computing environment comprising one or more computer clusters connected via a network. All computers within the distributed computing environment may be located in a single location or may be located as computer clusters in different remote locations connected by a network.

[0291] In some embodiments, the feature is implemented in the cloud as part of or as a service of a cloud computing system distributed to users by a self-service provisioning method based on elastic resources shared using web technologies. The characteristics of the cloud may include, for example, on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Cloud deployment models include public, private, and hybrid. Cloud service models include SaaS (Software as a Service), PaaS (Platform as a Service), DBaaS (Database as a Service), and IaaS (Infrastructure as a Service). A cloud generally refers to a combination of hardware, software, network, and web technologies that distribute shared elastic resources to users. The cloud as used herein can include public cloud, private cloud, and / or hybrid cloud implementations, and can include cloud SaaS, cloud DBaaS, cloud PaaS, and / or cloud IaaS deployment models.

[0292] In some embodiments, the feature is hardware, software, firmware 、or a combination thereof. In some embodiments, the feature is implemented using one or more processors configured or programmed to perform one or more functions of the taught approach. In some embodiments, the processor is a single-chip or multi-chip processor, a digital signal processor (DSP), a system-on-chip (SOC), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a state machine, discrete gates or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. In some implementations, the feature is implemented by a circuit having a specific function. In other implementations, the feature is implemented in a computer, computing system, processor, and / or network configured to perform a specific function using, for example, instructions stored on a computer-readable storage medium.

[0293] In some embodiments, the feature is incorporated into software and / or firmware for controlling the hardware of a processing system and / or network system using the features of the present disclosure, or software and / or firmware for enabling interaction between a processor and / or network and other systems. Such software or firmware may include, but is not limited to, application code, device drivers, operating systems, virtual machines, hypervisors, application programming interfaces, programming languages, and execution environments / containers. Appropriate software coding can be readily created by a skilled programmer based on the teachings of the present disclosure.

[0294] In some embodiments, the approaches taught by this disclosure include a computer program product that is a machine-readable or computer-readable medium storing or carrying instructions that include software and / or firmware. Using these instructions, a system such as a computer can be programmed or configured to perform the processes or functions of the approaches taught by this disclosure. The machine-readable or computer-readable medium can include any type of medium or device suitable for storing instructions and / or data, including but not limited to floppy (registered trademark) disks, hard drives, solid state drives, optical disks, DVDs, CD-ROMs, microdrives, magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, molecular memories, nanosystems, or variants and combinations thereof. In certain embodiments, the storage medium or computer-readable medium is a non-transitory machine-readable storage medium or non-transitory computer-readable storage medium. Also, the machine-readable medium or computer-readable medium may include a transient medium such as a carrier wave or a transmitted signal.

[0295] Accordingly, in one aspect, this specification describes systems and methods for supporting SQL-based rich queries in a blockchain fabric. According to one embodiment, the systems and methods described herein can create complex smart contracts in an easier and more manageable way by executing SQL queries. Also, performance can be improved by returning data selection back to the storage engine (instead of performing it at the smart contract level) and relying on a relational engine that supports concurrent read and write access to data. Also, the state of the world database can provide concurrent read / write access.

[0296] Further examples of the disclosure are described in the following numbered clauses. Clause 1 A system for supporting SQL-based rich queries in a blockchain fabric, an enterprise-class distributed ledger framework, and a distributed ledger fabric, the distributed ledger fabric including at least a transaction manager and a verification tool, comprising a state of a world database, the state of the world database including a versioned database and a relational database interface.

[0297] Item 2 The system according to item 1, wherein the relational database interface provides a relational database interface layer between the versioned database and one or more transactions executed on the distributed ledger fabric.

[0298] Item 3 The system according to item 2, wherein at least one of the one or more transactions includes at least one rich query.

[0299] Item 4 The system according to item 3, wherein at least one rich query accesses the versioned database via the relational database interface.

[0300] Item 5 The system according to item 2 or item 3, wherein at least one rich query includes a chain code.

[0301] Item 6 The system according to item 3, wherein the state of the upper world database provides concurrent read / write access.

[0302] Item 7 The distributed ledger fabric is provided as a blockchain cloud service, and the blockchain cloud service A peer container, an ordering container, and a chaincode container, the system according to any one of claims 1 to 6.

[0303] Claim 8 A method for supporting SQL-based rich queries in a blockchain fabric, providing an enterprise-class distributed ledger framework in one or more computers including a microprocessor; executing a distributed ledger fabric in the distributed ledger framework, the distributed ledger fabric including at least a transaction manager and a verification tool; associating a state of a world database with the distributed ledger fabric, the state of the world database including a versioned database and a relational database interface.

[0304] Claim 9 The method according to claim 8, wherein the relational database interface provides a relational database interface layer between the versioned database and one or more transactions executed on the distributed ledger fabric.

[0305] Claim 10 The method according to claim 9, wherein at least one of the one or more transactions includes at least one rich query.

[0306] Claim 11 The method according to claim 10, wherein at least one rich query accesses the versioned database via the relational database interface.

[0307] Claim 12 The method according to claim 9, 10 or 11, wherein the state of the world database provides concurrent read / write access.

[0308] Claim 13 The method according to claim 10 or any claim dependent thereon, wherein at least one rich query comprises a chain code.

[0309] Claim 14 The distributed ledger fabric is provided as a blockchain cloud service, The blockchain cloud service a peer container, an ordering container, and a chain code container, the method according to any one of claims 8 to 13.

[0310] Claim 15 A computer-readable medium carrying instructions for supporting SQL-based rich queries in a blockchain fabric, which instructions, when read and executed, cause one or more computers to perform steps including: providing an enterprise-class distributed ledger framework in one or more computers including a microprocessor; executing a distributed ledger fabric in the distributed ledger framework, the distributed ledger fabric including at least a transaction manager and a verification tool; associating a state of a world database with the distributed ledger fabric, the state of the world database including a versioned database and a relational database interface.

[0311] Claim 16 The computer-readable medium according to claim 15, wherein the relational database interface provides a relational database interface layer between the versioned database and one or more transactions executed on the distributed ledger fabric.

[0312] Item 17 At least one of the one or more transactions is at least one rich que ry, and the computer-readable medium according to claim 16.

[0313] Item 18 The computer-readable medium according to claim 17, wherein at least one rich query accesses a versioned database via a relational database interface.

[0314] Item 19 The computer-readable medium according to claim 16, 17, or 18, wherein the state of the world database provides concurrent read / write access.

[0315] Item 20 The distributed ledger fabric is provided as a blockchain cloud service, and the blockchain cloud service includes peer containers, ordering containers, and chaincode containers, and the computer-readable medium according to any one of claims 15 to 19.

[0316] The above description is not intended to be exhaustive or to limit the disclosure to the exact forms disclosed. Also, while embodiments have been described using a particular set of transactions and steps, it will be apparent to those skilled in the art that the execution of additional transactions and steps is not excluded unless specified otherwise. Further, in various embodiments, particular combinations of features are described, but it will be apparent to those skilled in the art that different combinations of features are within the scope of the disclosure. In particular, features (such as of an apparatus or method) described in a particular embodiment, variation, or drawing can be combined with or replaced by other features described in another embodiment, variation, or drawing without departing from the teachings and scope. Moreover, it will be apparent to those skilled in the art that various additional, subtractive, deletion, modification, replacement of elements by equivalents, and other modifications and changes in form, detail, implementation, and use can be made without departing from the spirit and scope of the disclosure. The broader spirit and scope of protection are defined by the following claims and their equivalents.< / state>

Claims

1. 1. A system for supporting SQL-based rich queries in a blockchain fabric, comprising: one or more computers, each containing a microprocessor; a blockchain fabric, the blockchain fabric including a ledger of a plurality of blocks; The system comprises: A state of a world database, the state of the world database being captured by a persistence engine operating on the blockchain fabric, the state of the world database including a versioned database and a relational database interface; a smart contract including at least one SQL-based rich query is executed against the state of the world database via the relational database interface; The at least one SQL-based rich query includes a query that includes a data filtering step performed by a storage engine.

2. The system of claim 1 , wherein the at least one SQL-based rich query performs a comparison between a plurality of values ​​contained in the state of the world database.

3. 3. The system of claim 1 or 2, wherein the versioned database comprises a transaction-aware database providing transactions of the smart contract executed in a concurrent read or write mode.

4. The system of claim 3 , wherein the state of the world database is accessible by the blockchain fabric.

5. The system of claim 3 or 4, wherein the relational database interface provides a relational database interface layer between the versioned database of the state of the world database and at least one rich query.

6. The system of any one of claims 1 to 5, wherein the state of the world database provides for concurrent read or write access.

7. The blockchain fabric is provided as a distributed ledger fabric; The distributed ledger fabric is provided as a blockchain cloud service; The blockchain cloud service is A peer container; An ordering container; The system of any one of claims 1 to 6, further comprising a chaincode container.

8. 1. A method for supporting SQL-based rich queries in a blockchain fabric, comprising: providing a blockchain fabric in one or more computers, each computer including a microprocessor, the blockchain fabric including a ledger of a plurality of blocks; providing a state of a world database, the state of the world database being populated by a persistence engine operating on the blockchain fabric, the state of the world database including a versioned database and a relational database interface; executing a smart contract including at least one SQL-based rich query against the state of the world database via the relational database interface, the at least one SQL-based rich query including a query including a data filtering step performed by a storage engine.

9. The method of claim 8 , wherein the at least one SQL-based rich query performs a comparison between a plurality of values ​​contained in the state of the world database.

10. 10. The method of claim 8 or 9, wherein the versioned database comprises a transaction-aware database providing transactions of the smart contract executed in a concurrent read or write mode.

11. The method of claim 10 , wherein the state of the world database is accessible by the blockchain fabric.

12. The method of claim 10 or 11, wherein the relational database interface provides a relational database interface layer between the versioned database of the state of the world database and the at least one rich query.

13. A method according to any one of claims 8 to 12, wherein the state of the world database provides for concurrent read or write access.

14. The blockchain fabric is provided as a distributed ledger fabric; The distributed ledger fabric is provided as a blockchain cloud service; The blockchain cloud service is A peer container; An ordering container; A chaincode container.

15. A program executed by a computer, the program causing the computer to execute the method according to any one of claims 8 to 14.

Images