System and method for supporting SQL-based rich queries in a Hyperledger Architecture blockchain

Abstract

Systems and methods for supporting rich SQL-based queries in a blockchain architecture are described herein. According to an embodiment, the systems and methods provided herein provide the ability to execute SQL queries to allow complex smart contracts to be created in an easier and more maintainable manner. In addition, performance is improved by pushing data filtering back to the storage engine (rather than happening at the smart contract level) and by being able to rely on a relational engine that supports concurrent read and write data access. Similarly, the world state database can also provide concurrent read / write access.

Description

[0001] Copyright Notice

[0002] A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

[0003] Priority claim:

[0004] This application claims the benefit of priority to U.S. Patent Application No. 16 / 261,363, filed on January 29, 2019, entitled “SYSTEM AND METHOD FORSUPPORTING SQL-BASED RICH QUERIES IN HYPERLEDGER FABRIC BLOCKCHAINS,” and U.S. Provisional Patent Application No. 62 / 711,385, filed on July 27, 2018, entitled “SYSTEM AND METHOD FORSUPPORTING SQL-BASED RICH QUERIES IN HYPERLEDGER FABRIC BLOCKCHAINS,” each of which is incorporated herein by reference. Technical Field

[0005] The present disclosure generally relates to systems and methods for providing distributed ledgers. More particularly, the present disclosure describes systems, methods, and components thereof for supporting SQL-based (or SQL-like) rich queries in distributed permissioned ledgers such as Hyperledger Architecture blockchains. Background Art

[0006] A distributed ledger can be broadly described as a digital record of asset ownership. There is neither a central administrator of the ledger nor a central data repository. Instead, the ledger is replicated across many participating nodes in a computing environment that may be geographically distributed across multiple sites, countries, or institutions. A consensus protocol ensures that each node's copy of the ledger is identical to every other node's copy. As such, the group of copies can be treated as a single shared ledger. Asset owners can use cryptographic signature techniques to use the distributed ledger, for example, to debit their accounts and credit the accounts of others.

[0007] A blockchain is a data architecture that can be used to implement a tamper-proof distributed ledger. Multiple nodes follow a common protocol where transactions from clients are packaged into blocks, and the nodes use a consensus protocol to agree on the next block. Blocks carry cumulative cryptographic hashes, making it difficult to tamper with the ledger. Each block can have a reference [hash value] to the previous block in time. In addition, each block can include its own hash. The blockchain can be traversed backwards (e.g., traversing up the chain).

[0008] Permissionless decentralized ledgers allow anonymous participants to maintain the ledger while avoiding control by any single entity. However, given the anonymity, identity, accountability, and auditability are difficult. In contrast, permissioned decentralized ledgers allow for levels of trust and accountability by allowing explicitly authorized parties to maintain the ledger. Permissioned ledgers support more flexible governance and more choices for consensus mechanisms. Both decentralized ledgers may be susceptible to manipulation by participants who prefer some transactions over others. However, accountability based on permissioned ledgers provides the opportunity to impose constraints on participants. Summary of the invention

[0009] According to an embodiment, a system and method for supporting SQL-based rich queries in a Hyperledger Fabric blockchain is described herein.

[0010] Systems and methods for supporting rich SQL-based queries in a blockchain architecture are described herein. According to an embodiment, the systems and methods provided herein provide the ability to execute SQL queries to allow complex smart contracts to be created in an easier and more maintainable manner. In addition, performance is improved by pushing data filtering back to the storage engine (rather than happening at the smart contract level) and by being able to rely on a relational engine that supports concurrent read and write data access. Similarly, the world state database can also provide concurrent read / write access.

[0011] These and other advantages of the present teachings will become apparent to those skilled in the art from the following description of the various embodiments, when read with reference to the accompanying figures.

[0012] The Hyperledger Project is a collaborative effort established as a project of the Linux Foundation to create an enterprise-grade, open-source distributed ledger framework and code base. The Hyperledger Framework is an implementation of a distributed ledger platform for running smart contracts. It uses container technology to host smart contracts called "chaincodes" that contain the application logic of the system.

[0013] According to an embodiment, participants in the hyperledger have copied copies of the ledger. In addition to sharing ledger information, the process of updating the ledger is also shared. Unlike other systems that use participants' private programs to update associated private ledgers, blockchain systems have shared programs to update shared ledgers. By leveraging the ability to coordinate its business network through a shared ledger, the blockchain network can reduce the time, cost, and risk associated with the distribution of private information to the ledger, and reduce processing time (while increasing trust). The hyperledger architecture is private and permissioned. Members of the hyperledger architecture network are registered. The hyperledger architecture also provides the ability to create channels. Each channel can contain a separate transaction ledger visible to a specific group of participants. This allows transaction privacy.

[0014] According to an embodiment, the distributed ledger protocol of the architecture is run by peers. The architecture distinguishes two types of peers: a validating peer is a node on the network responsible for running consensus, validating transactions, and maintaining the ledger. On the other hand, a non-validating peer is a node used as a proxy to connect a client (issuing a transaction) to a validating peer. A non-validating peer does not execute transactions, but it can verify them. Some features of the architecture include a licensed blockchain with immediate finality that runs an arbitrary smart contract called a chain code. User-defined chain code smart contracts are encapsulated in containers, and system chain codes run in the same process as peers. The process of keeping ledger transactions synchronized across the network (e.g., to ensure that the ledger is updated only when the transaction is approved by the appropriate participants, and when the ledger is indeed updated, they will update the same transaction in the same order) can be called consensus. The architecture implements consensus protocols and security by supporting certificate authorities (CAs) for TLS (transport layer security) certificates, registration certificates, and transaction certificates.

[0015] According to an embodiment, the Hyperledger architecture may include a world state database. This database is typically a key-value store. The world state is stored in a very fast key-value store. Given a tag (key), a value is associated with the key. For example, a key-value database may associate a balance with a key, or may associate a picture with a key, and so on. This is a very fast persistence engine.

[0016] According to an embodiment, smart contracts in the Hyperledger Fabric blockchain have access only to very basic value lookup and data filtering mechanisms; this makes smart contracts cumbersome to create, difficult to maintain, and often perform poorly.

[0017] Furthermore, according to an embodiment, the underlying persistent storage engine supported only works with systems such as LevelDB and CouchDB that do not support concurrent R / W access - forcing the blockchain to be locked for read access (commit) while endorsement operations (transaction execution) are running. This has a direct and negative impact on performance, especially when executing smart contracts whose execution requires a lot of computational work. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1A The diagram illustrates a transaction flow in the architecture of a blockchain cloud service system according to an embodiment.

[0019] Figure 1B The diagram illustrates a blockchain cloud service system according to an embodiment.

[0020] Figure 1C A BCS system according to an embodiment is illustrated.

[0021] Figure 1D A BCS system according to an embodiment is illustrated.

[0022] Figure 2 A gateway for a blockchain cloud service system according to an embodiment is illustrated.

[0023] Figure 3 The persistence of the blockchain cloud service system according to an embodiment is illustrated.

[0024] Figure 4 The diagram shows an example deployment of the architecture on BCS.

[0025] Figure 5 A chain code architecture according to an embodiment is illustrated.

[0026] Figure 6 A system for providing a management console according to an embodiment is illustrated.

[0027] Fig. 7A An example of a user interface in a BCS console UI according to an embodiment is illustrated.

[0028] Figure 7B An example of a user interface in a BCS console UI according to an embodiment is illustrated.

[0029] Figure 8 A system for providing a REST proxy in a BCS instance according to an embodiment is illustrated.

[0030] Fig.9A A typical IDCS use case for single sign-on according to an embodiment is shown.

[0031] Fig. 9BAn IDCS use case for fabric client authentication according to an embodiment is shown.

[0032] Fig.10 A system for supporting a world state database in an architecture blockchain according to an embodiment is shown.

[0033] Fig.11 A system for supporting SQL-based rich queries in a blockchain architecture according to an embodiment is shown.

[0034] Fig.12 is a flowchart of a method for supporting SQL-based rich queries in a blockchain architecture according to an embodiment. DETAILED DESCRIPTION

[0035] According to an embodiment, systems and methods for supporting SQL-based rich queries in a blockchain architecture are described herein. According to an embodiment, the systems and methods provided herein provide the ability to execute SQL queries to allow complex smart contracts to be created in an easier and more maintainable manner. In addition, performance is improved by pushing data filtering back to the storage engine (rather than happening at the smart contract level) and by being able to rely on a relational engine that supports concurrent read and write data access. Similarly, the world state database can also provide concurrent read / write access.

[0036] According to an embodiment, an example blockchain architecture that supports rich SQL-based queries in the blockchain architecture may be provided as a cloud service. According to an embodiment, the enterprise-level framework includes scalability, management, configuration, persistence, and compatibility with various customer applications by using cloud technology. In a specific embodiment, a permissioned blockchain ledger and blockchain architecture are provided as a blockchain cloud service (BCS).

[0037] In the following description, this aspect will be illustrated in the various figures of the accompanying drawings by way of example and not limitation. References to various embodiments in the present disclosure are not necessarily to the same embodiment, and such references mean at least one. Although specific implementations have been discussed, it should be understood that this is provided for illustrative purposes only. Those skilled in the relevant art will recognize that other components and configurations may be used without departing from the scope and spirit of the present disclosure. The description of this teaching provides examples and embodiments of the methods claimed for support and disclosure.

[0038] Furthermore, in some cases, numerous specific details are set forth to provide a thorough description of the present teachings. However, it will be apparent to those skilled in the art that the results and advantages of the methods of the present teachings can be achieved, and the concepts of the present teachings can be practiced without these specific details. In other instances, well-known features are not described in as much detail as possible to avoid obscuring the present disclosure.

[0039] The present teaching is described by means of functional building blocks that illustrate the performance of specific functions and their relationships. For ease of description, the boundaries of these functional building blocks are generally arbitrarily defined in this article. Therefore, in alternative embodiments, the functions shown to be performed by the same element can be performed by different elements. The functions shown to be performed in separate elements can be combined into one element instead. Alternative boundaries can be defined as long as the specified functions and their relationships are properly performed. Therefore, any such alternative boundaries are within the scope and spirit of the present disclosure.

[0040] Throughout the drawings and detailed description, common reference numerals are used to refer to like elements; thus, a reference numeral used in a figure may or may not be referenced in the detailed description specific to that figure if the element is described elsewhere.

[0041] Blockchain technology has the potential to significantly enhance enterprise business value by enabling near real-time distributed transactions across customer ecosystems and by enabling secure, tamper-proof data sharing. The Hyperledger Architecture blockchain includes modular architecture, horizontal / cross-industry technology support, and support for enterprise needs.

[0042] introduce

[0043] According to an embodiment, the Hyperledger Architecture is a platform for distributed ledger solutions, which is supported by a modular architecture, providing high confidentiality, resilience, flexibility and scalability. It is designed to support pluggable implementations of different components and adapt to the complexity and complexity that exists across economic ecosystems.

[0044] According to an embodiment, the Hyperledger framework provides a resilient and scalable architecture, distinguishing it from alternative blockchain solutions.

[0045] Blockchain — Distributed Ledger

[0046] According to an embodiment, a blockchain network may include a distributed ledger that records all transactions that occur on the network.

[0047] A blockchain ledger is often described as decentralized because it is replicated to many network participants, each of whom collaborates in maintaining the blockchain ledger. Decentralization and collaboration are attributes that reflect the way businesses exchange goods and services in the real world.

[0048] In addition to being decentralized and collaborative, information recorded to the blockchain is append-only, using cryptographic techniques that guarantee that once a transaction has been added to the ledger it cannot be modified. This immutability property makes it simple to determine the provenance of information, as participants can be sure that the information has not been altered after the fact. In this way, blockchains can be thought of as systems of proof.

[0049] Blockchain — Smart Contracts

[0050] According to an embodiment, to support consistent updates of information—as well as enable certain ledger functions (transactions, queries, etc.)—the blockchain network uses smart contracts to provide controlled access to the ledger.

[0051] According to an embodiment, smart contracts are not only a key mechanism for encapsulating information and keeping it simple on the network, they can also be written to allow participants to automatically execute certain aspects of a transaction.

[0052] A smart contract could, for example, be written to specify the cost of shipping an item, which varies depending on when the item arrives. When the item is received, the appropriate funds automatically change hands, according to the terms agreed to by both parties and written into the ledger.

[0053] Blockchain — Consensus

[0054] According to embodiments, the process of keeping ledger transactions synchronized across the network—to ensure that ledgers are updated only when transactions are approved by the appropriate participants, and that when ledgers do update, they update the same transactions in the same order—can be referred to as consensus.

[0055] According to an embodiment, a blockchain can be thought of as a shared, replicated transaction system that is updated via smart contracts and kept in sync through a collaborative process called consensus.

[0056] Advantages of blockchain

[0057] According to an embodiment, the currently available trading network is a version of the network that has existed since business records have been kept. Members of the business network trade with each other, but each member maintains a separate record of their transactions. Likewise, objects traded can establish the origin of these objects each time they are sold to ensure that the business selling the item has a chain of title verifying the business's ownership of the item.

[0058] While current business networks are modernized by computing systems, no unified system exists for managing the identities of network participants, establishing provenance is laborious as clearing securities trades (whose volume is measured in trillions of dollars worldwide) takes days, contracts must be signed and executed manually, and every database in the system contains unique information and therefore represents a single point of failure.

[0059] According to an embodiment, blockchain provides an alternative to the many inefficiencies represented by standard transaction systems by providing a standard method for establishing identities, performing transactions, and storing data on a network.

[0060] According to an embodiment, in a blockchain network, each participant therein has its own replica of the ledger. In addition to the ledger information being shared, the process of updating the ledger is also shared. Unlike other systems where a participant's private program is used to update the participant's private ledger, the blockchain system has a shared program for updating the shared ledger.

[0061] According to an embodiment, with the ability to coordinate business networks through a shared ledger, blockchain networks can reduce the time, cost, and risk associated with private information and processing while improving trust and visibility.

[0062] Hyperledger Architecture

[0063] Like other blockchain technologies, the Hyperledger Framework has a ledger, uses smart contracts, and is a system through which participants manage their transactions.

[0064] Hyperledger Fabric differs from some other blockchain systems in that it is private and permissioned. Members of the Hyperledger Fabric network are registered through a membership service provider, rather than the "proof of work" that some blockchain networks use to verify identity (allowing anyone who meets these criteria to join the network).

[0065] The Hyperledger architecture also provides several pluggable options. Ledger data can be stored in multiple formats, consensus mechanisms can be switched in and out, and different MSPs (Membership Service Providers) are supported.

[0066] The Hyperledger architecture also provides the ability to create channels, allowing a group of participants to create separate transaction ledgers. This allows for network options where some participants may be competitors and do not want every transaction they make—such as a special price they offer to some participants but not others—to be known to every participant. If two participants form a channel, then those participants—but not the other participants—have a copy of the channel's ledger.

[0067] Shared ledger

[0068] According to an embodiment, the Hyperledger architecture has a ledger subsystem that includes two components: world state and transaction log. Each participant has a copy of the ledger for each Hyperledger architecture network they belong to.

[0069] The world state component describes the state of the ledger at a given point in time. It is the database of the ledger. The transaction log component records all transactions that have led to the current value of the world state. It is the history of updates to the world state. The ledger is then a combination of the world state database and the transaction log history.

[0070] The shared ledger has a replaceable data repository for the world state. By default, this is a LevelDB key-value store. The transaction log does not need to be pluggable. It simply records the before and after values ​​of the ledger database used by the blockchain network.

[0071] Smart Contracts

[0072] Hyperledger Fabric smart contracts are written in chaincode and are called by applications external to the blockchain when they need to interact with the ledger. In most cases, chaincode only interacts with the database component of the ledger, the world state (e.g., querying it), and not with the transaction log.

[0073] consensus

[0074] According to an embodiment, transactions are written to the ledger in the order in which they occur, even though they may be between different sets of participants within the network. To this end, an order of transactions is established, and a method for rejecting bad transactions that have been inserted into the ledger by mistake (or maliciously) can be implemented.

[0075] The Hyperledger architecture allows network entities (e.g., network users, peers, initiators) to choose the consensus mechanism that best represents the relationships that exist between participants. As with privacy, there is a range of requirements; from networks that are highly structured in their relationships to more peer-to-peer networks.

[0076] Chain Code

[0077] According to an embodiment, chaincode can include software that defines asset(s), and transaction instructions for modifying asset(s) - it is business logic. Chaincode enforces rules for reading or changing key-value pairs or other state database information. Chaincode functions are executed against the ledger current state database and are initiated through transaction proposals. Chaincode execution results in a set of key-value writes (write sets) that can be submitted to the network and applied to the ledger on all peers.

[0078] Ledger Features

[0079] According to an embodiment, the ledger is an ordered, tamper-proof record of all state transitions in the architecture. State transitions are the result of chaincode invocations ("transactions") submitted by participants. Each transaction produces a collection of asset key-value pairs that are submitted to the ledger as a create, update, or delete.

[0080] The ledger consists of a blockchain for storing immutable sequential records in blocks, and a state database for maintaining the current state of the architecture. There can be one ledger per channel, and each channel contains a separate transaction ledger visible to a specific group of participants. Each peer maintains a copy of the ledger for each channel of which it is a member.

[0081] Privacy via channels

[0082] According to an embodiment, the Hyperledger architecture employs an immutable ledger on a per-channel basis, and chaincodes that can manipulate and modify the current state of assets (i.e., update key-value pairs). The ledger exists within the scope of a channel - it can be shared across the entire network (assuming that each participant is operating on a public channel) - or it can be private to include only a specific set of participants.

[0083] In the latter scenario, such participants can create separate channels, thereby isolating / separating their transactions from the ledger. To allow scenarios that want to bridge the gap between total transparency and privacy, chaincode can be installed only on peers that need access to asset state to perform reads and writes (e.g., if chaincode is not installed on a peer, then it will not be able to properly interface with the ledger). To further obfuscate data, values ​​within chaincode can be (partially or fully) encrypted using common cryptographic algorithms such as AES (Advanced Encryption Standard) before being appended to the ledger.

[0084] According to an embodiment, privacy may also be improved through the concept of "private sets" - a finer concept than per-channel privacy protection.

[0085] Security and Membership Services

[0086] According to an embodiment, the Hyperledger architecture provides a transaction network in which all participants have known identities. Public key infrastructure is used to generate cryptographic certificates that are tied to organizations, network components, and end-users or client applications. Therefore, data access controls can be manipulated and managed at the broader network and channel levels. This "permission" concept of the Hyperledger architecture, coupled with the existence and capabilities of channels, helps address scenarios where privacy and confidentiality are critical.

[0087] consensus

[0088] According to embodiments, in a distributed ledger, consensus can include more than simply agreeing on the order of transactions. The Hyperledger Architecture highlights this differentiation through its fundamental role in the entire transaction flow, from proposal and endorsement to ordering, verification, and commit. Consensus can be defined as the full-circle verification of the correctness of the set of transactions that comprise a block.

[0089] Consensus is eventually achieved when the order and results of a block's transactions have satisfied explicit policy criteria checks. These checks and balances occur during the lifecycle of a transaction and include the use of endorsement policies to specify which specific members must endorse a certain class of transactions, and system chaincodes to ensure that these policies are enforced and supported. Prior to committing, peers can employ these system chaincodes to ensure that sufficient endorsements exist and that they originate from the appropriate entities. Additionally, before any block containing transactions is appended to the ledger, a versioning check can be performed during which agreement or consent is reached on the current state of the ledger. This final check can provide protection against double-spend operations and other threats that could compromise data integrity, and allows functions to be executed against non-static variables.

[0090] In addition to the endorsement, validity, and versioning checks that occur, there is ongoing identity verification that occurs during the transaction flow. Access control lists are implemented at a hierarchical level of the network (ordering services down to channels), and as transaction proposals pass through different architectural components, payloads are repeatedly signed, verified, and authenticated. Consensus is not limited to agreeing on the order of a batch of transactions, but is a process that is achieved as a byproduct of the ongoing verification that occurs during the transaction flow from proposal to submission.

[0091] Blockchain Cloud Service—System Architecture

[0092] According to an embodiment, a system such as a cloud system (e.g., a blockchain cloud service (BCS)) can utilize the above-mentioned Hyperledger architecture as a starting point. Such a system provides a highly advanced and differentiated enterprise-level distributed ledger cloud platform that allows building new blockchain-based applications and / or extending existing SaaS, PaaS, IaaS, and on-premises applications.

[0093] According to an embodiment, the system can support mission-critical enterprise requirements such as scalability, security, robustness, integration, and performance to eliminate barriers to adoption in production and support blockchain applications. The system allows users to deploy, configure, manage, and monitor blockchains and reduce the cost of deploying blockchains in enterprises by providing BCS as a platform as a service (PaaS) cloud solution. The system also accelerates the development and integration of blockchain applications with other platforms. The system allows SaaS cloud customers to use the blockchain cloud platform to implement their procurement, payment, trade finance, accounting, HR, CX and other enterprise processes to securely share data and conduct distributed transactions with third-party applications and external distributed ledger technologies.

[0094] According to an embodiment, the system is a cloud service based on a PaaS manager (e.g., Oracle PaaS Service Manager (PSM) platform). Generally speaking, such a system is a managed cloud service that runs in a computing space (e.g., an external computing space). In an embodiment, the system utilizes features of the PSM platform, including Oracle Application Container Cloud Service (ACCS) layered using Oracle Identity Cloud Service (IDCS), Oracle Load Balancer as a Service (LBaaS), Oracle Event Hub Cloud Service, and Oracle Cloud Storage. Each customer blockchain can be provisioned and can run as a tenant. The system supports multiple blockchains, each of which is provisioned and runs as a separate tenant in a multi-tenant environment.

[0095] Thus, the system allows applications or client applications to implement a distributed ledger with smart contracts for applications. Clients and users of such a system can be inside or outside the cloud - blockchain trust - some blockchain networks may include components outside the cloud environment (or may be constrained to a specific cloud).

[0096] According to embodiments, such a system can be useful for various application functions, especially in multi-party transactions where trust and identity issues must be resolved. Unlike other blockchain systems, the system services provided are not anonymous. In fact, identity and auditability are basic and integrated factors. Thus, BCS can be applied to, for example, capital markets, cross-border transactions, financial services, asset transactions, legal regulatory applications, medical records, publishing, logistics, traceability, and anti-counterfeiting.

[0097] As mentioned above, every party on the blockchain has access to the entire database and its complete history (unless the ledger has been provisioned / privatized to certain parties). No single party controls data or information. Each party can also verify the records of its trading partners directly without the need for an intermediary. Communication occurs directly between peers rather than through a central node. Each node stores information and forwards it to all other nodes. Once a transaction is entered into the database and an account is updated, the records cannot be changed because they are linked to every transaction record that came before them (hence the term "chain"). If a transaction goes wrong, then a new transaction must be used to undo the error, and then both transactions are visible to the provisioned user. In order to add a new valid transaction, participants can agree on its validity via a consensus mechanism. Participants in the blockchain can prove where an asset came from and how the ownership of an asset has changed over time. Digital signatures can be used to authenticate documents and can be placed in access control [different levels of permissions] and programmability [executable business rules].

[0098] In many multi-party transactions, money is exchanged when one party receives an asset or service. Often due to transaction times, one party or the other must submit the goods or money before the other. In some environments, trust issues are addressed by using an intermediary, who holds the funds in escrow until the contract conditions are fulfilled. This solves the trust issue between the original parties. However, this approach adds complexity by adding another centralized party that must be trusted, and can increase the cost of the transaction. Using smart contracts as part of the provided system can eliminate the need for an intermediary - parties can conduct trusted transactions on the blockchain without an intermediary.

[0099] According to an embodiment, the advantages of the provided system (such as BCS) include that the information contained therein is distributed. Although auditability is available, access is controlled and some privacy can be maintained. Moreover, the blockchain ledger is essentially immutable and cannot be rejected. The ledger includes a list of blocks. Each transaction block contains: block ID, previous hash, data hash, timestamp, transaction ID list, action (1..n), chain code ID, chain code proposal, response (r / w set, event, success or failure), endorser. Since each block contains the previous hash and its own hash, these blocks are inherently ordered and immutable once they are known / distributed (note: the hash of the current block is the hash of the previous block and the hash of other data in the current block, so the blocks in the chain are linked). Consensus can resolve differences. Compared with centralized databases or intermediaries, there is no need to over-authorize centralized authorities. The distributed nature of the ledger also enhances the fundamental immutability of blockchain record keeping technology, as the use of distributed copies — and consensus — makes it difficult to modify it (even if it is algorithmically possible). Therefore, given the ordering of transactions — it is virtually impossible to attack the ledger if someone has a copy of the most recent block in the chain.

[0100] In a particular embodiment, as described below, the provided system can be based on the Oracle PaaS Service Manager (PSM) platform and augmented with a management console that simplifies / facilitates / automates the provisioning, monitoring, and configuration of a blockchain based architecture. In addition, a REST proxy service including a single REST API is provided to simplify the connection between applications and the blockchain architecture. Developers can build smart contracts, deploy them using the management console, and then have applications call smart contracts on the blockchain asynchronously (by default) or synchronously (if the request responds immediately). The REST proxy service and API provide both synchronous and asynchronous capabilities, depending on the needs of the platform.

[0101] According to an embodiment, the architecture-CA server can provide membership services for the architecture. The architecture-CA server can include three parts: authentication for users, authorization to access the blockchain (a set of peers and orderers), and CA servers that can deliver certificates to application clients, peers, and orderers. The architecture-CA can use certificates to implement authentication and authorization. Certificates include two types: registration certificates for authentication and transaction certificates for authorization. According to an embodiment, identity services such as IDCS can also provide authentication and authorization.

[0102] Hyperledger Architecture

[0103] As described above, in an embodiment, the provided system can implement a Hyperledger architecture that provides a distributed ledger platform for running smart contracts. The architecture utilizes container technology to host smart contracts called "chaincodes" that include the application logic of the system. In alternative embodiments, the blockchain cloud service implements an alternative distributed ledger platform, including, for example, the "Tendermint" ledger system described in U.S. Patent Application Serial No. 15 / 169,622, entitled "Accountability And Trust in Distributed Ledger Systems," filed on May 31, 2016, which is incorporated herein by reference.

[0104] The distributed ledger protocol of the Hyperledger architecture is run by peers. One drawback of existing blockchain technology is that all peers are required to record all transactions. This generates a lot of I / O and processor overhead and cannot be easily scaled to enterprise-level systems. The Hyperledger architecture distinguishes between two types of peers: the submitter peer is a node on the network that can verify endorsements and verify transaction results before submitting transactions to the blockchain and maintain the ledger. On the other hand, the non-validating peer is a node that acts as a proxy to connect the client (issuing the transaction) to the validating peer. The non-validating peer (or endorsing peer) does not execute transactions, but it can simulate and endorse transactions. The isolation of peer types / functions improves the scalability of the system. The sorting service can accept endorsed transactions, sort them into blocks, and deliver these blocks to the submitting peer. In such a distributed ledger system, consensus is the process of reaching an agreement on the next set of transactions to be added to the ledger. In the Hyperledger architecture, consensus consists of three different steps: transaction endorsement, sorting, and verification and submission.

[0105] According to an embodiment, Hyperledger features a permissioned blockchain with immediate finality that runs arbitrary smart contracts called chaincodes. User-defined chaincode smart contracts are encapsulated in containers, and system chaincodes run in the same process as peers. Chaincode execution is separated from transaction ordering, thereby limiting the level of trust and verification required across node types and reducing network overhead.

[0106] According to an embodiment, channels in the Hyperledger architecture enable multilateral transactions with the high degree of privacy and confidentiality required by competing businesses and regulated industries that exchange assets on a public network. An immutable shared ledger encodes the entire transaction history for each channel and includes query capabilities for efficient auditing and dispute resolution. The ledger is provided within the scope of the channel - it can be shared across the entire network (assuming each participant operates on a public channel) - or it can be private to include only a group of participants.

[0107] According to an embodiment, the Hyperledger architecture implements security by supporting a certificate authority (CA) for TLS certificates, enrollment certificates, and transaction certificates. Public key infrastructure is used to generate cryptographic certificates associated with organizations, network components, and end-user or client applications. Therefore, data access controls can be manipulated and managed at the broader network and channel levels. This "permission" feature of the Hyperledger architecture, coupled with the presence and functionality of channels, meets the privacy and confidentiality needs in multi-party enterprise systems.

[0108] According to an embodiment, the Hyperledger architecture provides the ability to modify assets using chaincode transactions. As described above, chaincode is software that defines one or more assets and is a transaction instruction for modifying (one or more) assets.

[0109] The integrated consensus mechanism plays a fundamental role in the transaction flow in the Hyperledger architecture, from proposal and endorsement, to ordering, verification and submission. As mentioned above, consensus is the verification of the validity of the set of transactions that comprise a block. Consensus is ultimately reached when the order and results of the transactions in a block meet explicit policy criteria checks.

[0110] Figure 1A The transaction flow in the architecture of the system providing blockchain services is illustrated. More specifically, the figure illustrates a blockchain cloud service (BCS) system according to an embodiment. At 1, the client 160 uses the architecture SDK 162 to access the architecture certificate authority 170, 172, 174 for registration. At 1.1, the architecture-CA returns the registration certificate to the client 160. At 2, the client 160 uses the architecture SDK 162 to access the peer container 180 to request an endorsement from the endorser 182. At 2.1, the endorser 182 returns the signed RWset (read / write set). At 3, the architecture SDK 162 at the client 160 submits the endorsed TX (transaction) including the RWset and the endorser signature to the sorting service at the sorting container 190. At 4, the sorter 192 delivers the TX batch to the submitter 184 in the peer container 180. The sorter is a defined set of nodes that sort transactions into blocks. The ordering service exists independently of the peer process and orders transactions for all channels on the network on a first-come, first-served basis. Committer 184 applies changes to ledger 186 and world state 188 at 5 and 5.1. Fabric certificate authority 170 can be used to verify signatures and authorizations for peer container 180, smart contract containers 166 and 168 (smart contracts), and orderer 192. In addition, smart contract 168 can communicate with endorser 182.

[0111] In an embodiment, the system can use a Kafka cluster as a sorting service. Kafka is a distributed streaming service that supports publish and subscribe semantics. The Kafka cluster runs on multiple servers and stores streams of records in categories called topics. Each record includes a key value and a timestamp. Therefore, Kafka can be used as a sorting service, including a sorting service node (OSN-n) and a Kafka cluster. The sorting service client can connect to multiple OSNs. The OSNs do not communicate directly with each other. These sorting service nodes (OSNs) (1) perform client authentication, (2) allow clients to write to or read from chain 1 using a simple interface, and (3) they also perform transaction filtering and validation on configuration transactions that reconfigure existing chains or create new chains. Messages (records) in Kafka are written to topic partitions. A Kafka cluster can have multiple topics, and each topic can have multiple partitions. Each partition is an ordered, immutable sequence of records that are continuously appended to. Once the OSNs have performed client authentication and transaction filtering, they can relay incoming client transactions belonging to a chain to the corresponding partition of the chain. They can then consume that partition and return an ordered list of transactions that is common across all ordering service nodes.

[0112] According to an embodiment, each peer has the ability to be an endorser and a committer. There is a configuration item (e.g., CORE_PEER_ENDORSER_ENABLED) that can enable a peer to become an endorser. When a peer joins a channel, the peer becomes a committer for this channel. When a chaincode is installed on a peer, the peer becomes a candidate endorser for this chaincode. When a client proposes a transaction, the client selects which peers (from the candidate endorsers) to be endorsers.

[0113] According to an embodiment, the sorting mechanism for the sorter to deliver blocks to peers is as follows. First, a peer (e.g., a leader peer) delivers a request for a new block from the sorter by sending the peer's version (the last block number). Next, the sorter checks the peer's version: a) if it is greater than the sorter's, an error is returned to the peer, indicating that the ledger in the sorter is lost and cannot be recovered from EventHub (in which case the sorter cannot continue to work properly); b) if the peer's version is less than the sorter's, the sorter retrieves the block from the local ledger (in RAM or in a local file) and then sends it back to the peer; or c) if they have the same version, the sorter blocks until a new block is available. When the new block data cut from EventHub is ready, the sorter puts it in the local block file or RAM, and then the delivery thread reads this block from the ledger and sends it back to the peer. The peer fetches this block, commits it to its local ledger, and can then broadcast its latest version to other peers.

[0114] BCS system architecture

[0115] Figure 1B The diagram illustrates a transaction flow in the architecture of a system providing blockchain services. More specifically, the diagram illustrates a blockchain cloud service (BCS) system according to an embodiment. As shown, the blockchain cloud service components are provisioned in a computing space 120 (e.g., an external computing space), such as on an Oracle PaaS Service Manager (PSM) platform. Access to the system is mediated by a PSM API 122 and a blockchain REST API 124. External computing 120 utilizes a load balancing as a service LBaaS 126 to distribute incoming transactions across available appropriate resources.

[0116] According to an embodiment, BCS is an application-container layered service built using the PSM platform on the application container cloud service 128. Each of the BCS entities runs on a separate container. Each of the BCS entities corresponds one-to-one to an application container. The blockchain cloud service implements the features of the above-mentioned hyperledger architecture. In addition to the components that build the basic architecture network, several components have been developed to use the hyperledger architecture for blockchain cloud services. These components require separate deployment behaviors and binaries to deploy these components. The cloud stack manager can be used to enable users to automatically provision all services defined by the blueprint as units called stacks.

[0117] In an embodiment, BCS provides an implementation of the Hyperledger Architecture, which is an implementation of a distributed ledger platform for running smart contracts. BCS uses container technology to host smart contracts called "chaincodes" that contain the application logic of the system.

[0118] According to an embodiment, the distributed ledger protocol of the architecture is run by peers. The architecture distinguishes between two types of peers: validating peers are nodes on the network responsible for running consensus, validating transactions, and maintaining ledgers. On the other hand, non-validating peers are nodes that act as proxies to connect clients (that issue transactions) to validating peers. A non-validating peer does not execute transactions, but it can verify them. Some key features released by the architecture include a permissioned blockchain with instant finality that runs arbitrary smart contracts called chaincodes. User-defined chaincode smart contracts are encapsulated in containers, and system chaincodes run in the same process as peers. The architecture implements consensus protocols and security by supporting certificate authorities (CAs) for TLS certificates, registration certificates, and transaction certificates.

[0119] According to an embodiment, BCS entities run in hierarchical container instances with ACCS 128. These containers are created and / or started by the provisioning operation of PSM. The Architecture-CA container 130 is a container in which the BCS architecture CA (certificate and authority) component is provided. The BCS peer (container) 132 is a container in which the BCS peer network entity that maintains the ledger and runs the chain code container to perform read / write operations on the ledger component runs. The BCS sorter container 134 is a container in which the BCS sorter that provides services to sort transactions to the blockchain for all channels runs. The BCS chain code execution container 139 is a container created and started by a peer entity. In this container, the chain code execution unit communicates with the parent peer entity and executes the encoding of assets and transaction instructions to modify assets in the blockchain.

[0120] According to an embodiment, the BCS chain code builder container 140 is a container created and started by a peer entity. In this container, the chain code building environment is installed and deployed, and the chain code execution unit is built therein. The client-side architecture SDK 106 provides functions for accessing BCS. The blockchain cloud service also utilizes the event hub cloud service 150, the cloud storage service 152, and the identity service 154. Oracle Storage Cloud Service is used as a storage service for BCS.

[0121] According to an embodiment, Docker / Weave 141 is a container service. Containers provide a way to package software in a format that can be run in isolation on a shared operating system. Unlike VMs, containers do not bundle an entire operating system - instead, they require the use of libraries and settings required to make the software work. This enables an efficient, lightweight, self-contained system and ensures that the software always runs the same, no matter where it is deployed.

[0122] According to an embodiment, each BCS instance includes different types of nodes. There can be a few (e.g., 0 or more than 0) to many peer nodes in a BCS instance. There can be a few (e.g., 0) to many sorter nodes in a BCS instance. There are 1 to many Architecture-CA nodes in a BCS instance, one for each VM. BCS Gateway: There can be a few (e.g., 0) to many BCS Gateways in a BCS instance. The BCS Console is also a component of a BCS instance. There is only one BCS Console in a BCS instance.

[0123] According to an embodiment, the BCS Management Server (Console) 136 is a component of the BCS that provides rich monitoring, management, and view capabilities to the BCS stack instance, as described in more detail below. The BCS Gateway (REST Proxy) 138 is a new component of the BCS and provides a REST API interface to customers / clients and is used to access the architecture to perform transactions, as described in more detail below.

[0124] According to an embodiment, on the public access client side 100, the PSM console UI 102 allows management of the Platform Service Manager. The BCS console UI 104 allows control of the BCS management server. Various different client types can access BCS services, including the fabric SDK client 106, the BCS REST client 108, and the fabric membership client 110.

[0125] According to an embodiment, a blueprint can be defined for each type of container listed above as a separate service type. Oracle Cloud Stack Manager uses the blueprint to automatically provision all separate service types into a single stack unit. The benefit of defining a service type for each BCS entity is that it is easy to upgrade and maintain the various running entities. The Application Container Layered Service supports four types of operations: CREATE_SERVICE, DELETE_SERVICE, SCALE_SERVICE, and Start / Stop / Restart. These operations can be applied per service.

[0126] According to an embodiment, in the Hyperledger Fabric network, the ordering service component uses Apache Kafka to provide ordering services and support for multiple chains in a crash-tolerant manner. Thus, in the BCS cloud service, the ordering service component will use OEHCS (Oracle Event Hub Cloud Service, which provides the power of Kafka as a managed streaming data platform and can be integrated with the rest of the Oracle Cloud).

[0127] Figure 1C The BCS system according to an embodiment is illustrated. More specifically, the figure shows the BCS runtime.

[0128] According to an embodiment, clients such as gateway-based applications 103 and / or architecture-based applications 105 can communicate with AACS instances 128 via networks such as the Internet 107 and via front ends such as load balancers LBaaS 126, which may include CloudGate (discussed below). Incoming calls may include REST communications (shown as thicker dashed lines in the figure), or in some cases, incoming gRPC communications (shown as lighter dashed lines in the figure). Incoming REST communications may be directed to a gateway 138 (which may include a REST API / REST proxy), a console 136, or an agent architecture-CA 130 (as discussed above). The REST communications, now converted / transformed into internal calls (gRPC), can interface with instances of blockchain architecture / hyperledger (including agents / peers 132, agents / orderers 134, chaincodes 142, and chaincode builders 140). Meanwhile, incoming gRPC communications may be sent directly to, for example, proxy / peer 132 and proxy / orderer 134 to interface with the blockchain / hyperledger.

[0129] According to an embodiment, once a transaction within an ACCS instance has occurred, the ACCS instance may persist the ledger at a cloud storage device, for example, via REST communications, or may communicate with an event hub also via REST communications.

[0130] According to an embodiment, although only one ACCS instance is shown in the figure, those skilled in the art will readily understand that one or more ACCS instances may exist with which a client (such as a gateway-based application 103 and / or an architecture-based application 105) may communicate via the described BCS runtime.

[0131] Figure 1D A BCS system according to an embodiment is illustrated. More specifically, the figure illustrates the cardinality of components within the BCS system, ie the ratio of components to each BCS instance.

[0132] According to an embodiment, for each BCS instance 100a: the orderer 101a may be provided in a 1:N ratio; the architecture-CA membership 102a may be provided in a 1:N ratio; the BCS REST-proxy 103a may be provided in a 1:N ratio; the BCS console 104a may be provided in a 1:1 ratio, and the peer container 105a may exist in a 1:N ratio.

[0133] Each peer container may include endorsers who can simulate transactions and committers who can apply changes to the ledger, which is also provided at the peer container.

[0134] According to an embodiment, chain code 109a may be provided at a 1:N ratio relative to peer containers. In addition, storage 106a may be provided at an N:1 ratio relative to peer containers and orderers. Likewise, event hub 107a may be provided at an N:1 ratio relative to peer containers and orderers. IDCS 108a may be provided at an N:1 ratio relative to fabric-CA membership.

[0135] Blockchain Cloud Service (BCS) Gateway

[0136] According to an embodiment, the BCS Gateway (BCSGW) comprises a network node that communicates with the fabric network using the fabric SDK.The BCS Gateway provides a HTTPS RESTful API to customers on the client side that allows clients / client applications to interact with elements of the BCS's fabric.

[0137] Figure 2 The diagram shows a gateway for a blockchain cloud service system according to an embodiment. Figure 2 As shown, the end user 200 interacts with the application adapter 202 using HTTPS for authentication and authorization. The application adapter 202 uses HTTPS to an LBaaS such as Cloud Gate 212 (i.e., LBaaS) to access the public cloud 210. Load balancing as a service (LBaaS) is performed on the incoming transactions. Cloud Gate 212 passes the transaction to BCS Gateway 222 using HTTPS. The BCS Gateway provides an interface to the BCS architecture 220, where the communication utilizes the gRPC remote procedure call protocol.

[0138] According to an embodiment, Cloud Gate 212 is a reverse proxy "access enforcement module" or "policy enforcement point" that uses, for example, OAuth2 and OpenID Connect standards to protect web browsers and REST API resources. IDCS uses Cloud Gate internally to protect its own management UI and REST API (referred to as the "IDCS web layer"). For other applications, Cloud Gate: OTD is deployed as an additional instance in a semi-supported / temporary setting called Non-IDCS or Standalone.

[0139] According to an embodiment, (for UI clients) OAuth / OpenID-based authentication supports user browser flow, which is triggered if the HTTP request contains a "User-Agent" header (which means that the request comes from a UI such as a browser or mobile application). Cloud Gate prompts the user to enter credentials (username / password), verifies the credentials, and then creates and returns an OAuth session cookie, which can be used by subsequent HTTP requests from the browser. (For programmatic clients) OAuth / OpenID-based authentication also supports resource server flow. This flow is triggered if the HTTP request contains an authentication "bearer" token header. Cloud Gate verifies the token for authentication.

[0140] According to an embodiment, for HTTP Basic Authentication, the credentials (username / password) must be included in the HTTP Authorization "Basic" header for each HTTP request. Cloud Gate verifies these credentials for each HTTP request. This method applies to both UI clients and programmatic clients.

[0141] According to an embodiment, the multi-token flow is an adaptive method that covers certain HTTP requests. If the HTTP request contains an Authorization "Basic" header, then Cloud Gate will perform the HTTP Basic behavior. If the HTTP request contains an Authorization "Bearer" header, then Cloud Gate behaves the same as the Resource Server flow.

[0142] In an embodiment, the BCS console browser client utilizes the user browser flow. In an embodiment, for BCS console and gateway programmatic clients, the system can use the Cloud Gate multi-token authentication method. Programmatic clients can call the BCS REST API via HTTP basic authentication.

[0143] According to an embodiment, the BCS gateway 222 communicates with peers 224, which are network entities that maintain ledgers and run chaincode containers to perform read / write operations on ledgers. Peers are owned and maintained by members. The BCS gateway 222 and peers 224 communicate with (one or more) orderers 226. The orderer provides an ordering service. The orderer is a defined set of nodes that order transactions into blocks. The ordering service exists independently of the peer process and orders transactions for all channels on the network on a first-come, first-served basis. Peers 224 and (one or more) orderers 226 communicate with the fabric certificate authority 228. The BCS gateway 222 also provides access to the BCS management server / console 230.

[0144] According to an embodiment, BCS is deployed on a cloud system such as Oracle Cloud. The gateway can run in an ACCS container. The gateway is stateless. The gateway can be updated by killing the old gateway and starting a new gateway. The BCS gateway can allow customers to query or call the architecture chain code through the RESTful protocol. The BCS gateway allows clients to access the architecture network in Oracle Cloud through HTTPS / RESTful services. The BCS gateway is a network node that communicates with the architecture network using the architecture SDK. Communication within the architecture uses gRPC as the communication protocol. On the client side, the BCS gateway provides an HTTPS / RESTful API to customers. The REST API allows clients to call functions within the architecture using the architecture SDK.

[0145] According to an embodiment, a gateway may be provided in a one-to-one relationship with an architecture user. All gateway users belong to one organization, and all gateway users are mapped to one architecture user in one gateway. One gateway is configured with only one architecture user.

[0146] According to an embodiment, IDCS issues gateway certificates and gateway user ("application adapter") certificates. These certificates are signed with the organization CA. Gateways and gateway users can be deployed with the organization CA so they can authenticate each other using HTTPS.

[0147] According to an embodiment, each end user accesses the BCSGW through an "application adapter". There are 3 layers of authentication. The end user 200 can be authenticated by the application adapter 202. The application adapter 202 can be authenticated by the BCS gateway 222 with a client certificate. The BCS gateway can be authenticated by peers 224 and sequencers 226 in the fabric network 220.

[0148] According to the embodiment, a container runs a tomcat server, deploys a BCS gateway, and is mapped to a framework user. Multiple application adapters can be connected to a gateway.

[0149] According to an embodiment, different gateways may be associated with different fabric users. An end user of an application adapter connected to a gateway may be mapped to a fabric user.

[0150] According to an embodiment, BCSGW runs in Oracle Cloud and the configuration is set by the BCS console using a JSON file. An admin user can publish some peers, channels, and chaincodes to the gateway. The admin user starts the gateway through the console. The gateway does not refresh the configuration after booting. The admin user can set endorsers for the chaincode. The end user is unaware of the policy and the gateway does not check the chaincode policy.

[0151] According to an embodiment, BCSGW is started by the BCS console. The BCS console creates a BCSGW configuration file and starts a new gateway using the BCSGW package. After startup, the startup script checks the BCSGW configuration file, modifies Tomcat's configuration file (e.g., Tomcat configuration file), and then starts Tomcat. Tomcat starts a thread for BCSGW for each channel (the thread reads the configuration file), which creates a channel object and creates connections with sorting, peers, and event hubs. Different channels will have different connections with sorting / peers / event hubs. The event hub here is the second port of the peer. The gateway connects to this port to get the results of the transaction. The Tomcat servlet container can listen and wait for client requests. For the chain code query method, BCSGW sends the request to all peers of the channel and uses only the first result. For the chain code call method, BCSGW sends the request to all endorsers of the channel. If one of them returns successfully, then BCSGW sends the transaction to all sorters of the channel.

[0152] According to an embodiment, asynchronous API is supported. A peer can open two ports, one for event exchange. The gateway can connect to the event port of the peer. For one channel, the gateway only needs to connect to one event port. The normal client API is synchronous. Transactions can take several seconds and the client needs to wait for a response. Sending asynchronous events to the client is not in the V1 plan. In addition to the synchronous transaction API, the gateway also provides an asynchronous transaction API "asyncinvoke".

[0153] In an embodiment, an asynchronous API can work in this way. After checking the parameters of the client request, the gateway returns a transaction ID to the client. The client can know that the transaction has been initiated but not yet completed. The gateway will start a background thread to continue processing the transaction. The client can track unfinished transactions. The gateway can provide the client with a "transaction" API for querying the transaction status using the transaction ID.

[0154] According to an embodiment, client login can be supported. BCSGW can support HTTPS protocol and does not allow unsecured HTTP access. BCSGW uses certificates to trust application adapters or SALT. Application adapters can authenticate end users. Tomcat needs to be set up to use HTTPS client certificate authentication. The keystore file includes the BCSGW certificate and CA certificate to verify the client provided by the BCS console. The BCS gateway provides a BCS Rest interface for client access.

[0155] Persistence - Storage Cloud

[0156] According to an embodiment, the Hyperledger Architecture project code stores the blocks of the ledger in the local file system, and other runtime data such as block index, world state, history, and ledger provider database (keeping all ledger IDs and recovery status) are stored in LevelDB, which is also stored in the local file system. In ACCS, the container file system is temporary, which means that when the container is stopped due to some hardware failure and a new container is restarted on a new VM - the file system content may be lost. Considering the case where all containers are lost, there is no way to recover the ledger. Therefore, the ledger data must be stored outside the ACCS container. Therefore, a persistence solution is provided in the form of an object storage service for use by the components of the above-mentioned Hyperledger Architecture.

[0157] According to an embodiment, in BCS, the persistence solution utilizes a storage cloud service (e.g., Oracle Storage Cloud Service). The ledger is backed up to an object repository. The ledger blocks are written to the container file system, but are also backed up to the object storage device. The index and world state are recorded using the container file system, but if the container is restarted, the index and world state can be restored from the storage cloud service. Oracle Storage Cloud is an Infrastructure as a Service (IaaS) product that provides enterprise-level large-scale object storage solutions for files and unstructured data.

[0158] Figure 3 The figure illustrates the persistence of the blockchain cloud service system according to an embodiment. Figure 3 As shown in , ACCS instance 300 includes multiple containers. The containers include, for example, sorted containers 302, 304 with ledgers / blockchains 312, 314. The ledgers / blockchains 312 and 314 are backed up to an object storage device 320 through a REST interface. The object storage device 320 can be, for example, a cloud storage service.

[0159] Object storage is used to persist the ledger of each sorter. The current mechanism for the sorter to deliver blocks to peers is as follows. First, the peer delivers a request for a new block from the sorter by sending the peer's version (the last block number). Next, the sorter checks the peer's version, a) if it is greater than the sorter, then an error is returned to the peer, which indicates that the ledger in the sorter is lost and cannot be recovered from EventHub. In this case, the sorter cannot continue to work properly. b) If the peer's version is less than the sorter, then the sorter retrieves the block from the local ledger in RAM or local file and sends it back to the peer. c) If they have the same version, then the sorter blocks until a new block is available. When the new block data cut from EventHub is ready, the sorter puts it in the local block file or RAM, and then the delivery thread reads this block from the ledger and sends it back to the peer. Finally, the peer gets this block and commits it to the local ledger. Next, the latest version of the ledger can be broadcast to other peers.

[0160] According to an embodiment, according to the above processing, the sorter or EventHub can persist the entire block. As described above, EventHub has a time-limited retention. If EventHub can do this, the sorter can set the ledger type to RAM or file, and once the sorter is restarted and the ledger is lost, it can replay the records from EventHub and cut the batch messages into blocks, and then the ledger can be rebuilt. If EventHub only supports a limited retention period, then once the sorter is restarted and the ledger is lost, it cannot correctly rebuild the ledger because the first record in EventHub is not the real record in the ledger. In this case, the sorter cannot start the old channel because the first block with the channel information is lost and the version number (the last block number) is also incorrect.

[0161] Then, according to an embodiment, each sorter can persist each block to Oracle storage, while also saving all channel IDs to objects in the storage. On the peer, only the genesis block is persisted because it has channel information. For other block data, once it is lost, the peer can retrieve it from the sorter.

[0162] According to an embodiment, the ACCS instance 300 may also include peer containers 306, 308, which include ledgers 316, 318 and indexes 326, 328. There are five types of runtime data generated by peers: transaction log (block file); block file index (LevelDB); ledger provider DB (LevelDB); state database (LevelDB or couchdb); history (LevelDB). All transaction data is stored in the transaction log as linked blocks in local files, which must be persisted to Oracle Storage Cloud Service. The ledger provider DB retains all ledger IDs and recovery status in LevelDB. The ledger ID is a unique ID that identifies the channel to which the peer belongs. It must be persisted to Oracle Storage Cloud Service. For others, the peer can automatically recover it at runtime, so they are kept in the local file system.

[0163] According to an embodiment, Oracle Storage Cloud Service provides a REST API for uploading / downloading files to / from an object. When a new chunk is generated, first, it will be written to the local chunk file as before, with one chunk per file. Next, this chunk file will be uploaded to Oracle Storage as an object. If it fails, the changes in the local file will be rolled back and an error will be returned to the caller.

[0164] According to an embodiment, for the chunk file index, when the sorter updates the latest checkpoint, the information can be first persisted to the Oracle storage device, and then the local LevelDB can be updated. If the operation event fails, an error can be returned to the caller. This information will be used for the recovery of the chunk file index. In the Oracle storage device, each peer and sorter has a unique container name, which is a combination of the msp id and the node id. The object name is the name of the chunk file prefixed with the channel name. For more details, see the Name Conventions in Oracle Storage Device section.

[0165] According to an embodiment, an option to save the ledger provider DB to Oracle Storage can be provided. For the ledger provider DB, the entire LevelDB can be copied to Oracle Storage Cloud Service as soon as it is updated. This file is very small and is not updated frequently, so the overhead on replication can be ignored. When the container is restarted, it can be downloaded from Oracle Storage Cloud Service (if it exists). If the sorter is restarted from a new container, it will first download the channel ID from the storage device object, and then get the latest checkpoint from the storage device by the channel ID. Next, start recovering the block index from the first block to the last block. During this period, the block files will be downloaded one by one. After that, the sorter starts to recover the state DB and history DB. If the peer is restarted from a new container, it will first download the ledger provider DB, and then it can get all the ledger IDs. Next, get the relevant origin block from the storage device by the ledger ID. The peer starts with the configuration in the origin block and sends a request to the sorter to get other block data. After the peer gets these blocks, it starts to recover the block index, state, and history DB.

[0166] According to an embodiment, the local block file acts as a read cache. Queries will first read the data locally, and if it does not exist, then download it from the object storage device. In addition to the ledger, the source code of the chaincode needs to be persisted to the Oracle storage device. In the current architecture, the encoded source code will be stored on the peer after the chaincode is installed. The peer will check the chaincode container for each call or instantiation, and if the container does not exist, the peer will rebuild it from the source code. Therefore, it can be uploaded to the Oracle storage device for each chaincode installation and downloaded when the peer restarts from a disk failure.

[0167] BCS: SDK-based configuration file manipulation and post-provision deployment

[0168] According to an embodiment, the configuration file and deployment function deploy, initiate generation, update and obtain the configuration about the application when deploying or updating the application, and the application includes peers, sorters, CA servers and chain codes. These functions reside in the BCS console (Node.js) and the architecture container (peer / sorter / chain code container). These functions will obtain / update the configuration according to the request from the UI, and call the SDK API to activate the configuration change when necessary. The component as a part of the BCS console backend interacts with the BCS console UI, the IDCS backend SDK and all BCS applications to provide SDK for obtaining / updating the configuration for UI operations according to the request. This component also helps to supply BCS applications. The BCS supply component deploys the BCS application into the Docker container of the VM created using PSM. This feature will implement the SDK API for obtaining or updating the BCS application configuration and deployment in the post-supply stage for the BCS console UI and the BCS supply component. In the post-supply stage, the supply system will deploy BCS applications such as CA servers, sorters, and peers under Docker / Swarm. When the VM starts, it will call the startup script to perform post-provisioning and VM initialization work.

[0169] According to an embodiment, configuration files are provided for the fabric components including peers, orderers, fabric CAs, and BCS gateways. BCS application packages, configurations, and chaincodes are stored in the customer's storage cloud service.

[0170] According to an embodiment, the provisioning system should complete all resource allocations. Resources include VMs, networks, and storage.

[0171] According to an embodiment, the provisioning system should save all resource allocation information to the storage service. This information includes the VM number and its network address / account credentials, the BCS application number and its type in each VM, public and internal IP. And there should also be enough internal IP addresses for containers (accessible between VMs).

[0172] According to an embodiment, when the BCS provisioning component has completed the provisioning work, the VM startup script will be started, and then call the swarm to deploy the application container, and inside the container, the container startup.sh script performs the launch operation.

[0173] According to an embodiment, the BCS console will obtain the configuration from the storage service when it starts, and save the input of the user operation from the UI back to the storage service, and then send a restart command to the swarm.

[0174] According to an embodiment, the required security certificates may be stored in IDCS. Alternatively, the security certificates may be retrieved from IDCS.

[0175] According to an embodiment, the BCS console backend may communicate with the BCS application using swarm.

[0176] According to an embodiment, when a BCS application container is started, the BCS application may collect configuration details to determine its application type (peer or chaincode container or other), and then load the required configuration.

[0177] According to an embodiment, this component updates the configuration and provides the BCS application startup shell code. The BCS get / update configuration file operation can be divided into several parts. First, the BCS console will get the configuration from the storage device when it starts, and save the configuration from the BCS console to the storage device when it needs to be updated (shell and Node.js). When the BCS application container starts, the startup script (in each Docker container) will first start, then get the configuration of its application type, and get the application certificate from IDCS (shell). When the BCS console UI restarts the BCS application, it sends a message to Docker / Swarm to restart the application in the container.

[0178] According to an embodiment, the BCS console is stateless and, when started, can collect all BCS instance configurations and connect to BCS applications and monitor them. The configuration will be obtained from the storage service via the backend API. When any configuration changes, the BCS console will call the backend API to save the configuration back to the storage service and restart the relevant application. When a customer changes a configuration item via the BCS console UI, the UI encodes the configuration as key / value data, and the backend code transforms it into a file and saves it to the storage service. The BCS console can monitor, start and stop BCS applications. The start and stop commands use the Docker / Swarm API to implement this function.

[0179] Deployment of the architecture network

[0180] According to an embodiment, an architecture network includes the following entities: peers, clients, an ordering service, and a set of protocols that facilitate communication between these entities. An organization is a logical entity or company that constitutes a stakeholder of an architecture network. An architecture network has multiple participating organizations. Members: Legally independent entities that have a unique root certificate for the network. Network components such as peer nodes and application clients will be linked to members. Each organization can have one or more members. An organization can contribute to both orderers and peers, or only to orderers, or only to peers.

[0181] The first step in deploying a fabric network is to define the participants. This step is done out-of-band to the fabric network. All participating organizations of the fabric network negotiate and finalize the composition of the network, including, for example, which organizations contribute to orderer nodes, and which organizations contribute to peer nodes. Each organization that contributes to orderer nodes publishes a root certificate for its orderer servers. Each organization that contributes to peer nodes publishes a root certificate for its peer servers. Each organization that has clients publishes a root certificate for its clients. Clients can be separated from peers to different members in one organization.

[0182] As an example, four banks (Bank 1, Bank 2, Bank 3, and Bank 4) have decided to deploy a blockchain network using an ordering service, which will include orderer nodes owned by Bank 1 and Bank 2. And Bank 1 only contributes to the orderer in this network. Each bank is an organization that structures the network: Bank 1 has 1 member: orderer (root_cert_1); Bank 2 has 3 members: client (root_cert_21), peer (root_cert22), orderer (root_cert23); Bank 3 has 2 members: client (root_cert31), peer (root_cert32); Bank 4 has 2 members: client (root_cert41), peer (root_cert42).

[0183] After defining the participants, certificates are generated for orderers and peers. Each orderer or peer requires a (private key, signed certificate) pair to identify itself. Each member can configure and start its own infrastructure CA server with its root certificate, and use the CLI or SDK to request the CA server to generate (private key, signed certificate) for each orderer / peer server of this member. BCS provides an infrastructure CA server that can provide certificates. However, the infrastructure CA server is not the only way to generate certificates. Users can use other CA systems to perform the same operation. Therefore, the infrastructure CA server is not a mandatory component in the infrastructure network.

[0184] After certificates are generated for the orderer and peers, the fabric network is bootstrapped by creating a system channel. The ordering service has only one system channel (and one system channel for a fabric network), and it is the first channel to be created (or more accurately bootstrapped). The system channel defines the composition of the fabric network:

[0185] A sorting service

[0186] ○One or more sorter organizations.

[0187] MSP ID

[0188] ■Certificate

[0189] ○ Ordering service properties (e.g. type - solo or Kafka, orderer address, batch size / timeout)

[0190] ○ Policy (who can create channels, etc.)

[0191] ●One or more consortiums. Each consortium contains

[0192] ○ One or more peer organizations. Any peer organization that wants to participate in this architecture network must be defined in one of the alliances.

[0193] MSP ID

[0194] ■Certificate

[0195] ■Anchor peer

[0196] After the fabric network system channel is bootstrapped, a genesis block (the first block in the chain) is created for the system channel. The orderer service administrator generates a genesis block for the system channel. The genesis block can be generated by the tool configtxgen(genesismethod=file), or during orderer startup (genesismethod=provisional). When using the configtxgen tool to generate a genesis block, you must write a configuration file configtx.yaml as input. This file contains the following information: the root certificates of all orderer organizations in the fabric network; the root certificates of all peer organizations; ordering service properties: orderer type, address, batch timeout, batch size, kafka; policies; channel readers: authenticate and verify channel delivery requests; channel writers: authenticate and verify channel broadcast requests; chain creators: evaluate chain creation requests; administrators: authenticate and verify channel reconfiguration requests;

[0197] The orderer service administrator uses the configuration file and the genesis block to start the orderer server. This creates a system channel using the genesis block. Starting the orderer server requires the configuration file orderer.yaml: listening address / port, ledger type, etc.; LocalMSP (private key, signed certificate). Each organization that provides the ordering service will start its orderer server (the genesis block should not be specified).

[0198] Each organization contributing to a peer node prepares a configuration file for each peer (default location / etc / hyperledger / fabric / core.yaml) to specify: LocalMSP (private key, signed certificate) to identify the peer; and peer properties: listening address / port, boot peer, gossip properties, etc. Then start the peer server.

[0199] After starting the orderer and peers, a channel administrator (who has the privilege to create channels) uses the fabric CLI or SDK to request the orderer to create a channel with the following inputs: a consortium (which must have been defined in the system channel); and one or more peer organizations in the consortium. Each participating organization uses the fabric CLI or SDK to connect some of its peers to the newly created channel.

[0200] Example: Deployment of an Architecture Network on BCS

[0201] Figure 4 An example deployment of the architecture on BCS is illustrated.

[0202] More specifically, the diagram and description describe the steps to deploy a fabric network on BCS. In this example, four entities A, B, C, and D want to create and join a fabric network. The four entities discuss offline and decide on the responsibilities of each entity. Each entity creates one or more BCS instances on OPC.

[0203] According to an embodiment, entity A provides both orderers and peers. Entity A creates two instances: Orderer_Org1 401 for orderers and Peer_Org1 421 for peers. Entity A is also responsible for creating a fabric network (note: only orderers can create fabric networks). Ordering service 400 includes Orderer_Org1 401 and Orderer_Org2 402 and Kafka cluster 410.

[0204] According to an embodiment, entity B provides both orderers and peers. Entity B creates two instances: Orderer_Org2 402 for orderers and Peer_Org2 422 for peers.

[0205] According to an embodiment, entity C only provides peers. Entity C creates an instance Peer_Org3 423 .

[0206] According to an embodiment, entity D only provides peers. Entity D creates an instance Peer_Org4 424.

[0207] According to an embodiment, the administrator of each BCS instance collects the CA certificate and administrator certificate of the current organization from the BCS console. The administrator of each peer organization identifies the anchor peer of the current organization and collects the IP / port of the anchor peer. The four entities exchange all collected information offline.

[0208] According to an embodiment, from the BCS console, the administrator of Orderer_Org1 creates a fabric network by creating a system channel using the following information collected in the previous step: CA certificates and administrator certificates for each organization; and anchor peers for each peer organization. The backend work includes calling the fabric tool to create a genesis block and configuring the orderer to create a system channel using the genesis block.

[0209] According to an embodiment, from the BCS console, the administrator of each peer organization joins the fabric network by updating the configuration of all peer nodes to add the collected CA / administrator certificates of other organizations and restarting all peer nodes.

[0210] According to an embodiment, in the system, a method is provided to allow new organizations to join an existing fabric network. In addition, a user-friendly method can be provided to facilitate communication between participants in order to create / join a fabric network, for example, to cover offline actions of initially forming a fabric.

[0211] Chaincode (smart contract) container

[0212] According to an embodiment, and as discussed above, chaincode is software that defines one or more assets, and transaction instructions for modifying the asset(s). Chaincode enforces rules for reading or changing key-value pairs or other state database information. Chaincode functions are executed against the ledger's current state database and are initiated through transaction proposals. Chaincode execution results in a collection of key-value writes (write sets) that can be submitted to the network and applied to the ledger on all peers.

[0213] According to an embodiment, in order to support consistent updates of information - and enable multiple ledger functions (transactions, queries, etc.) - the blockchain network uses smart contracts to provide controlled access to the ledger. Smart contracts can encapsulate information, automatically replicate information across the architecture, and smart contracts are also written to allow participants to automatically execute certain aspects of transactions.

[0214] According to an embodiment, a Hyperledger Architecture smart contract is written in chaincode and is called by an application external to the blockchain when the application needs to interact with the ledger. In most cases, the chaincode only interacts with the database component of the ledger, the world state (e.g., queries it), and not with the transaction log.

[0215] According to an embodiment, the Hyperledger architecture leverages the Docker engine to build the chaincode, deploy it, and keep it running. This section describes the architecture of the architecture and how it is integrated into the ACCS layered model of BCS.

[0216] According to an embodiment, the architecture deploys and manages user chaincode as follows: First, build the chaincode in a temporary CC env container. Second, transfer the chaincode as source code to the builder container, compile it with statically linked required libraries ("Java build"), and then send the binary file back to the peer. Static linking allows the actual chaincode container to be as small as possible. Third, build the chaincode image and container and start it. The chaincode container then remains running until the peer is shut down or the channel terminates. If the chaincode container crashes or is killed, then, if the image exists, it is restarted at the next call. The design is that there is one chaincode Docker container for each peer and channel. The chaincode is explicitly installed on the peer. That is: not all peers joining the channel must install the chaincode.

[0217] According to an embodiment, a user can deploy a fabric network in an ACCS hierarchical container, which has the ability to transparently distribute components such as peers, sequencers, and chaincodes. The chaincode runtime environment container (ccenv) will be dynamically launched as an ACLS container. The chaincode binary will be saved in cloud storage because local block storage is not considered a reliable way to recover. Once built, the chaincode binary will be uploaded to cloud storage for recovery purposes in case of container crashes.

[0218] According to an embodiment, each chaincode interaction may correspond to various functions of the chaincode. The only restriction is that the chaincode cannot be called or queried before it is instantiated. In addition, at any call, if the chaincode container cannot be found as running, then the chaincode container is restarted.

[0219] Figure 5The chaincode architecture according to an embodiment is illustrated. More specifically, the figure illustrates the chaincode architecture according to an embodiment, which allows the client 530 to install the chaincode in the ACCS environment 500 and run transactions. Step 1, the client 530 installs the chaincode source code to the peer 1, 510. First, the chaincode is built in a temporary CC env container. When the client 530 performs "install", it will: start the builder container (which will automatically start the builder agent), wait for the builder container to complete initialization, and send the chaincode source code to the builder container via the peer (step 2). The builder agent will build the chaincode (Java build). The chaincode is transferred to the builder container as source code, compiled with statically linked required libraries ("Java build"), and then the binary file is sent back to the peer. Static linking allows the actual chaincode container to be as small as possible. Once built, the chaincode package (tgz file) will be uploaded to the cloud storage device 560 (step 3). The builder agent sends the cloud storage location to the peer for later reference (step 4.2).

[0220] According to an embodiment, the peer 510 will then use the PSM REST API to launch the CC env as an ACLS (Access Control List) container 520. Build the chaincode image and container and launch it. The chaincode container then remains running until the peer is shut down or the channel is terminated. The peer 510 passes the chaincode ID, its own IP (for chaincode registration), and the cloud storage location to the ACLS container launch (step 4.1). The peer will wait for the chaincode to start, or time out after a set period of time. ccenv will start the chaincode. After launching, the chaincode will register itself with the peer (step 4.3). The chaincode will be ready to be called in transactions (step 5), which will be executed using the connection established at registration.

[0221] According to an embodiment, the builder container 550 includes a simple REST server. The builder container 550 includes a builder agent 553. The builder container 550 starts and listens for chaincode build requests. When the builder container 550 receives a build request (e.g., a POST call with base64-encoded source code as the body), it base64-decodes the source code and saves the chaincode source code in the local file system. The builder agent 553 then performs a "Java build" on the source code. If the "Java build" succeeds, the builder agent 553 packages the binary file and uploads it to the cloud storage device 560. The builder agent also returns the chaincode location to the peer. If the "Java build" fails, the agent returns the error and reason to the peer.

[0222] BCS Management Console

[0223] As described above, each instance of the BCS may include a management console, which may be used to manage and monitor the BCS instances, including BCS gateways, BCS nodes, and BCS channels.

[0224] According to an embodiment, a system for providing a management console may include a web application running in a scripting runtime environment, such as Node.js. The web application may be built on a graphical user interface framework and a web framework; and may include multiple custom functions or APIs to communicate with various nodes or services in a BCS instance. The web application may populate information from various nodes or services in a BCS instance into a view object for display in a console user interface. The management console may also provide administrators with the ability to start, stop, and update one or more nodes in a BCS instance. A set of management REST APIs may be provided by the scripting runtime environment, or may be accessed by the scripting runtime environment to support the same functionality as that provided by the web application.

[0225] According to an embodiment, the system may facilitate monitoring and management of associated BCS instances through a web interface provided by a web application or through a custom REST client application written using a set of management REST APIs.

[0226] According to an embodiment, the management console may enable a BCS administrator to manage multiple 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.

[0227] According to an embodiment, managing BCS components may include performing one or more of the following operations: starting a component, stopping a component, adding a component, removing a component, viewing / editing properties of a component, viewing performance metrics of a component, and viewing logs of a component.

[0228] Figure 6 A system for providing a management console according to an embodiment is illustrated.

[0229] As shown, the BCS management console 136 may be provided as a component of a BCS instance in the application container cloud service 128. The BCS management console may be a web application running in a scripting runtime environment 605, which may represent a runtime environment provided by Node.js.

[0230] According to an embodiment, within the management console, there may be a fabric node SDK 611, a plurality of fabric custom functions 613, and a plurality of ACCS APIs 615. The SDK, custom functions, and ACCS APIs may be used to communicate with a fabric network 601, which may include a distributed streaming service (e.g., Kafka) 603. The management console may also include a view object 623, which may contain information that needs to be displayed in a BCS console UI 104 or a REST client 604, or information that needs to be passed from a BCS console UI or a REST client to the management console. The fabric node SDK 611 may operate to map information from the fabric network with information from the BCS console UI or a REST client.

[0231] According to an embodiment, the BCS management console may also include a GUI framework (e.g., JET) 617 and a web framework (e.g., Express) 619. The GUI framework may provide various user interface (UI) components and elements that may be used in the management console web application. For example, these UI components and elements may be used to create forms, collect data, and visualize data. The web framework may be written in JavaScript and may provide a web application framework that includes a robust feature set for developing web and mobile applications.

[0232] Figure 7A-7B An example of a user interface in a BCS console UI according to an embodiment is illustrated.

[0233] According to the embodiment, Fig. 7A As shown in , a BCS summary 711 may be displayed in a dashboard. The summary may include the number of organizations, the number of peers, the number of orderers, the number of channels, and the number of chain codes.

[0234] According to an embodiment, health information 713 of a BCS instance may be displayed. The health information may be displayed visually and numerically. The sample UI may also display transaction execution 714 and ledger summary 715.

[0235] According to an embodiment, Figure 7B The information for all nodes in the BCS instance is illustrated. For example, the sample UI shows a total of 5 nodes, including 2 peers, 1 orderer, 1 fabric-CA, and 1 REST proxy (within the BCS gateway node). For each node, the summary UI 717 displays the name of the node 723, the node's routing information 725, the node's type 729, and the node's status information 731. The sample UI includes a button 721 for an administrator to add a node, and one or more drop-down lists 719 for filtering nodes.

[0236] Node Management

[0237] According to an embodiment, there may be two entities that can use the management console to manage a BCS instance: a BCS administrator and a BCS user. Each BCS instance has only one BCS administrator account. The BCS administrator account may be created when a BCS instance is created. The BCS administrator may be bundled with the fabric-CA administrator (i.e., all operations performed by the BCS administrator from the BCS console or through the BCS management REST API use the fabric-CA administrator identity). There may be multiple BCS user accounts, which may be created by a BCS administrator by registering a fabric-CA identity.

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

[0239] In addition, according to an embodiment, the management console may enable BCS administrators to start and stop peer nodes, orderer nodes, fabric-CA nodes, and BCS gateway nodes; as well as add and remove peer nodes, orderer nodes, and BCS gateway nodes. Fabric CA nodes cannot be added or removed.

[0240] According to an embodiment, when adding a node, the BCS administrator can set the properties of the node. The newly added node can be automatically started as part of the add operation. When a node is removed, the node will be stopped and removed from the BCS instance.

[0241] According to an embodiment, the BCS console UI may list all channels that the active peer node participates in and all chaincodes installed on the active peer node.

[0242] According to an embodiment, when managing peer nodes, a BCS administrator can add an active peer node to an existing channel and view and edit the properties of an active orderer node. A BCS user can view some of the properties of an active peer node.

[0243] Additionally, snapshot performance metrics of active peer nodes such as: memory usage, percentage of CPU used, network I / O, and disk I / O can be displayed in the BCS console UI.

[0244] According to an embodiment, when managing a sorter node, a BCS administrator can view the logs of an active sorter node, view and edit the properties of an active sorter node. A BCS user can view some of the properties of an active peer node. Similar to managing a peer node, a BCS administrator can view the following snapshot performance metrics of an active sorter node: memory usage, percentage of CPU used, network I / O, and disk I / O.

[0245] According to an embodiment, when managing a fabric CA node, a BCS administrator can view and edit the properties of an active fabric CA node, obtain a CA certificate from an active fabric CA node, and view logs of an active fabric CA node. In addition, a BCS administrator can view the following performance metrics of an active fabric node: memory usage, percentage of CPU used, network I / O, and disk I / O.

[0246] As described above, managing BCS gateway nodes may include adding or more removing BCS gateway nodes. Since the maximum number of allowed BCS gateway nodes is specified when instantiating a particular BCS instance, the number of BCS gateway nodes that can be added to a BCS instance is limited by the configured maximum number of allowed BCS gateways.

[0247] According to an embodiment, each BCS gateway node may have a name, which is a globally unique identity of the gateway node. The name may be referenced when configuring the BCS gateway node in the future. The network address may also be determined and displayed when the BCS gateway node is created.

[0248] According to an embodiment, when configuring a BCS gateway node, a BCS administrator may define a BCS gateway configuration file and boot the BCS gateway node. When a BCS instance is provisioned, no channels may be created or any chaincodes deployed. As such, the BCS gateway node is not functional until one or more chaincodes are deployed and a valid BCS gateway configuration is defined through the management console.

[0249] For each BCS gateway node, there may be a configuration page. In some embodiments, the following items may be configured in the configuration page:

[0250] 1). Channel: Select which channels to expose through the current gateway node.

[0251] 2) Chaincode: Select which instantiated chaincode to expose from the list of all instantiated chaincodes in each channel.

[0252] 3). Endorser: For each chain code, define the endorsing peers.

[0253] 4). Generate the BCS Gateway configuration according to the settings as described above. Once a valid configuration file is generated for the BCS Gateway, the gateway can be started.

[0254] According to an embodiment, the BCS console allows viewing BCS gateway properties using a list view function. In the list view, the following information is provided for each BCS gateway:

[0255] 1). Name: A globally unique name specified when creating the gateway.

[0256] 2). Architecture identity name: Each BCS gateway can be associated with an architecture client identity, which is registered and enrolled when the BCS gateway is created. All actions taken by the BCS gateway (e.g., call, query) can be granted the permissions of this architecture client.

[0257] 3). Network address: An access point with a public Internet network address.

[0258] 4). Status: On or Off

[0259] According to an embodiment, the management console also allows the BCS administrator to view the logs of active BCS Gateway nodes and view the following BCS Gateway metrics:

[0260] 1). Connected clients: client name, address, login time, etc.

[0261] 2). Current transaction information: Current transaction information may be available together with status information (i.e. the state of this transaction). Current transaction information may be useful when debugging a suspended transaction.

[0262] 3). Transaction statistics: Transaction statistics may be available through the management console UI. For example, transaction statistics may include the number of completed transactions, the number of event notifications received, and the number of event notifications delivered.

[0263] 4). Memory usage.

[0264] 5).CPU percentage.

[0265] 6). Network I / O.

[0266] 7).Disk I / O.

[0267] Channel Management

[0268] According to an embodiment, a BCS user can list all channels that the current BCS instance participates in. A BCS administrator can create a channel using a channel name, a consortium name, and one or more organization names as input. Output can also be displayed to indicate the success or failure of the channel creation.

[0269] According to an embodiment, a BCS user can view the participating nodes and organizations of a channel. The management console can support two view modes: list mode and topology mode. In list mode, participating local nodes and external organizations (represented by their anchor peers) can be listed as a list. In topology mode, participating local nodes and external organizations (represented by their anchor peers) can be represented in a topology map.

[0270] According to an embodiment, a BCS administrator can query the ledger of peers in a channel. The ledger can consist of a list of transaction blocks, each of which can contain a block ID, a previous hash, a data hash, a timestamp, a list of transaction IDs, an action (1..n), a chaincode ID, a chaincode proposal, a response (r / w set, event, success or failure), and one or more endorsers. The following statistics can also be displayed: the number of blocks and the number of calls.

[0271] According to an embodiment, a BCS administrator can list all chaincodes instantiated in a channel. The listed items can include the chaincode ID and version. The BCS administrator can also view the following information of the instantiated chaincode: Path, which is the path specified by the instantiated transaction; and instantiation parameters.

[0272] According to an embodiment, a BCS administrator can upgrade an instantiated chaincode in a channel. The upgrade operation can take the following inputs: a target endorsing peer that has a new version of the chaincode installed; one or more orderers; the chaincode version; and arguments, which can optionally be an array of String arguments specific to the chaincode. The output of the upgrade operation can be success or failure with an error message.

[0273] Chain code management

[0274] According to an embodiment, a BCS administrator can list all chaincodes installed on any peer of the current BCS instance. The listed items include the chaincode ID and version. In addition, the BCS administrator can also view the following information of the installed chaincode: the local peer node with the installed chaincode, and the channel where the chaincode has been instantiated.

[0275] According to an embodiment, through the management console, the BCS administrator can install the chaincode to one or more local peer nodes. The input of the installation operation can include: the target peer; the chaincode type, such as golang / 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 the chaincode package, which is optional. The output of the installation operation may be success, or failure with an error message.

[0276] According to an embodiment, a BCS administrator may instantiate an installed chaincode to a channel with the following information as input: a channel name; a target endorsing peer on which the chaincode is installed; an orderer; parameters, which may be optional and may be a String array parameter specific to the chaincode; and an endorsement policy, which may have a defined format or a default format in the absence of a defined format.

[0277] Membership Management

[0278] According to an embodiment, the BCS administrator can list all identities in the current BCS instance, register new users / identities for the current BCS instance, deregister identities, and remove users from the current BCS instance. In addition, the BCS administrator can view / edit the following attributes of an identity, as shown in Table 1:

[0279]

[0280] Table 1

[0281] According to an embodiment, the management console enables a BCS user to register or re-register the user himself, which can generate a private key and certificate for the user. The management console also enables a BCS administrator to revoke a previously registered identity and enables a BCS user to change its password.

[0282] According to an embodiment, the BCS management console may be started or stopped together with the start or stop of the associated BCS instance.

[0283] According to an embodiment, there are two ways to set the log level of the BCS Management Console: from the BCS Management Console itself, and using the Management REST API to change the log level at runtime.

[0284] REST API

[0285] As mentioned above, the communication between different components within the fabric network is based on the gRPC protocol. As such, a BCS instance based on the fabric network will require the client application to use the fabric SDK to call the chain code in the BCS instance.

[0286] Requiring client applications to use a framework SDK to communicate with a blockchain cloud service can partially offset the benefits of providing a blockchain framework as a cloud service. For example, one of the benefits is that a cloud service should be accessible from anywhere with an internet connection.

[0287] According to an embodiment, the systems and methods described herein can provide a REST proxy within a BCS instance. The REST proxy can provide multiple REST APIs for REST clients to use to query through chaincode, synchronously or asynchronously call transactions through chaincode, obtain transaction status, and obtain BCS proxy version. The REST proxy can authenticate REST calls from REST calls and convert REST calls into GRPC calls. The REST proxy also provides REST APIs that support the same functions provided by the BCS management console.

[0288] According to an embodiment, the REST proxy provides a user interface for client applications to consume BCS instances.

[0289] Figure 8 A system for providing a REST proxy in a BCS instance according to an embodiment is illustrated.

[0290] like Figure 8 As shown in , the REST proxy 138 may include a REST authenticator 827 and a protocol converter 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 may authenticate the call to determine whether the REST call includes a valid username and a valid password to allow REST access to the BCS instance.

[0291] According to an embodiment, if the REST call is authenticated by the LBaaS, the LBaaS may direct the REST call to a REST proxy, which may forward the REST call 835 to the IDCS 813 to determine whether the client application has been granted proper authorization with respect to the BCS.

[0292] According to an embodiment, if the client application is properly authorized, the REST proxy can transform / convert the REST call into a gRPC call 825 and send the GRPC call to the fabric network 601. Once the REST call is transformed / converted into an internal call (gRPC), it can be connected to an instance of the blockchain fabric / hyperledger.

[0293] According to an embodiment, the REST call may be transformed by a protocol converter, which may be a Java application based on the architecture Java SDK 831 with the GRPC library 833.

[0294] like Figure 8 As further shown in , the REST proxy can communicate with the management console using REST 821 as described above to expose one or more functions provided by the REST API 823 to the management console.

[0295] Example REST API

[0296] According to an embodiment, before calling the REST API for a BCS instance, the REST proxy needs to be started and running. The status of the REST proxy can be checked through the management console. If the REST proxy is not started and running, it needs to be started from the management console.

[0297] According to an embodiment, a REST API may be called to interact with a smart contract (chain code) deployed on a peer node in a BCS instance. The deployment process may be completed through a management console.

[0298] According to an embodiment, example REST APIs are provided, which are provided for illustration purposes. The examples used herein assume that the following example chaincode is deployed to the BCS network.

[0299]

[0300] According to an embodiment, further, an example management console is provided. If the REST proxy is not started and running, it can be started from the management console.

[0301] According to an embodiment, a REST API may be called to interact with a smart contract (chain code) deployed on a peer node in a BCS instance. The deployment process may be completed through a management console.

[0302] According to an embodiment, example REST APIs are provided, which are provided for illustration purposes. The examples used herein assume that the following example chaincode is deployed to the BCS network.

[0303] According to an embodiment, the REST API provides the following functions: Query by chaincode; Invoke transaction by chaincode; Invoke transaction asynchronously by chaincode; Get transaction status; and Get BCS gateway version. The client accesses the BCS gateway using HTTPS and utilizes the message format according to the API in order to perform these functions.

[0304] According to an embodiment, the chaincode is called through the "query" function of the chaincode to perform a query action. The chaincode and the parameters for the query are specified through the REST API. Get transaction status - This REST API queries the transaction status in the channel. The channel and transaction ID are specified through the REST API. Get gateway version. This REST API returns the gateway version information.

[0305] According to an embodiment, through the "call transaction" function of the chain code. The REST API calls the chain code to perform the transaction action, and the chain code and the call parameters are specified through the REST API. The REST API executes the transaction in synchronous mode, which means that a response is sent back in any of the following three situations: the transaction is successfully executed; the transaction fails to complete; or the transaction times out.

[0306] According to an embodiment, through the "asynchronous call transaction" function of the chain code. The REST API calls the chain code to perform the transaction action, and the chain code and the call parameters are specified through the REST API. The REST API executes the transaction in asynchronous mode, which means that the response / confirmation is sent back immediately after the transaction is submitted without waiting for it to complete or time out. The result can be provided subsequently. A BCS instance management REST API is provided to support the same functions provided by the BCS console (described below).

[0307] Fabric Certificate Authority (Fabric CA) integrated with Identity Cloud Service (IDCS)

[0308] According to an embodiment, the architecture-CA server provides membership services for the architecture. It includes three parts: authentication for users, authorization for access to the blockchain (a set of peers and orderers), and a CA server that can provide certificates to application clients, peers, and orderers. Architecture-CA uses certificates to implement authentication and authorization. Certificates include two types: registration certificates for authentication and transaction certificates for authorization. IDCS also provides authentication and authorization. But its authorization is implemented by OAuth. This means that if a peer wants to access the orderer, the peer should obtain the user's access token from IDCS and use this token to access the orderer.

[0309] According to an embodiment, the architecture CA uses a database or LDAP to store information of registered users of the architecture CA, such as the user's name / password, the user's certificate, and the user's affiliation. The end user of the public cloud (OPC) will apply a centralized IDCS instance to manage its employees to access the public cloud (OPC) instances of all its applications. The blockchain cloud service BCS is preferably integrated with the IDCS for other cloud services. Therefore, the end user can apply a centralized IDCS instance to manage its employees to access all public cloud (OPC) instances of its applications, including BCS.

[0310] In one embodiment, Blockchain Cloud Service (BCS) uses Oracle Identity Cloud Service (IDCS) to store user information in a centralized manner. BCS stores the information of the framework CA users in IDCS, allowing Oracle BCS to use IDCS to manage the centralized BCS user information across multiple public cloud service instances. Therefore, in an embodiment, the information and certificates of the BCS framework CA users are stored in Oracle IDCS. The framework certificate authority framework is a framework membership provider (MSP), which includes PKI private keys, signed certificates, CA certificate chains, and is set by the framework CA client / server.

[0311] According to an embodiment, BCS makes full use of OPC's user management. Any BCS user must first be an OPC user (and therefore an IDCS identity). When a BCS instance is created, several types of applications are created: BCS console, CA, and REST proxy. For the console, there are two application roles: console administrator and console user. For the CA, there are four application roles: architecture administrator, architecture client, architecture peer, architecture sorter. For the REST proxy, there are two application roles: gateway administrator and gateway user.

[0312] According to an embodiment, in order to become a BCS user, an OPC user needs to be granted certain BCS application roles in the OPC user management console.

[0313] When creating a BCS instance, the creator needs to provide an existing OPC user / password and this user will be automatically granted the BCS Console Administrator and Schema Administrator roles, making this user a BCS Administrator.

[0314] Authentication - For BCS console / CA / REST agent, authentication is done at Cloud Gate. For peers / orderers, authentication is signature based. For BCS console, after authentication, the console will get the current user's application role (by calling IDCS). If the user is not granted the console administrator or console user role, then the connection is rejected. Otherwise, the console performs access control based on predefined rules, for example, ordinary users can generally only read information while administrators can do everything.

[0315] According to an embodiment, for CA, after authentication, CA obtains the application role of the current user. If the user is not granted any framework role, the registration request is rejected.

[0316] According to an embodiment, for a REST proxy, after authentication, the REST proxy obtains the application role of the current user. If the user is not granted the gateway administrator or gateway user role, the request is rejected. Otherwise, the REST proxy performs access control based on predefined rules, for example, ordinary users can call / query, and administrators can change configurations and obtain metrics.

[0317] According to an embodiment, the fabric-CA server provides membership services for the fabric. It includes three parts: authentication for users, authorization for access to the blockchain (a set of peers and orderers), and a CA server that can provide certificates to application clients, peers, and orderers.

[0318] According to an embodiment, the architecture-CA uses certificates to implement authentication and authorization. Certificates include two types: enrollment certificates for authentication and transaction certificates for authorization.

[0319] According to an embodiment, IDCS also provides authentication and authorization. But its authorization is implemented by OAuth. This means that if a peer wants to access the sorter, the peer should obtain the user's access token from IDCS and use this token to access the sorter.

[0320] Fig.9A A typical IDCS use case for single sign-on according to an embodiment is illustrated.

[0321] According to an embodiment, a web application 901 may be added to IDCS 902 in an initial step. A client such as a web browser 900 may then request authentication (e.g., username and password) from the web application. Because the web application has been added to IDCS, the web application may instruct the web browser to issue an authentication request to IDCS. After receiving a response from the web application, the web browser may then request authentication (e.g., username and password) from IDCS.

[0322] IDCS can then authenticate the request and, upon successful authentication, send a token back to the web browser. Having authenticated and received its token, the web browser can make requests from the web application. The web application can verify the token and signal to the web browser that the authentication was successful.

[0323] exist Fig.9A In the scenario depicted in Figure 1, IDCS acts as an identity provider (IdP) to provide identity services to applications. All communications between all parties are based on HTTP. This use case is configuration-driven but only applies to HTTP-based applications.

[0324] Fig. 9BAn IDCS use case for fabric client authentication according to an embodiment is shown.

[0325] According to an embodiment, an architecture client 904 associated with an already registered and enrolled architecture user (whose private key and certificate are already stored in the state repository on the client side) can request a new client () and obtain the user context of the client (user name). The architecture SDK 905 can load the user from the state repository and return the user object to the architecture client. After receiving the user object, the client can send a transaction proposal to the architecture SDK, which can sign the proposal using the same private key. The signed proposal can then be forwarded to the peer (or multiple peers) 906, which will verify the signature at the membership service 907. The membership service can obtain the user's certificate from IDCS 902, and can use the certificate from IDCS to verify the user's signature. The membership service can then return a verification that the signature has been verified to the peer.

[0326] Support for rich SQL-based queries in the Hyperledger Architecture blockchain

[0327] According to an embodiment, the system and method can support a relational engine for world state persistence in a blockchain world. It also provides the ability to query the key / value pair engine using SQL and verify the result at submission by calculating the merkle tree stored in the transaction payload.

[0328] According to an embodiment, the systems and methods provided herein provide the ability to execute SQL queries to allow complex smart contracts to be created in an easier and more maintainable manner. In addition, performance is improved by pushing data filtering back to the storage engine (rather than happening at the smart contract level) and by being able to rely on a relational engine that supports concurrent read and write data access.

[0329] Fig.10 A system for supporting a world state database in an architecture blockchain according to an embodiment is shown.

[0330] According to an embodiment, the world state database 1000 may include a versioned database provider 1005 and a versioned database 1010. In a typical Hyperledger blockchain architecture, as well as other blockchain architectures, the world state database contains a key-value pair database—that is, each "value" in the database is paired with a "key" that can be used to look up the value.

[0331] According to an embodiment, for each transaction that changes the blockchain, the world state updates the version. The transaction manager 1015 controls access to the world state database. That is, the transaction manager adjusts the write / read hold of the world state database. The validator 1020 is an entity responsible for verifying that the data is still consistent when, for example, a smart contract is trying to submit a transaction. The execution of the transaction is divided between endorsements (e.g., execution and verification (submission)). Execution (endorsement) is a simulation of what the transaction will become if the transaction is submitted-this is part of the transaction that accesses the world state database. Verification occurs later at submission. The transaction must collect a large number of endorsements through multiple nodes executing chain codes, and once the transaction has enough endorsements to satisfy the policy on the ledger that the transaction is trying to update, the transaction can move to the submission stage. Generally speaking, there is a period of time between the two stages of the transaction. Verification obtains information from the endorsement and verifies that the information is still valid. If everything is still good, then the transaction is submitted and the world state is updated.

[0332] According to an embodiment, a plurality of operations 1030 may be performed in association with the world state database. These operations include, but are not limited to, GetState, GetStateMultipleKey, GetStateRange, ExecuteQuery, GetLatestSavepoint, ApplyUpdates. Likewise, a plurality of operations 1035 may be performed in association with the transaction manager. These include, but are not limited to, Simulator, QueryExecutor, ValidateAndPrepare, and Commit.

[0333] As an example, the world state database can show the current balance of every Bitcoin user. This is a consistent snapshot of the current world state.

[0334] According to an embodiment, in a hyperledger, the world state is captured in a persistence engine. It cannot be accessed from the outside, but can be accessed internally by the blockchain. Smart contracts within the blockchain—transactions can access the world state database.

[0335] According to an embodiment, for example, a smart contract may be written to send a certain amount of money from party A to party B over a period of time. A smart contract may also be written to ensure that before the money can be sent, party B must meet a certain condition, such as transferring ownership of a piece of property to party A. A smart contract may also be written to ensure that party A receives ownership before any funds are sent from party A to party B.

[0336] According to an embodiment, smart contracts rely on a world state database. A smart contract can query the current balance of account A, the current balance of account B, and the current ownership of the property to be transferred. All of this is done by checking the world state database. Smart contracts are stored procedures. The underlying data can be thought of as a set of underlying tables to be accessed.

[0337] According to an embodiment, the world state database is stored in a fast key-value store. Such a database works by associating a value with a key given a tag (key). For example, a balance can be associated with a key. As another example, a picture (bitmap) can be associated with a key... and so on. Generally speaking, such a persistence engine is very fast.

[0338] However, according to an embodiment, there are limitations on such persistence engines because such systems only support search mechanisms. For example, they cannot provide rich queries, such as comparisons between multiple values. For example, a key-value persistence engine cannot process a query requesting the account name with the highest balance among 10,000 different accounts. Such a persistence engine also cannot perform functions, such as maximum (max), minimum (min) or average (average) for the values ​​stored therein. For example, a key-value persistence engine cannot provide the average balance of users within a period of X months in response to such a query. Instead, a script or smart contract must be written to extract each value from a key-value pair, and then the query is run for each extracted value. Such limitations on key-value persistence engines make it difficult and cumbersome to write smart contracts because such smart contracts must handle the inherent limitations provided on the key-value storage library.

[0339] Likewise, according to an embodiment, the key-value persistence engine does not support the ability to run read and write transactions concurrently. During reads, write locks are implemented so that values ​​are not changed during read transactions. Likewise, during writes, read locks are implemented so that any values ​​to be written are not mistakenly read during write operations. Such read and write locks introduce further limitations to traditional key-value storage persistence engines.

[0340] According to embodiments, systems and methods may provide a relational database or other persistence engine that allows rich queries (eg, SQL) rather than a key-value persistence engine.

[0341] According to an embodiment, when a blockchain architecture such as the Hyperledger blockchain architecture is provided with access to a relational database, this allows users and smart contracts to go beyond the limitations of a key-value store. Such a database may include support for MVCC (multi-version concurrency control), snapshots (allowing the creation of data snapshots, but not blocking users / operations from writing to the database). This may improve performance and availability, as well as simplify coding / writing smart contracts and other transaction processing that would need to query a persistence engine.

[0342] Fig.11 A system for supporting SQL-based rich queries in a blockchain architecture according to an embodiment is illustrated.

[0343] According to an embodiment, a system for supporting SQL-based rich queries in a blockchain architecture may include a world state database 1100, which may include a relational database interface 1102, a versioned database provider 1105, and a versioned database 1110. Likewise, a transaction manager 1115 and a validator 1120 may be provided. From a traditional system, the world state interface, the transaction manager, and the validation engine are all updated.

[0344] According to an embodiment, the transaction manager and validation engine (e.g., validator 112) are built against the same interface supported by the Hyperledger architecture, but rely internally on create and commit relational transactions. Likewise, the versioned database provider and versioned database include transaction-aware versioned databases. This is similar to versioned databases, but they are stored in a transactional manner. This can allow transactions to be created in read / write mode, and the database internals will handle such cases without placing a read / write hold.

[0345] Likewise, according to an embodiment, a relational database interface 1102 is provided. The interface may include an abstraction that allows a user (e.g., a smart contract) to plug any relational engine desired into the system. Examples include Oracle, SQL, or any other database that supports SQL and transactions (e.g., SQL Lite). In an embodiment, Berkeley DB is supported, which allows a relational layer that allows contracts to interact with a versioned database in a relational manner. According to an embodiment, BerkeleyDB is an embedded database, which may improve performance.

[0346] According to an embodiment, unlike locking methods used for databases such as LevelDB and / or Couch DB, the transaction manager may be aware of database transactions.

[0347] According to an embodiment, each channel can share the same versioned database (e.g., SQLite). Each database can contain multiple tables; each table is mapped to a versioned database (e.g., Berkeley DB). BDB can be made to persist multiple databases into a single file on the file system.

[0348] According to an embodiment, channels can share a table - channel_height, which contains the current height / save point of all channels. The table has 4 columns: key, value, blockNo and txnNo; the key is used for the channel name; blockNo and txnNo describe the current height of the channel.

[0349] According to an embodiment, each channel is also associated with a "state" table for each (system and user) chaincode instantiated on that channel. This table is named <channelname> __ <chaincodename>The table has 5 columns: key, value, valueJson, blockNo, and txnNo. "key" is the name of the key set to the world state; "value" is the value of the key when the value cannot be parsed as a valid json; "valueJson" is the value of the key when the value can be parsed as a valid json; "blockNo" and "txnNo" represent the current height stored for the corresponding key.

[0350] According to an embodiment, the table is created immediately when a channel is created and when the chaincode is deployed.

[0351] According to an embodiment, execution of rich queries against the BDB world state is performed through chaincode using the shim API.The expression specified in the GetQueryResult() function may be a valid SELECT SQL expression.

[0352] According to an embodiment, there are no restrictions in the specified SELECT expression, except that the table that can be accessed by the expression is a table representing the world state associated with the channel / chaincode combination to which the currently executing chaincode is bound.

[0353] According to an embodiment, a user does not need to know the internal name used to represent the world state associated with a particular channel / chaincode pair; instead, the user uses " <state>" placeholder (not case sensitive) refers to the table name. For example, this expression retrieves the value associated with the key "key1": SELECT * FROM <state>WHERE key = 'key1' (for records, keywords in SQL expressions are not case sensitive).

[0354] According to an embodiment, attempting to execute a rich query that is not a SELECT expression, or attempting to access a table other than the table associated with the channel / chaincode bound to the currently executing chaincode, will return an error.

[0355] According to an embodiment, the results returned by GetQueryResult() are consistent with what the framework already supports for queries executed against CouchDB: the result is an iterator where each consumed iterable contains a key and a json payload. In the case of BDB enriched query results, the key names may take the form of "__sqlresult_X" - where X is the zero-based index of the returned iterable, and the json payload is a jsonified version of the result set returned by that query iteration. In other words, a json map where each property name corresponds to each returned column name in the SQL result set, and each property value corresponds to the value returned for that column in the current iteration.

[0356] According to an embodiment, the following provides an example that iterates through all returned marble IDs for a given color (error handling omitted):

[0357] coloredMarbleIterator,err:=stub.GetQueryResult("SELECT key FROM <state>

[0358] WHERE json_extract(valueJson,'$.color')='"+color+"'")

[0359] defer coloredMarbleIterator.Close()

[0360] / / Iterate through the result set, and for each marble found, transfer to newOwner

[0361] for coloredMarbleIterator.HasNext(){

[0362] queryResponse,err:=coloredMarbleIterator.Next()

[0363] / / Of course, there are different ways to do this, but golang allows users to directly

[0364] Unmarshal json strings into structs - this is convenient

[0365] key:=&struct{Key string}{}

[0366] json.Unmarshal([]byte(queryResponse.Value),&key)

[0367] returnedMarbleID:=key.Key

[0368] fmt.Printf("-found a marble ID:%s\n",returnedMarbleID)

[0369] }

[0370] In accordance with an embodiment, the system and method may perform full validation on the enriched query results at submission time. At endorsement time, a merkle tree hash is calculated for all results consumed from a GetQueryresult() call and stored as part of the transaction payload - along with the full SQL expression. At submission time, the SQL expression associated with the enriched query executed at endorsement time is re-executed and its merkle tree hash is incrementally checked against the merkle tree hash calculated at endorsement time. The validator consumes query results until the same index consumed at endorsement time is reached, or until the iterator is exhausted. If the merkle tree hashes match, and if the exhaustion state of the iterator matches at the end of the query, then the enriched query is validated; otherwise, the transaction is marked as invalid due to a phantom read error.

[0371] According to an embodiment, BDB supports MVCC (Multi-Version Concurrency Control) and snapshot isolation levels for transactions. Therefore, the system and method can take advantage of the ability to perform concurrent read / write transactions.

[0372] Fig.12 is a flowchart of a method for supporting SQL-based rich queries in a blockchain architecture according to an embodiment.

[0373] At step 1201, the method may provide an enterprise-level distributed ledger framework at one or more computers including a microprocessor.

[0374] At step 1202, the method may execute a distributed ledger architecture within a distributed ledger framework, the distributed ledger architecture comprising at least a transaction manager and a validator.

[0375] At step 1203, the method may associate a world state database with the distributed ledger architecture, the world state database comprising a versioned database and a relational database interface.

[0376] Although various embodiments have been described above, it should be understood that they are presented by way of example and not limitation. The embodiments are selected and described in order to explain the features and principles of the present teachings and their practical applications. The embodiments illustrate systems and methods that utilize various features to improve the performance of systems and methods by providing new and / or improved functionality and / or providing performance advantages including, but not limited to, reduced resource utilization, increased capacity, increased throughput, improved efficiency, reduced latency, enhanced security, and / or improved ease of use.

[0377] Some embodiments are described herein with reference to flowcharts and / or block diagrams of methods, devices (systems) and computer program products for illustrating architectures, functions, processes and / or operations. Each box in a flowchart or block diagram represents a part of an element, function, process, module, fragment or instruction, which includes one or more executable instructions for implementing a specified function. In some alternative embodiments, the functions mentioned in the block diagram or flowchart do not occur in the order shown in the figure. For example, depending on the functions involved, two boxes shown in succession can be executed substantially simultaneously, or in reverse order. Each box in a flowchart and / or block diagram and the combination of boxes in a flowchart and / or block diagram can be implemented by a combination of computer program instructions and / or dedicated hardware and / or hardware and computer program instructions that perform a specified function.

[0378] In some embodiments, features are implemented in a computer including a processor, a computer-readable medium, and a network card / interface for communicating with other computers. In some embodiments, features are implemented in a network computing environment including a computing system that includes various types of computer configurations, including personal computers, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and links interconnected by a network. The network can be a local area network (LAN), a switched 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 transmissions, routers, firewalls, switches, gateway computers, and / or edge servers.

[0379] In some embodiments, features are implemented in a computing system that includes a back-end component (e.g., as a data server), or includes a middleware component (e.g., an application server), or includes a front-end component (e.g., a client computer with a graphical user interface or a web browser through which a user can interact with an implementation of the subject matter described herein), or includes any combination of such back-end, middleware, or front-end components. Interconnected by a network. The computing system may include clients and servers that have a client-server relationship to each other. In some embodiments, features are implemented in a computing system that includes a distributed computing environment in which one or more clusters of computers are connected by a network. The distributed computing environment may have all computers located in a single location, or have clusters of computers at different remote geographical locations connected by a network.

[0380] In some embodiments, features are implemented in the cloud as part of a cloud computing system or as a service of a cloud computing system, based on shared elastic resources delivered to users in a self-service, metered manner using web technologies. Characteristics of the cloud may include, for example: on-demand self-service; broad network access; resource pooling; rapid elasticity; and measured services. Cloud deployment models include: public, private, and hybrid. Cloud service models include software as a service (SaaS), platform as a service (PaaS), database as a service (DBaaS), and infrastructure as a service (IaaS). Cloud generally refers to a combination of hardware, software, network, and web technologies that deliver shared elastic resources to users. As used herein, a cloud may include public, private, and / or hybrid cloud embodiments, and may include cloud SaaS, cloud DBaaS, cloud PaaS, and / or cloud IaaS deployment models.

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

[0382] In some embodiments, features are incorporated into software and / or firmware for controlling the hardware of a processing and / or network system, and for enabling a processor and / or network to interact with other systems utilizing these features of the present teachings. 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. Based on the teachings of the present disclosure, a skilled programmer can readily prepare appropriate software coding.

[0383] In some embodiments, the present teaching method includes a computer program product, which is a machine-readable or computer-readable medium (multiple media) having instructions including software and / or firmware stored thereon / therein or carried therein / by it, which can be used to program or otherwise configure a system such as a computer to perform any process or function of the present teaching method. The machine-readable or computer-readable medium may include a storage medium, which may include any type of medium or device suitable for storing instructions and / or data, including but not limited to a floppy disk, a hard disk drive, a solid-state drive, an optical disk, a DVD, a CD-ROM, a microdrive, and a magneto-optical disk, a ROM, a RAM, an EPROM, an EEPROM, a DRAM, a VRAM, a flash memory device, a magnetic card or an optical card, a molecular memory, a nanosystem, or a variant and combination thereof. In a particular embodiment, the storage medium or computer-readable medium is a non-transient machine-readable storage medium or a non-transient computer-readable storage medium. The machine-readable or computer-readable medium may also or alternatively include a transient medium such as a carrier or a transmission signal.

[0384] Thus, from one perspective, systems and methods for supporting rich SQL-based queries in a blockchain architecture have been described. According to an embodiment, the systems and methods provided herein provide the ability to execute SQL queries to allow complex smart contracts to be created in an easier and more maintainable manner. In addition, performance is improved by pushing data filtering back to the storage engine (rather than happening at the smart contract level) and by being able to rely on a relational engine that supports concurrent read / write data access. Likewise, the world state database can also provide concurrent read / write access.

[0385] Other examples of the present teachings are listed in the following numbered clauses:

[0386] Item 1. A system for supporting SQL-based rich queries in a blockchain architecture, comprising: an enterprise-level distributed ledger framework; a distributed ledger architecture comprising at least a transaction manager and a validator; and a world state database comprising a versioned database and a relational database interface.

[0387] Clause 2. The system of clause 1, wherein the relational database interface provides a relational database interface layer between the versioned database and one or more transactions operating on the distributed ledger architecture.

[0388] Clause 3, a system as described in clause 2, wherein at least one transaction of the one or more transactions includes at least one enriched query.

[0389] Clause 4. The system of clause 3, wherein the at least one enriched query accesses the versioned database via the relational database interface.

[0390] Clause 5, a system as described in Clause 2 or 3, wherein the world state database provides concurrent read / write access.

[0391] Clause 6, a system as described in clause 3 or any clause related thereto, wherein the at least one enriched query includes a chain code.

[0392] Clause 7. A system as described in any preceding clause, wherein the distributed ledger architecture is provided as a blockchain cloud service, the blockchain cloud service comprising a peer container, a sorting container, and a chaincode container.

[0393] Clause 8. A method for supporting SQL-based rich queries in a blockchain architecture, comprising: providing an enterprise-level distributed ledger framework at one or more computers including a microprocessor; operating a distributed ledger architecture within the distributed ledger framework, the distributed ledger architecture comprising at least a transaction manager and a validator; and associating a world state database with the distributed ledger architecture, the world state database comprising a versioned database and a relational database interface.

[0394] Clause 9. The method of clause 8, wherein the relational database interface provides a relational database interface layer between the versioned database and one or more transactions operating on the distributed ledger architecture.

[0395] Clause 10, the method of clause 9, wherein at least one of the one or more transactions comprises at least one enriched query.

[0396] Clause 11. The method of clause 10, wherein the at least one enriched query accesses the versioned database via the relational database interface.

[0397] Clause 12, a method as described in Clause 9, 10 or 11, wherein the world state database provides concurrent read / write access.

[0398] Clause 13. The method of clause 10 or any claim related thereto, wherein the at least one enriched query comprises a chain code.

[0399] Clause 14. A method as described in any one of clauses 8 to 13, wherein the distributed ledger architecture is provided as a blockchain cloud service, the blockchain cloud service comprising a peer container, a sorting container, and a chaincode container.

[0400] Clause 15. A computer-readable medium having instructions thereon for supporting SQL-based rich queries in a blockchain architecture, comprising: when read and executed, causing one or more computers to perform steps comprising: providing an enterprise-level distributed ledger framework at one or more computers including a microprocessor; operating a distributed ledger architecture within the distributed ledger framework, the distributed ledger architecture comprising at least a transaction manager and a validator; and associating a world state database with the distributed ledger architecture, the world state database comprising a versioned database and a relational database interface.

[0401] Clause 16. The computer-readable medium of Clause 15, wherein the relational database interface provides a relational database interface layer between the versioned database and one or more transactions operating on the distributed ledger architecture.

[0402] Clause 17. The computer-readable medium of clause 16, wherein at least one transaction of the one or more transactions comprises at least one enriched query.

[0403] Clause 18. The computer-readable medium of Clause 17, wherein the at least one enriched query accesses the versioned database via the relational database interface.

[0404] Clause 19. The computer-readable medium of clause 16, 17, or 18, wherein the world state database provides concurrent read / write access.

[0405] Clause 20. A computer-readable medium as described in any of clauses 15 to 19, wherein the distributed ledger architecture is provided as a blockchain cloud service, the blockchain cloud service comprising a peer container, a sorting container, and a chaincode container.

[0406] The foregoing description is not intended to be exhaustive or to limit the scope to the precise form disclosed. In addition, where an embodiment has been described using a particular series of transactions and steps, it should be clear to those skilled in the art that, unless otherwise stated, the embodiment does not exclude the execution of additional transactions and steps. In addition, although various embodiments describe specific combinations of features, it should be understood that different combinations of these features will be clear to those skilled in the relevant art within the scope of this teaching and scope. Specifically, the features (similar devices or similar methods) shown in a given embodiment, variant, or figure can be combined with or replaced with another feature in another embodiment, variant, or figure without departing from the teaching and scope. Moreover, it is clear to those skilled in the relevant art that various additions, reductions, deletions, changes, replacements of elements with equivalents, and other modifications and changes in form, details, implementation, and application can be made therein without departing from the spirit and scope of the present disclosure. The broader spirit and scope of protection are intended to be defined by the following claims and their equivalents.< / state> < / state> < / state> < / chaincodename> < / channelname>

Claims

1. A system for supporting SQL-based rich queries in a blockchain, comprising: Distributed ledger platform; A distributed ledger architecture running within the distributed ledger platform, the distributed ledger architecture comprising at least a transaction manager and a validator; A blockchain running on the distributed ledger platform, wherein the blockchain includes a ledger of multiple blocks, each block including multiple key-value pairs; as well as a world state database comprising a relational database interface and a versioned database, wherein the world state database is accessible by the blockchain; and Wherein the relational database interface provides a relational database interface layer between the versioned database of the world state database and one or more smart contracts running on the blockchain.

2. The system of claim 1, wherein at least one of the one or more smart contracts comprises at least one enriched query.

3. The system of claim 2, wherein the at least one enriched query accesses the versioned database via the relational database interface.

4. The system of claim 2 or 3, wherein the at least one enriched query comprises a chain code.

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

6. The system of any one of claims 1 to 3, wherein the distributed ledger architecture is provided as a blockchain cloud service, the blockchain cloud service comprising: peer container, sorting containers, and Chaincode container.

7. A method for supporting SQL-based rich queries in a blockchain, comprising: Provided at one or more computers including a microprocessor Distributed ledger platform, and A blockchain running on the distributed ledger platform, wherein the blockchain includes a ledger of multiple blocks, each block including multiple key-value pairs; Running a distributed ledger architecture within the distributed ledger platform, the distributed ledger architecture comprising at least a transaction manager and a validator; as well as associating a world state database with the distributed ledger architecture, the world state database comprising a relational database interface and a versioned database, wherein the world state database is accessible by the blockchain; and Wherein the relational database interface provides a relational database interface layer between the versioned database of the world state database and one or more smart contracts running on the blockchain.

8. The method of claim 7, wherein at least one of the one or more smart contracts includes at least one enriched query.

9. The method of claim 8, wherein the at least one enriched query accesses the versioned database via the relational database interface.

10. The method of claim 8 or 9, wherein the at least one enriched query comprises a chain code.

11. The method of any one of claims 7 to 9, wherein the world state database provides concurrent read / write access.

12. The method according to any one of claims 7 to 9, wherein the distributed ledger architecture is provided as a blockchain cloud service, the blockchain cloud service comprising peer container, sorting containers, and Chaincode container.

13. A computer-readable medium carrying instructions for supporting SQL-based rich queries in a blockchain, comprising: When read and executed, one or more computers are caused to perform the method as claimed in any one of claims 7 to 12.

Images