WO2023185054A1 - Method and system for deploying chaincode in alliance chain - Google Patents

Abstract

The present application provides a method and system for deploying a chaincode in an alliance chain. The method comprises: a third-party construction module receiving a first chaincode mounting command and a chaincode source code sent by a client; the third-party construction module constructing a chaincode mirror image on the basis of the chaincode source code; and the third-party construction module creating and starting a chaincode container on the basis of the chaincode mirror image, configuring a peer container and the chaincode container to be gRPC clients, establishing a proxy server as a gRPC server, and notifying the peer container of information of the gRPC server. By means of the described solution, a developer can still compile in a conventional chaincode compiling manner during the development of a chaincode source code, without making a change, so that there is no additional development cost for a chaincode developer; meanwhile, the chaincode mirror image is constructed by the third-party construction module, so that the dependence on a Docker is eliminated; on the other hand, although the chaincode container and the peer container are both configured to be the gRPC clients, the connection between the chaincode container and the peer container can be achieved by means of the proxy server, so that the chaincode container can be decoupled from the peer container, thereby achieving servitization.

Description

Methods and systems for deploying chaincode in alliance chains

This application claims priority to the Chinese patent application submitted to the State Intellectual Property Office of China on March 30, 2022, with application number 202210327152.7 and the application name "Method and system for deploying chain code in alliance chain", the entire content of which is incorporated by reference incorporated in this application.

Technical field

The embodiments of this specification belong to the field of blockchain technology, and particularly relate to a method and system for deploying chain codes in a consortium chain.

Background technique

Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. In the blockchain system, data blocks are combined into a chained data structure in a chronological manner and are cryptographically guaranteed to be an untamperable and unforgeable distributed ledger. Due to the characteristics of blockchain, such as decentralization, non-tamperable information, and autonomy, blockchain has also received more and more attention and applications.

Contents of the invention

The purpose of the present invention is to provide a method and system for deploying chain code in a consortium chain, including:

A method of deploying chaincode in a consortium chain, including:

The third-party building module receives the command to install the first chain code and the chain code source code sent by the client;

The third-party building module builds a chaincode image based on the chaincode source code;

The third-party building module creates and starts the chain code container based on the chain code image, sets the Peer container and the chain code container as communication clients, establishes a proxy server as the communication server, and notifies the Peer container of the communication server information.

A system for deploying chaincode in a consortium chain, including:

The third-party building module receives the command to install the first chain code and the chain code source code sent by the client. The third-party building module builds a chain code image based on the chain code source code, and creates and starts the chain code container based on the chain code image. , set the Peer container and chain code container as the communication client, establish a proxy server as the communication server, and notify the Peer container of the communication server information;

The Peer container is set as a communication client, receives the chain code transaction request initiated by the user through the communication server, and sends the request to the chain code container through the communication server;

The chain code container is set as a communication client. After receiving the chain code transaction request through the communication server, the transaction is executed, and the execution result is returned to the Peer container through the communication server;

Proxy server, set as communication server.

The above solution allows developers to write in the traditional chain code method without making changes when developing chain code source code, thus adding no additional development costs to chain code developers. At the same time, by building chain code images from third-party building modules, we get rid of dependence on Docker. On the other hand, although the chaincode container and the Peer container are both set as communication clients, the connection between the chaincode container and the Peer container can be opened through the proxy server, thereby decoupling the chaincode container and the Peer container. This enables service-oriented services.

Description of drawings

In order to explain the technical solutions of the embodiments of this specification more clearly, the drawings needed to be used in the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some of the embodiments recorded in this specification. , for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without exerting creative labor.

Figure 1 is an architectural diagram of Hyperledger Fabric in some embodiments of the present disclosure;

Figure 2 is a schematic diagram of the transaction process of Hyperledger Fabric in some embodiments of the present disclosure;

Figure 3 shows the ledger structure of Hyperledger Fabric in some embodiments of the present disclosure;

Figure 4 shows the structure of blocks and transactions in some embodiments of the present disclosure;

Figure 5 is a schematic diagram of the basic principles of Docker in some embodiments of the present disclosure;

Figure 6 is a schematic diagram of the operation logic of Docker in some embodiments of the present disclosure;

Figure 7 is a schematic diagram of the basic principles of Kubernetes in some embodiments of the present disclosure;

Figure 8 is a schematic diagram of communication and command links including Docker in this disclosure;

Figure 9 is a schematic diagram of deploying a traditional chaincode container in the present disclosure;

Figure 10 is a schematic diagram of deploying a traditional chaincode container in the present disclosure;

Figure 11 is a schematic diagram of communication and command links after removing Docker in this disclosure;

Figure 12 is a schematic diagram of deploying external chain code after removing Docker in this disclosure;

Figure 13 is a flow chart of deploying chaincode containers after removing Docker in this disclosure;

Figure 14 is a schematic diagram of the deployment chain code container after removing Docker in this disclosure.

Detailed ways

In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described The embodiments are only some of the embodiments of this specification, but not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts should fall within the scope of protection of this specification.

Blockchains can usually be divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. In addition, there are many types of combinations, such as private chain + alliance chain, alliance chain + public chain and other different combinations. Among them, the most decentralized one is the public chain. Public chains are represented by Bitcoin and Ethereum. Participants who join the public chain can read data records on the chain, participate in transactions, and compete for the accounting rights of new blocks. Moreover, each participant (i.e., node) can freely join and exit the network and perform related operations. On the contrary, the private chain has the writing permission of the network controlled by an organization or institution, and the data reading permission is regulated by the organization. Simply put, a private chain can be a weakly centralized system with strict restrictions and few participating nodes. This type of blockchain is more suitable for internal use within specific organizations. The alliance chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization". Each node in the alliance chain usually has a corresponding entity or organization; participants join the network through authorization and form a stakeholder alliance to jointly maintain the operation of the blockchain.

HyperLedger Fabric is an open source alliance chain implementation. Different from public chains such as Bitcoin and Ethereum, nodes in the Hyperledger Fabric network generally need to be authorized and authenticated before joining, thereby avoiding the resource overhead of POW (Proof of Work, proof of work), greatly improving transaction processing efficiency, and meeting the requirements of Enterprise-level applications require processing performance, and the system does not require token support to operate.

Figure 1 shows a typical architecture diagram of Hyperledger Fabric 1.4 and 2.0. Often multiple organizations come together as a consortium to form a blockchain network. In other words, organizations are participants in the blockchain system. An organization in Fabric can be a company, an enterprise, or an association in the real world. As shown in Figure 1, it includes organization 1, organization 2 and organization 3. Each organization can have its own corresponding Fabric-CA (Certification Authority, certificate issuance) server. An organization can have multiple peer nodes. The organization's Fabric-CA can issue certificates to Peer nodes within the organization, and the issued certificates can be used to identify the nodes and their organizations.

The nodes organized in the blockchain network are called Peers. Among them, the ledger can be saved on the Peer node. Specifically, Peer nodes can include endorsement nodes (Endorsing Peer), accounting nodes (Committing Peer), master nodes (Leader Peer) and anchor nodes (Anchor Peer). An organization can choose which nodes to install chaincode to implement business processes shared by consortium members without having to install chaincode on every node. Generally, chaincode can be installed on the endorsing node. After the chain code is installed on the endorsing node, and after instantiation, other nodes between organizations with a collaborative relationship (also called a channel) can know the chain code, and only then can the application initiate a call. The most important additional information provided when instantiating is the endorsement policy, which describes which organizations must approve the transaction before it will be accepted onto their ledger. In fact, one or more smart contracts (Smart Contract) can be defined in the chain code. Each smart contract has a unique identifier in the chaincode. Applications can access the specified smart contract in the chaincode container through the smart contract's identifier. The peer node can also be the master node. There is generally only one master node in an organization. The master node can communicate with the ordering service to obtain the latest blocks from the ordering service and synchronize them among the nodes within the organization. Peer nodes can also be anchor nodes. Anchor nodes can exchange information with other organizations on behalf of the organization. Generally every organization has an anchor node. All peer nodes can be accounting nodes, which are used to verify transactions in the ordering service node block and maintain copies of the world state and ledger. The accounting node can obtain the blocks containing transactions from the orderer node and add them to the blockchain after verifying these blocks. It should be noted that "node" is a logical entity, and multiple nodes of different types can run on the same physical entity.

Application (Application, abbreviated as App) can be connected to the blockchain node through the built-in SDK (Software Development Tool) and API (Application Programming Interface, Application Programming Interface). The App can then generate a transaction proposal that calls the chaincode and submit the transaction proposal to the blockchain network. As mentioned before, once the chaincode is installed and instantiated on the peer node, the smart contract within the chaincode becomes available to the associated channel, which means that the application can call the chaincode. The application calls the chain code by sending a transaction proposal to the node to which the organization specified by the endorsement policy belongs. The transaction proposal serves as the input of the smart contract, and the smart contract on the endorsement node generates an endorsed transaction response after simulated execution. The blockchain network can eventually sort these transactions and generate blocks and submit them to the distributed ledger. Specifically, the sorting service can complete the sorting of transactions and generate blocks. When this process is completed, the App can receive the corresponding event.

In a simple model often used for testing, the ordering service is an independent node in the network, that is, the ordering service is composed of one ordering node. Many times, an ordering service can include multiple nodes and can be configured to have different ordering nodes in different organizations.

Specifically, combined with the Hyperledger Fabric architecture shown in Figure 1, a typical transaction process is as follows:

a1: The application sends a transaction proposal (proposal) to the endorsement node.

After logging in to the application with an account, for example, after logging in to the application with account A, you can use the SDK in the application to generate a transaction. The role of the SDK includes packaging transaction proposals into a suitable format (such as the protocol buffer used in gRPC) and generating signatures for transaction proposals based on the user's key. This generated transaction can contain <clientID, chaincodeID, txPayLoad, timestamp, clientSig> and other information. Among them, clientID represents the account ID of the logged-in client, chaincodeID represents the ID of the called chaincode, txPayLoad represents the transaction payload, timestamp represents the timestamp of transaction initiation, and clientSig is the signature of the client account.

Applications can send transactions to one or more endorsement nodes according to the endorsement policy (EndorsePolicy). Endorsement policies generally include nodes organized by relationships such as and, or, majorityof, etc., which can be specified in the chain code. and{endorsement node 1, endorsement node 2, endorsement node 3} can indicate that the transaction needs to be endorsed by endorsement node 1, endorsement node 2, and endorsement node 3. or{endorsement node 1, endorsement node 2, endorsement node 3} can mean endorsement by any one of endorsement node 1, endorsement node 2, and endorsement node 3. majorityof{endorsing node 1, endorsing node 2, endorsing node 3} can mean that the transaction needs to be endorsed by at least half of the nodes among endorsing node 1, endorsing node 2, and endorsing node 3. Here, it means that at least half of the three endorsing nodes need to be endorsed. 2.

As shown in Figure 2, taking and {endorsement node 1, endorsement node 2, endorsement node 3} as an example of the endorsement strategy, the application sends the transaction to the endorsement node 1, endorsement node 2, and endorsement node 3 respectively.

a2: After the endorsement node verifies the received transaction proposal, it simulates execution of the transaction and endorses it, and returns a proposal response (proposalresponse) to the application.

After the endorsement node verifies the transaction content, it can simulate the execution of the contract in the transaction. The endorsement node's verification of the transaction may include verifying the transaction signature using the public key of account A, the transaction has not been submitted before (replay attack protection), the transaction initiator is a qualified initiator on the channel, etc. After passing the verification, according to the above example, the endorsing node can further simulate the execution of the sent transaction. During the simulated execution process, the endorsing node can call the chain code specified in the transaction (specifically, specify the smart contract in the chain code), and input the parameters in the transaction, and then simulate the execution.

The execution results of the transaction generally include the generated read set (ReadSet, Rset or RS) and/or write set (WriteSet, Wset or WS) (RS and WS can be collectively referred to as read and write sets, or written as RWset). These read and write sets can eventually be written to the blockchain ledger maintained locally by the Peer node. Read sets and write sets generally use Key-Value expressions. In addition, the read-write set generally also carries version information, which indicates the version for which the operations in the read-write set are generated.

After the transaction is simulated and executed and a read-write set is generated, the endorsement node can endorse the generated read-write set. Specifically, the endorsement node can use its own private key to sign the read-write set according to the endorsement policy.

Continuing the previous example, if and{endorsing node 1, endorsing node 2, endorsing node 3} is used as the endorsement strategy, the endorsing node 1, endorsing node 2, and endorsing node 3 simulate and execute the transaction respectively. , and send the endorsement results to the application respectively. Under this endorsement strategy, the endorsement results of different endorsement nodes for the same transaction generally only have different signatures, otherwise it does not comply with the endorsement strategy.

a3: The application collects the returned proposal response from the endorsement node.

The application may collect proposal responses returned by endorsing nodes. As shown in Figure 2, taking and {endorsement node 1, endorsement node 2, endorsement node 3} as an example of the endorsement strategy, the application can collect proposal responses returned by endorsement node 1, endorsement node 2, and endorsement node 3. Specifically, the SDK in the application can be used to parse the returned proposal response. Specifically, the SDK can verify the signature of the endorsement node in the proposal response, and compare the proposal responses returned by each endorsement node to determine whether the proposal responses are consistent (normally only the signatures should be inconsistent) and whether they are executed in accordance with the specified endorsement policy.

a4: The application sends the endorsed transaction to the ordering node.

When the application collects consistent proposal responses returned by enough endorsement nodes, for example, after collecting the proposal responses returned by endorsement node 1, endorsement node 2, and endorsement node 3, the application can call the SDK to convert the endorsed transaction Sent to ordering node. The endorsed transactions can include packaged results including transaction proposals, read/write sets, and endorsement signatures.

a5: The sorting service sorts these transactions and generates blocks based on the sorted results.

The sorting service can continuously collect endorsed transactions, including at least one endorsed transaction sent by different applications or the same application. Specifically, the sorting node in the sorting service can sort these transactions after collecting a certain amount of endorsement transactions. Specifically, for example, transactions can be sorted according to their timestamps. The sorting node can then package the sorted transactions into blocks.

a6: The sorting service broadcasts the generated block to the master node, and the master node synchronizes it to other Peer nodes in the organization to which it belongs.

In a Hyperledger Fabric network composed of different organizations, there is a master node in one or more Peer nodes of each organization. The master node can communicate with the ordering node to obtain the latest blocks from the ordering node and synchronize them among the peer nodes in the organization.

a7: The accounting node verifies the block, appends the block to the blockchain of the local ledger, and updates the world state in the local ledger based on the block.

All Peer nodes can be accounting nodes. Accounting nodes can maintain ledgers locally. The ledger may include blockchain data and world state data, as shown in Figure 3.

A blockchain consists of a series of blocks linked back and forth. Each block includes three parts: block header, block data and block metadata.

The block header contains the block number (N0, N1, N2, N3... in Figure 3). The block number of each block is unique and generally increases monotonically. The block number can be generated by the ordering service during the process of packaging and generating blocks. The block header can also contain the hash value of the block data of the current block (CH in Figure 3, CurrentBlockHash), and the hash value of the previous block header (PH0, PH1, PH2, etc. in Figure 3, PH is PreviousBlockHash The abbreviation of is also the block hash of the previous block). In this way, all blocks in the blockchain are arranged in order and cryptographically linked together. This hashing and linking makes blockchain ledger data extremely secure. Even if a node that saves the blockchain ledger has its data tampered with, other nodes can quickly confirm the tampered blockchain ledger through the hash value of the block. For example, in block 2 in Figure 3, its block header 2 includes the block number N2, the hash value of block data 2 of the current block, and the hash value of block header 1 of the previous block 1.

Block data contains an ordered list of transactions. Each transaction in the transaction list represents a query or update operation on the world state. As mentioned before, block data can be written to the block data when the ordering service packages and generates blocks. As shown in Figure 4, block data can include a series of transactions. These transactions can be sorted by transaction time. Each transaction can include transaction header, transaction signature, transaction proposal, transaction response, and transaction endorsement.

●The transaction header records some important metadata about the transaction, such as the name and version of the relevant chain code.

●The transaction signature contains a signature created by the client application. This field can be used to determine whether the transaction has been tampered with.

●Transaction proposals include encoded input parameters provided by the application to the smart contract. When the smart contract runs, the input parameters provided by this proposal are combined with the current world state to determine the new world state.

●The transaction response records the values before and after the world state in the form of a read-write set.

●The transaction response is the output of the smart contract. If the transaction verification is successful, the transaction will be applied to the ledger to update the world state.

●Transaction endorsement is a set of signed transaction responses. These signatures come from relevant organizations specified by the endorsement policy, and the number of these organizations must meet the requirements of the endorsement policy.

Block metadata includes the time the block was written, as well as the certificate, public key, and signature of the block writer. Subsequently, the submitter of the block will also add a valid or invalid flag to each transaction, but since this information is generated at the same time as the block, it will not be included in the current block hash of the block header.

It should be noted that the genesis block (i.e., block 0 in Figure 3) generally does not contain any user transactions, but only some configuration transactions. Configuration transactions can be used to initialize world state.

The world state is a database that stores the current values of a set of ledger states. The current value of a ledger state can be accessed through the world state without the need to traverse the entire transaction log to calculate the current value.

An example of world state records the information of two cars CAR1 and CAR2. For example, it is recorded in two states respectively.

The k1-v1 of the first state is:

{key=CAR1,value=Audi}version=0

There is a more complex value in the second state:

{key=CAR2,value={model:BMW,color:red,owner:Jane}}version=0

Overall, the second state is a key-value pair (abbreviated as k-v pair), in which value2 also contains k-v pairs, and the above example contains three different k-v pairs, here we set them to the three in v2 The k-v pairs are k21=model:v21=BMW, k22=color:v22=red, k23=owner:v23=Jane.

The version of both states is 0, which is also the starting version of each state. The version number can be incremented each time the status is updated. When updating the status, the version number will first be checked to ensure that the current status version is consistent with the version at the time of endorsement (to avoid concurrent updates).

Applications can invoke (invoke) smart contracts to ultimately implement operations such as put and delete on the world state. In one example, application 1 initiated a transaction T8 to endorsement node 1 in organization 1, endorsement node 2 in organization 2, and endorsement node 3 in organization 3 according to the endorsement policy. The endorsement policy is, for example, "and{endorsement node 1 , endorse node 2, endorse node 3}". Similarly, application 2 also initiated a transaction T9 to endorsement node 1 in organization 1, endorsement node 2 in organization 2, and endorsement node 3 in organization 3 according to the endorsement policy. The endorsement policy is also "and{endorsement node 1" , endorse node 2, endorse node 3}".

A T8 transaction example is:

<clientID=application1,

chaincodeID=ID1,

txPayLoad=[Method1(k1)],

timestamp,

clientSig>

This T8 transaction calls the chain code numbered ID1, for example, calls the method Method1 and enters the parameter k1. For example, Method1 is to read the value corresponding to the input parameter, that is, to read the brand of the vehicle.

A T9 transaction example is:

<clientID=application1,

chaincodeID=ID1,

txPayLoad=[Method2(k23,"Paul")]

timestamp,

clientSig>

This T9 transaction calls the chain code numbered ID1, for example, calls the method Method2 and enters the parameter k23. Method 2 is, for example, to modify the name of the vehicle owner, usually when the vehicle is transferred.

After the two transactions T8 and T9 are verified, simulated and endorsed by each endorsement node, each endorsement node returns application 1 and application 2 respectively in the proposal response. The endorsement node simulates the execution of the transaction content. For example, for T8 and T9, the read and write sets are generated as follows:

T8: Read<k1>version=0

T9: Write<k23,Paul>version=0

The version=0 indicates the state version for which the operation is generated.

The endorsement node can endorse the generated read-write set and return the proposal response to Application 1 and Application 2 respectively. For example, for the T8 transaction, endorsement node 1, endorsement node 2, and endorsement node 3 respectively perform simulated execution and endorsement of the transaction, and send the endorsement results to the application 1 respectively. For T9 transactions, similarly, endorsement node 1, endorsement node 2, and endorsement node 3 simulate and execute and endorse the transaction respectively, and send the endorsement results to the application 2 respectively.

After Application 1 and Application 2 each collect the proposal responses returned by the endorsement nodes, they can send the endorsed transactions to the ordering node. The endorsed transactions can include packaged results including transaction proposals, read/write sets, and endorsement signatures. The sorting service sorts transactions T8 and T9. For example, according to the timestamp of the transaction, T8 comes before T9 comes after, then the sorted result of T8 and T9 generates block 3. Subsequently, the ordering service can broadcast the generated block 3 to each master node in organization 1, organization 2 and organization 3, and synchronize it to other peer nodes in the organization to which it belongs. Each accounting node verifies the block, appends the block to the blockchain of the local ledger, and updates the world state in the local ledger based on the block. At this time, the state affected by the transaction in block 3 is as follows:

k1-v1:

{key=CAR1,value=Audi}version=1

k2-v2:

{key=CAR2,value={model:BMW,color:red,owner:Paul}}version=1

The above-mentioned endorsement node simulates the execution of the transaction content, including the simulated execution of the transaction that calls the chain code, and can use container technology, that is, the chain code container mentioned above. The chaincode container refers to the container environment (Docker) in which the chaincode runs independently of the endorsement node process. Its function is to provide an isolated sandbox environment for the chaincode to run. Containers are lightweight packages of application code that also contain the dependencies required for a program to run, such as specific versions of programming language runtimes and libraries required to run software services. In this way, the execution of smart contracts can be isolated and the endorsing node process will not crash due to errors or malicious code. When instantiating the chaincode, the endorsing node populates the container image with the chaincode and calls the Docker management API to deploy the image. If the container is not running, you can start a new container. Once run, proposals received by the endorsing node will be transferred to the container for execution.

As mentioned above, the execution of the chain code requires the installation of the chain code. That is, after the chain code is installed on the endorsing node, it can be called by the application only after it is instantiated. The deployment of chain code on the blockchain includes the deployment of traditional chain code and the deployment of external chain code. External chain code can be deployed and executed on nodes outside the blockchain, for example, to facilitate users to independently manage the running environment of each external node and its code. Traditional chain code is different from external chain code. Traditional chain code is deployed and executed by nodes inside the blockchain.

The container technology mentioned above is a type of virtual machine technology. Virtualization technology actually includes hardware virtualization and container technology. Virtual machines use hardware virtualization technology. The virtual machine requires virtual hardware to install a complete operating system before it can install/run applications. If every time an application is released, a virtual machine is used to virtualize a complete operating system and a complete dependency environment is set up, which will be a relatively tedious task. Container technology is relatively lightweight. The operating system can be removed from the container, and instead it contains the application and the system environment on which the application depends. Through container technology, applications and dependent environments can be packaged, and the packaged content can still run normally when transplanted to other hosts with the same operating system. It can be seen that the advantages of container virtualization technology are that it is more lightweight, easy to migrate, convenient to deploy, and consumes less resources. Additionally, containers enable standardization. One of the mainstream container technologies is docker, in addition to rocket, rkt and kata.

The core concepts of Docker include: Image, Container, and Registry.

The entire operating logic of Docker is shown in Figure 5. The Docker Client sends the Docker command that needs to be executed to the Docker Daemon (daemon process, also called Docker Engine) on the host where Docker is running (DockerHost), and the Docker Daemon decomposes the request and executes it. For example:

Executing the Docker build command will build an image based on the Dockerfile and store it locally;

Executing the Docker pull command will pull the image from the remote container image warehouse to the local one;

Executing the Docker run command will pull the container image and run it into a container instance.

Image construction includes writing the dependencies and target files that need to be installed according to the Dockerfile, and superimposing them onto an existing base image to generate a new image. When the container is running, a Container layer is generated on top of the container image. This layer loads a copy of the complete container image into memory and runs it. This copy loaded into memory can be modified by the container, but it is limited to running in memory; any modifications to the Container layer will not take effect on the underlying image, and the modifications made when the container dies will also be included. die. Dockerfile is a configuration file used when executing the docker build command to build a docker image. It allows the docker image to be defined through basic syntax. Each instruction in it can describe a step to build the image. For example:

The commands we commonly use in Dockerfile are as follows:

·FROM: What image is built based on

·WORKDIR: The working directory of the container

·RUN: Execute commands during the container building process

·CMD&ENTRYPOINT: Execute the command after the container is started

·ADD&COPY: Add specified files to the container image

·ENV: Set environment variables

·EXPOSE: Set the port exposed by the container

Specifically, as shown in Figure 6, the Docker client sends the request that needs to be created to Docker Engine. As mentioned earlier, Docker Engine is a containerized daemon. Docker Engine can send the request to containerd, and containerd calls runC. containerd is used to manage the life cycle of the container. It implements the management of the container life cycle by calling the runC API. runC directly interacts with the files that the container depends on (such as cgroup/linux kernel, etc.), and is responsible for configuring the cgroup/namespace and other environments required to start the container for the container, and creating related processes for starting the container. In Figure 6, there is an additional containerd-shim layer (also called a shim carrier, similar to an adaptation layer). The function of container-shim is to decouple containerd from the real container (process in it), allowing runC to create /Exit after running the container. When containerd goes down, containerd-shim can be maintained, thus ensuring that the file descriptor opened by the container will not be closed (so that Dockerd can be upgraded without affecting the service). Rely on containerd-shim to collect/report the exit status of containers so that containerd is not needed to monitor the created child processes. For example, a fabric peer node can eventually run in the container process on the far left in Figure 6. This container can also be called a Peer container.

As the number of container instances increases, the complexity of container management rises sharply. At this time, kubernetes (k8s for short) comes in handy. k8s is an open source container cluster management system that can realize automatic deployment, automatic expansion and contraction, maintenance and other functions of container clusters. It can help with a series of operations such as deployment, release and orchestration of containers, and can greatly simplify the management of containers. Operation and maintenance operations.

In Kubernetes, you can create multiple containers, each container runs an application instance, and then use the built-in load balancing strategy to manage, discover, and access this group of application instances, and these details do not require operation and maintenance personnel. to perform complex manual configuration and processing. The Kubernetes cluster architecture and related core components are shown in Figure 7: A Kubernetes cluster generally contains 1 Master node and multiple Node nodes. A node can be a physical machine or a virtual machine. Master is the cluster control node of k8s. In each k8s cluster, a Master is responsible for the management and control of the entire cluster. Other machines in the k8s cluster are called Node nodes. The Node node is the workload node in the k8s cluster. The Node can be assigned some workload by the Master; when a Node goes down, the workload on it will be automatically assigned by the Master. Transfer to other Node.

Each Node node runs the key component kubelet. Kubelet is the Master's Agent on the Node node. It works closely with the Master to manage the life cycle of the local running container. It is responsible for the creation, start and stop of the container corresponding to the Pod, and implements the basic functions of cluster management. Pod is the smallest deployment unit in k8s. It is a collection of containers and the basic unit for k8s to orchestrate services and scale up and down.

Node nodes can be dynamically added to the k8s cluster during operation, provided that some key components including the above kubelet have been correctly installed, configured and started on this node node. By default, kubelet will register itself with the Master. Once the Node is included in the cluster management scope, the kubelet will regularly report its own situation to the Master node, such as the operating system, Docker version, the CPU and memory status of the machine, and what previous The Pod is running, etc., so that the Master can learn the resource usage of each Node and implement an efficient and balanced resource scheduling strategy. When a Node does not report information for more than the specified time, it will be judged as "lost contact" by the Master, and the Node's status will be marked as Not Ready. Then the Master will trigger the automatic process of "large workload transfer".

In addition, the Node node also has the component kube-proxy, which is used to implement the network proxy of the Pod on the Node node, realize the communication between Kubernetes Service and the outside, and can maintain network rules and four-layer load balancing work. Kubernetes Service is located between kube-proxy and Pod, which defines the access entrance of a service. Access between internal Pods and containers can be performed directly through service. The relationship between kube-proxy, service (i.e. Kubernetes Service) and Pod in Figure 7 is only for illustration. In fact, one service can correspond to multiple Pods, and one Pod can also correspond to multiple services. Service can be created by k8s, and the relationship between service and Pod can also be created by k8smaster (not shown in the figure).

If you use Docker as a K8S container runtime, kubelet needs to first call Docker Engine through docker-shim, and then call containerd through Docker Engine. docker-shim is a component of Kubernetes, its main purpose is to operate Docker through CRI (Container Runtime Interface, container runtime interface). Docker appeared in 2013, Kubernetes was released in 2014 and used Docker as the container runtime (Container Runtime) by default, and docker-shim first officially appeared in 2016. When Docker was first created, it did not consider container orchestration or Kubernetes, so Docker itself does not comply with CRI, that is, it does not comply with the container runtime interface. Therefore, Kubernetes used Docker as its default container runtime when it was first created, and subsequent code contains a lot of Docker-related operating logic. Later, in order to be able to decouple and be compatible with more container runtimes, Kubernetes separated the entire logic related to operating Docker to form docker-shim. Overall, the architecture of using Docker as the K8S container runtime can be shown in Figure 7. In this figure, the pod on the leftmost side of each node illustrates the relationship between kubelet and multiple Container commands in the Pod, while for other pods The Container is omitted. Among them, the communication and command relationship can be shown in Figure 8. If Docker is used as a K8S container, kubelet needs to first call Docker through docker-shim, and then call containerd through Docker.

Most of the existing Fabric peer nodes are deployed through kubernetes. As shown in the container process on the lower left side of Figure 6, this container process can actually run a Peer node. This container process can also be called a Peer container. Using container technology to run the chain code, it is ultimately expected to run the chain code in the middle container process as shown in Figure 6.

To use container technology to run chain code, you need to generate a chain code program in the container and the operating environment required for the execution of the chain code program. A chaincode program can be a binary file, that is, a compiled object file. The operating environment refers to the dependencies required for the above-mentioned program to run. In traditional chain code, containerized chain code programs run on nodes and require an adapted operating environment. In order to reduce the user's burden and allow users to only focus on the source code of the chain code developed at the high-level language level without paying attention to the differences in its running environment on different blockchain nodes, the blockchain receives the source code of the chain code developed by the user. Finally, kubernetes and docker can be combined to compile the chain code source code and execute it, thereby achieving the advantages of lightweight, easy migration, convenient deployment, and low resource usage, and realizing functions such as automated deployment, automatic expansion and contraction, and maintenance of container clusters.

The process of deploying traditional chaincode in Hyperledger Fabric is shown in Figure 9. It should be noted that it is assumed here that a Peer container has been deployed in a Container using kubernetes and docker technology. This Peer container is, for example, container1, in which, for example, the endorsement node is running.

b1: The client initiates an installation chaincode command to the endorsement node to be deployed, and packages the created chaincode source code and endorsement policy and sends them to the node.

The client here refers to the blockchain client that creates the chaincode source code and sends the chaincode source code. After developers create the chaincode source code, they can package the chaincode source code and set the endorsement policy. Then they can send the packaged chaincode source code and the set endorsement policy through the client to the endorsement node where the chaincode is to be deployed. The endorsement nodes to be deployed with chaincode generally include the endorsement nodes included in the endorsement policy. The endorsement node is a Peer container as shown in the figure.

b2: The endorsement node uses docker to create a temporary container, and compiles the chain code source code into a target file in the created temporary container.

According to the type of chain code source code sent by the client, the endorsing node can use docker (docker here mainly includes docker-shim and dockerengine in the figure) to create the corresponding temporary container. The corresponding temporary container contains the compilation environment of the corresponding source language. The local or remote image warehouse of the endorsing node contains compilation environment images for compiling various chain code source codes, and can be pulled and used by docker. In this way, the endorsing node receives a type of source code and can use docker to create a temporary container containing the corresponding compilation environment. For example, for source code edited in Go language, create a temporary container suitable for the Go language compilation environment; for source code edited in Java language, create a temporary container suitable for the Java language compilation environment; for source code edited using Node.js language, create a temporary container suitable for the Java language compilation environment. source code, create a temporary container suitable for the node.js language compilation environment.

In the created temporary container, the source code can be compiled and then the target file can be generated. Similarly, the source code edited in the Go language is compiled into a binary file in a temporary container, the Java language source code is compiled into a jar file in the temporary container, and the node.js language source code is compiled into target code.

Specifically, during the process of creating a temporary container, the peer container can generate a first configuration file based on the language of the chain code source code uploaded by the client, here for example dockerfile_1, the content of which describes the steps for creating a temporary container. The Peer container can send the Dockerbuild command and the dockerfile_1 to docker-shim, and then send it to dockerEngine. Docker Engine can pull the compilation environment image suitable for compiling chain code source code based on the (local or remote) image warehouse specified in dockerfile_1, and send the request to containerd, which then calls runC. The result of executing the above command is that runC pulls up a temporary container built based on the compilation ring mirror image. This temporary container is, for example, container2.

In the temporary container, the chain code source code can be compiled based on the compilation ring mirror, thereby obtaining the chain code program, that is, the above target file.

It should be noted that the temporary container is activated directly by the Peer container through Docker-shim without going through k8s.

b3: The temporary container places the compiled target file in a certain directory and notifies the Peer container.

b4: After receiving the notification, the Peer container uses docker to build a chain code image containing the target file.

Specifically, after receiving the notification, the Peer container can generate a second configuration file based on the target file, here for example dockerfile_2, the content of which describes the steps to build a chain code image, and includes the image of the running environment for executing the chain code program. and the storage path of the chaincode program. The Peer container can send the Dockerbuild command, the Dockerpull command and the dockerfile_2 to reach the dockerEngine through the Docker-shim call. Docker Engine can pull the operating environment image suitable for running the chain code program based on the (local or remote) image warehouse specified in dockerfile_2, and pull the target code from the aforementioned storage path. In this way, a new image containing the chaincode program and running environment can be regenerated and stored in the local/remote warehouse. This newly generated chain code image can be run by containers on the current host or other hosts on the Fabric network, thereby achieving one-time packaging and multiple executions. The host here can be a physical machine or a virtual machine, or even a container.

b5: After the Peer container receives the transaction that calls the chain code, it starts the chain code container through docker and installs and instantiates the chain code in it based on the chain code image.

Subsequently, after the Peer container receives the transaction calling the chain code, if the traditional chain code container has not been started, the Peer container can initiate a Dockerrun command to dockerEngine through docker-shim, and the command is sent to containerd, and then containerd calls runC. In this way, runC pulls up a traditional chaincode container built based on the chaincode image. This traditional chaincode container is, for example, container3.

Furthermore, the Peer container can input the parameters in the transaction to the chain code container, and perform chain code simulation to execute the transaction.

In addition, after b3, you can also use the following method as shown in Figure 10:

b5': The Peer container starts the chaincode container through docker and installs and instantiates the chaincode based on the chaincode image.

In b4, as mentioned above, after receiving the notification, the Peer container uses docker to build a chain code image containing the target file. In addition to sending the Dockerbuild command and the dockerfile_2 to dockerEngine, the Peer container can also send the Docker run command to dockerEngine. This instruction is sent to containerd through docker-shim and dockerEngine, and then containerd calls runC. In this way, runC pulls up a traditional chaincode container built based on the chaincode image. This traditional chaincode container is, for example, container3. That is to say, once the chain code image is built, the traditional chain code container built by the chain code image can be pulled up, without having to wait for the transaction of calling the chain code to be triggered by the Peer node to pull up the traditional chain like in b5. code container. In this way, the traditional chain code container is pulled up in advance. After the subsequent peer node receives the transaction request to call the chain code, it can directly call the chain code for simulated execution, instead of temporarily pulling up the traditional chain code container and then calling the chain code. Carry out simulated execution. Obviously, this method can improve the execution speed of the contract.

It can be seen that the main role of dockerengine in the above process is to build the image, and most communication with dockerengine needs to be carried out through Dockershim. The process of deploying traditional chaincode in Fabric 2.0 (and subsequent versions) using kubernetes and docker technology relies heavily on docker, specifically docker-shim and dockerEngine. In addition, as mentioned before, if you use Docker as a K8S container runtime, kubelet needs to first call DockerEngine through docker-shim, and then call containerd through Docker Engine.

As mentioned before, docker-shim is a component of Kubernetes. Its main purpose is to operate Docker through CRI, specifically the above-mentioned DockerEngine. When Docker was first created, it did not consider container orchestration or Kubernetes. However, Kubernetes used Docker as its default container runtime when it was first created. The subsequent code contains a lot of Docker-related operating logic. Later, in order to be able to decouple and be compatible with more container runtimes, Kubernetes separated the entire logic related to operating Docker to form docker-shim.

Containerd is a product of the standardization of container technology. In order to be compatible with OCI (Open Container Organization) standards, the container runtime and its management functions are separated from Docker Daemon. containerd can provide an interface for DockerDaemon upwards, so that Docker Daemon can shield the following structural changes and ensure that the original interface is downwardly compatible. downwards, it can be combined with runC through containerd-shim, so that the engine can be upgraded independently, avoiding all the previous upgrades of Docker Daemon. Container unavailability problem. runc is a command line tool that can create and run containers according to OCI standards.

Theoretically, even if dockerEngine is not running, containers can be managed directly through containerd, which eliminates the need for docker-shim.

K8S releases CRI (Container Runtime Interface), which unifies the container runtime interface. Any container runtime that supports CRI can be used as the underlying container runtime of K8S. Kubernetes mentioned in version 1.20 that it will no longer maintain the docker-shim shim in subsequent versions, and will begin to remove the shim as early as version 1.23. Docker-shim has been removed, thus removing support for Docker as a container runtime. As mentioned before, containerd is a project separated from Docker and can serve as an underlying container runtime in its own right. Now it has become a better choice for Kubernete container runtime. Not only Docker, but also many cloud platforms also support containerd as the underlying container runtime. In addition to containerd, there are also CRI-O and others that can be used as the underlying container runtime.

If containerd is used as a K8S container runtime, containerd can have a built-in CRI plug-in, so that kubelet can directly call containerd, as shown in Figure 11. Obviously, kubelet directly calls containerd through CRI, which can shorten the communication link, thereby improving performance, and the resource usage will become smaller after removing docker (Docker is not a pure container runtime and has a lot of other functions, so its existence consume more resources).

In addition to traditional chain codes, external chain codes can also be deployed in Hyperledger Fabric. A process of deploying external chaincode is shown in Figure 12. Similar to Figure 9, it is assumed that a Peer container has been deployed in a Container using kubernetes and docker technology. This Peer container runs in a cloud service environment. As mentioned before, traditional chaincode is generally deployed and executed on nodes within the blockchain. External chain codes are generally deployed and run on nodes outside the blockchain to facilitate users to independently manage each external node and its operating environment. As shown in Figure 12, in an example, the user environment includes Client. The process can include the following:

d1: Client builds and starts the external chain code container in the user environment where it is located.

After the Client starts the external chain code container, it can also obtain the address (such as IP address) and port where the external chain code container runs. Since the external chaincode container needs to execute the chaincode and is located outside the blockchain network, subsequent nodes on the blockchain must forward the transaction calling the chaincode to the external chaincode container, and the nodes on the blockchain will It is necessary to obtain information such as the address and port of the external chain code container (for example, including certificate configuration for TLS (Transport Layer Security, Transport Layer Security Protocol) communication) in order to communicate with the external chain code container.

The communication method can use RPC (Remote Procedure Call, remote procedure call). RPC can encapsulate a service call in a local method, allowing the caller to call the service as if it were a local method, while shielding it from the underlying implementation details. Therefore, it is a lightweight and imperceptible way of cross-process communication. The specific implementation can be through a set of agreements between the caller and the server, and data interaction can be carried out based on TCP long connections.

gRPC is an RPC implementation developed by Google. It is a high-performance, open source and universal RPC framework designed for mobile and HTTP/2. It supports many common programming languages and also provides powerful streaming calling capabilities. , has become one of the most mainstream RPC frameworks. Implement the defined service interface on the server side and run a gRPC server to handle gRPC client calls. When the gRPC client initiates a call to the gRPC server, it needs to obtain the address, port and other information of the gRPC server. gRPC is a preferred implementation in this application. In fact, both communication clients and communication servers with similar functions can be implemented in this application. The following explanation will still take gRPC as an example.

The Client starts an external chaincode container and can set the external chaincode container as the gRPC server.

d2: Client sends the instruction to install the external chain code to the Peer container in the cloud service environment.

The instruction sent by the Client to install the external chain code may include the IP address and port of the external chain code container. Specifically, the Client can send a connection.json file, which contains the IP address, port and other information of the above-mentioned external chain code container. In addition, the Client can also send a metadata.json file, which indicates that the specified installed chain code is an external chain code.

d3: The Peer container initiates a connection with the external chain code container to call the chain code.

After the Peer container receives the instruction to install the external chain code, through metadata.json, the Peer container can know that the external chain code is currently installed. Furthermore, the Peer container can be set up as a gRPC client. After the Peer container obtains the address, port and other information of the external chain code container through connection.json, it can initiate a connection with the external chain code container through the gRPC client and maintain a long connection.

Subsequently, after the Peer container receives the transaction that calls the external chain code, it can send the transaction to the external chain code container through the maintained long connection, thereby realizing the call of the chain code. After the transaction calling the chain code is executed in the external chain code container, as mentioned above, the execution result, that is, the read/write set, can be returned to the gRPC client through the maintained long connection, that is, returned to the Peer container.

In fact, in the examples in Figures 9 and 10, the started traditional chaincode container can be set as the gRPC client, and the Peer container can be set as the gRPC server. The gRPC server will not actively initiate a connection to the gRPC client, but the gRPC client needs to actively initiate a connection to the gRPC server. In b5, the Peer container, as a gRPC server, can include its own address and port in the instructions for creating a traditional chain code container, and can be placed in the connection.json file and sent to the traditional chain code container. Furthermore, after the traditional chaincode container is built, a connection can be initiated to the Peer container based on the address and port of the gRPC server in the connection.json file. After success, a long connection can be maintained with the Peer container. Subsequently, the Peer container can send the transaction calling the chain code to the traditional chain code container through the long connection to simulate execution. In b1, the installation chaincode instruction initiated by the Client does not need to include the connection.json and metadata.json files.

Different from the traditional chain code container construction method, during the construction process of the external chain code container, the client needs to inform the peer through the installation chain code instructions of connection.json and metadata.json that contain the address and port of the external chain code container. The container is currently installed with external chaincode. In addition, since the user can build and start the external chain code container in advance in the user environment where the client is located or the environment specified by the user, there is no need for the Peer container to participate in the construction and startup process, so the construction and startup of the external chain code container are omitted here. detailed process.

The advantage of setting the external chain code container as the gRPC server is that the external chain code container can be decoupled from the Peer container, so that it can be service-oriented. On the one hand, the external chain code container does not need to run on the same host as the Peer, but can run on a different host from the Peer container, which is more flexible; on the other hand, the external chain code container can be used as a service Provided to different Peer containers, for example, serving different Peer containers in the same organization. In this case, the Peer container acts as a gRPC client.

The process of deploying chaincode in an alliance represented by Hyperledger Fabric 2.0 can be shown in Figure 13 and includes the following:

S110: The third-party building module receives the command to install the first chain code and the chain code source code sent by the client.

The client can be similar to the b1 process in Figure 9, initiate a command to install the first chain code to the endorsement node to be deployed, and package and send the created chain code source code and endorsement policy to the node. After developers create the chaincode source code, they can package the chaincode source code and set the endorsement policy. Then they can send the packaged chaincode source code and the set endorsement policy through the client to the endorsement node where the chaincode is to be deployed. The endorsement nodes to be deployed with chaincode generally include the endorsement nodes included in the endorsement policy.

The first chaincode command here is very similar to the traditional chaincode command mentioned above. It does not include the connection.json and metadata.json files, and it does not include the IP address and port of the gRPC server.

As shown in Figure 1 and the corresponding text, the fabric can include multiple organizations, and each organization can have multiple peers. Here, a governor node can be set up in each organization to manage peer nodes in the current organization. As mentioned before, it can be set that a Peer node has been deployed in a container using kubernetes and containerd technology, which can be called a Peer container, and a governor node has been deployed in another container, which can be called a governor container. In addition to managing peer nodes in the current organization, the governor container can also have a built-in cckeeper module. Of course, other forms of setting cckeeper outside the Peer container are also possible. In addition, the cckeeper module can also be built into the Peer container.

The example in Figure 13 illustrates the situation where the cckeeper module is built into the governor container. Other situations are slightly simpler than this.

S120: The third-party building module builds a chaincode image based on the chaincode source code.

After the peer container receives the command to install the first chain code and the chain code source code from the client, it can send the command to install the first chain code and the chain code source code to the built-in or external cckeeper module. This cckeeper is a third-party Building blocks. In addition, the client can also send the command to install the first chain code and the chain code source code directly to the Governor container, so that cckeeper can obtain the command to install the first chain code and the chain code source code. In either case, the cckeeper module can receive the chain code source code sent by the client, and then generate a third configuration file (dockerfile), here set to dockerfile_3. Dockerfile_3 can include a description of creating an image and building a container.

Building a chaincode image, as mentioned above, includes compiling the chaincode program and adding the compiled chaincode program to a running environment to generate an image.

The cckeeper module can send the task of creating an image and building a container to the k8s Master. In this way, referring to Figure 7, the Master can initiate tasks to the kubelet in a node. After receiving the task, kubelet sends the command to create a container to containerd through the CRI plug-in, and then containerd calls runC, so that an image building container can be created, such as container4.

On the other hand, after the cckeeper module generates dockerfile_3, it can send dockerfile_3 to imgbuilder (container image building tool), and then imgbuilder can pull a compilation environment image based on the content in dockerfile_3. The content in this image is suitable for compiling the chain code source code. For example, imgbuilder can include the Kaniko container image tool, which is a container image building tool open sourced by Google and has the functions required by the imgbuilder module. imgbuilder can perform image building tasks in the created image building container. In the image building container, imgbuilder can compile the chain code source code based on the compilation ring mirror, thereby obtaining the chain code program, which is the above target file. imgbuilder can store the generated chain code program in a path and notify cckeeper, either through the Peer container or directly.

After receiving the notification, the cckeeper module can generate a fourth configuration file based on the target file, here for example dockerfile_4, the content of which describes the steps to build the chain code image, and includes the image of the running environment for executing the chain code program and the chain The storage path of the code program. cckeeper can send instructions to build chaincode mirrors to imgbuilder. imgbuilder can pull the operating environment image suitable for running the chain code program according to the (local or remote) image warehouse specified in dockerfile_4, and pull the target code from the aforementioned storage path. In this way, a new image containing the chaincode program and running environment can be regenerated and stored in the local/remote image warehouse. This newly generated chain code image can be run by containers on the current host or other hosts on the Fabric network, thereby achieving one-time packaging and multiple executions. The host here can be a physical machine or a virtual machine, or even a container.

After imgbuilder completes building the chaincode image, it can send a notification to cckeeper.

S130: The third-party building module creates and starts a chaincode container based on the chaincode image, sets the Peer container and chaincode container as the gRPC client, establishes a proxy server as the gRPC server, and notifies the gRPC server information to Peer container.

Here, the chain code container can be started after cckeeper completes building the chain code container, or the Peer container can trigger cckeeper to start the chain code container after receiving a transaction request to call the chain code.

The former is, for example, that the Peer container starts the chaincode container through cckeeper and installs and instantiates the chaincode in it based on the chaincode image. Specifically, after imgbuilder completes building the chaincode image, it can send a notification to cckeeper. After receiving the notification, cckeeper can pull up a traditional chaincode container built based on the chaincode image. That is to say, once the chain code image is built, the traditional chain code container built by the chain code image can be pulled up. In this way, the traditional chain code container is pulled up in advance. After the subsequent peer node receives the transaction request to call the chain code, it can directly call the chain code for simulated execution, instead of temporarily pulling up the traditional chain code container and then calling the chain code. Carry out simulated execution. Obviously, this method can improve the execution speed of the contract.

The latter is, for example, that after the Peer container receives the transaction that calls the chain code, it starts the chain code container through cckeeper and installs and instantiates the chain code in it based on the chain code image. Specifically, after imgbuilder completes building the chain code image, it can send a notification to cckeeper, so that cckeeper can obtain the storage path of the chain code image. After the Peer container receives the transaction calling the chain code, if the traditional chain code container has not been started, the Peer container can call cckeeper, and the cckeeper will pull up a traditional chain code container based on the chain code image. This traditional chain code container is, for example, It's a container.

Furthermore, the Peer container can input the parameters in the transaction to the chaincode container, and perform chaincode simulation to execute the transaction.

Additionally, third-party building blocks can set up the chaincode container as a gRPC client. The chaincode container is created by the Governor using a CRI-compliant container runtime and is created according to the client's first chaincode installation command. In this case, the chaincode container acts as a gRPC client. To use the created chaincode container to provide services for different Peer containers like the aforementioned external chaincode container, the Peer container also needs to serve as a gRPC client.

In this way, the Peer container and the chain code container are both gRPC clients. The two cannot establish a communication link and cannot communicate. The transaction initiated by the client to call the chain code cannot be realized.

Therefore, the Governor container can use a CRI-compliant container runtime to create a Proxy container, and the Proxy container can open a communication link between the Peer container and the chain code container, which are both gRPC clients. Specifically, the cckeeper in the Governor container can send a command to create a Proxy container to the Master, and the Master will notify the kubelet in the Node of the command. The kubelet can further use containerd containing the CRI plug-in to create a container in a Pod. This container. The ccproxy module can be run in the Proxy container. The image containing the ccproxy module can be pulled from the image repository and then started. The ccproxy module can establish two gRPC servers, one is a pseudo Peer server and the other is a pseudo chain code server. The pseudo chaincode server is responsible for interacting with the chain code container established by cckeeper in the traditional chain code manner, while the pseudo Peer server is responsible for interacting with the Peer container in the external chain code manner.

cckeeper can send information such as the IP address and port number of the Proxy container to the Peer container through the connection.json file. In this way, the Peer container can be set up as a gRPC client. After the Peer container obtains the address, port and other information of the Proxy container through connection.json, it can initiate a connection with the Proxy chain code container through the gRPC client and maintain a long connection.

Subsequently, after the Peer container receives the transaction calling the chain code, it can send the transaction to the chain code container through the maintained long connection, thereby realizing the call to the chain code. After the transaction calling the chain code is executed in the chain code container, as mentioned above, the execution result, that is, the read/write set, can be returned to the gRPC client through the maintained long connection, that is, returned to the Peer container.

As mentioned above, the above solution allows developers to write the chain code source code according to the traditional chain code method without making changes, thus adding no additional development costs to the chain code developers. At the same time, by using third-party building modules to build chain code images, we get rid of dependence on Docker. On the other hand, although the chain code container and the Peer container are both set as gRPC clients, the connection between the chain code container and the Peer container can be opened through the proxy server, thereby decoupling the chain code container and the Peer container. This enables service-oriented services.

The following uses a specific example in Hyperledger Fabric to illustrate the process of deploying chain code in the consortium chain, as shown in Figure 14, including:

c1: The client sends the first installation chaincode command to the Governor container. This command includes the created chaincode source code and endorsement policy.

As shown in Figure 1 and the corresponding text, the fabric can include multiple organizations, and each organization can have multiple peers. Here, a governor node can be set up in each organization to manage peer nodes in the current organization. As mentioned before, it can be set that a Peer node has been deployed in a container using kubernetes and containerd technology, which can be called a Peer container, and a governor node has been deployed in another container, which can be called a governor container. In addition to managing peer nodes in the current organization, governor can also have a built-in cckeeper module.

After the user creates the chaincode source code, he can send the chaincode source code and endorsement policy to the governor container belonging to the organization through the client.

The first install chaincode command is similar to the install traditional chaincode command in Figure 9. The Governor container receives the chain code source code sent from the client and can generate a third configuration file (dockerfile). Specifically, you can use its built-in cckeeper to generate this dockerfile, which is set to dockerfile_3 here. Dockerfile_3 can include a description of creating an image and building a container.

c2: The Governor container uses a CRI-compliant container runtime to create an image to build the container, and compiles the chain code source code into a target file.

The Governor can send the task of creating an image and building a container to the k8s Master, which can be sent by the cckeeper. In this way, referring to Figure 7, the Master can initiate tasks to the kubelet in a node. After receiving the task, kubelet sends the command to create a container to containerd through the CRI plug-in, and then containerd calls runC, so that an image building container can be created, such as container3.

On the other hand, after the Governor generates dockerfile_3, it can send dockerfile_3 to imgbuilder, and then imgbuilder can pull a compilation environment image based on the content in dockerfile_3. The content in this image is suitable for compiling the chain code source code. For example, imgbuilder can include the Kaniko container image tool, which is a container image building tool open sourced by Google and has the functions required by the imgbuilder module. imgbuilder can perform image building tasks in the created image building container. In the image building container, imgbuilder can compile the chain code source code based on the compilation ring mirror, thereby obtaining the chain code program, which is the above target file. imgbuilder can store the generated chain code program in a path and notify cckeeper.

During the above process, kubelet can communicate with containerd through CRI, and then send the relevant commands to create the container to containerd. In this way, after canceling docker-shim and docker-engine, the link is streamlined while keeping the image link open, improving performance and reducing resource usage as mentioned above.

c3: The image building container places the compiled target file in a certain directory and notifies the Governor container.

c4: The Governor container uses imgbuilder to build a chaincode image containing the target file and stores it in the image warehouse.

After receiving the notification, the cckeeper in the Governor container can generate a fourth configuration file based on the target file, here for example dockerfile_4, the content of which describes the steps to build a chain code image, and includes the image of the running environment for executing this chain code program. and the storage path of the chaincode program. cckeeper can send instructions to build chaincode mirrors to imgbuilder. imgbuilder can pull the operating environment image suitable for running the chain code program according to the (local or remote) image warehouse specified in dockerfile_4, and pull the target code from the aforementioned storage path. In this way, a new image containing the chaincode program and running environment can be regenerated and stored in the local/remote image warehouse. This newly generated chain code image can be run by containers on the current host or other hosts on the Fabric network, thereby achieving one-time packaging and multiple executions. The host here can be a physical machine or a virtual machine, or even a container.

After imgbuilder completes building the chaincode image, it can send a notification to the Governor container.

c5: The Governor container uses a CRI-compliant container runtime to create chaincode containers and Proxy containers.

Chaincode containers and Proxy containers can be created by cckeeper in the Governor container using a CRI-compliant container runtime. Specifically, cckeeper can send commands to create chaincode containers and Proxy containers to the Master, and the Master will notify the kubelet in the Node of the command. The kubelet can further use containerd containing the CRI plug-in to create a container.

The chaincode image can be run in the chaincode container. Through a series of instructions, the built chaincode image can be pulled from the image warehouse and run in a container of the Pod, thereby generating a chaincode container.

In Figures 9 and 10, Docker is used as the K8S container to run, and the chain code container is created by DockerEngine through containerd, and the created chain code container and the Peer container are located in the same host, so the Peer container can obtain the chain code container. address so that the Peer container can communicate with the chaincode container. Therefore, after the subsequent Peer container receives the transaction request for calling the chain code, it can input the parameters and other information carried in the transaction into the chain code container. The chain code in the chain code container can be run, and the running results can be fed back to the Peer container. For example, the read/write set mentioned above.

Different from the implementation in Figures 9 and 10 above, in Figure 14, the chaincode container is created by the Governor using a CRI-compliant container runtime and is created according to the client's installation chaincode command. In this case, the chaincode container acts as a gRPC client. . To use the created chaincode container to provide services for different Peer containers like the aforementioned external chaincode container, the Peer container also needs to serve as a gRPC client.

In this way, the Peer container and the chain code container are both gRPC clients. The two cannot establish a communication link and cannot communicate. The transaction initiated by the client to call the chain code cannot be realized.

Therefore, the Governor container can use a CRI-compliant container runtime to create a Proxy container, and the Proxy container can open a communication link between the Peer container and the chain code container, which are both gRPC clients. Specifically, the cckeeper in the Governor container can send a command to create a Proxy container to the Master, and the Master will notify the kubelet in the Node of the command. The kubelet can further use containerd containing the CRI plug-in to create a container in a Pod. This container. The ccproxy module can be run in the Proxy container. The image containing the ccproxy module can be pulled from the image repository and then started. The ccproxy module can establish two gRPC servers, one is a pseudo Peer server and the other is a pseudo chain code server. The pseudo chaincode server is responsible for interacting with the chain code container established by cckeeper in the traditional chain code manner, while the pseudo Peer server is responsible for interacting with the Peer container in the external chain code manner.

c6: The Governor container sends the command to install the second chain code to the Peer container.

Specifically, the cckeeper in the Governor can send the command to install the second chain code to the Peer container. Similar to the above-mentioned installation of external chain code instructions in Figure 13, the address and port of the chain code service may be included in the command to install the second chain code sent. Specifically, cckeeper can send a connection.json file, which contains information such as the address and port of the above-mentioned chain code service.

After the Peer container receives the command to install the second chain code and obtains the address and port of the chain code Proxy container through connection.json, the Peer container can be set as a gRPC client. Furthermore, the Peer container can initiate a connection with the Proxy container through the gRPC client and maintain a long connection. The chain code service can interact with the pseudo chain code server in the Proxy container, so that the Peer container interacts with the Proxy container in a similar way to the external chain code and can maintain a long connection. On the other hand, as mentioned above, the chaincode container can interact with the pseudo chaincode server in a manner similar to traditional chaincode and can maintain a long connection.

In fact, it can include a c7 step, in which cckeeper can establish a chain code service, as shown in the figure. After the Peer container receives the command to install the second chain code and obtains the address and port of the chain code service container through connection.json, the Peer container can be set as a gRPC client. Furthermore, the Peer container can initiate a connection with the chaincode service container through the gRPC client and maintain a long connection. The chain code service can interact with the pseudo chain code server in the Proxy container, so that the Peer container interacts with the Proxy container in a similar way to the external chain code and can maintain a long connection. On the other hand, as mentioned above, the chaincode container can interact with the pseudo chaincode server in a manner similar to traditional chaincode and can maintain a long connection. This is a more specific form of transformation.

In short, the connection between the chaincode container and the Peer container can be opened through the Proxy container. Subsequently, the Client initiates a transaction to call the chain code to the Peer container. The Peer container can initiate the transaction to the chain code container and connect to the chain code container. It can communicate and interact with the chain code container through the Proxy container, and the chain code container can simulate the transaction. Execute and return the read/write set. In this way, the client calls the chain code, and the interactive link can be shown as the dotted line in Figure 14.

Through the above process, developers can still write in the traditional chain code method without making changes when developing chain code source code, thus adding no additional development costs to chain code developers. At the same time, by installing the first chaincode command received by the Governor container, and creating the chaincode container, Proxy container and chaincode service, the created chaincode container can be service-oriented and more flexible like the external chaincode container. And can serve different Peer containers. More importantly, the above solution uses Governor to build chaincode images and create chaincode containers, eliminating dependence on Docker. At the same time, it is still compatible with traditional chaincode installation, which facilitates unified management of Fabric resources within the K8s cluster.

In the 1990s, improvements in a technology could be clearly distinguished as hardware improvements (for example, improvements in circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements in method processes). However, with the development of technology, many improvements in today's method processes can be regarded as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement of a method flow cannot be implemented using hardware entity modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic functions are determined by the user programming the device. Designers can program themselves to "integrate" a digital system on a PLD, instead of asking chip manufacturers to design and produce dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing, and before compilation The original code must also be written in a specific programming language, which is called Hardware Description Language (HDL), and HDL is not just one kind, but there are many, such as ABEL (Advanced Boolean Expression Language) , AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., are currently the most commonly used The two are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that by simply logically programming the method flow using the above-mentioned hardware description languages and programming it into the integrated circuit, the hardware circuit that implements the logical method flow can be easily obtained.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor. , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers and embedded microcontrollers. Examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, For Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, the controller can be completely programmed with logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded logic by logically programming the method steps. Microcontroller, etc. to achieve the same function. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as structures within hardware components as well as software modules implementing the methods.

The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not rule out that with the development of computer technology in the future, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, or a personal digital assistant. , media player, navigation device, email device, game console, tablet, wearable device, or a combination of any of these devices.

Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-inventive means. The sequence of steps listed in the embodiment is only one way of executing the sequence of many steps, and does not represent the only execution sequence. When the actual device or terminal product is executed, it may be executed sequentially or in parallel according to the methods shown in the embodiments or figures (for example, a parallel processor or a multi-thread processing environment, or even a distributed data processing environment). The terms "comprises," "comprises" or any other variation thereof are intended to cover a non-exclusive inclusion such that a process, method, product or apparatus including a list of elements includes not only those elements but also others not expressly listed elements, or also elements inherent to the process, method, product or equipment. Without further limitation, it does not exclude the presence of additional identical or equivalent elements in a process, method, product or apparatus including the stated elements. For example, if the words "first" and "second" are used to express names, they do not indicate any specific order.

For the convenience of description, when describing the above device, the functions are divided into various modules and described separately. Of course, when implementing one or more of this specification, the functions of each module can be implemented in the same or multiple software and/or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. . The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each process and/or block in the flowchart illustrations and/or block diagrams, and combinations of processes and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce a use A device for realizing the functions specified in one process or multiple processes of the flowchart and/or one block or multiple blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions The device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device. Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information. Information may be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and read-only memory. (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape, magnetic tape storage, graphene storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device. As defined in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should be understood by those skilled in the art that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. Product form.

One or more embodiments of this specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of the present description may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

Each embodiment in this specification is described in a progressive manner. The same and similar parts between the various embodiments can be referred to each other. Each embodiment focuses on its differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple. For relevant details, please refer to the partial description of the method embodiment. In the description of this specification, reference to the terms "one embodiment," "some embodiments," "an example," "specific examples," or "some examples" or the like means that specific features are described in connection with the embodiment or example. , structures, materials or features are included in at least one embodiment or example of this specification. In this specification, the schematic expressions of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the specific features, structures, materials or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and combine different embodiments or examples and features of different embodiments or examples described in this specification unless they are inconsistent with each other.

The above descriptions are only examples of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. To those skilled in the art, various modifications and changes may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of the claims.

Claims (20)

1. A method of deploying chaincode in a consortium chain, including:

   The third-party building module receives the command to install the first chain code and the chain code source code sent by the client;

   The third-party building module builds a chaincode image based on the chaincode source code;

   The third-party building module creates and starts the chain code container based on the chain code image, sets the Peer container and the chain code container as communication clients, establishes a proxy server as the communication server, and notifies the Peer container of the communication server information.
2. According to the method of claim 1, the third-party building module builds a chaincode image based on the chaincode source code, including:

   The third-party building module calls the container image building tool to build the chain code image based on the chain code source code and the adapted operating environment.
3. According to the method in claim 2, the third-party building module calls a container image construction tool to build a chain code image based on the chain code source code and the adapted operating environment, including:

   The third-party building module calls the container image building tool, which compiles the chain code source code sent by the client to obtain the chain code program;

   The third-party building module calls the container image building tool to add the chain code program to the adapted operating environment and generate it, thereby generating a chain code image.
4. According to the method in claim 3, the third-party building module calls a container image building tool, and the chain code source code sent by the client is compiled to obtain a chain code program, including:

   The third-party building module generates a third configuration file based on the chain code source code and sends it to the container image building tool, and creates an image to build the container;

   The container image building tool pulls the compilation environment image according to the third configuration file, and performs the image building task in the image building container to obtain the compiled chain code program.
5. According to the method of claim 3, the third-party building module calls a container image construction tool, adds the chain code program to an adapted operating environment and generates it, and generates a chain code image, including:

   The third-party building module generates the fourth configuration file based on the generated chain code program;

   The third-party building module calls the container image building tool and sends the fourth configuration file to the container image building tool;

   The container image building tool pulls the running environment image according to the fourth configuration file, and generates a chain code image including the chain code program and the running environment.
6. As in the method of claim 1, the third party creates and starts a chaincode container based on the chaincode image, including:

   After the third-party building module completes building the chain code, the chain code container is started, and the chain code image is loaded and started in the traditional chain code container; or,

   After receiving the transaction request for calling the chain code, the peer container triggers the third-party building module to start the chain code container, and loads and starts the chain code image in the traditional chain code container.
7. According to the method of claim 1, the third-party building module establishes a proxy server as a communication server and notifies the communication client of information about the communication server, including:

   The third-party building module establishes a proxy server, and establishes two communication servers on the proxy server, one as a pseudo Peer server and the other as a pseudo chain code server;

   Send the IP address and port information of the pseudo chaincode server to the chaincode container, and send the IP address and port information of the pseudo Peer server to the Peer container.
8. The method of claim 7, wherein:

   The Peer container initiates a connection with the proxy server through the communication client and maintains a long connection;

   The chain code container initiates a connection with the proxy server through the communication client and maintains a long connection.
9. The method according to any one of claims 1 to 8, wherein the third-party building module is provided inside the Peer container or outside the Peer container.
10. The method of claim 9, wherein a third-party building module is provided outside the Peer container, including:

    Third-party building blocks are set up in governance nodes.
11. A system for deploying chaincode in a consortium chain, including:

    The third-party building module receives the command to install the first chain code and the chain code source code sent by the client. The third-party building module builds a chain code image based on the chain code source code, and creates and starts the chain code container based on the chain code image. , set the Peer container and chain code container as the communication client, establish a proxy server as the communication server, and notify the Peer container of the communication server information;

    The Peer container is set as a communication client, receives the chain code transaction request initiated by the user through the communication server, and sends the request to the chain code container through the communication server;

    The chain code container is set as a communication client. After receiving the chain code transaction request through the communication server, the transaction is executed, and the execution result is returned to the Peer container through the communication server;

    Proxy server, set as communication server.
12. As in the system of claim 11, the third-party building module builds a chaincode image based on the chaincode source code, including:

    The third-party building module calls the container image building tool to build the chain code image based on the chain code source code and the adapted operating environment.
13. As in the system of claim 12, the third-party building module calls a container image construction tool to build a chain code image based on the chain code source code and the adapted operating environment, including:

    The third-party building module calls the container image building tool, which compiles the chain code source code sent by the client to obtain the chain code program;

    The third-party building module calls the container image building tool to add the chain code program to the adapted operating environment and generate it, thereby generating a chain code image.
14. As in the system of claim 13, the third-party building module calls a container image building tool, and the chain code source code sent by the client is compiled to obtain a chain code program, including:

    The third-party building module generates a third configuration file based on the chain code source code and sends it to the container image building tool, and creates an image to build the container;

    The container image building tool pulls the compilation environment image according to the third configuration file, and performs the image building task in the image building container to obtain the compiled chain code program.
15. As in the system of claim 13, the third-party building module calls a container image construction tool, adds the chain code program to an adapted operating environment and generates it, and generates a chain code image, including:

    The third-party building module generates the fourth configuration file based on the generated chain code program;

    The third-party building module calls the container image building tool and sends the fourth configuration file to the container image building tool;

    The container image building tool pulls the running environment image according to the fourth configuration file, and generates a chain code image including the chain code program and the running environment.
16. As in the system of claim 11, the third party creates and starts a chaincode container based on the chaincode image, including:

    After the third-party building module completes building the chain code, the chain code container is started, and the chain code image is loaded and started in the traditional chain code container; or,

    After receiving the transaction request for calling the chain code, the peer container triggers the third-party building module to start the chain code container, and loads and starts the chain code image in the traditional chain code container.
17. As in the system of claim 11, the third-party building module establishes a proxy server as the communication server, and notifies the communication client of information about the communication server, including:

    The third-party building module establishes a proxy server, and establishes two communication servers on the proxy server, one as a pseudo Peer server and the other as a pseudo chain code server;

    Send the IP address and port information of the pseudo chaincode server to the chaincode container, and send the IP address and port information of the pseudo Peer server to the Peer container.
18. The system of claim 17, wherein:

    The Peer container initiates a connection with the proxy server through the communication client and maintains a long connection;

    The chain code container initiates a connection with the proxy server through the communication client and maintains a long connection.
19. The system according to any one of claims 11 to 18, wherein the third-party building module is provided inside the Peer container or outside the Peer container.
20. The system of claim 19, wherein a third-party building module is provided outside the Peer container, including:

    Third-party building blocks are set up in governance nodes.

Images