JP2022174127A - DAG-based transaction processing method and system in distributed ledger - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a DAG-based transaction processing system and a method in a distributed ledger.

SOLUTION: A method comprises the steps of: accessing, by a client 160, by use of a fabric SDK 162, a fabric certificate authority 172 to obtain a registration certificate; accessing a peer container 180 to obtain a signed read/write set from an endorser 182; submitting a signed transaction, including the read/write set and the signature of the endorser, to an ordering container 190; distributing, by the ordering container 190, a transaction batch to a committer 184 in the peer container 180; and modifying a ledger 186 and a world state 188 by the committer 184.

SELECTED DRAWING: Figure 1A

COPYRIGHT: (C)2023,JPO&INPIT

Description

COPYRIGHT NOTICE A portion of the disclosure of this patent document contains material that is protected by copyright. As this patent document or patent disclosure appears in the Patent and Trademark Office patent file or records, the copyright holder has no objection to any reproduction by anyone, but otherwise reserves all copyright rights. .

PRIORITY CLAIM This application is filed on Jan. 29, 2019 and entitled "DAG-Based Transaction Processing Method And System In A Distributed Ledger," U.S. Patent Application No. 16/261,371 and dated Aug. 24, 2018. and claims the benefit of priority under U.S. Provisional Patent Application No. 62/722,595, entitled "DAG-Based Transaction Processing Method and System in Distributed Ledgers," each of which is incorporated herein by reference in its entirety. incorporated into the specification.

FIELD The present disclosure relates generally to systems and methods for providing distributed ledgers. More particularly, this disclosure discloses a Directed Acyclic Graph (DAG) based transaction processing method and system and components thereof in a distributed ledger.

Background Distributed ledgers are loosely referred to as digital records of asset ownership. A ledger has no central administrator and no central data store. Instead, the ledger is replicated across many participating nodes that may be geographically distributed across multiple locations, multiple countries, or multiple facilities in the computing environment. Consensus protocols ensure the identity of each node's copy of the ledger with every other node's copy. Similarly, a set of copies may be viewed as one shared ledger. Asset owners can use the distributed ledger to post the liabilities of some asset owners' accounts and assess the creditworthiness of other asset owners' accounts, for example, based on cryptographic signature technology. .

Blockchain is a data structure that can be used to implement a tamper-proof distributed ledger. Multiple nodes follow a common protocol that packages transactions from clients into blocks, and the nodes use a consensus protocol to agree on the next block. Blocks have a cumulative cryptographic hash, making it difficult to tamper with the ledger. Each block has a reference value (hash value) of the previous block in time. Each block also has its own hash value. A blockchain can be traversed backwards (e.g., up the chain).

A permissionless distributed ledger allows anonymous participants to manage the ledger while avoiding control by any single entity. However, in the case of anonymity, identity, accountability and auditability are difficult. In contrast, permissioned distributed ledgers enable trust levels and accountability by allowing explicitly authorized parties to manage the ledger. Permissioned ledgers support more flexible management and a wider choice of consensus mechanisms. Participants who prefer some transactions over others can easily operate two types of distributed ledgers. However, the underlying accountability of a permissioned ledger provides an opportunity to constrain participants.

Blockchain offers a potential solution to the distributed ledger problem by recording transaction history using a linear record structure. However, due to the fundamental nature of distributed systems, transaction conflicts often arise when multiple parties send multiple transactions to the same shared ledger. There are several methods for mitigating contention, but none provide good performance.

A typical public blockchain, a public blockchain associated with cryptocurrencies, allows miners to decide which transactions to keep or which to reject based on ordering. These miners in effect opt for the incentive model because they always prefer transactions with more rewards. However, partly due to incentive models, public blockchains are very slow.

A typical enterprise blockchain fabric chooses a timing model in which each peer submits transactions simply based on the time order of a series of transactions from an ordering service. In this case, the chronological order may result in many transactions being rejected.

Overview This specification describes a DAG-based transaction processing system and method and components thereof on a distributed ledger, according to one embodiment.

According to one embodiment, the present disclosure provides a new transaction processing model by introducing a DAG structure. New models can achieve high throughput performance. Additional weighting mechanisms can be used to adjust the final performance based on various business requirements. Unlike existing work using linear structures, better performance can be achieved.

The Hyperledger Project is a collaborative effort accomplished as a Linux Foundation project to create an open source, enterprise-grade distributed ledger framework and codebase. Hyperledger Fabric is an implementation of a distributed ledger platform for executing smart contracts. Hyperledger Fabric utilizes container technology to host smart contracts called "chaincode" that contain the system's application logic.

According to one embodiment, Hyperledger participants replicate 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 related private ledgers, blockchain systems use shared programs to update shared ledgers. By coordinating a business network of participants through a shared ledger, a blockchain network eliminates the time, costs and risks associated with distributing private information across ledgers (while increasing trust), as well as processing time. can be reduced. The Hyperledger Fabric is private and permissioned. A member of the Hyperledger Fabric network is registered. The hyperledger fabric can also provide the ability to create channels. Each channel may contain a separate transaction ledger that is visible to a particular group of participants. This allows transaction privacy.

According to one embodiment, Fabric's distributed ledger protocol is executed by peers. The fabric distinguishes between two types of peers. Validating peers are nodes on the network that are involved in executing consensus, validating transactions, and managing the ledger. Non-validating peers, on the other hand, are nodes that act as proxies to connect clients (that issue transactions) to validating peers. Non-verifying peers do not execute transactions, but are able to verify transactions. Some features of Fabric include a permissioned blockchain that has instant finality and executes arbitrary smart contracts called chaincodes. User-defined chaincode smart contracts are encapsulated in containers, and system chaincode runs in processes similar to peers. Keep ledger transactions in sync across the network (e.g., update the ledger only if the appropriate participants approve the transaction, and when updating the ledger, update the ledger in the same order with similar transactions) The process for ensuring that The fabric implements consensus protocols and security by supporting Certificate Authorities (CAs) for authenticating TLS (Transport Layer Security) certificates, registration certificates, and transaction certificates.

FIG. 2 illustrates a transaction flow within the fabric of the blockchain cloud service system, according to one embodiment; 1 illustrates a blockchain cloud service system, according to one embodiment; FIG. 1 illustrates a BCS system, according to one embodiment; FIG. 1 illustrates a BCS system, according to one embodiment; FIG. FIG. 2 illustrates a gateway of a blockchain cloud service system, according to one embodiment; FIG. 2 illustrates persistence of a blockchain cloud service system, according to one embodiment; FIG. 4 illustrates an exemplary arrangement of fabrics on the BCS; FIG. 4 illustrates a chaincode architecture, according to one embodiment. 1 illustrates a system for providing a management console, according to one embodiment; FIG. [0014] Figure 4 illustrates an example user interface within the BCS console UI, according to one embodiment; [0014] Figure 4 illustrates an example user interface within the BCS console UI, according to one embodiment; 1 illustrates a system for providing REST proxies at a BCS instance, according to one embodiment; FIG. [0012] Figure 4 illustrates a typical IDCS use case for single sign-on, according to one embodiment; [0013] Figure 4 illustrates an IDCS use case for fabric client authentication, according to one embodiment; 1 illustrates a DAG-based transaction processing method and system in a distributed ledger, according to one embodiment; FIG. [0014] Figure 4 illustrates an exemplary relationship graph that may be used with an embodiment of the present disclosure, according to one embodiment; [0014] Figure 4 illustrates an exemplary relationship graph that may be used with an embodiment of the present disclosure, according to one embodiment; [0014] Figure 4 illustrates an exemplary relationship graph that may be used with an embodiment of the present disclosure, according to one embodiment; 1 is a flowchart illustrating an example directed acyclic graph (DAG) based transaction processing method in a distributed ledger, according to one embodiment.

DETAILED DESCRIPTION According to one embodiment, the present specification describes a system and method for supporting SQL-based rich queries in blockchain fabric. According to one embodiment, the systems and methods described herein can create complex smart contracts in an easier and more manageable manner by executing SQL queries. Performance can also be improved by moving data culling back to the storage engine (rather than performing it at the smart contract level) and relying on a relational engine that supports concurrent read and write access of data. Also, the states of the world database can provide simultaneous read/write access.

According to one embodiment, an exemplary blockchain fabric that supports SQL-based rich queries on the blockchain fabric can be provided as a cloud service. According to one embodiment, an enterprise-grade framework includes extensibility, management, configuration, persistence, and compatibility of various client applications using cloud technologies. In certain embodiments, the permissioned blockchain ledger and blockchain fabric are provided as a blockchain cloud service (BCS).

In the following description, the disclosure is illustrated by way of example and not by way of limitation in the accompanying drawings. References to various embodiments in this disclosure do not necessarily refer to similar embodiments, and such references imply at least one. Although specific implementations are described, these implementations are provided for purposes of illustration. A person skilled in the relevant art will recognize that other components and configurations can be used without departing from the scope and spirit of the disclosure. The description of this disclosure provides examples and embodiments that support and disclose the claimed method.

Also, in certain instances, numerous specific details are given to provide a thorough description of the disclosure. One skilled in the art will understand, however, that the results and advantages of the methods taught in the present disclosure may be achieved and the concepts taught in the present disclosure may be practiced without these specific details. would do. In some instances, well-known features are not described in detail so as not to obscure the present disclosure.

The teachings of the present disclosure are described using functional building blocks that illustrate the capabilities of particular functions and their relationships. The boundaries of these functional building blocks are often arbitrarily defined in this disclosure for convenience of explanation. Thus, in alternative embodiments, functions performed by similar elements may be performed by different elements. Each element that performs a function may be merged into one element. Alternate boundaries may be defined so long as they adequately perform the specified functions and their relationships. Any of these alternate boundaries are therefore within the scope and spirit of the present disclosure.

Like reference numbers are used throughout the drawings and detailed description to denote like elements. Thus, where an element is described elsewhere, a reference number used in a drawing may or may not be referenced in the detailed description relating to that drawing.

Blockchain technology can dramatically increase enterprise business value by distributing transactions in near real-time and enabling secure, tamper-proof data sharing in the user ecosystem. The Hyperledger Fabric Blockchain incorporates modular architecture, flat/common industrial technology support, and support for enterprise demand.

Introduction According to one embodiment, the hyperledger fabric is a platform for distributed ledger solutions backed by a modular architecture that provides a high degree of confidentiality, resiliency, flexibility and scalability. The Hyperledger Fabric is designed to support pluggable implementations of different components and adapt to the complexity and congestion present in practical ecosystems.

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

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

Blockchain ledgers are often referred to as distributed ledgers because they are replicated by many network participants and managed by the cooperation of each network participant. Distribution and collaboration are attributes that reflect how businesses exchange goods and services in the real world.

In addition to decentralization and collaboration, the information recorded on the blockchain is only added using cryptography. That is, once a transaction is added to the ledger, it cannot be changed. This immutability allows participants to easily determine the origin of information, as information cannot be changed after the fact. Blockchain may therefore be thought of as a proof system.

Blockchain - Smart Contracts According to one embodiment, to support consistent updates of information and specific ledger functions (transactions, queries, etc.), the blockchain network uses smart contracts to provide access to ledgers. Control access.

According to one embodiment, smart contracts are an important mechanism for encapsulating information and easily maintaining that information across the network, as well as allowing participants to automatically execute certain parts of a transaction. may be written.

A smart contract may be written, for example, to vary the shipping cost depending on the arrival time of the item. Corresponding funds will automatically be transferred upon receipt of the goods under the terms agreed upon by both parties and set forth in the ledger.

Blockchain - Consensus According to one embodiment, keep ledger transactions in sync across the network (e.g., update the ledger only if the appropriate participants approve the transaction, update the ledger, and so on). transactions) may be referred to as consensus.

According to one embodiment, a blockchain may be thought of as a shared and replicated transaction system. This transactional system is updated via smart contracts and kept consistently in sync via a collaborative process called consensus.

Advantages of Blockchain According to one embodiment, the currently available transaction network is the version of the network that existed when business records were kept. Members of a business network transact with each other, and each member maintains their own transaction records. Similarly, the provenance can be verified each time an item is sold to ensure that the company selling the item has a chain of title to verify ownership of the item.

Despite modern business networks being modernized by computing systems, there is no unified system for managing the identities of network participants, and the (trillion-dollar global) securities Verification of provenance is difficult because it takes days to settle transactions and contracts must be manually signed and executed. It also presents a drawback because each database in the system contains unique information.

Blockchain, according to one embodiment, replaces many inefficient standard transaction systems by providing a standard way to establish identities, conduct transactions, and store data on a network. offer.

According to one embodiment, each participant in the blockchain network has its own copy 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 related private ledgers, blockchain systems use shared programs to update shared ledgers.

According to one embodiment, by coordinating a business network of participants via a shared ledger, a blockchain network increases trust and visibility while increasing the time, costs and risks associated with distributing private information. , as well as processing time can be reduced.

Hyperledger Fabric Hyperledger Fabric, like other blockchain technologies, is a system that has a ledger, uses smart contracts, and allows participants to manage transactions.

Hyperledger Fabric differs from some other blockchain systems because it is private and permissioned. Some blockchain networks use identities instead of “proof of work” to authenticate (only those who meet the criteria are allowed to join the network). Members of the Hyperledger Fabric network register through membership service providers.

Hyperledger Fabric also offers several pluggable options. Ledger data can be stored in multiple formats, the consensus mechanism can be switched in and out, and different MSPs (Membership Service Providers) can be supported.

Additionally, the Hyperledger Fabric allows participant groups to create separate transaction ledgers by providing the ability to create channels. This prevents some participants on the network from being competitors and not exposing all transactions to all participants (e.g. offering special prices to some participants and not be done). When two participants create a channel, they have a copy of the channel's ledger, except for the other participants.

Shared Ledger According to one embodiment, the Hyperledger Fabric has a ledger subsystem that includes two components: world state and transaction log. Each participant has a copy of the ledger of all Hyperledger Fabric networks to which it belongs.

The world state component describes the state of the ledger at a given point in time. Worldstate is a ledger database. A component called the transaction log records all transactions that have resulted in the current value of the world state. The transaction log is the update history of the world state. A ledger is thus a combination of a world state database and a transaction log history.

The shared ledger has a world state interchangeable data store. By default, the shared ledger is a level DB key-value store database. The transaction log does not have to be pluggable. A transaction log simply records the values of the ledger database before and after being used by the blockchain network.

Smart Contracts Hyperledger Fabric smart contracts are written in chaincode and invoked by applications outside the blockchain when they need to interact with the ledger. In most cases, the chaincode only interacts with the database component of the ledger, which is world state (eg, searches the database), not the transaction log.

Consensus According to one embodiment, transactions are written to the ledger in the order in which they are executed, even if they are executed between different sets of participants in the network. Thus, transaction ordering is established and bad transactions that are incorrectly (or maliciously) inserted into the ledger can be rejected.

The Hyperledger Fabric allows network entities (eg, network users, peers, starters) to choose a consensus mechanism that best represents the relationship between the participants. Similar to privacy, there is a need for networks that range from highly structured networks to more peer-to-peer networks with relationships between participants.

Chaincode According to one embodiment, a chaincode may include software that defines one or more assets and transaction instructions (business logic) for modifying the assets. Chaincode implements rules for reading or modifying key-value pairs or other state database information. Chaincode functionality runs against the ledger's current state database and is driven by transaction proposals. Execution of the chaincode results in a set of key-value writes (writeset) that are submitted to the network and applied to the ledger on all peers.

Ledger Characteristics According to one embodiment, a ledger is a continuous, tamper-resistant record of all state transitions in the fabric. A state transition is the result of a participant executing chaincode (a transaction). Each transaction produces a set of asset key-value pairs that are committed to the ledger as create, update, or delete.

The ledger consists of a blockchain, which stores an immutable chain of records in blocks, and a state database, which holds the current fabric state. Each channel contains one ledger, and each channel contains a separate ledger of transactions visible to a particular group of participants. Each peer maintains a copy of the ledger for each channel of which it is a member.

Channel Privacy According to one embodiment, the Hyperledger Fabric maintains an immutable ledger for each channel and a chaincode that can process and change the current state of assets (i.e., update key-value pairs). use. The ledger exists at the scope of the channel. The ledger may be shared across the network (if all participants are operating on one common channel) or may be privateized to include only a specific set of participants.

In the latter case, participants can separate/isolate transactions and ledgers by creating separate channels. To be able to bridge the gap between full transparency and privacy, chaincode may be installed only on peers that need access to the asset state to perform reads and writes (i.e. , if you do not install the chaincode on the peer, the peer will not be able to properly interface with the ledger). To further obfuscate the data, encrypt (partially or fully) the value in the chaincode using a normal cryptographic algorithm such as AES (Advanced Encryption Standard) before adding it to the ledger .

According to one embodiment, privacy can be improved using a "private collection", which is a smaller concept than channel privacy.

Security and Membership Services According to one embodiment, the Hyperledger Fabric provides a transaction network in which all participants have known identities. A public key infrastructure is used to create cryptographic certificates that are associated with organizations, network components, and end-users or client applications. Thus, access to data can be controlled and managed over wider networks and channels. This "permission" concept of the Hyperledger fabric, along with the presence and properties of channels, can address scenarios where privacy and confidentiality are important.

Consensus According to one embodiment, in a distributed ledger, consensus can involve more than simply agreeing on the order of transactions. This distinction is underscored by its fundamental role in the entire transaction flow of the Hyperledger Fabric, from proposals and endorsements to ordering, verification and commitment. Consensus is defined as a complete verification of the correctness of a set of transactions containing blocks.

Consensus is ultimately achieved when the order and outcome of transaction blocks satisfy explicit policy criteria checks. These checks and balances are made during a transaction, use endorsement policies to determine which specific members must sign a particular transaction, and to ensure that these policies are enforced and adhered to. contains the system chaincode of Prior to commitment, peers can utilize these system chaincodes to verify that the endorsement does exist and is from the proper entity. It also performs a version check before appending any block containing transactions to the ledger while agreeing or agreeing on the current state of the ledger. This final check provides protection against double-use and other threats that can compromise data integrity, and allows execution of functions on non-static variables.

Includes endorsements, verifications and version checks as well as ongoing identity verification done to the transaction flow. Access control lists are implemented on the network hierarchy (from ordering service to channel), and payloads are iteratively signed, verified, and authenticated as transaction proposals pass through different architectural components. Consensus is not limited to an agreed-upon sequence of transactions, but rather is a process achieved as a by-product of ongoing validation of the flow of transactions from proposal to commitment.

Blockchain Cloud Services—Architecture According to one embodiment, systems such as cloud systems (eg, Blockchain Cloud Services (BCS)) can utilize the hyperledger fabric described above as a starting point. Such systems enable the creation of new blockchain-based applications and/or the extension of existing SaaS, PaaS and IaaS and on-premise applications by providing a highly advanced and unique enterprise-grade distributed ledger cloud platform. to enable.

According to one embodiment, the system removes barriers to adoption and support of blockchain applications under construction by supporting mission-critical enterprise demands such as scalability, security, robustness, uniformity, and performance. can be done. By providing BCS as a cloud PaaS (Platform as a Service), the system enables users to deploy, configure, manage and monitor blockchains and reduce the cost of deploying blockchains in enterprises. to The system also accelerates the development of blockchain applications and integration with other platforms. The system allows SaaS cloud users to use third-party applications and external distributed ledger technology using the blockchain cloud platform to access data for enterprise processes such as procurement, payments, trade finance, accounting, HR, CX, etc. It can be shared safely and can perform distributed transactions.

According to one embodiment, the system is a cloud service based on a PaaS manager (eg, Oracle PaaS Service Manager (PSM) platform). Typically, such systems are cloud managed services that operate on computational spaces (eg, external computational spaces). In one embodiment, the system uses Oracle Identity Cloud Service (IDCS), Oracle Load Balancer Service (LBaaS), Oracle Event Hub Cloud Service, and Oracle Cloud Storage to provide tiered Oracle Application Container Cloud Service (ACCS). Take advantage of the features of the PSM platform, including: Each client's blockchain can be created and can be run as a tenant. The system can support multiple blockchains, with each blockchain created and operating as a respective tenant in a multi-tenant environment.

Thus, the system allows applications or client applications to implement distributed ledgers, including smart contracts, as needed or desired. Clients and users of such systems may be internal to the cloud (blockchain trust) or external. Some blockchain networks may include components outside the cloud environment, or may be limited to specific clouds.

According to one embodiment, the system is useful for a wide variety of applications, especially multi-party transactions where trust and identity must be resolved. Unlike other blockchain systems, the system services of the present disclosure are not anonymous. In fact, identity and auditability are fundamental integration factors. Thus, BCS may have applications in, for example, capital markets, cross-border transactions, financial services, asset transactions, legal regulation, healthcare records, publishing, logistics, change tracking, and anti-counterfeiting.

As mentioned above, each party on the blockchain has access to all databases and all histories (unless the ledger was created/privatized to a specific party). Neither party has control over the data or information. Also, all parties can directly verify the transaction partner's records without an intermediary. Communication occurs directly between peers without going through a central node. Each node stores information and forwards information to all other nodes. Once a transaction is entered into the database and the account is updated, the record is linked to the records of all previously entered transactions (hence the term "chain") and cannot be changed. If there is an error in the transaction, a new transaction can be used to correct the error. Both transactions are visible to the provided user. To add a new valid transaction, participants can agree on the validity of the transaction via a consensus mechanism. Blockchain participants can verify the provenance of assets and changes in asset ownership over time. Digital signatures can be used to authenticate documents and add to access control (change permission levels) and programmability (executable business rules).

In many multiparty transactions, parties exchange money upon receiving assets or services. Transaction time typically requires one party to provide goods or money before the other party. In some circumstances, credit is settled by an intermediary depositing funds until the terms of the contract are met. This method resolves the trust between the parties. However, this method adds another centralized party that must be trusted, thus increasing complexity and increasing the cost of the transaction. By using smart contracts as part of the system of the present disclosure, middlemen can be eliminated. This allows parties to conduct trusted transactions on the blockchain without an intermediary.

According to one embodiment, advantages of the disclosed system, such as the BCS, include distributing information within the system. Audit capabilities are available, access can be controlled, and some privacy can be managed. Also, the blockchain ledger is inherently immutable and irrevocable. A ledger is made up of blocks. Each transaction block has block id, past hash, data hash, timestamp, transaction id list, operation (1-n), chaincode id, chaincode proposal, response (r/w set, event, success or failure) , and endorsers. Each block contains a past hash and a hash of itself, so once published/distributed, it is inherently ordered and immutable (note that the hash of the current block is the hash of the past block and the hash of the current block). linking blocks in a chain, as it is a hash with other data in . Consensus can resolve contradictions. There is no need to give undue power to centralized authorities compared to centralized databases or intermediaries. The decentralized nature of the ledger also reinforces the fundamental immutability of blockchain recording technology, as it is difficult to change (albeit algorithmically possible) through the use of distributed copying and consensus. Therefore, hacking the ledger is nearly impossible if someone has a copy of the latest block on the chain because the order of transactions is constant.

In certain embodiments, as described below, the system of the present disclosure can be based on the Oracle PaaS Service Manager (PSM) platform to simplify/facilitate fabric-based blockchain creation, monitoring and configuration /enhanced by including an automating management console. Also, to simplify the contact between applications and the blockchain fabric, a REST proxy service is provided that includes one REST API. A developer builds a smart contract, deploys the smart contract using the management console, and then uses an application to execute the smart contract on the blockchain either asynchronously (by default) or (immediate response is required). can be called synchronously. REST proxy services and APIs provide both synchronous and asynchronous capabilities, depending on the needs of the platform.

According to one embodiment, the fabric CA server can provide membership services for the fabric. The Fabric CA server has three parts: authentication of users, authorization to access the blockchain (groups of peers and orders), and provision of certificates to application clients, peers and orders. It can include a CA server that distributes. The Fabric CA can utilize certificates to enforce authentication and authorization. Certificates include two types: registration certificates for authentication and transaction certificates for authorization. According to one embodiment, an identity service such as IDCS may also provide authentication and authorization.

Hyperledger Fabric As noted above, in one embodiment, the system of the present disclosure may implement a hyperledger fabric that provides a distributed ledger platform for executing smart contracts. Hyperledger Fabric utilizes container technology to host smart contracts called "chaincode" that contain the system's application logic. In an alternative embodiment, the blockchain cloud service is, for example, U.S. patent application Ser. No. 15/169,622, "Accountability and Implement alternative distributed ledger platforms, including the “Tendermint” ledger system described in Trust.

The Hyperledger Fabric's distributed ledger protocol is executed by peers. One drawback of traditional blockchain technology is that all peers are required to record all transactions. This causes substantial I/O and processor overhead and cannot be conveniently scaled for enterprise grade systems. The Hyperledger Fabric distinguishes between two types of peers. A committer peer is a node on the network that confirms endorsements, verifies transaction outcomes before committing transactions to the blockchain, and manages the ledger. Non-validating peers, on the other hand, are nodes that act as proxies to connect clients (that issue transactions) to validating peers. Non-Validating Peer (or Endorsaper)
does not execute transactions, but can simulate and sign transactions. Peer type/function separation improves system scalability. An ordering service can receive signed transactions, order them into blocks, and send the blocks to committer peers. In such distributed ledger systems, consensus is the process of forming agreement on the next set of transactions to be added to the ledger. In the Hyperledger Fabric, consensus involves three distinct steps: transaction endorsement, ordering, and verification and commitment.

According to one embodiment, Hyperledger is characterized by a permissioned blockchain that has instant finality and executes arbitrary smart contracts called chaincodes. User-defined chaincode smart contracts are encapsulated in containers, and system chaincode runs in processes similar to peers. Chaincode execution is split in transaction order, thus limiting the level of trust and verification between nodes required and reducing network overhead.

According to one embodiment, channels within the Hyperledger Fabric enable multiparty transactions with the high degree of privacy and confidentiality demanded by competing businesses and regulated industries exchanging assets over a common network. to An immutable shared ledger encrypts all transaction histories for each channel and includes query capabilities for efficient audit and dispute resolution. A ledger is created at the scope of the channel. The ledger may be shared across the network (if all participants are operating on one common channel) or may be privateized to include only a specific set of participants.

According to one embodiment, the hyperledger fabric implements security by supporting Certificate Authorities (CA) for authenticating TLS certificates, registration certificates and transaction certificates. A public key infrastructure is used to create cryptographic certificates that are associated with organizations, network components, and end-users or client applications. Thus, access to data can be controlled and managed over wider networks and channels. This "permissive" feature of the Hyperledger Fabric, along with the presence and capabilities of channels, meet the privacy and confidentiality requirements of multi-party systems.

According to one embodiment, the hyperledger fabric can modify assets using chaincode transactions. As mentioned above, chaincode is software that defines one or more assets and transaction instructions for modifying the assets.

The unified consensus mechanism has a fundamental role in the transaction flow of the Hyperledger Fabric, from proposal and endorsement, to ordering, verification and commitment. Consensus, as described above, is a verification of the validity of the transaction set containing the block. Consensus is ultimately achieved when the order and outcome of transaction blocks satisfy explicit policy criteria checks.

FIG. 1A shows the flow of transactions made to the fabric of a system that provides blockchain services. More specifically, FIG. 1A illustrates a Blockchain Cloud Service (BCS) system, according to one embodiment. At 1, client 160 uses fabric SDK 162 to access and register with fabric certificate authorities 170 , 172 , 174 . At 1.1, Fabric CA sends a registration certificate to client 160 . 2, the client 160 uses the Fabric SDK 162
Request a signature from the endorser 182 by accessing the peer container 180 using . At 2.1, the endorser 182 returns a signed RW set (read/write set). At 3 , fabric SDK 162 of client 160 submits the signed TX (transaction) containing the RW set and the endorser's signature to the ordering service of ordering container 190 . At 4 , orderer 192 delivers the TX batch to committer 184 in peer container 180 . An order is a predetermined set of nodes that orders transactions into blocks. The ordering service exists independently of peer processes and orders transactions for all channels on the network on a first-come, first-served basis. Committer 184 modifies ledger 186 and world state 188 at 5 and 5.1. Fabric certificate authority 170 can be used to verify signatures and authorizations of peer containers 180 , smart contract containers 166 and 168 , and orders 192 . Additionally, smart contract 168 may communicate with endorsers 182 .

In one embodiment, the system can utilize a Kafka cluster as an ordering service. Kafka is a decentralized streaming service that supports publishing and subscription semantics. Kafka clusters run on multiple servers and store sets of recordings in categories called topics. Each record contains a key, value and timestamp. Thus, Kafka may be used as an ordering service including Ordering Service Nodes (OSN-n) and Kafka clusters. An ordering service client may be connected to multiple OSNs. OSNs do not communicate directly with each other. These Ordering Service Nodes (OSNs) (1) perform client authentication, (2) allow clients to write to or read from chain 1 using a simple interface, and (3) existing Screen and validate transactions against constituent transactions to reconfigure chains or create new chains. Messages (records) in Kafka are written to topic partitions. A Kafka cluster may have multiple topics, and each topic may have multiple partitions. Each partition is an ordered, immutable sequence of records that are continuously appended. After performing client authentication and transaction screening, the OSN can relay incoming client transactions belonging to a particular chain to the corresponding chain partitions. The client transaction can then execute in that partition and return an ordered list of common transactions to all ordering service nodes.

According to one embodiment, each peer can be an endorser and a committer. A configuration item (eg, CORE_PEER_ENDORSER_ENABLED) can make a peer an endorser. When a peer joins a channel, it becomes a committer for this channel. Once a chaincode is installed on a peer, this peer becomes a potential endorser of this chaincode. When a client proposes a transaction, the client can select peers (from potential endorsers) to be endorsers.

According to one embodiment, the ordering mechanism for the order to distribute blocks to peers is as follows. First, a peer (eg, reader peer) requests a new block from the order by sending its own version (last block number). The order then checks the peer's version. a) If the peer's version is greater than the order's version, return an error to the peer indicating that the order's ledger has been lost and cannot be recovered from the EventHub (in this scenario, the order proper operation cannot continue). b) If the peer's version is less than the order's version, the order retrieves the block from its local ledger in RAM or a local file and sends it back to the peer. c) If both have similar versions, the order will stop until a new block is available. When a new block cut from the event hub becomes available, the order puts this block into a local block file or RAM and then sends back to the peer a distribution thread that reads this block from the ledger. Peers can get this block, commit it to their local ledger, and broadcast the latest version of the block to other peers.

BCS System Architecture Figure 1B shows the transaction flow made to the fabric of a system that provides blockchain services. More specifically, FIG. 1B illustrates a Blockchain Cloud Service (BCS) system, according to one embodiment. As shown, a blockchain cloud service component is created in a compute space 120 (eg, an external compute space), eg, on the Oracle PaaS Service Manager (PSM) platform. Access to the system is mediated by PSM API 122 and blockchain REST API 124 . The external compute space 120 utilizes load balancing as a service (LBaaS) 126 to distribute incoming transactions appropriately across available resources.

According to one embodiment, BCS is an application container layer service built using the PSM platform on application container cloud service 128 . Each BCS entity runs on a separate container. Each BCS entity corresponds one-to-one with an application container. A blockchain cloud service implements the features of the Hyperledger Fabric described above. In addition to the components that build the basic fabric network, several components are being developed to leverage Hyperledger Fabric in blockchain cloud services. You need to deploy these components with separate behaviors and binaries. With the cloud stack manager, you can automatically create all services defined by a blueprint as a single unit called a stack by authorizing users.

In one embodiment, BCS provides a hyperlegga fabric implementation for implementing a distributed ledger platform for executing smart contracts. BCS utilizes container technology to host smart contracts called “chaincode” that contain the application logic of the system.

According to one embodiment, the fabric's distributed ledger protocol is performed by peers. The fabric distinguishes between two types of peers. A validating peer is a node on the network that participates in executing consensus, validating transactions, and managing the ledger. Non-validating peers, on the other hand, are nodes that act as proxies to connect clients (that issue transactions) to validating peers. Non-verifying peers do not execute transactions, but are able to verify transactions. Some key features of Fabric include a permissioned blockchain that has instant finality and executes arbitrary smart contracts called chaincodes. User-defined chaincode smart contracts are encapsulated in containers, and system chaincode runs in processes similar to peers. Fabric implements consensus protocols and security by supporting Certificate Authorities (CAs) for authenticating TLS certificates, registration certificates, and transaction certificates.

According to one embodiment, BCS entities operate with container instances layered using ACCS 128 . A container is created and/or activated by a PSM create operation. Fabric CA container 130 is a container that provides the BCS Fabric CA (Certificate Authority) component. The BCS peer container 132 is the container in which the BCS peer network entity for managing the ledger component and executing the chaincode container operates to perform read/write operations on the ledger component. The BCS order container 134 is the container in which the BCS order for sequencing transactions onto the blockchain of all channels operates. A BCS chaincode execution container 139 is a container created and operated by a peer entity. In the container, the chaincode execution unit communicates with the parent peer entity to perform the encoding of assets and transaction instructions to modify the assets in the blockchain.

According to one embodiment, the BCS chaincode builder container 140 is a container created and operated by a peer entity. A chaincode building environment is installed and deployed in a container, and a chaincode execution unit is built in the container. Fabric SDK client 106 provides functionality for accessing the BCS. Blockchain cloud services also make use of event hub cloud service 150 , cloud storage service 152 , and identity service 154 . Oracle® Storage Cloud Service is used as a storage service for BCS.

According to one embodiment, Docker/Weave 141 is a container service. Containers are a way of packaging software in a format that can be run independently on a shared operating system. Unlike VMs, containers do not bundle a complete operating system, but instead bundle with the libraries and settings necessary for software operation. This allows the creation of an efficient, lightweight, self-contained system, ensuring that the software always behaves the same regardless of where it is located.

According to one embodiment, each BCS instance is composed of different types of nodes. A BCS instance may contain a few (eg, zero or more) to many peer nodes and may contain a few (eg, zero) to many order nodes. Each VM contains one BCS instance, and each BCS instance contains one to multiple Fabric CA nodes. For BCS Gateways, a BCS instance can contain a few (eg, zero) to many BCS Gateways. A BCS console is a component of a BCS instance. Each BCS instance contains only one BCS console.

According to one embodiment, BCS management server (console) 136 is a BCS component for providing many monitoring, management and display functions to BCS stack instances, as described in more detail below. As described in more detail below, the BCS Gateway (REST Proxy) 138 is a new BCS component that provides a REST API interface to consumers/clients. Consumers/clients perform transactions by accessing the fabric using the REST API interface.

According to one embodiment, the PSM console UI 102 of the public access client 100 allows administration of the platform service manager. The BCS console UI 104 allows control of the BCS management server. A variety of different types of clients can access BCS services, including fabric SDK clients 106, BCS REST clients 108, and fabric membership clients 110. FIG.

According to one embodiment, blueprints can be defined as independent service types for each of the types of containers listed above. Oracle Cloud Stack Manager uses Blueprints to automate the creation of all independent service types in a single stack unit. An advantage of defining each BCS entity as a service type is to easily update and manage the various execution entities. The application container tier service supports four types of operations: CREATE_SERVICE, DELETE_SERVICE, SCALE_SERVICE, Start/Stop/Restart. These operations can be applied on a service-by-service basis.

According to one embodiment, in the Hyperlegga Fabric network, the ordering service component uses Apache Kafka to provide the ordering service in a crash-fault tolerant manner and support multiple chains. Therefore, in the BCS cloud service, the ordering service component uses the Oracle Event Hub Cloud Service (OEHCS), which delivers the power of Kafka as a processed streaming data platform and can be integrated with the rest of Oracle's cloud. .

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

According to one embodiment, a client, such as a gateway-based application 103 and/or a fabric-based application 105, through a network such as the Internet 107 and a front end such as a load balancer LBaaS 126 including Cloud Gate (discussed below): It can communicate with AACS instance 128 . Incoming calls can include REST communications (shown as thick dashed lines in the figure) or, in certain circumstances, incoming gRPC communications (shown as light dashed lines in the figure). Incoming REST communications may be forwarded to gateway 138 (which may include a REST API/REST proxy), console 136, or agent fabric CA 130 (described above). REST communications transformed/transformed into internal calls (gRPC) interface with instances of Blockchain Fabric/Hyperledger (including Agent/Peer 132, Agent/Order 134, Chaincode 142, and Chaincode Builder 140) be able to. Incoming gRPC communications, on the other hand, can, for example, be forwarded directly to agent/peer 132 and agent/order 134 to interface with the blockchain/hyperledger.

According to one embodiment, when a transaction is made to an ACCS instance, the ACCS instance can persist the ledger to cloud storage via REST communication, for example, or communicate with an event hub via REST communication. be able to.

According to one embodiment, the drawing shows only one ACCS instance, but those skilled in the art will appreciate that a client (eg, gateway-based application 103 and/or fabric-based application 105) may use the BCS runtime described above. It will be readily appreciated that there may be more than one ACCS instance that can communicate via.

FIG. 1D shows a BCS system, according to one embodiment. More specifically, FIG. 1D shows the component concentrations within the BCS system, ie the ratio of components to each BCS instance.

According to one embodiment, for each BCS instance 100a, orders 101a are provided in a 1:N ratio, fabric CA memberships 102a are provided in a 1:N ratio, and BCS REST proxy 103a: Provided in a 1:N ratio, BCS consoles 104a may be provided in a 1:1 ratio and peer containers 105a may be provided in a 1:N ratio.

Each peer container can include endorsers that can simulate transactions and committers that are formed in the same peer container and can apply changes to the ledger.

According to one embodiment, chaincodes 109a may be provided to peer containers in a 1:N ratio. Storage 106a may also be provided in an N:1 ratio to peer containers and orders. Similarly, event hubs 107a may be provided in a ratio of N:1 to peer containers and orders. IDCS 108a may be provisioned in an N:1 ratio to fabric CA membership.

Blockchain Cloud Service (BCS) Gateway According to one embodiment, the BCS Gateway (BCSGW) includes network nodes that communicate with the Fabric network using the Fabric SDK. The BCS Gateway enables client applications to interact with the fabric elements of the BCS by providing an HTTPS REST API to client-side consumers.

FIG. 2 shows a gateway of a blockchain cloud service system, according to one embodiment. As shown in FIG. 2, end user 200 authenticates and authorizes by interacting with application adapter 202 using HTTPS. Application adapter 202 accesses public cloud 210 using HTTPS to LBaaS such as Cloud Gate 212 (ie, LBaaS). A load balancing service (LBaaS) is performed for incoming transactions. Cloud Gate 212 passes the transaction to BCS Gateway 222 using HTTPS. A BCS gateway provides an interface to the BCS fabric 220 . This interface communicates using the gRPC remote procedure call protocol.

According to one embodiment, Cloud Gate 212 is a reverse proxy "access enforcement module" or "policy enforcement point" that protects web browser and REST API resources using, for example, the OAuth2 and OpenID Connect standards. IDCS protects its administrative UI and REST API (referred to as the “IDCS web tier”) by using Cloud Gate internally. As another application, Cloudgate OTD is deployed as an additional instance in a semi-support/provisional setup known as non-IDCS or standalone.

According to one embodiment, OAuth/OpenID-based authentication is triggered when an HTTP request contains a "user-agent" header, i.e. when the HTTP request is from a UI like a browser or mobile app (UI client ) to support the user browser flow. Cloud Gate presents the user with credentials (username/password), validates the credentials, then creates and returns to the user an OAuth session cookie that can be used by subsequent HTTP requests from the browser. OAuth/OpenID based authentication also supports resource server flow (of program clients). This flow is triggered when an HTTP request contains an authentication "bearer" token header. Cloud Gate validates the token for authentication.

According to one embodiment, for HTTP basic authentication, the credentials (username/password) must be included in the HTTP authentication "basic" header of each HTTP request. Cloud Gate verifies the credentials of each HTTP request. This method applies to both UI clients and programmatic clients.

According to one embodiment, multi-token flow is a self-adaptive method that covers specific HTTP requests. If the HTTP request contains an authentication "basic" header, Cloud Gate performs HTTP basic behavior. If the HTTP request contains an authentication "bearer" header, Cloud Gate behaves similarly to the resource server flow.

In one embodiment, the BCS console browser client utilizes the user browser flow. In embodiments, the system may use the Cloud Gate multi-token authentication method for BCS console and gateway program clients. A program client can call the BCS REST API via HTTP basic authentication.

According to one embodiment, the BCS gateway 222 communicates with peers 224, which are network entities that manage the ledger and execute chaincode containers, to perform read/write operations to the ledger. Peers are owned and managed by members. BCS gateways 222 and peers 224 communicate with orders 226 . Order provides ordering services. An order is a predetermined set of nodes that orders transactions into blocks. The ordering service exists independently of peer processes and orders transactions for all channels on the network on a first-come, first-served basis. Peers 224 and orders 226 communicate with fabric authority 228 . BCS gateway 222 also provides access to BCS management server/console 230 .

According to one embodiment, the BCS is deployed in a cloud system such as Oracle cloud. The gateway can operate on ACCS containers. Gateways are stateless. Gateways can be updated by killing the old gateway and starting the new one. The BCS Gateway can allow client queries or invoke Fabric chaincode via RESTful protocol. The BCS Gateway allows clients to access the fabric network in the Oracle cloud via HTTPS/RESTful services. A BCS Gateway is a network node that uses the Fabric SDK to communicate with the Fabric network. Communication within the fabric uses gRPC as the communication protocol. The BCS gateway provides HTTPS/RESTful APIs to client-side clients. The REST API allows clients to invoke functions within Fabric using the Fabric SDK.

According to one embodiment, gateways may be provided in a one-to-one relationship to fabric users. All gateway users belong to one organization, and all gateway users map to one fabric user within one gateway. One gateway constitutes only one fabric user.

According to one embodiment, IDCS issues gateway certificates and gateway user (“app adapter”) certificates. These certificates are signed by an organizational CA. Gateways and gateway users are co-located with an organizational CA so they can verify each other using HTTPS.

According to one embodiment, each end-user accesses the BCSGW through an "app adapter". Authentication has three stages. That is, end user 200 is authenticated by App Adapter 202 , App Adapter 202 is authenticated by BCS Gateway 222 with a client certificate, and BCS Gateway is authenticated by Peer 224 and Order 226 in Fabric Network 220 . be.

According to one embodiment, one container runs one tomcat server and deploys one BCS gateway mapped to one fabric user. Multiple App Adapters can be connected to one gateway.

According to one embodiment, different gateways may be associated with different fabric users. An end user of an App Adapter connecting to one gateway may be mapped to one fabric user.

According to one embodiment, the BCSGW runs on the Oracle cloud and the configuration is set by the BCS console using a JSON file. Admin users can expose peers, channels and parts of chaincode to the gateway. An admin user launches the gateway via the console. Gateway does not refresh configuration after startup. Admin users can configure chaincode endorsers. End-users are unaware of policies and gateways do not check chaincode policies.

According to one embodiment, the BCSGW is launched by the BCS console. The BCS console creates the BCSGW configuration file and launches the new gateway using the BCSGW package. At startup, the startup script checks the BCSGW configuration file and modifies the configuration file for Tomcat (eg, Tomcat configuration file) before starting Tomcat. Tomcat launches a BCSGW thread that creates channel objects and connections with orders, peers and event hubs by reading each channel's configuration file. Different channels have different connections to the Order/Peer/Event Hub. The event hub is the peer's second port. The gateway gets the result of the transaction by connecting to this port. Tomcat servlet container can listen for client requests. For the chaincode query method, the BCSGW sends the request to all peers of the channel and uses only the first result. For the chaincode call method, the BCSGW sends the request to all endors of the channel, and if one of all the endors returns success, the BCSGW sends the transaction to all orders of the channel.

According to one embodiment, an asynchronous API can be supported. A peer can open two ports. One port is for exchanging events. A gateway can connect to a peer's event port. A gateway may connect to one event port of one channel. A normal client API is synchronous. A transaction may take several seconds and the client has to wait for a response. Sending asynchronous events to clients is not included in the V1 plan. In addition to the synchronous transaction API, the gateway provides an asynchronous transaction API "asynchronous call".

In one embodiment, an asynchronous API can operate as follows. After checking the parameters of the client request, the gateway returns the transaction ID to the client. Therefore, the client can recognize that the started transaction has not ended. The gateway launches a background thread to continue processing the transaction. Clients can track incomplete transactions. The gateway can provide a "transaction" API for clients to query the transaction state using the transaction ID.

According to one embodiment, client login may be supported. The BCSGW can support the HTTPS protocol and deny insecure HTTP access. BCSGW authenticates the App Adapter or SALT with a certificate. The App Adapter can authenticate the end user. Tomcat needs to be configured to use HTTPS client certificate authentication. The keystore file contains the BCSGW certificate and CA certificate to verify that the client is served by the BCS console. The BCS Gateway provides a BCS REST interface for clients to access.

Persistence - Storage Cloud According to one embodiment, the Hyperledger Fabric project code stores blocks and other runtime data such as block index, world state, history, and ( Contains a block to store the Ledger Provider database (which holds all Ledger IDs and recovery status) in the level DB stored in the same local file system. In ACCS, the container file system is ephemeral. This means that if some hardware failure causes a container to be stopped and a new container to be restarted on a new VM, the contents of the filesystem may be lost. If all containers are lost, the ledger cannot be recovered. Therefore, the ledger data must be stored outside the ACCS container. As such, a persistence solution is provided as an object store service used by the components of the Hyperledger Fabric described above.

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

FIG. 3 illustrates persistence of a blockchain cloud service system, according to one embodiment. As shown in FIG. 3, ACCS instance 300 includes multiple containers. Containers include, for example, order containers 302 , 304 with ledgers/blockchains 312 , 314 . Ledger/blockchain 312 and 314 are backed up to object storage 320 via a REST interface. Object storage 320 may be, for example, a cloud storage service.

Object storage is used to persist the ledger for each order. The current mechanism for orders to distribute blocks to peers is as follows. First, a peer requests a new block from the order by sending its own version (last block number). The order then checks the peer's version. a) If the peer's version is greater than the order's version, return an error to the peer indicating that the order's ledger has been lost and cannot be recovered from the EventHub (in this scenario, the order proper operation cannot continue). b) If the peer's version is less than the order's version, the order retrieves the block from its local ledger in RAM or a local file and sends it back to the peer. c) If both have similar versions, the order blocks until a new block is available. When a new block cut from the event hub becomes available, the order puts this block into a local block file or RAM and then sends back to the peer a distribution thread that reads this block from the ledger. Peers can get this block, commit it to their local ledger, and broadcast the latest version of the block to other peers.

According to one embodiment, the above process allows either order or event hub to persist all blocks. As mentioned above, Event Hubs support time bound holds. If the event hub can perform block saving, the order can set the ledger type to RAM or file. If an order is restarted and the ledger is lost, the order can rebuild the ledger by playing recordings from the event hub and cutting batch messages into blocks. If the Event Hub only supports time bound hold, once an order is restarted and the ledger is lost, it will not be possible to rebuild the ledger correctly because the first record in the Event Hub is not the true record of the ledger. Can not. In this case, the order cannot activate the old channel because the first block containing the channel information is missing and the version number (last block number) is also incorrect.

According to one embodiment, each order can persist all channel IDs to object storage and save each block to oracle storage. Peers only persist genesis blocks with channel information. If other block data is lost, the peer can read other block data from the order.

According to one embodiment, ACCS instance 300 may include peer container 306 containing ledger 316 and index 326 and peer container 308 containing ledger 318 and index 328 . Peers have five types of runtime data: transaction log (block file), block file index (level DB), ledger provider DB (level DB), state database (level DB or couch DB), and history (level DB). to generate All transaction data is stored in the transaction log as linked blocks in local files and persisted to the Oracle Storage Cloud Service. The Ledger Provider DB persists all Ledger IDs and statuses to the Level DB. Ledger ID is a unique ID to identify the channel to which the peer belongs and must be stored in the Oracle Storage Cloud Service. At runtime, peers can automatically recover others and save them to the local file system.

According to one embodiment, the Oracle Storage Cloud Service provides a REST API for uploading files to or downloading files from objects. When creating a new block, first write the block to the local block file as before, but with the difference that only one block is written to each file. Then upload this block file as an object to Oracle storage. If the upload fails, the local file changes are rolled back and an error sent back to the originator.

According to one embodiment, when an order updates the latest checkpoint of the block file index, it persists that information to Oracle storage and then updates the local level DB. If this operation fails, an error can be sent back to the originator. This information is used to recover the block file index. In Oracle storage, each peer and order has a unique container name consisting of a combination of MSP ID and node ID. The object name is a combination of the channel name as a prefix and the block file name. See Oracle Storage Naming Conventions for further details.

According to one embodiment, the ledger provider DB can optionally be stored in Oracle storage. When the Ledger Provider DB is updated, the entire Level DB can be replicated to the Oracle Storage Cloud Service. Since this file is very small and infrequently updated, the replication overhead is negligible. If you restart the container, you can download the container from Oracle Storage Cloud Service. When restarting an order from a new container, first the order downloads the channel ID from the storage object, then the order gets the latest checkpoint from the storage according to the channel ID. The order then recovers the block indices from the first block to the last block. During this time, the block files are downloaded one by one. The order then restores the state DB and history DB. When restarting a peer from a new container, first the peer can download the ledger provider DB and then get all the ledger IDs. The peer then retrieves the relevant genesis block from storage according to the ledger ID. Peers start with settings in the genesis block and get other block data by sending quests to Orenda. After getting these blocks, the peer recovers the block index, state DB and history DB.

According to one embodiment, a local block file acts as a read cache. Queries first read the data from local, and if the data does not exist locally, download the data from object storage. Besides the ledger, the chaincode source code needs to be persisted in Oracle storage. After installing the chaincode on the current fabric, the source code is encoded and stored on the peer. Peers check the chaincode container for each invocation or instance, and rebuild the container from the source code if the container does not exist. Therefore, each chaincode installation can upload the source code to the oracle storage, and when the peer restarts from a disk failure, the source code can be downloaded from the oracle storage.

BCS: SDK-Based Configuration File Manipulation and Post-Creation Deploy According to one embodiment, configuration files and deployment functions are used to deploy or update an application, including peers, orders, CA servers, and chaincodes. Deploy, generate, update, and retrieve settings. These functions reside in both the BCS console (Node.js) and the fabric container (peer/order/chaincode container). When requested by the UI, these functions get/update settings and change settings by calling SDK APIs as needed. This component as part of the BCS Console Backend provides SDKs to manipulate the UI and retrieve/get requested settings by interacting with the BCS Console UI, the IDCS Backend SDK, and all BCS applications. Update. This component also assists in creating BCS applications. The BCS authoring component deploys the BCS application into a docker container in a VM created using PSM. This feature implements the SDK API of the BCS Console UI, and the BCS authoring component retrieves or updates and deploys the BCS application configuration during the late authoring phase. The production system deploys BCS applications such as CA servers, orders and peers into a docker/swarm in the late production stage. When the VM starts up, it does late creation work and VM early work by calling startup scripts.

According to one embodiment, configuration files are provided to fabric components including peers, orders, fabric CAs, and BCS gateways. BCS application packages, settings, and chaincodes are stored in the client's storage cloud service.

According to one embodiment, the production system performs all resource allocations. Resources include VMs, networks, and storage.

According to one embodiment, the production system stores all resource allocation information in a storage service. This information includes VM number and associated network address/account credentials, number and type of BCS applications within each VM, public and internal IPs. Also, the production system has sufficient internal IP addresses for containers (accessible between VMs).

According to one embodiment, when the BCS authoring component has completed its authoring work, the VM startup script deploys the application container by launching and invoking Swarm, and the container startup shell script performs initial operations within the container. do.

According to one embodiment, when the BCS console runs, it retrieves settings from the storage service, saves user input from the UI to the storage service, and then sends a reboot command to the swarm.

According to one embodiment, the required security credentials may be stored in IDCS or obtained from IDCS.

According to one embodiment, the BCS console backend can use Swarm to communicate with the BCS application.

According to one embodiment, when the BCS application container is started, the BCS application determines the application type (peer, chaincode container or other) by gathering configuration details and sets the required configuration. can be loaded.

According to one embodiment, this component updates settings and provides BCS application launch shellcode. The operation of retrieving/updating configuration files by the BCS includes several steps. First, when the BCS console is started, it retrieves the settings from storage and saves the settings (shell and node.js) to storage when it needs to be updated.
When a BCS application container is started, first the startup script (in each docker container) is started, then it gets the settings for the application type and gets the app certificate from IDCS (shell). If the BCS Console UI restarts the BCS application, it will send a message to docker/swarm to restart the application in the container.

According to one embodiment, the BCS console is stateless, and once started it can collect all BCS instance settings, connect to BCS applications, and monitor BCS applications. The settings are retrieved from the storage service via the backend API. When the settings are changed, the BCS console saves the settings to the storage service and restarts the associated applications by calling backend APIs. When a client changes a setting item through the BCS console UI, the UI encodes the setting into key/value data, and the backend code converts it to 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 achieve this functionality.

Deploying the Fabric Network According to one embodiment, the fabric network includes the following entities: peers, clients, ordering services, and a set of protocols to facilitate communication between these entities. An organization is a logical entity or enterprise that makes up the fabric network participants. A fabric network has multiple participants. A member is a legally independent entity that owns a network's unique root certificate. Network components such as peer nodes and application clients are linked to members. Each organization may have one or more members. An organization can configure both orders and peers, only orders or only peers.

The first step in deploying a fabric network is to define participants. This step takes place out-of-band on the fabric network. All participants in the fabric network negotiate and determine the composition of the network, eg, which organization constitutes the order node or which organization constitutes the peer node. Each organization that composes an Order Node publishes the root certificate of the Order Server. Each organization that makes up a peer node publishes the peer server's root certificate. Each organization that contains a client publishes the client's root certificate. Clients can be separated from peers to different members in an organization.

As an example, suppose four banks (Bank 1, Bank 2, Bank 3, and Bank 4) deploy a blockchain network with an ordering service that includes Order Nodes owned by Bank 1 and Bank 2. Bank 1 constitutes only the orders of this network. Each bank is an organization of fabric networks. That is, Bank 1 has one member, Order (Root Certificate 1). Bank 2 has three members: client (root certificate 21), peer (root certificate 22), and order (root certificate 23). Bank 3 has two members: client (root certificate 31) and peer (root certificate 32). Bank 4 has two members: client (root certificate 41) and peer (root certificate 42).

After defining the participants, create the order and peer certificates. Each order or peer needs a (private key and signature certificate) pair to identify itself. Each member configures and starts its own fabric CA server with the root certificate, and uses the CLI or SDK to make requests to the CA server for each order/peer server of that member (private key and signing certificate). BCS provides a fabric CA server that can create certificates. However, the Fabric CA server is not the only means for creating certificates. Users can use other CA systems to create certificates. Therefore, the Fabric CA server is not a required component of the Fabric network.

After creating the order and peer certificates, by creating a system channel:
Bring up the fabric network. Since there is only one system channel for the ordering service (and therefore one fabric network), the system channel created (more precisely activated) is the first channel. A system channel defines the following constructs of the fabric network: one ordering service and one or more consortia. An ordering service consists of one or more ordering organizations (each organization includes an MSP ID and certificate) and attributes of the ordering service (e.g. type such as Solo or Kafka, order address, batch size/timeout). and policies (for creating channels). Each consortium contains one or more peer organizations, and each peer organization that wishes to join this fabric network must be defined in one of the consortia. Each organization contains an MSP ID, a certificate and an anchor peer.

After the fabric network system channel is activated, the system channel genesis block (the first block in the chain) is created. The ordering service administrator creates genesis blocks for system channels. The genesis block may be created (as a file) by the configuration file generation (configtxgen) tool, or it may be created (temporarily) at order activation. If you use the configuration file generator to create the genesis block, you must create the configuration file configtx.yaml as input. This file contains the following information: root certificates of all ordering organizations in the fabric network, root certificates of all peer organizations, order type, address, batch timeout, batch size and ordering Service attributes, policies, channel readers for authenticating and validating channel delivery requests, channel writers for authenticating and validating channel broadcast requests, chain creators for evaluating chain creation requests, channel reconfiguration and administrators for authenticating and validating requests.

The ordering service administrator uses the configuration file and the genesis block to start the order server. In other words, the genesis block is used to create system channels. To start the order server, we need a configuration file orderer.yaml which contains the listening address/port, ledger type, local MSP (private key, signing certificate). Each organization that offers ordering services launches its own order server (without specifying a genesis block).

Each organization that configures a peer node has a local MSP (private key, signing certificate) to identify the peer, and settings for each peer to identify peer attributes such as listen address/port, bootstrap peer, gossip attributes, etc. Prepare a file (default location/etc/hyperledger/fabric/core.yaml) and start the peer server.

After launching orders and peers, the channel administrator (who has rights to create channels) uses the fabric CLI or SDK to enter the following: one consortium (already defined in the system channel), and Request an order to create a channel that includes one or more peer organizations in the consortium. Each participating organization uses the fabric CLI or SDK to join some of its peers to the newly created channel.

Example: Placement of Fabric Network on BCS FIG. 4 shows an exemplary placement of Fabric on the BCS.

More specifically, the drawings and description describe steps for deploying a fabric network on a BCS. In this example, four entities A, B, C, and D wish to create and join a fabric network. The four entities discuss offline and decide on the responsibilities of the various entities. Each entity creates one or more BCS instances on OPC.

According to one embodiment, entity A provides both orders and peers. Entity A creates two instances: Order_Org1 401 for Order and Peer_Org1 421 for Peer. Entity A also participates in the creation of fabric networks (note that only orders can create fabric networks). The ordering service 400 includes Order_org 1 401 , Order_org 2 402 , and Kafka cluster 410 .

According to one embodiment, entity B provides both orders and peers. Entity B creates two instances: Order_Org2 402 for Order and Peer_Org2 422 for Peer.

According to one embodiment, entity C only provides peers. Entity C creates instance peer_org3 423 .

According to one embodiment, entity D only provides peers. Entity D creates instance Peer_Organization 4 424 .

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

According to one embodiment, the administrator of Order_Org1 can access from the BCS console the information collected in the previous step, i.e. each organization's CA certificate and admin certificate, and each peer organization's anchor Create a fabric network by creating a system channel with peers. The backend work includes creating genesis blocks by calling fabric tools and creating system channels by setting orders with the genesis blocks.

According to one embodiment, each peer organization's administrator updates all peer nodes' settings to add the other organization's CA/administrator certificates that have been collected from the BCS console, and updates all peer nodes to Join the fabric network by rebooting.

According to one embodiment, a method is provided for enabling new organizations to join existing fabric networks in a system. It can also provide a method that facilitates communication between participants and is easy for users to handle in order to create/join a fabric network, e.g. to protect offline actions prior to forming the fabric.

Chaincode (Smart Contract) Container According to one embodiment, as described above, a chaincode includes software that defines one or more assets and transaction instructions (business logic) for modifying the assets. can be done. Chaincode implements rules for reading or modifying key-value pairs or other state database information. Chaincode functionality runs against the ledger's current state database and is driven by transaction proposals. Execution of the chaincode results in a set of key-value writes (writeset) that are submitted to the network and applied to the ledger on all peers.

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

According to one embodiment, Hyperledger Fabric smart contracts are written in chaincode and invoked by applications external to the blockchain when they need to interact with the ledger. In most cases, the chaincode only interacts with the database component of the ledger, which is world state (eg, searches the database), not the transaction log.

According to one embodiment, the Hyperledger Fabric uses the Docker Engine to build chaincode, deploy chaincode, and execute chaincode. This section describes the architecture of the fabric and how it integrates into the ACCS layering model of the BCS.

According to one embodiment, Fabric deploys and manages user chaincodes as follows. First, build the chaincode in the ephemeral CC environment container. The chaincode is then transferred as source code to the builder container, compiled with the required statically linked libraries (“Java build”), and sent back to the peer as binary. Static linking allows the actual chaincode container to be as small as possible. Then build and start the chaincode image and container. The chaincode container will continue to run until the peer dies or the channel terminates. If the chaincode container crashes or is killed, the image will be restarted on the next call if it exists. For this design, one peer and channel has one chaincode docker container. Chaincode is explicitly installed on peers. That is, the chaincode does not necessarily have to be installed on all peers participating in the channel.

According to one embodiment, users can place fabric networks that can easily distribute components such as peers, orders, and chaincodes into the ACCS hierarchical container. The chaincode runtime environment container (ccenv) is dynamically activated because the chaincode binaries in the ACLS container need to be stored in cloud storage, as local block storage is not a reliable recovery method. Once built, the chaincode binary is uploaded to cloud storage for recovery in case of a container crash.

According to one embodiment, each chaincode interaction corresponds to different functions of the chaincode. The only restriction is that it cannot be called or queried until after instantiating the chaincode. Also, when called, chaincode containers that are not running will be restarted.

FIG. 5 illustrates a chaincode architecture, according to one embodiment. More specifically, FIG. 5 illustrates a chaincode architecture that enables a client 530 to install chaincode and perform transactions in the ACCS environment 500, according to one embodiment. In step 1 , client 530 installs the chaincode source code on peer 1 510 . First, build the chaincode in the ephemeral CC environment container. When the client 530 performs an "install", the client 530 launches a builder container that automatically launches the builder agent, waits for the builder container to finish initializing, and installs the chaincode through the peer. Submit the source code to the builder container (step 2). The builder agent builds the chaincode (Java build). Transfer the chaincode as source code to the builder container, compile it with the required statically linked libraries (“Java build”), and send it back to the peer as a binary. Static linking allows the actual chaincode container to be as small as possible. Once built, the chaincode package (tgz file) is uploaded to cloud storage 560 (step 3). The builder agent sends the cloud storage location to the peer for later reference (step 4.2).

According to one embodiment, the peer 510 then launches the CC environment as an ACLS (Access Control List) container 520 using the PSM REST API. Build and start chaincode images and containers. The chaincode container will continue to run until the peer dies or the channel terminates. Peer 510 starts passing the chaincode ID, self IP (for chaincode registration) and cloud storage location to the ACLS container (step 4.1). The peer waits for chaincode startup or timeout after a set period of time. The CC environment launches chaincode. Once activated, the chaincode registers itself with the peer (step 4.3). This allows the chaincode to be invoked in a transaction using the connection established during registration (step 5).

According to one embodiment, builder container 550 includes a simple REST server. Builder container 550 includes builder agent 553 . When the builder container 550 is started, it listens for requests to build chaincodes. When builder container 550 receives a build list, eg, a POST call with a body of base 64 encoded source code, base 64 decodes the source code and saves the chaincode source code to the local file system. Builder agent 553 performs a “Java build” on the source code. If the “Java build” succeeds, builder agent 553 packages and uploads the binary to cloud storage 560 . The builder agent also sends the chaincode location to the peer. If the "Java build" fails, the agent will send the error and reason to the peer.

BCS Management Console As described above, each instance of BCS includes a management console, which can be used to manage and monitor the BCS instance, including BCS gateways, BCS nodes, and BCS channels.

According to one embodiment, a system for providing an administrative console can include a web application running in a scripting runtime environment, such as Node.js. Web applications can be built on graphical user interface frameworks and web frameworks and can include multiple custom functions or APIs for communicating with various nodes or services within a BCS instance. A web application can load information from various nodes or services within the BCS instance into view objects and display it in the console user interface. The management console can also provide administrators with the ability to start, stop, and update one or more nodes within the BCS instance. The administrative REST API set may be provided by or accessed by the scripting runtime environment to support functionality similar to that provided by web applications.

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

According to one embodiment, a BCS administrator can, via an administrative console, configure one or more peer nodes, one or more order nodes, one or more fabric CA nodes, one or more BCS gateway nodes, channels, and Multiple components of a BCS instance can be managed, including one or more chaincodes.

According to one embodiment, managing BCS components includes starting components, stopping components, adding components, removing components, viewing/editing component attributes, viewing component performance metrics, viewing component logs. The actions may include performing one or more actions.

FIG. 6 illustrates a system for providing a management console, according to one embodiment.
As depicted, BCS management console 136 may be provided as a component of a BCS instance within application container cloud service 128 . The BCS administration console may be a web application running in the scripting runtime environment 605, which is the runtime environment provided by Node.js.

According to one embodiment, the management console may include a fabric node SDK 611 , fabric custom functions 613 and ACCS APIs 615 . SDKs, custom functions, and ACCS APIs can be used to communicate with fabric network 601 , which can include distributed streaming services (eg, Kafka) 603 . The management console further includes view objects 623, which can contain information that needs to be displayed in the BCS console UI 104 or REST client 604 or passed from the BCS console UI or REST client to the management console. It can contain the information you need. The fabric node SDK 611 is operable to map information from the fabric network to information from the BCS console UI or REST client.

According to one embodiment, the BCS management console uses a GUI framework (e.g., JET
) 617 and a web framework (eg, express) 619 . A GUI framework can provide various user interface (UI) components and elements that can be used in a management console web application. For example, UI components and elements can be used to create forms, collect data, and visualize data. The web framework can be written in JAVA Script and can provide a web application framework that includes a set of robust features for developing web and mobile applications.

7A-7B illustrate example user interfaces within the BCS console UI, according to one embodiment.

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

According to one embodiment, the health information 713 of the BCS instance can be displayed. Health information is presented visually and displayed numerically. The example UI can also display transaction executions 714 and ledger summary 715 .

According to one embodiment, FIG. 7B shows information for all nodes within a BCS instance. For example, the example UI shows a total of 5 nodes including 2 peers, 1 order, 1 fabric CA, and 1 REST proxy (inside the BCS gateway node). The overview UI 717 displays the node name 723, the route information of the node 725, the type of the node 729, and the status information of the node 731. FIG. The exemplary UI includes a button 721 for administrators to add nodes and one or more drop-down lists 719 for filtering nodes.

Managing Nodes According to one embodiment, two entities, BCS administrators and BCS users, can manage BCS instances using an administrative console. There is only one BCS administrator account for each BCS instance. A BCS administrator account may be created when creating a BCS instance. The BCS administrator may be bundled with the Fabric CA administrator (i.e. the BCS administrator uses the Fabric CA administrator ID to perform all operations from the BCS console or via the BCS Admin REST API). do). There may be more than one BCS user account. A BCS user account may be created by a BCS administrator by registering a Fabric CA identity.

According to one embodiment, the nodes within a BCS instance may be displayed in one web page. A management console can support two modes. The first mode can present each node's name, kind, access URL, and state as a list. A second mode can graphically present the channels that each peer participates in.

Additionally, according to one embodiment, a BCS administrator can start and stop peer nodes, order nodes, fabric CA nodes, and BCS gateway nodes via the management console, and can Nodes can be added and deleted. Fabric CA nodes cannot be added or deleted.

According to one embodiment, a BCS administrator can set attributes of a node when adding the node. Newly added nodes can be automatically started as part of the add operation. When deleting a node, the node is stopped and deleted from the BCS instance.

According to one embodiment, the BCS console UI can list all channels that the active peer node participates in and all chaincodes installed on the active peer node.

According to one embodiment, when managing peer nodes, the BCS administrator can add active peer nodes to existing channels and view and edit attributes of active order nodes. BCS users can view some attributes of active peer nodes.

Also, snapshots of active peer node performance metrics, such as memory utilization, CPU utilization, network I/O, and disk I/O, may be displayed in the BCS console UI.

According to one embodiment, when managing an order node, the BCS administrator can view logs of active order nodes and view and edit attributes of active order nodes. BCS users can view some attributes of active order nodes. Similar to managing peer nodes, BCS administrators can view snapshots of active order node performance metrics, such as memory utilization, CPU utilization, network I/O, and disk I/O. can.

According to one embodiment, when a BCS administrator manages Fabric CA nodes, the BCS administrator can view and edit attributes of active Fabric CA nodes, obtain CA certificates from active Fabric CA nodes, CA node logs can be viewed. BCS administrators can also view snapshots of active fabric node performance metrics, such as memory utilization, CPU utilization, network I/O, and disk I/O.

As described above, managing BCS Gateway nodes may further include adding BCS Gateway nodes or deleting BCS Gateway nodes. As specified at the time, the number of BCS gateway nodes that can be added to a BCS instance is limited by the configured maximum allowed number of BCS gateway nodes.

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

According to one embodiment, a BCS administrator can define a BCS gateway configuration file and launch a BCS gateway node when configuring the BCS gateway node. There is no need to create channels or deploy chaincodes when creating a BCS instance. Therefore, a BCS Gateway node will not function until you deploy one or more chaincodes and define valid BCS Gateway settings via the management console.

Each BCS gateway node has a configuration page. In certain embodiments, the following items can be set on the settings page.
1) Channel: Select a channel to expose through the current gateway node.
2) Chaincode: From the list of all chaincodes instantiated for each channel, select the instantiated chaincode to publish.
3) Endorser: Defines the endorser of each chaincode.
4) Create a BCS gateway configuration according to the above settings. Once a valid configuration file for the BCS gateway is created, the gateway can be started.

According to one embodiment, the BCS console allows viewing of BCS gateway properties using a view list function. View List provides the following information for each BCS Gateway:
1) Name: A globally unique name specified when creating the gateway.
2) Fabric Identifier: Each BCS Gateway can be associated with an identity of the Fabric Client that is registered when creating the BCS Gateway. This fabric client can perform all operations (eg, calls, queries) performed by the BCS gateway.
3) Network Address: The access point has a public internetwork address.
4) State: active or inactive.

According to one embodiment, a BCS administrator can view the logs of active BCS Gateway nodes and view the following BCS Gateway metrics via the Management Console.
1) Connected clients: client name, address, logon time, etc.;
2) Current transaction information: Current transaction information is available along with state information, ie the state of the transaction. Current transaction information is useful when debugging frozen transactions.
3) Transaction Statistics: Transaction statistics are available via the management console UI. For example, transaction statistics may include the number of transactions completed, the number of event notifications received, and the number of event notifications sent.
4) Memory utilization.
5) CPU utilization.
6) Network I/O.
7) Disk I/O.

Managing Channels According to one embodiment, a BCS user can list all channels that the current BCS instance participates in. A BCS administrator can create a channel with the channel name, consortium name, and one or more organization names as inputs. Also, the output can be displayed to indicate the success or failure of channel creation.

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

According to one embodiment, the BCS administrator can query the ledger of peers in the channel. A ledger can contain multiple transaction blocks. Each transaction block has block id, past hash, data hash, timestamp, transaction id list, operation (1-n), chaincode id, chaincode proposal, response (r/w set, event, success or failure) , and one or more endorsers. It can also display the following statistical data: number of blocks and number of calls.

According to one embodiment, a BCS administrator can list all chaincodes instantiated on a channel. Listed items may include chaincode IDs and versions. BCS administrators can also view the following information for instantiated chaincodes: the path specified by the instantiated transaction, and instance arguments.

According to one embodiment, the BCS administrator can update the chaincode instantiated on the channel. The update operation accepts the following inputs: target endorser containing the new version of the installed chaincode, one or more orders, the chaincode version, and optional arguments that can be string arguments specific to the chaincode. can be used. The output of the update operation may be success or failure with an error message.

Managing Chaincodes According to one embodiment, a BCS administrator can list all chaincodes installed on any peer of the current BCS instance. The items listed include the chaincode ID and version. BCS administrators can also view the following information for installed chaincodes: the local peer node that installed the chaincode, and the channel that instantiated the chaincode.

According to one embodiment, a BCS administrator can install chaincode on one or more local peer nodes via an administrative console. The inputs to install are the target peer, the chaincode type, e.g., 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, An optional chaincode package can be included. The output of the install operation may be success or failure with an error message.

According to one embodiment, the BCS administrator can add the following information: channel name, target endorser with new version of installed chaincode, order, chaincode version, and chaincode-specific string arguments. An installed chaincode can be instantiated into a channel as input with possible optional arguments, a specific format, or an endorsement policy with a default format if there is no specific format.

Membership Management According to one embodiment, the BCS administrator can list all IDs in the current BCS instance, register new users/IDs in the current BCS instance, and register An identity can be released and a user can be deleted from the current BCS instance. In addition, the BCS administrator can view/edit the following attributes of identification information, as shown in Table 1.

According to one embodiment, BCS users are allowed to register or re-register themselves via the administration console. This allows the user's private key and certificate to be created. Also, BCS administrators can revoke previously registered identities via the management console, and BCS users can change passwords via the management console.

According to one embodiment, the associated BCS instance can be started or stopped and the BCS administration console can be started or stopped.

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

REST APIs
As mentioned above, different components within the fabric network communicate based on the gRPC protocol. Therefore, for BCS instances based on the Fabric network, client applications need to use the Fabric SDK to invoke the chaincode within the BCS instance.

Having client applications communicate with blockchain cloud services using the Fabric SDK partially negates the benefits of offering a blockchain framework as a cloud service. For example, one advantage is that cloud services can be accessed from any location with an Internet connection.

According to one embodiment, the systems and methods described herein can provide a REST proxy at the BCS instance. REST Proxy is used by REST clients to query through chaincode, invoke transactions through chaincode synchronously or asynchronously, get transaction status, and multiple A REST API can be provided. A REST proxy can authenticate REST calls and convert them into GRPC calls. Also, the REST proxy can provide a REST API that supports functionality similar to that provided by the BCS management console.

According to one embodiment, the REST proxy provides a user interface for client applications to consume BCS instances.

FIG. 8 illustrates a system for providing REST proxies at a BCS instance, according to one embodiment.

As shown in FIG. 8, REST proxy 138 may include REST authentication tool 827 and protocol conversion tool 829 . When a BCS REST API client 808 sends a REST call 815 to a REST proxy, the LBaaS 126 connected to Cloud Gate 811 authenticates the REST call to enable REST to access the BCS instance with a valid user It can be determined whether a first name and a valid password are included in the REST call.

According to one embodiment, if the LBaaS authenticates the REST call, it forwards the REST call to a REST proxy, which forwards the REST call 835 to IDCS 813, which in turn directs the client application to be properly authorized by the BCS. It is possible to determine whether or not

According to one embodiment, if the client application is properly authorized, the REST proxy can divert/convert the REST call to a gRPC call 825 and send the gRPC call to fabric network 601 . REST calls, when converted/converted to internal calls (gRPC), can interface with blockchain fabric/hyperledger instances.

According to one embodiment, REST calls may be converted by a protocol conversion tool, which may be a Java application based on Fabric Java SDK 831 with gRPC library 833 .

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

Exemplary REST API
According to one embodiment, the REST proxy must be up and running before calling the REST API of the BCS instance. The status of the REST proxy can be checked via the management console. If the REST proxy is not up and running, you will need to activate the REST proxy from the admin console.

According to one embodiment, it is possible to interact with smart contracts (chaincode) located on peer nodes within a BCS instance by invoking REST APIs. The deployment process can be accomplished through the administration console.

According to one embodiment, an exemplary REST API is provided for purposes of illustration. The examples used herein assume the following exemplary chaincodes are deployed in the BCS network.

According to one embodiment, an example includes a management console. If the REST proxy is not up and running, you can activate it from the admin console.

According to one embodiment, it is possible to interact with smart contracts (chaincode) located on peer nodes within a BCS instance by invoking REST APIs. The deployment process can be accomplished through the administration console.

According to one embodiment, an exemplary REST API is provided for purposes of illustration. The examples used herein assume the following exemplary chaincodes are deployed in the BCS network.

According to one embodiment, the REST API provides the following functions: query via chaincode, invoke transaction via chaincode, asynchronously invoke transaction via chaincode, get transaction status, BCS gateway Provides version retrieval. To perform these functions, the client accesses the BCS gateway using HTTPS and utilizes message formats according to the API.

According to one embodiment, the query via chaincode function performs query operations by invoking the chaincode. Chaincode and query arguments are REST
Specified via API. The Get Transaction Status REST API gets the status of a transaction by querying the channel. Channel and transaction IDs are specified via the REST API. The Get BCS Gateway Version REST API returns gateway version information.

According to one embodiment, the Invoke Transactions Through Chaincode REST API performs transactions by invoking chaincodes. The chaincode and invocation arguments are specified via the REST API. This REST API executes transactions in synchronous mode. This means returning either a transaction success response, a transaction failure response, or a transaction timeout response.

According to one embodiment, the Asynchronous Invocation of Transactions Through Chaincode REST API executes a transaction by invoking a chaincode. The chaincode and invocation arguments are specified via the REST API. This REST API executes transactions in an asynchronous mode. This means returning a response/acknowledgment immediately after submitting the transaction without waiting for the transaction to finish or timeout. Results are provided thereafter. The BCS Instance Management REST API supports functionality similar to that provided by the BCS Console (described below).

Fabric Certificate Authority (Fabric CA) integrated with Identity Cloud Service (IDCS)
According to one embodiment, the fabric CA server provides fabric membership services. The Fabric Membership Service consists of three parts: user authentication, authorization to access the blockchain (groups of peers and orders), and CA to distribute certificates to application clients, peers and orders. Including server. The Fabric CA uses certificates to enforce authentication and authorization. Certificates include two types: registration certificates for authentication and transaction certificates for authorization. IDCS also provides authentication and authorization. However, this authorization is enforced by OAuth. That is, when a peer wants to access an order, it obtains the user's access token from IDCS and uses this token to access the order.

According to one embodiment, the fabric CA uses a database or LDAP to store information for registered users of the fabric CA, such as user name/password, user credentials, and user affiliation. Public cloud (OPC) end-users utilize one centralized IDCS instance for managing employees to access all public cloud (OPC) instances utilized by employees. The blockchain cloud service BCS is preferably integrated with the IDCS used for other cloud services. Thus, end-users can access all public cloud (OPC) instances (including BCS) utilized by employees using one centralized IDCS instance for managing employees.

In one embodiment, the Blockchain Cloud Service (BCS) uses Oracle Identity Cloud Service (IDCS) to centrally store user information. The BCS stores the Fabric CA user's information in the IDCS. This allows Oracle BCS to use IDCS to manage centralized BCS user information across multiple public cloud service instances. Therefore, in one embodiment, BCS fabric CA user information and credentials are stored in Oracle IDCS. The Fabric Certificate Authentication Framework is a Fabric Membership Provider (MSP) that includes a PKI private key, a signed certificate, a CA certificate chain, and is configured by the Fabric CA client/server.

According to one embodiment, the BCS utilizes OPC user management. First, BCS users must be OPC users (with IDCS IDs). When a BCS instance is created, several types of applications are created including BCS console, CA and REST proxy. The Console has two app roles: Console Admin and Console User. CA has four app roles: Fabric Admin, Fabric Client, Fabric Peer, and Fabric Order. The REST Proxy has two app roles: Gateway Admin and Gateway User.

According to one embodiment, in order for an OPC user to become a BCS user, it is necessary to grant the OPC user a specific BCS app role in the OPC user management console.

Creators must provide an existing OPC user/password when creating a BCS instance, and this user is automatically granted the BCS Console Admin and Fabric Admin roles. Therefore, this user becomes the BCS administrator.

In case of BCS console/CA/REST proxy authentication, the authentication is done at Cloud Gate. For Peer/Order, authentication is based on signatures. For the BCS console, after authentication, the console gets the current user's app roles (by calling IDCS). If this user is not granted the Console Administrator or Console User role, the connection will be denied. Otherwise, the console performs access control based on predefined rules. For example, normal users can only read information, and administrators can do anything.

According to one embodiment, for the CA, after authentication, the CA obtains the current user's app role. If the user has not been granted the fabric role, the registration request will be rejected.

According to one embodiment, for a REST proxy, after authentication, the REST proxy retrieves the current user's app role. If the user is not granted the Gateway Administrator or Gateway User role, the request is denied. Otherwise, the console performs access control based on predefined rules. For example, normal users can make calls/queries and administrators can change settings and get metrics.

According to one embodiment, the fabric CA server provides fabric membership services. The Fabric Membership Service can deliver three parts: user authentication, authorization to access the blockchain (groups of peers and orders), and certificates to application clients, peers and orders. Contains CA servers.

According to one embodiment, the fabric CA uses certificates to perform authentication and authorization. Certificates include two types: registration certificates for authentication and transaction certificates for authorization.

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

FIG. 9A illustrates a typical IDCS use case for single sign-on, according to one embodiment.

According to one embodiment, in an initial step, web application 901 can be added to IDCS 902 . A client, such as web browser 900, can then request authentication (eg, username and password) from the web application. Since the web application has already been added to IDCS, it can instruct the web browser to send the authentication request to IDCS. The web browser can request authentication (eg, username and password) from IDCS after receiving a response from the web application.

IDCS can then authenticate the request and return a token to the web browser if authentication is successful. A web browser that has been authenticated and has received a token can send requests to the web application. The web application can validate the token and inform the web browser that the authentication was successful.

For the case shown in FIG. 9A, the IDCS acts as an Identity Provider (IdP) that provides services for identifying applications. All communication between all participants is based on HTTP. This use case is configuration-driven, but applies only to HTTP-based applications.

FIG. 9B illustrates an IDCS use case for fabric client authentication, according to one embodiment.

According to one embodiment, a fabric client 904 associated with a fabric user that is already registered and registered (the user's private key and certificate are already stored in the client-side state store) requests a new client. and get the user information (user name) of the client. Fabric SDK 905 can load the user from the state store and return the user object to the fabric client. Upon receiving the user object, the client can send a transaction proposal to the fabric SDK, and the fabric SDK can sign the proposal with a similar private key. The signed proposal is then sent to peer 906 , who can verify the signature using 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 send back to the peer a proof that the signature has been verified.

DAG-Based Transaction Processing in a Distributed Ledger According to one embodiment, a DAG-based transaction processing system and method in a distributed ledger can be implemented. This model can improve throughput performance. Additional weighting mechanisms can be used to adjust the final performance based on various business requirements. Unlike existing work using linear structures, better performance can be achieved.

Traditionally, blockchain offers a potential solution to solve the distributed ledger problem by recording transaction history using a linear record structure. However, due to the fundamental nature of distributed systems, transaction conflicts often arise when multiple parties send multiple transactions to the same shared ledger. There are several methods for mitigating contention, but none provide good performance.

Typical public blockchains, such as those associated with cryptocurrencies, let miners decide which transactions to keep or which to reject. These miners effectively opt for an incentive model (e.g., to allow some blockchains to pay miners to prioritize certain transactions over others). In this case, miners and other members of the blockchain consensus always prefer transactions with more rewards. This leads to slow blockchain performance.

Other enterprise blockchain fabrics choose a timing model in which each peer submits transactions simply based on the time order of a series of transactions from an ordering service. In this case, many transactions may be rejected due to chronological ordering and conflicts between transactions.

According to one embodiment, the disclosed system and method provide a new transaction processing model by introducing a DAG structure. New models can achieve high throughput performance. Additional weighting mechanisms can be used to adjust the final performance based on various business requirements. Unlike existing work using linear structures, better performance can be achieved.

FIG. 10 illustrates a system for supporting provision of DAG-based transaction processing methods and systems on distributed ledgers, according to one embodiment.

According to one embodiment, a DAG-based transaction processing system and method design in a distributed ledger may include a conflict detector 1005, a ranking generator 1010, and a transaction picker 1015. can.

According to one embodiment, the conflict detector can detect conflict relationships between multiple transactions, eg, multiple transactions from transaction list 1001 .

According to one embodiment, in general, transactions #1 and #2 are considered conflicting if transaction #1 depends on some key that is changed in transaction #2. An edge can be drawn between transactions #1 and #2. Several DAGs can be drawn for a series of transactions.

According to one embodiment, each transaction has one edge and vertex marked as the bottom layer of the graph in the DAG.

According to one embodiment, race conditions can be expanded. For example, two transactions may modify the same table, or the creators of two transactions may belong to the same department.

According to one embodiment, after conflict detection, the relationships are represented as several DAGs. Each transaction is a vertex of conflict graph 1002 .

According to one embodiment, the ranking generator of the present systems and methods can add weights to each vertex of the generated graph 1002 . If all transactions have similar weights, the initial ranking of each vertex can be set to a similar value, eg "1".

According to one embodiment, the weights of multiple transactions may be set automatically by the system and method, or may be set via user/administrator input. A transaction may include an indication of its weight.

According to one embodiment, after setting the initial ranking/weight 1003 for each transaction, the system and method can calculate the ranking according to the vertices.

According to one embodiment, if transaction #1 has an initial value of x and a vertex points to another transaction #2, then transaction #1 contributes "-x" to transaction #2's ranking/weight.

According to one embodiment, with this process, each vertex in the DAG has a ranking value, which is calculated using the initial ranking and contribution rankings from neighboring transactions.

According to one embodiment, systems and methods can use a transaction picker to select transactions based on rankings of a ranked DAG.

According to one embodiment, the selection process is as follows. First, starting from the lowest vertices, according to the following principle: when selecting transaction #x, do not select all adjacent transactions (i.e., transactions conflicting with transaction #x): Select the transaction with the highest ranking.

Finally, according to one embodiment, a subset of transactions that can be safely committed can be selected. This method can achieve the highest total weight of a series of transactions. The selected transaction is output as result 1004 .

FIG. 11 illustrates an exemplary relationship graph that may be used with an embodiment of the present disclosure, according to one embodiment.

According to one embodiment, for example, assume the ledger system receives a series of transactions comprising eight ordered transactions #1-#8, labeled 1101-1108. In this embodiment, the conflict relationships of each transaction determined by the conflict detector can be summarized in one graph.

After conflict detection, the conflict relationship is as follows.
・C (#1, #2, #3) = #6
・C(#4, #5)=#7
・C(#6, #7)=#8
According to one embodiment, the above conflict relationship can be understood as transaction #6 conflicting with transactions #1, #2 and #3. Similarly, transaction #7 conflicts with transactions #4 and #5, and transaction #8 conflicts with transactions #6 and #7.

Continuing with this example, the weight of each transaction is, for example, equal to '1', according to one embodiment. Based on this, the ranking generator generates the relationship graph shown in FIG. 11 and provides it to the transaction picker. A transaction picker selects a transaction to commit.

As shown in FIG. 11, transactions #1, #2, #3, #4 and #5 all have a weight and transaction ranking of "1". To determine the transaction ranking for each transaction, we subtract these weights from those of the competing transactions using the method described above. Therefore, if we compute the transaction ranking of transaction #6 by subtracting the weights of transactions #1, #2 and #3 from the weight of transaction #6 (i.e., 1-3=-2), transaction #6 is equal to transaction Has a ranking of "-2". A similar procedure is performed to determine the total transaction weight of transaction #7. By subtracting the transaction weights of transactions #4 and #5 from the transaction weight of transaction #7 (ie, 1−2=−1), transaction #7 has a transaction ranking of “−1”. Similarly, repeat this procedure for transaction #8. By subtracting the negative weights of transactions #6 and #7 from the transaction weight of transaction #8, transaction #8 has a total transaction ranking of "4".

According to one embodiment, after computing the conflict graph, the transaction picker can determine which transactions to commit after the ranking generator ranks each transaction according to the weighted transaction conflicts. In this example, transaction #8 (which has the highest ranking) and transactions #1-#5 are selected to commit because they have positive values and do not conflict with each other. Transactions #6 and #7 are not selected for commit because they have low transaction rankings and both transactions conflict with transaction #8. Such selection is shown in the figure. In the illustration, transactions that have been selected to commit have a thick outline, and transactions that have not been selected to commit are shown with dashed lines.

FIG. 12 illustrates an exemplary relationship graph that may be used with an embodiment of the present disclosure, according to one embodiment.

According to one embodiment, FIG. 12 shows a second situation that is more complicated than the situation shown in FIG.

According to one embodiment, for example, assume a blockchain system receives a series of transactions comprising eight ordered transactions #1-#8, labeled 1201-1208. In this embodiment, the conflict relationships of each transaction determined by the conflict detector can be summarized in one graph.

After conflict detection, the conflict relationship is as follows.
・C (#1, #2, #3) = #6
・C(#4, #5)=#7
・C (#3, #6, #7) = #8
According to one embodiment, the above conflict relationship can be understood as transaction #6 conflicting with transactions #1, #2 and #3. Similarly, transaction #7 conflicts with transactions #4 and #5, and transaction #8 conflicts with transactions #3, #6 and #7.

Continuing with this example, the weight of each transaction is, for example, equal to '1', according to one embodiment. Based on this, the ranking generator generates the relationship graph shown in FIG. 12 and provides it to the transaction picker. A transaction picker selects a transaction to commit.

As shown in FIG. 12, transactions #1, #2, #3, #4 and #5 all have a weight and transaction ranking of "1". To determine the transaction ranking for each transaction, we subtract these weights from those of the competing transactions using the method described above. Therefore, if we compute the transaction ranking of transaction #6 by subtracting the weights of transactions #1, #2 and #3 from the weight of transaction #6 (i.e., 1-3=-2), transaction #6 is equal to transaction Has a ranking of "-2". A similar procedure is performed to determine the total transaction weight of transaction #7. By subtracting the transaction weights of transactions #4 and #5 from the transaction weight of transaction #7 (ie, 1−2=−1), transaction #7 has a transaction ranking of “−1”. Similarly, repeat this procedure for transaction #8. By subtracting the negative weights of transactions #3, #6 and #7 from the transaction weight of transaction #8, transaction #8 has a total transaction ranking of "3".

In the relationship graph of FIG. 12, the systems and methods can provide multiple transaction conflicts. For example, in FIG. 12, transaction #3 conflicts with two transactions (#6 and #8).

According to one embodiment, after computing the conflict graph, the transaction picker can determine which transactions to commit after the ranking generator ranks each transaction according to the weighted transaction conflicts. In this example, transactions #8 and #1, #2, #4 and #5 (which have the highest rankings) are selected to commit because they have positive values and do not conflict with each other. Transaction #3 is selected to commit because it competes with transaction #8, which has a higher ranking than transaction #3, even though it has similar transaction rankings to transactions #1, #2, #4, and #5. not. Transactions #6 and #7 are not selected for commit because they have low transaction rankings and both transactions conflict with transaction #8. Such selection is shown in the figure. In the illustration, transactions that have been selected to commit have a thick outline, and transactions that have not been selected to commit are shown with dashed lines.

FIG. 13 illustrates an exemplary relationship graph that may be used with an embodiment of the present disclosure, according to one embodiment.

According to one embodiment, FIG. 13 shows a third situation that is more complicated than the situation shown in FIG. In the relationship map of Figure 13, the 14 transactions are separated into two conflict clusters. Transactions #1 to #8 (1301 to 1308) are included in cluster A, and transactions #9 to #14 (1309 to 1314) are included in cluster B.

According to one embodiment, for example, assume that a blockchain system receives a series of transactions comprising 14 ordered transactions, labeled Transactions #1-#14. The conflict relationships of all transactions determined by the conflict detector can be summarized in one graph.

After conflict detection, the conflict relationship is as follows.
・C (#1, #2, #3) = #6
・C(#4, #5)=#7
・C (#3, #6, #7) = #8
・C (#9, #10, #11, #13) = #14
・C(#11, #12)=#13
Continuing with this example, according to one embodiment, each transaction's Assume that the weight is equal to '1'.

Transactions #1 to #8 are included in cluster A, as shown in FIG. Transactions #1, #2, #3, #4 and #5 all have a weight and transaction ranking of "1". To determine the transaction ranking for each transaction, we subtract these weights from those of the competing transactions using the method described above. Therefore, if we compute the transaction ranking of transaction #6 by subtracting the weights of transactions #1, #2 and #3 from the weight of transaction #6 (i.e., 1-3=-2), transaction #6 is equal to transaction Has a ranking of "-2". A similar procedure is performed to determine the total transaction weight of transaction #7. By subtracting the transaction weights of transactions #4 and #5 from the transaction weight of transaction #7 (ie, 1−2=−1), transaction #7 has a transaction ranking of “−1”. Similarly, repeat this procedure for transaction #8. By subtracting the negative weights of transactions #3, #6 and #7 from the transaction weight of transaction #8, transaction #8 has a total transaction ranking of "3".

Transactions #9 to #14 are included in cluster B, as shown in FIG. Transactions #9, #11, #12 and #14 all have a weight and transaction ranking of "1". Transaction #10 has an initial weight of "2". Transaction #13 has an initial weight of '5', but subtracts '2' from this weight (the weight of transactions #11 and #12) to have a transaction ranking of '3'. Transaction #14 has an initial weight of '1', but subtracts '7' from this weight (the initial and modified weights of transactions #9, #10, #11, and #13) to give a transaction ranking of '-'. 6”.

According to one embodiment, after computing the conflict graph, the transaction picker can determine which transactions to commit after the ranking generator ranks each transaction according to the weighted transaction conflicts. In this example, transactions #8 and #13 (which have the highest ranking) and transactions #1, #2, #4, #5, #9 and #10 have positive values and do not conflict with each other. Therefore, it is selected for commit. Transaction #3 is selected to commit because it competes with transaction #8, which has a higher ranking than transaction #3, even though it has similar transaction rankings to transactions #1, #2, #4, and #5. not. Transactions #6 and #7 are not selected for commit because they have low transaction rankings and both transactions conflict with transaction #8. Transactions #11 and #12 are not selected for commit because they conflict with transaction #13. Transaction #14 is not selected for commit because it has a lower transaction ranking than the edge-sharing transactions.

FIG. 14 is a flowchart illustrating an example directed acyclic graph (DAG) based transaction processing method in a distributed ledger, according to one embodiment.

At step 1401, the method can provide a distributed ledger fabric for processing multiple transactions in an enterprise-grade distributed ledger framework.

At step 1402, the method can detect conflicts between transactions using a conflict detector.

At step 1403, the method may use the ranking generator to add an initial weight parameter of the plurality of initial weight parameters to each transaction of the plurality of transactions. A ranking generator generates a DAG, at least one vertex of the DAG containing a ranking value.

At step 1404, the method may use a transaction picker to select a set of transactions to commit from the plurality of transactions based on the generated DAG.

While various embodiments have been described above, these embodiments are presented by way of illustration and not limitation of the present disclosure. These embodiments were chosen and described in order to explain the features and principles of the disclosure and its practice. Embodiments illustrate systems and methods. These embodiments may provide new and/or improved functionality and/or reduced resource utilization, increased capacity, increased throughput, improved efficiency, reduced latency, enhanced security. Various features are used to improve the performance of systems and methods by providing performance advantages including, but not limited to, improved ease of use, and/or.

Certain embodiments are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products that illustrate architecture, functionality, processes and/or operations. Each block of a flowchart or block diagram represents an element, function, process, module, segment, or portion of instruction comprising one or more executable instructions to implement the specified function. In some alternative implementations, the functions noted in the block diagrams or flowcharts may occur out of the order noted. For example, two blocks shown in succession may be executed substantially concurrently or in the reverse order depending on the functionality involved. Each block of the flowcharts and/or block diagrams, or combinations of blocks in the flowcharts and/or block diagrams, represents computer program instructions and/or dedicated hardware and/or hardware and computer program instructions that perform the specified function. may be implemented in combination with

In some embodiments, features are implemented in a computer that includes a processor, a computer-readable medium, and a network card/interface for communicating with other computers. In some embodiments, features include personal computers interconnected by a network, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. It is implemented in a network computing environment with computing systems that include various types of computer configurations. The network may be a local area network (LAN), a switched fabric network (eg, InfiniBand), a wide area network (WAN), and/or the Internet. A network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and/or edge servers.

In some embodiments, a feature is a computing system that includes back-end components (e.g., data servers), or a computing system that includes middleware components (e.g., application servers), or front-end components (e.g., a client computer with a graphical user interface or web browser used to interact with implementations of the subject matter described herein), or back-end components, middleware components, or interconnected by a network; Implemented in a computing system that includes any combination of front-end components. A computing system can include clients and servers that have a client-server relationship to each other. In some embodiments, functionality is implemented in a computing system that comprises a distributed computing environment that includes one or more computer clusters connected via a network. All computers in a distributed computing environment may be located at a single location, or may be located as computer clusters at different remote locations connected by a network.

In some embodiments, features are implemented in the cloud as part of a cloud computing system or as a service distributed to users in a self-service provisioning manner based on shared elastic resources using web technologies. Cloud characteristics may include, for example, on-demand self-service, broad network access, resource pools, rapid adaptability, and counting services. Cloud deployment models include public, private, and hybrid. Cloud service models include SaaS (Software as a Service), PaaS (Platform as a Service), DBaaS (Database as a Service), and IaaS (Infrastructure as a Service). Cloud generally refers to a combination of hardware, software, network, and web technologies that distribute shared elastic resources to users. Cloud as used herein can include public cloud, private cloud, and/or hybrid cloud implementations and can include cloud SaaS, cloud DBaaS, cloud PaaS, and/or cloud IaaS deployment models.

In some embodiments, features are implemented using hardware, software, firmware, or a combination thereof. In some embodiments, features are implemented using a processor configured or programmed to perform one or more functions of the approaches taught. In some embodiments, the processor is a single-chip or multi-chip processor, digital signal processor (DSP), system-on-chip (SOC), application-specific designed to perform the functions described herein. Integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic devices, state machines, discrete gate or transistor logic, discrete hardware components, or any combination thereof. In some implementations, features are implemented by circuits that perform the specified functions. In other implementations, the features are implemented in a computer, computing system, processor, and/or network configured to perform specified functions, e.g., using instructions stored on a computer-readable storage medium. be.

In some embodiments, features include software and/or firmware for controlling hardware in processing systems and/or network systems, or processors and/or networks and other systems using features of the present disclosure. embedded in software and/or firmware to enable interaction of Such software or firmware may include, but is not limited to, application code, device drivers, operating systems, virtual machines, hypervisors, application programming interfaces, programming languages, and execution environments/containers. Appropriate software encoding can readily be prepared by skilled programmers based on the teachings of the present disclosure.

In some embodiments, the approaches taught in this disclosure include computer program products that are machine-readable or computer-readable media for storing or carrying instructions, including software and/or firmware. These instructions can be used to program or configure a system, such as a computer, to carry out the processes or functions of the approaches taught in this disclosure. A machine-readable or computer-readable medium may be a floppy disk, hard drive, solid state drive, optical disk, DVD, CD-ROM, microdrive, magneto-optical disk, ROM, RAM, EPROM, EEPROM, DRAM, VRAM, flash Any type of medium or device suitable for storing instructions and/or data including, but not limited to, memory devices, magnetic or optical cards, molecular memories, nanosystems, or variations thereof and combinations thereof can include a storage medium that can include In certain embodiments, a storage medium or computer-readable medium is a non-transitory machine-readable storage medium or non-transitory computer-readable storage medium. A machine-readable medium or computer-readable medium may also include transitory media such as carrier waves or transmission signals.

Accordingly, from one aspect, this specification describes a DAG-based transaction processing system and method on a distributed ledger. According to one embodiment, a DAG-based transaction processing system and method on a distributed ledger can be deployed. This model can improve throughput performance. Additional weighting mechanisms can be used to adjust the final performance based on various business requirements. Unlike existing work using linear structures, better performance can be achieved.

Further examples of the disclosure are described in the numbered sections below.
Section 1. A directed acyclic graph (DAG) based transaction processing system in a distributed ledger, comprising an enterprise-grade distributed ledger framework and a distributed ledger fabric, the distributed ledger fabric comprising a plurality of transactions, comprising a conflict detector, the conflict detector detecting conflicts between the transactions, and a ranking generator, wherein the ranking generator selects one of the initial weight parameters adding an initial weight parameter to each transaction of a plurality of transactions, the ranking generator generating a DAG, at least one vertex of the DAG containing a ranking value, comprising a transaction picker, the transaction picker comprising: A transaction set to be committed is selected from a plurality of transactions based on the generated DAG.

Clause 2. The system of Clause 1, wherein the plurality of initial weight parameters are provided via an input.

Clause 3. The system of Clause 1, wherein the plurality of initial weight parameters are automatically derived.

Clause 4. The system of Clause 3, wherein the plurality of initial weight parameters are derived based on the relative importance of each of at least the plurality of transactions.

Section 5. The generated DAG calculates a ranking of each of the plurality of transactions, and the calculated ranking of each of the plurality of transactions is one of the initial weighting parameters or modified weighting parameters assigned to the transaction. A system according to any one of the preceding clauses, wherein the system is

Clause 6. The system of Clause 5, wherein each modified weight parameter is calculated based on an initial weight parameter of the subject transaction and at least one ranking of transactions competing with the subject transaction.

Clause 7. The system of any one of clauses 1-6, wherein transactions in multiple transaction sets to be committed are non-conflicting.

Section 8. A directed acyclic graph (DAG) based transaction processing method in a distributed ledger, comprising providing a distributed ledger fabric in an enterprise-grade distributed ledger framework, the distributed ledger fabric processes a plurality of transactions, a conflict detector detecting a plurality of conflicts between the plurality of transactions; and a ranking generator adding one of the plurality of initial weight parameters to the plurality of transactions. the ranking generator generating a DAG, at least one vertex of the DAG containing a ranking value, and the transaction picker adding a plurality of Involves selecting a set of transactions to commit from the transactions.

Clause 9. The method of clause 8, wherein the plurality of initial weight parameters are provided via an input.

Clause 10. The method of clause 8, wherein the plurality of initial weight parameters are automatically derived.

Clause 11. The method of Clause 10, wherein the plurality of initial weight parameters are derived based on the relative importance of each of at least the plurality of transactions.

Section 12. The generated DAG calculates a ranking of each of the plurality of transactions, and the calculated ranking of each of the plurality of transactions is one of the initial weighting parameters or modified weighting parameters assigned to the transaction. Clause 12. The method of any one of clauses 8-11, wherein

Clause 13. The method of Clause 12, wherein each modified weight parameter is calculated based on an initial weight parameter of the target transaction and at least one ranking of transactions competing with the target transaction.

Clause 14. The method of any one of clauses 8-13, wherein each transaction in a set of multiple transactions to be committed is non-conflicting.

Section 15. A computer-readable medium bearing directed acyclic graph (DAG) based transaction processing instructions in a distributed ledger, the instructions being read and executed to cause one or more computers to: Cause steps to be performed that include:
a conflict detector detecting multiple conflicts between multiple transactions;
a ranking generator adding an initial weight parameter of the plurality of initial weight parameters to each transaction of the plurality of transactions, the ranking generator generating a DAG; The vertices contain ranking values,
A transaction picker selects a set of transactions to commit from the plurality of transactions based on the generated DAG.

Clause 16. The computer-readable medium of Clause 15, wherein the plurality of initial weight parameters are provided via inputs.

Clause 17. The computer-readable medium of Clause 15, wherein the plurality of initial weight parameters are automatically derived.

Clause 18. The computer-readable medium of Clause 17, wherein the plurality of initial weight parameters are derived based on the relative importance of each of at least the plurality of transactions.

Section 19. The generated DAG computes a ranking of each of the multiple transactions,
19. The computer readable according to any one of clauses 15-18, wherein the calculated ranking of each of the plurality of transactions is one of an initial weighting parameter or a modified weighting parameter assigned to the transaction. medium.

Clause 20. The computer-readable medium of Clause 19, wherein each modified weight parameter is calculated based on an initial weight parameter of the subject transaction and at least one ranking of transactions competing with the subject transaction.

The description above is not intended to be exhaustive or to limit the scope to the precise forms disclosed. Also, while the embodiments have been described using a particular series of transactions and steps, it will be apparent to those skilled in the art that this does not preclude the execution of additional transactions and steps unless explicitly stated. Furthermore, while specific combinations of features are described in various embodiments, it will be apparent to those skilled in the art that different combinations of features are within the scope of the disclosure. In particular, features (such as apparatus or methods) described in a particular embodiment, variation or drawing may be practiced in another embodiment, variation or drawing, without departing from the teachings and scope of another embodiment, variation or drawing. Can be combined or replaced with features. Moreover, various additions, subtractions, deletions, variations, substitutions of elements with equivalents, and other modifications and alterations in form, detail, implementation and application may be made without departing from the spirit and scope of the present disclosure. will be clear to those skilled in the art. The broader spirit and scope of protection is defined by the following claims and their equivalents.

Claims (15)

A directed acyclic graph (DAG) based transaction processing system on a distributed ledger, comprising:
An enterprise-grade distributed ledger framework and
a distributed ledger fabric, the distributed ledger fabric processing a plurality of transactions;
a conflict detector, said conflict detector detecting conflicts between said transactions;
a ranking generator, wherein the ranking generator adds an initial weight parameter of a plurality of initial weight parameters to each transaction of the plurality of transactions, the ranking generator generating a DAG; at least one vertex includes a ranking value;
A system comprising a transaction picker, wherein the transaction picker selects a transaction set to be committed from the plurality of transactions based on the generated DAG. 2. The system of claim 1, wherein the plurality of initial weight parameters are provided via inputs. 2. The system of claim 1, wherein the plurality of initial weight parameters are automatically derived. 4. The system of claim 3, wherein the plurality of initial weight parameters are derived based on at least the relative importance of each of the plurality of transactions. the generated DAG computes a ranking of each of the plurality of transactions;
4. The system of any one of the preceding claims, wherein the calculated ranking of each of the plurality of transactions is one of an initial weighting parameter or a modified weighting parameter assigned to the transaction. 6. The system of claim 5, wherein each modified weight parameter is calculated based on an initial weight parameter of a target transaction and at least one ranking of transactions competing with the target transaction. 4. A system according to any one of the preceding claims, wherein each transaction in the plurality of transaction sets to be committed is non-conflicting. A directed acyclic graph (DAG) based transaction processing method in a distributed ledger, comprising:
providing a distributed ledger fabric in an enterprise-grade distributed ledger framework, the distributed ledger fabric processing a plurality of transactions;
a conflict detector detecting conflicts between the transactions;
a ranking generator adding an initial weight parameter of one of a plurality of initial weight parameters to each transaction of the plurality of transactions, wherein the ranking generator generates a DAG; one vertex contains the ranking value,
A method comprising a transaction picker selecting a set of transactions to commit from the plurality of transactions based on the generated DAG. 9. The method of claim 8, wherein the plurality of initial weight parameters are provided via inputs. 9. The method of claim 8, wherein the plurality of initial weight parameters are automatically derived. 11. The method of claim 10, wherein the plurality of initial weight parameters are derived based on at least the relative importance of each of the plurality of transactions. calculating a ranking of each of the plurality of transactions in the generated DAG;
12. A method as claimed in any one of claims 8 to 11, wherein the calculated ranking of each of the plurality of transactions is one of an initial weighting parameter or a modified weighting parameter assigned to the transaction. 13. The method of claim 12, wherein each modified weight parameter is calculated based on an initial weight parameter of a target transaction and at least one ranking of transactions competing with the target transaction. 14. A method as claimed in any one of claims 8 to 13, wherein each transaction in the plurality of transaction sets to be committed is non-conflicting. A computer-readable medium bearing directed acyclic graph (DAG) based transaction processing instructions in a distributed ledger, which instructions, when read and executed, cause one or more computers to: A computer readable medium for carrying out the method of any one of claims 8 to 14.

Images