Method and system for deploying chain code in consortium chain

Abstract

The present application provides a method and system for deploying chaincode in a consortium chain. The method includes: a third-party construction module receives a command and a chaincode source code for installing a first chaincode from a client; the third-party construction module builds a chaincode image based on the chaincode source code; the third-party construction module creates and starts a chaincode container based on the chaincode image, sets the Peer container and the chaincode container as gRPC clients, establishes a proxy server as a gRPC server, and notifies the Peer container of the information of the gRPC server. Through the above scheme, developers can still write in the traditional chaincode mode when developing chaincode source code without making changes, so that no additional development cost is added to chaincode developers; at the same time, by building a chaincode image by a third-party construction module, the dependence on Docker is eliminated; on the other hand, although both the chaincode container and the Peer container are set as gRPC clients, the connection between the chaincode container and the Peer container can be pulled through through the proxy server, so that the chaincode container can be decoupled from the Peer container, so that it can be service-oriented.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of blockchain technology, and in particular, to a method and system for deploying chain codes in a consortium chain. Background Art

[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. In the blockchain system, data blocks are combined into a chain data structure in a sequential manner according to time order, and a distributed ledger that cannot be tampered with or forged is guaranteed by cryptography. Due to the characteristics of blockchain such as decentralization, information cannot be tampered with, and autonomy, blockchain has also received more and more attention and application. Summary of the invention

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

[0004] A method for deploying chain code in a consortium chain, comprising:

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

[0006] The third-party building module builds a chain code image based on the chain code source code;

[0007] The third-party construction 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 a communication server, and notifies the information of the communication server to the Peer container.

[0008] A system for deploying chain codes in a consortium chain, comprising:

[0009] A third-party construction module receives a command for installing the first chain code and a chain code source code from a client, builds a chain code image based on the chain code source code, creates and starts a chain code container based on the chain code image, sets a Peer container and a chain code container as communication clients, establishes a proxy server as a communication server, and notifies the Peer container of information of the communication server;

[0010] The Peer container is set as a communication client, receives the chaincode transaction request initiated by the user through the communication server, and sends the request to the chaincode container through the communication server;

[0011] The chaincode container is set as a communication client. After receiving the chaincode transaction request through the communication server, it executes the transaction and returns the execution result to the Peer container through the communication server.

[0012] Proxy server, set as the communication server.

[0013] The above solution allows developers to develop chaincode source code in the traditional chaincode way without making any changes, which does not add additional development costs to chaincode developers. At the same time, by building chaincode images with third-party building modules, the dependence on Docker is eliminated. On the other hand, although both the chaincode container and the Peer container are set as communication clients, the connection between the chaincode container and the Peer container can be connected through the proxy server, so that the chaincode container can be decoupled from the Peer container, so that it can be service-oriented. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

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

[0016] Figure 2 A schematic diagram of a transaction process of Hyperledger Fabric in some embodiments of the present disclosure;

[0017] Figure 3 The ledger structure of Hyperledger Fabric in some embodiments of the present disclosure;

[0018] Figure 4 The structure of blocks and transactions in some embodiments of the present disclosure;

[0019] Figure 5 A schematic diagram of the basic principle of Docker in some embodiments of the present disclosure;

[0020] Figure 6 A schematic diagram of the operation logic of Docker in some embodiments of the present disclosure;

[0021] Figure 7 A schematic diagram of the basic principles of Kubernetes in some embodiments of the present disclosure;

[0022] Figure 8 A schematic diagram of the communication and command links included in the present disclosure including Docker;

[0023] Fig. 9 A schematic diagram of deploying a traditional chain code container in the present disclosure;

[0024] Fig.10 A schematic diagram of deploying a traditional chain code container in the present disclosure;

[0025] Fig.11 This is a schematic diagram of the communication and command links after removing Docker in the present disclosure;

[0026] Fig.12 This is a schematic diagram of deploying external chaincode after removing Docker in this disclosure;

[0027] Fig.13 This is a flowchart of deploying chaincode containers after removing Docker in this disclosure;

[0028] Fig.14 This is a schematic diagram of the deployment chaincode container after removing Docker in this disclosure. DETAILED DESCRIPTION

[0029] 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 drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0030] Blockchain can generally be divided into three types: public chain (Publick Blockchain), private chain (PrivateBlockchain) and consortium chain (Consortium Blockchain). In addition, there are many types of combinations, such as private chain + consortium chain, consortium chain + public chain and other different combinations. Among them, the public chain has the highest degree of decentralization. Participants who join the public chain can read the data records on the chain, participate in transactions, and compete for the right to record 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 write permission of the network controlled by a certain organization or institution, and the data reading permission is stipulated by the organization. In simple terms, the private chain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for use within a specific organization. The consortium chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization". Each node in the consortium 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.

[0031] HyperLedger Fabric is an open source consortium chain implementation. Unlike public chains, nodes in the Hyperledger Fabric network generally need to be authorized and authenticated before joining, thus avoiding the resource overhead of POW (Proof of Work), greatly improving transaction processing efficiency, meeting the processing performance requirements of enterprise-level applications, and the system can run without the support of tokens.

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

[0033] The nodes of an organization in a blockchain network are called peers. Among them, the ledger can be stored on the peer node. Specifically, the peer node can include the endorsing peer, the committing peer, the leader peer, and the anchor peer. An organization can choose which node to install the chain code to implement the business process shared by the alliance members without installing the chain code on each node. Generally, the chain code can be installed on the endorsing node. After the chain code is installed on the endorsing node, after instantiation, other nodes between organizations with collaborative relationships (also called channels) can know the chain code and can be called by the application. The most important additional information provided during instantiation is the endorsement policy, which describes which organizations must approve the transaction before it will be accepted into their ledger. In fact, one or more smart contracts can be defined in the chain code. Each smart contract has a unique identifier in the chain code. The application can access the specified smart contract in the chain code container through the identifier of the smart contract. The peer node can also be a master node. Generally, there is only one master node in an organization. The master node can communicate with the sorting service to obtain the latest blocks from the sorting service and synchronize between 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, each organization has an anchor node. All peer nodes can be accounting nodes, which are used to verify transactions in the sorting service node blocks and maintain copies of the world state and ledgers. Accounting nodes can obtain blocks containing transactions from orderer nodes and add them to the blockchain after verifying these blocks. It should be noted that a "node" is a logical entity, and multiple nodes of different types can run on the same physical entity.

[0034] Applications (Apps) can connect to blockchain nodes through built-in SDKs (Software Development Kits) and APIs (Application Programming Interfaces). Apps can then generate transaction proposals to invoke chaincodes and submit them to the blockchain network. As mentioned earlier, once a chaincode is installed and instantiated on a peer node, the smart contracts in the chaincode become available to the associated channels, meaning that applications can invoke the chaincode. Applications invoke chaincodes by sending transaction proposals to the nodes of the organizations specified by the endorsement policy. The transaction proposals are used as inputs to the smart contracts, and the smart contracts on the endorsement nodes simulate execution to generate an endorsed transaction response. The blockchain network can eventually sort these transactions and generate blocks before submitting them to the distributed ledger. Specifically, the sorting service can sort the transactions and generate blocks. When this process is completed, the App can receive the corresponding events.

[0035] In a simple mode often used for testing, the sorting service is a separate node in the network, that is, a sorting service is composed of a sorting node. In many cases, the sorting service can include multiple nodes, and can be configured to have different sorting nodes in different organizations.

[0036] Specific, combined Figure 1 In the Hyperledger Fabric architecture shown in the figure, a typical transaction process is as follows:

[0037] a1: The application sends a transaction proposal to the endorsing node.

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

[0039] Applications can send transactions to one or more endorsement nodes according to the endorsement policy. Endorsement policies generally include nodes organized by relationships such as and, or, and majority of, which can be specified in the chaincode. 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 indicate that any one of endorsement node 1, endorsement node 2, and endorsement node 3 endorses the transaction. majority of{endorsement node 1, endorsement node 2, endorsement node 3} can indicate that the transaction needs to be endorsed by at least half of the nodes among endorsement node 1, endorsement node 2, and endorsement node 3, which means at least 2 of the 3 endorsement nodes.

[0040] like Figure 2 As shown in , taking and{endorsing node 1, endorsing node 2, endorsing node 3} as an endorsement policy as an example, the application sends the transaction to endorsing node 1, endorsing node 2, and endorsing node 3 respectively.

[0041] a2: After verifying the received transaction proposal, the endorsement node simulates the execution of the transaction and endorses it, and returns a proposal response to the application.

[0042] 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 can include verifying the transaction signature with the public key of account A, that the transaction has not been submitted before (replay attack protection), and that the transaction initiator is a qualified initiator on the channel. After verification, according to the above example, the endorsement node can further simulate the execution of the sent transaction. During the simulated execution process, the endorsement node can call the chain code specified in the transaction (specifically, the smart contract in the specified chain code), and input the parameters in the transaction, and then simulate the execution.

[0043] The execution result of a transaction generally includes the generated read set (ReadSet, Rset or RS) and / or write set (Wset or WS) (RS and WS can be collectively referred to as read-write sets, or written as RWset). These read-write sets can eventually be written into the blockchain ledger maintained locally by the Peer node. Read sets and write sets are generally expressed in the form of Key-Value. In addition, the read-write set generally also includes version information, indicating the version targeted when the operation in the read-write set is generated.

[0044] After the transaction is simulated and a read-write set is generated, the endorsing node can endorse the generated read-write set. Specifically, the endorsing node can sign the read-write set with its own private key according to the endorsement policy.

[0045] Continuing with the above example, with and{endorsing node 1, endorsing node 2, endorsing node 3} as the endorsement policy, the endorsement node 1, endorsement node 2, and endorsement node 3 simulate execution and endorsement of the transaction, and send the endorsement results to the application. Under this endorsement policy, the endorsement results of different endorsement nodes for the same transaction are generally only different in signatures, otherwise they do not comply with the endorsement policy.

[0046] a3: The application collects proposal responses returned by the endorsing nodes.

[0047] The application can collect proposal responses returned by endorsing nodes. Figure 2 As shown in , taking and{endorsing node 1, endorsing node 2, endorsing node 3} as an endorsement policy as an example, 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 responses. 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 according to the specified endorsement policy.

[0048] a4: The application sends the endorsed transaction to the sorting node.

[0049] When the application collects consistent proposal responses returned by enough endorsement nodes, for example, after collecting proposal responses returned by endorsement nodes 1, 2, and 3, the application can call the SDK to send the endorsed transaction to the sorting node. The endorsed transaction can include a packaged result including transaction proposals, read / write sets, and endorsement signatures.

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

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

[0052] a6: The sorting service broadcasts the generated block to the master node, which is then synchronized to other peer nodes in the organization.

[0053] In the 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 sorting node to obtain the latest block from the sorting node and synchronize it in the peer nodes within the organization.

[0054] a7: After verifying the block, the accounting node appends the block to the blockchain of the local ledger, and updates the world state in the local ledger based on the block.

[0055] All peer nodes can be accounting nodes. Accounting nodes can maintain ledgers locally. The ledgers can include blockchain data and world state data, such as Figure 3 shown.

[0056] The blockchain consists of a series of linked blocks. Each block consists of three parts: block header, block data, and block metadata.

[0057] The block header contains the block number ( Figure 3 The block number of each block is unique and generally monotonically increasing. The block number can be generated by the sorting 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 ( Figure 3 CH, CurrentBlockHash), and the hash value of the previous block header ( Figure 3 In this way, all blocks in the blockchain are arranged in order and cryptographically linked together. This hashing and linking makes the blockchain ledger data very secure. Even if a node that saves the blockchain ledger is tampered with, other nodes can quickly confirm the tampered blockchain ledger through the block's hash value. For example Figure 3 Block 2 in the block, its block header 2 includes 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.

[0058] The 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 above, the block data can be written into the block data when the sorting service packages and generates blocks. Figure 4 As shown, the block data may include a series of transactions. These transactions may be sorted by transaction time. Each transaction may include a transaction header, transaction signature, transaction proposal, transaction response, and transaction endorsement.

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

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

[0061] ●Transaction proposals include the input parameters provided by the coded 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.

[0062] ●The transaction response records the previous and next values ​​of the world state in the form of a read-write set.

[0063] ●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.

[0064] ●A transaction endorsement is a set of signed transaction responses that come from organizations specified in the endorsement policy, and the number of these organizations must meet the requirements of the endorsement policy.

[0065] The block metadata includes the time when the block was written, as well as the certificate, public key and signature of the block writer. Subsequently, the block submitter will also add a valid or invalid mark for 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.

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

[0067] The world state is a database that stores the current values ​​of a set of ledger states. The world state allows access to the current value of a ledger state without having to traverse the entire transaction log to calculate the current value.

[0068] An example of a world state is recording information of two cars CAR1 and CAR2, for example, using two states to record each.

[0069] The k1-v1 of the first state is:

[0070] {key=CAR1, value=Audi} version=0

[0071] The second state has a more complex value:

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

[0073] Overall, the second state is a key-value pair (abbreviated as k-v pair). Among them, what is contained in value2 is also a k-v pair. And there are three different k-v pairs in the above example. Let the three k-v pairs in v2 be k21=model:v21=BMW, k22=color:v22=red, and k23=owner:v23=Jane respectively.

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

[0075] The application can call (invoke) the smart contract to finally perform operations such as put and delete on the world state. In an example, Application 1 initiated a transaction T8 to Endorsing Node 1 within Organization 1, Endorsing Node 2 within Organization 2, and Endorsing Node 3 within Organization 3 according to the endorsement policy. The endorsement policy is, for example, "and{Endorsing Node 1, Endorsing Node 2, Endorsing Node 3}". Similarly, Application 2 also initiated a transaction T9 to Endorsing Node 1 within Organization 1, Endorsing Node 2 within Organization 2, and Endorsing Node 3 within Organization 3 according to the endorsement policy. The endorsement policy is also, for example, "and{Endorsing Node 1, Endorsing Node 2, Endorsing Node 3}".

[0076] Transaction T8 is, for example:

[0077] <clientID=Application 1,

[0078] chaincodeID=ID1,

[0079] txPayLoad=[Method1(k1)],

[0080] timestamp,

[0081] clientSig>

[0082] This Transaction T8 calls the chaincode numbered ID1. For example, it calls Method1 therein and inputs the parameter k1. This Method1 is, for example, to read the value corresponding to the input parameter, that is, to read the brand of the vehicle.

[0083] Transaction T9 is, for example:

[0084] <clientID=Application 1,

[0085] chaincodeID=ID1,

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

[0087] timestamp,

[0088] clientSig>

[0089] Transaction T9 invokes the chaincode with ID1, for example, invokes method Method2 therein and inputs the parameter k23. This Method2 is, for example, to modify the name of the vehicle owner, usually in the case of vehicle transfer.

[0090] After Transactions T8 and T9 are verified, simulated, and endorsed by each endorsing node, each endorsing node returns the proposal responses to Applications 1 and 2 respectively. The endorsing nodes simulate the execution of the transaction content. For example, the read-write sets generated for T8 and T9 are as follows:

[0091] T8: Read <k1>version=0

[0092] T9: Write<k23,Paul> version=0

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

[0094] The endorsing node can endorse the generated read-write set and return the proposal response to the application 1 and application 2 respectively. For example, for a T8 transaction, endorsing node 1, endorsing node 2, and endorsing node 3 simulate execution and endorse the transaction respectively, and send the endorsement results to the application 1 respectively. For a T9 transaction, similarly, endorsing node 1, endorsing node 2, and endorsing node 3 simulate execution and endorse the transaction respectively, and send the endorsement results to the application 2 respectively.

[0095] After Application 1 and Application 2 have each collected the proposal responses returned by the endorsement nodes, they can send the endorsed transactions to the sorting node. The endorsed transactions can include the packaged results including transaction proposals, read / write sets and endorsement signatures. The sorting service sorts transactions T8 and T9. For example, according to the timestamps of the transactions, T8 comes first and T9 comes last, and the sorted results of T8 and T9 generate block 3. Subsequently, the sorting service can broadcast the generated block 3 to each master node in Organization 1, Organization 2 and Organization 3, and the master node will synchronize it to other Peer nodes in the organization to which it belongs. After each accounting node verifies the block, it 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:

[0096] k1-v1:

[0097] {key=CAR1, value=Audi} version=1

[0098] k2-v2:

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

[0100] The above endorsement nodes simulate the execution of transaction content, including the simulated execution of transactions that call chaincodes, and can use container technology, namely the chaincode container mentioned above. The chaincode container refers to the container environment (Docker) in which the chaincode runs independently of the endorsement node process, and its role is to provide an isolated sandbox environment for the chaincode to run. The container is a lightweight application code package that also contains the dependencies required for the program to run, such as a specific version of the programming language runtime and the libraries required to run the software service. In this way, the execution of smart contracts can be isolated, and the endorsement node process will not crash due to errors or malicious code. When instantiating the chaincode, the endorsement node fills the container image with the chaincode and calls the Docker management API to deploy the image. If the container is not running, a new container can be started. Once running, all proposals received by the endorsement node will be transferred to the container for execution.

[0101] As mentioned above, the execution of chaincode requires the installation of chaincode, that is, after the chaincode is installed on the endorsement node, it can be called by the application after instantiation. The deployment of chaincode on the blockchain includes the deployment of traditional chaincode and the deployment of external chaincode. External chaincode can be deployed and executed on nodes outside the blockchain, for example, to facilitate users to independently manage each external node and its code operating environment. Traditional chaincode is different from external chaincode. Traditional chaincode is deployed and executed by nodes inside the blockchain.

[0102] The container technology mentioned above is a type of virtualization technology. Virtualization technology actually includes hardware virtualization and container technology. Virtual machines use hardware virtualization technology. Virtual machines need to virtualize hardware and install a complete operating system before they can install / run applications. If you use a virtual machine to virtualize a complete operating system and set up a complete dependent environment every time you release an application, it will be a tedious task. Container technology is relatively lighter. The operating system can be removed from the container, and the application and the system environment on which the application depends are included. Through container technology, applications and dependent environments can be packaged, and the packaged content can still run normally when ported to other hosts with the same operating system. It can be seen that the advantages of container virtualization technology are lighter, easier to migrate, easier to deploy, and less resource consumption. In addition, containers can be standardized. One of the mainstream container technologies is docker, and there are also other technologies such as Rocket, rkt, and kata.

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

[0104] The entire operation logic of Docker is as follows Figure 5 As shown. The Docker Client sends the Docker command to be executed to the Docker Daemon (daemon, also known as DockerEngine) on the host (DockerHost) where Docker is running. The Docker Daemon decomposes the request for execution. For example:

[0105] Execute the Docker build command to build an image based on the Dockerfile and store it locally;

[0106] Execute the Docker pull command to pull the image from the remote container image repository to the local machine.

[0107] Executing the Docker run command will pull the container image and run it as a container instance.

[0108] Image building includes writing the dependencies and target files that need to be installed according to the Dockerfile, and superimposing them into an existing base image to generate a new image. When the container is running, a Container layer will be generated on the upper layer of the container image. This layer loads a copy of the complete container image into the memory for execution. The copy loaded into the memory can be modified for the container, but it is limited to running in the memory; any changes to the Container layer will not take effect on the underlying image, and the changes made will disappear when the container disappears. 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, and each instruction in it can describe a step in building an image. For example:

[0109] The commands we commonly use in Dockerfile are as follows

[0110] FROM: what image to build on

[0111] WORKDIR: The working directory of the container

[0112] RUN: Executes commands during container building process

[0113] CMD & ENTRYPOINT: Execute the command after the container is started

[0114] ADD & COPY: Add the specified file to the container image

[0115] ENV: Set environment variables

[0116] EXPOSE: Set the port exposed by the container

[0117] Specifically, Figure 6 As shown in the figure, the Docker client sends the request to be created to the Docker Engine. As mentioned above, the Docker Engine is a containerized daemon process. The Docker Engine can send the request to containerd, and containerd calls runC. Containerd is used to manage the life cycle of the container, and manages the life cycle of the container by calling the runC API. RunC directly interacts with the files that the container depends on (such as cgroup / linux kernel, etc.), is responsible for configuring the cgroup / namespace and other environments required to start the container, and creates related processes to start the container. Figure 6 There is an additional containerd-shim layer (also called a shim carrier, similar to an adaptation layer) in Docker. The role of container-shim is to decouple containerd from the real container (the process inside), allowing runC to exit after creating / running the container. When containerd crashes, containerd-shim can be maintained, so it can be guaranteed that the file descriptors opened by the container will not be closed (so that Dockerd can be upgraded without affecting the service). Relying on containerd-shim to collect / report the exit status of the container, containerd does not need to monitor the created child processes. For example, a fabric peer node can eventually run on Figure 6 In the container process on the far left, this container can also be called a Peer container.

[0118] As the number of container instances increases, the complexity of container management increases dramatically. At this time, kubernetes (abbreviated as k8s) comes in handy. k8s is an open source container cluster management system that can realize the functions of automatic deployment, automatic expansion and contraction, maintenance, etc. of container clusters. It can help to deploy, publish, and orchestrate containers, and can greatly simplify the management and operation of containers.

[0119] In Kubernetes, you can create multiple containers, each of which runs an application instance. Then, through the built-in load balancing strategy, you can manage, discover, and access this group of application instances. These details do not require the operation and maintenance personnel to perform complex manual configuration and processing. Kubernetes cluster architecture and related core components such as Figure 7 As shown: A Kubernetes cluster generally contains 1 Master node and multiple Node nodes. A node can be a physical machine or a virtual machine. The Master is the cluster control node of k8s. Each k8s cluster has a Master responsible for the management and control of the entire cluster. Other machines in the k8s cluster are called Node nodes. Node nodes are workload nodes in the k8s cluster. Nodes can be assigned some workloads by the Master. When a Node goes down, its workload will be automatically transferred to other Nodes by the Master.

[0120] 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, and is responsible for tasks such as creating, starting and stopping the container corresponding to the Pod, and realizing the basic functions of cluster management. Pod is the smallest deployment unit in k8s, a collection of containers, and the basic unit for k8s to perform service orchestration and scaling.

[0121] Node nodes can be dynamically added to the k8s cluster during operation, provided that some key components including the above-mentioned kubelet have been correctly installed, configured, and started on the node. By default, kubelet will register itself with the Master. Once the Node is included in the cluster management scope, kubelet will regularly report its own situation to the Master node, such as the operating system, Docker version, CPU and memory of the machine, and which Pods were running before, so that the Master can know the resource usage of each Node and implement an efficient and balanced resource scheduling strategy. If a Node fails to report information for more than a specified time, it will be judged as "lost" by the Master, and the Node's status will be marked as unavailable (Not Ready), and then the Master will trigger the automatic process of "large workload transfer".

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

[0123] If Docker is used as the K8S container runtime, kubelet must first call Docker Engine through docker-shim, and then call containerd through Docker Engine. Docker-shim is a component of Kubernetes, and its main purpose is to operate Docker through CRI (Container Runtime Interface). Docker appeared in 2013. In 2014, Kubernetes was released and used Docker as the container runtime by default. Docker-shim first appeared in 2016. When Docker was first created, container orchestration or Kubernetes was not considered, 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 at the beginning of its creation, and the subsequent code contained a lot of Docker-related operation logic. Later, in order to be able to decouple and be compatible with more container runtimes, Kubernetes separated the operation-related logic of Docker into docker-shim. Overall, the architecture of using Docker as the K8S container runtime can be as follows Figure 7 As shown in the figure, the pod on the left of each node shows the command relationship between kubelet and multiple containers in the pod, while the containers in other pods are omitted. The communication and command relationship can be as follows Figure 8 As shown in the figure, if Docker is used as the container runtime of K8S, kubelet needs to call Docker through docker-shim first, and then call containerd through Docker.

[0124] Most of the existing Fabric peer nodes are deployed through Kubernetes. Figure 6 The container process on the lower left shows that the container process can actually run a Peer node. This container process can also be called a Peer container. Using container technology to run chaincode, we ultimately hope to Figure 6 The chaincode runs in the intermediate container process shown.

[0125] To run chaincode using container technology, it is necessary to generate the chaincode program and the operating environment required for the chaincode program to execute in the container. The chaincode program can be a binary file, that is, a target file obtained after compilation. The operating environment refers to the dependencies required for the program to run. In traditional chaincode, a containerized chaincode program needs to be run in an operating environment that is compatible with it. In order to reduce the burden on users, users only need to focus on developing the chaincode source code at the high-level language level, without having to pay attention to the differences in the operating environment on different blockchain nodes. After receiving the source code of the chaincode developed by the user, the blockchain can combine kubernetes and docker to compile the chaincode source code and execute it, thereby achieving advantages such as lightweight, easy migration, convenient deployment, and low resource consumption, and realizing the functions of automatic deployment, automatic expansion and contraction, and maintenance of container clusters.

[0126] The process of deploying traditional chaincode in Hyperledger Fabric is as follows: Fig. 9 It should be noted that, here, it is assumed that a Peer container has been deployed in a Container using kubernetes and docker technology, and this Peer container is, for example, container1, in which, for example, an endorsement node is running.

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

[0128] The client here refers to the blockchain client that creates the chaincode source code and sends the chaincode source code. After the developer creates the chaincode source code, he can package the chaincode source code and set the endorsement policy. Then he can send the packaged chaincode source code and the set endorsement policy to the endorsement node to deploy the chaincode through the client. The endorsement node to deploy the chaincode generally includes the endorsement node included in the endorsement policy. The endorsement node is shown as a Peer container in the figure.

[0129] 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.

[0130] According to the type of chain code source code sent by the client, the endorsement node can use docker (the docker here mainly includes docker-shim and dockerengine in the figure) to create a corresponding temporary container. The corresponding temporary container contains the compilation environment of the corresponding source code language. The local or remote image repository of the endorsement node contains the compilation environment image for compiling multiple chain code source codes, which can be pulled and used by docker. In this way, when the endorsement node receives a type of source code, it can use docker to create a temporary container containing the corresponding compilation environment. For example, for source code edited in go language, a temporary container suitable for go language compilation environment is created; for source code edited in java language, a temporary container suitable for java language compilation environment is created; for source code edited in node.js language, a temporary container suitable for node.js language compilation environment is created.

[0131] In the created temporary container, you can compile the source code to generate the target file. Similarly, the source code edited in the go language is compiled into a binary file in the temporary container, the source code in the java language is compiled into a jar file in the temporary container, and the source code in the node.js language is compiled into the target code.

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

[0133] In the temporary container, the chain code source code can be compiled based on the compilation environment mirror to obtain the chain code program, that is, the target file above.

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

[0135] b3: The temporary container puts the compiled target file into a directory and notifies the Peer container.

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

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

[0138] b5: After receiving the transaction to call the chain code, the Peer container starts the chain code container through Docker and installs and instantiates the chain code based on the chain code image.

[0139] After that, after the Peer container receives the transaction to call the chaincode, if the traditional chaincode container is not started, the Peer container can initiate a Dockerrun instruction to the dockerEngine through docker-shim, and the instruction is sent to containerd, which then calls runC. In this way, runC pulls up a traditional chaincode container built based on the chaincode image, such as container3.

[0140] Furthermore, the Peer container can input the parameters in the transaction into the chain code container to perform chain code simulation to execute the transaction.

[0141] In addition, you can also add b3 and Fig.10 As shown, use the following method:

[0142] b5': The Peer container starts the chain code container through Docker and installs and instantiates the chain code based on the chain code image.

[0143] 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 the dockerEngine, the Peer container can also send the Docker run command to the dockerEngine. The instruction is sent to containerd through docker-shim and dockerEngine, and then containerd calls runC. In this way, runC pulls up a traditional chain code container built based on the chain code image, and this traditional chain code container is, for example, container3. In other words, 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 that calls the chain code to be triggered by the Peer node to pull up the traditional chain code container as in b5. In this way, the traditional chain code container is pulled up in advance, and the subsequent Peer node can directly call the chain code for simulated execution after receiving the transaction request to call the chain code, instead of temporarily pulling up the traditional chain code container and then calling the chain code for simulated execution. Obviously, this method can improve the execution speed of the contract.

[0144] It can be seen that the main role of dockerengine in the above process is to build images, and most of the communication with dockerengine needs to be carried out through Dockershim. The process of deploying traditional chaincode in Fabric2.0 (and subsequent versions) that uses kubernetes and docker technology is very dependent on docker, specifically docker-shim and dockerEngine. In addition, as mentioned earlier, when using Docker as the K8S container runtime, kubelet needs to first call DockerEngine through docker-shim, and then call containerd through Docker Engine.

[0145] As mentioned above, docker-shim is a component of Kubernetes. Its main purpose is to operate Docker through CRI, specifically the DockerEngine mentioned above. Docker did not consider container orchestration or Kubernetes when it was first created, but Kubernetes adopted Docker as its default container runtime at the beginning of its creation, and the subsequent code contains a lot of Docker-related operation logic. In order to decouple and be compatible with more container runtimes, Kubernetes later separated the logic related to operating Docker into docker-shim.

[0146] Containerd is a product of the standardization of container technology. In order to be compatible with the OCI (Open Container Initiative) standard, the container runtime and its management functions are separated from the Docker Daemon. Containerd can provide an interface for Docker Daemon upward, so that Docker Daemon can shield the underlying structural changes and ensure the backward compatibility of the original interface. Downward, it can be combined with runC through containerd-shim, so that the engine can be upgraded independently, avoiding the problem that the previous Docker Daemon upgrade would cause all containers to become unavailable. Runc is a command line tool that can create and run containers according to the OCI standard.

[0147] In theory, even if dockerEngine is not running, containers can be managed directly through containerd, so docker-shim is not needed.

[0148] K8S released CRI (Container Runtime Interface), which unified 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 remove the shim as early as version 1.23. Docker-shim was removed, and this also removed support for Docker as a container runtime. As mentioned earlier, containerd is a project separated from Docker, which can be used as a bottom-level container runtime itself. Now it has become a better choice for Kubernete container runtime. Not only Docker, but many cloud platforms also support containerd as the bottom-level container runtime. In addition to containerd, there are also CRI-O and others that can be used as bottom-level container runtimes.

[0149] If containerd is used as the K8S container runtime, containerd can have a built-in CRI plug-in, so that kubelet can directly call containerd, such as Fig.11 As shown. Obviously, kubelet can shorten the communication link by calling containerd directly through CRI, thereby improving performance, and the resource usage will also be reduced after removing Docker (Docker is not a pure container runtime, it has a lot of other functions, so its existence is more resource-consuming).

[0150] In addition to traditional chaincodes, external chaincodes can also be deployed in Hyperledger Fabric. A process of deploying external chaincodes is as follows: Fig.12 Indicated in Fig. 9 In the example above, a Peer container is deployed in a container using kubernetes and docker technology, and the Peer container runs in a cloud service environment. As mentioned above, traditional chaincodes are generally deployed and executed on nodes inside the blockchain. External chaincodes are generally deployed and run on nodes outside the blockchain to facilitate users to independently manage each external node and its operating environment. Fig.12 As shown, in one example, the user environment includes a Client. The process may include the following:

[0151] d1: The client builds and starts the external chaincode container in the user environment.

[0152] After the client starts the external chaincode container, it can also obtain the address (such as IP address) and port where the external chaincode container is running. Since the external chaincode container needs to execute the chaincode and is located outside the blockchain network, the nodes on the blockchain need to forward the transaction that calls the chaincode to the external chaincode container. The nodes on the blockchain need to obtain the address and port of the external chaincode container (such as certificate configuration for TLS (Transport Layer Security) communication) to communicate with the external chaincode container.

[0153] The communication method can be RPC (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 the underlying implementation details. Therefore, it is a lightweight and imperceptible cross-process communication method. The specific implementation can be a set of agreements between the caller and the service provider, and data interaction can be based on TCP long connections.

[0154] gRPC is an implementation of RPC, developed by Google. It is a high-performance, open source and general RPC framework designed for mobile and HTTP / 2. It supports many common programming languages ​​and provides powerful streaming calling capabilities. It 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. The gRPC client initiates a call to the gRPC server and needs to obtain information such as the address and port of the gRPC server. gRPC is a preferred implementation in this application. In fact, communication clients and communication servers with similar functions can be implemented in this application. The following still takes gRPC as an example.

[0155] The client starts an external chaincode container and can set the external chaincode container as the gRPC server.

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

[0157] 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 specifies the IP address, port and other information of the external chain code container. In addition, the client can also send a metadata.json file, which specifies that the chain code to be installed is an external chain code.

[0158] d3: The Peer container initiates a connection with the external chain code container to implement the call of the chain code.

[0159] After the Peer container receives the instruction to install the external chain code, the Peer container can know that the external chain code is currently installed through metadata.json. Then, the Peer container can be set as a gRPC client. After the Peer container obtains the address and port 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.

[0160] Subsequently, after the Peer container receives the transaction to call the external chain code, it can send the transaction to the external chain code container through the maintained long connection, thereby implementing the call to the chain code. After the transaction to call the chain code is executed in the external chain code container, as described above, the execution result, i.e., the read / write set, can be returned to the gRPC client, i.e., to the Peer container, through the maintained long connection.

[0161] In fact, Fig. 9 , 10 In the example, the traditional chaincode container after startup can be set as the gRPC client, and the Peer container can be set as the gRPC server. The gRPC server does not actively initiate a connection to the gRPC client, but requires the gRPC client 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 instruction to create the traditional chaincode container, and can be placed in the connection.json file and sent to the traditional chaincode container. Furthermore, after the traditional chaincode container is built, it can initiate a connection to the Peer container based on the address and port of the gRPC server in the connection.json file, and can maintain a long connection with the Peer container after success. Subsequently, the Peer container can send the transaction that calls the chaincode to the traditional chaincode 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.

[0162] Different from the traditional chaincode container construction method, during the construction of the external chaincode container, the client needs to inform the Peer container that the external chaincode is currently installed through the connection.json and metadata.json installation chaincode instructions containing the address and port of the external chaincode container. In addition, since the user can build and start the external chaincode container in the user environment of the client or the environment specified by the user in advance, the Peer container does not need to participate in the construction and startup process, so the detailed process of building and starting the external chaincode container is omitted here.

[0163] 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 provided as a service to different Peer containers, such as serving different Peer containers in the same organization. In this case, the Peer container acts as a gRPC client.

[0164] The process of deploying chaincode in a consortium represented by Hyperledger Fabric 2.0 can be as follows: Fig.13 , and includes the following:

[0165] S110: The third-party construction module receives the command for installing the first chain code and the chain code source code sent by the client.

[0166] Clients can Fig. 9 The process is similar to b1 in , in which the command to install the first chain code is sent to the endorsement node to be deployed, and the created chain code source code and endorsement policy are packaged and sent to the node. After the developer creates the chain code source code, he can package the chain code source code and set the endorsement policy, and then send the packaged chain code source code and the set endorsement policy to the endorsement node to deploy the chain code through the client. The endorsement nodes to deploy the chain code generally include the endorsement nodes included in the endorsement policy.

[0167] The first chaincode command here is very similar to the traditional chaincode command mentioned above. Neither of them contains the connection.json and metadata.json files, nor does it contain the IP address and port of the gRPC server.

[0168] like Figure 1 As described in the corresponding text, fabric can include multiple organizations, each organization can have multiple peers, and here, a governor node can be set in each organization to manage the peer nodes in the current organization. As mentioned earlier, it can be set here that the Peer node has been deployed in a container using kubernetes and containerd technology, which can be called a Peer container, and the governor node has been deployed in another container, which can be called a governor container. In addition to managing the peer nodes in the current organization, the governor container can also have a built-in cckeeper module. Of course, it is also possible to set cckeeper in other forms other than the Peer container. In addition, the cckeeper module can also be built into the Peer container.

[0169] Fig.13 The example in Figure 1 illustrates the case where the cckeeper module is built into the governor container. Other cases are slightly simpler than this.

[0170] S120: The third-party construction module builds a chain code image based on the chain code source code.

[0171] After the Peer container receives the command and chain code source code for installing the first chain code from the client, it can send the command and chain code source code for installing the first chain code to the built-in or external cckeeper module, which is the third-party building module. In addition, the client can also send the command and chain code source code for installing the first chain code directly to the Governor container, so that cckeeper can obtain the command and chain code source code for installing the first chain 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), which is set to dockerfile_3 here. Dockerfile_3 can include a description of creating an image building container.

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

[0173] The cckeeper module can send the task of creating an image build container to the master of k8s. Figure 7 , the Master can initiate a task to the kubelet in a node. After receiving the task, the kubelet sends a command to create a container to containerd through the CRI plug-in, and then containerd calls runC to create an image building container, such as container4.

[0174] 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 according to the content in dockerfile_3, and the content in this image is suitable for compiling the chain code source code. For example, imgbuilder can include 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 environment image to obtain the chain code program, that is, the target file above. imgbuilder can store the generated chain code program in a path and notify cckeeper, which can be notified through the Peer container or directly.

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

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

[0177] S130: The third-party construction module creates and starts a chain code container based on the chain code image, sets the Peer container and the chain code container as gRPC clients, establishes a proxy server as a gRPC server, and notifies the Peer container of the information of the gRPC server.

[0178] 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.

[0179] The former is, for example, that the Peer container starts the chaincode container through cckeeper and installs and instantiates the chaincode 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. In other words, once the chaincode image is built, the traditional chaincode container built by the chaincode image can be pulled up. In this way, the traditional chaincode container is pulled up in advance, and the subsequent Peer node can directly call the chaincode for simulated execution after receiving a transaction request to call the chaincode, instead of temporarily pulling up the traditional chaincode container and then calling the chaincode for simulated execution. Obviously, this method can improve the execution speed of the contract.

[0180] The latter is, for example, after the Peer container receives the transaction to call the chain code, it starts the chain code container through cckeeper and installs and instantiates the chain code 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 to call the chain code, if the traditional chain code container is not started, the Peer container can call cckeeper, and cckeeper pulls up a traditional chain code container built based on the chain code image. This traditional chain code container is, for example, container.

[0181] Furthermore, the Peer container can input the parameters in the transaction into the chain code container to perform chain code simulation to execute the transaction.

[0182] In addition, the third-party building module can set the chaincode container as a gRPC client. The chaincode container is created by the Governor using a container runtime that complies with CRI and is created according to the client's installation of the first chaincode command. In this case, the chaincode container acts as a gRPC client. To provide services to different Peer containers like the aforementioned external chaincode container, the Peer container also needs to act as a gRPC client.

[0183] In this way, both the Peer container and the chaincode container are gRPC clients. The two cannot establish a communication link and cannot communicate. The transaction initiated by the client to call the chaincode cannot be implemented.

[0184] Therefore, the Governor container can use a CRI-compliant container runtime to create a Proxy container, and the Proxy container can open up a communication link between the Peer container and the chaincode container, both of which are gRPC clients. Specifically, the cckeeper in the Governor container can send a command to create a Proxy container to the Master, and the Master notifies the kubelet in the Node of the command, and the kubelet can further use containerd containing the CRI plug-in to create a container in a Pod. This container. The ccproxy module can 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-chaincode server. The pseudo-chaincode server is responsible for interacting with the chaincode container established by cckeeper in the traditional chaincode manner, while the pseudo-Peer server is responsible for interacting with the Peer container in the external chaincode manner.

[0185] cckeeper can send 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 as a gRPC client. After the Peer container obtains the address and port number 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.

[0186] Subsequently, after the Peer container receives the transaction to call the chaincode, it can send the transaction to the chaincode container through the maintained long connection, thereby implementing the call to the chaincode. After the transaction to call the chaincode is executed in the chaincode container, as described above, the execution result, i.e., the read / write set, can be returned to the gRPC client, i.e., to the Peer container, through the maintained long connection.

[0187] As mentioned above, the above solution allows developers to develop chaincode source code in the traditional chaincode way without making changes, which does not add additional development costs to chaincode developers. At the same time, by building chaincode images with third-party building modules, the dependence on Docker is eliminated. On the other hand, although both the chaincode container and the Peer container are set as gRPC clients, the connection between the chaincode container and the Peer container can be pulled through the proxy server, so that the chaincode container can be decoupled from the Peer container, so that it can be service-oriented.

[0188] The following is a specific example in Hyperledger Fabric to illustrate the process of deploying chain code in a consortium chain. Fig.14 As shown in, including:

[0189] c1: The client sends the first installation chaincode command to the Governor container, which includes the created chaincode source code and endorsement policy.

[0190] like Figure 1 As described in the corresponding text, fabric can include multiple organizations, each organization can have multiple peers, and here, a governor node can be set in each organization to manage the peer nodes in the current organization. As mentioned earlier, it can be set here 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 the peer nodes in the current organization, the governor can also have a built-in cckeeper module.

[0191] After the user creates the chaincode source code, he can use the client to send a message to the governor container of the organization that owns the chaincode source code and endorsement policy.

[0192] The first command to install the chaincode is similar to Fig. 9 The Governor container receives the chain code source code sent by the client and can generate a third configuration file (dockerfile). Specifically, the built-in cckeeper can be used to generate this dockerfile, which is set as dockerfile_3 here. Dockerfile_3 can include a description of creating an image to build a container.

[0193] c2: The Governor container uses a CRI-compliant container runtime to create an image build container and compile the chaincode source code into a target file.

[0194] Governor can send the task of creating an image build container to the Master of k8s, which can be sent by the cckeeper. Figure 7 , the Master can initiate a task to the kubelet in a node. After receiving the task, the kubelet sends a command to create a container to containerd through the CRI plug-in, and then containerd calls runC to create an image building container, such as container3.

[0195] On the other hand, after Governor generates dockerfile_3, it can send dockerfile_3 to imgbuilder, and then imgbuilder can pull a compilation environment image according to the content in dockerfile_3, and the content in this image is suitable for compiling the chaincode 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 chaincode source code based on the compilation environment image to obtain the chaincode program, which is the target file above. imgbuilder can store the generated chaincode program in a path and notify cckeeper.

[0196] In the above process, kubelet can communicate with containerd through CRI, and then send the relevant commands for creating containers to containerd. In this way, after canceling docker-shim and docker-engine, the links for building images are streamlined while keeping them unobstructed, thus improving performance and reducing resource usage as mentioned above.

[0197] c3: The image building container puts the compiled target file into a directory and notifies the Governor container.

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

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

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

[0201] c5: The Governor container uses a CRI-compliant container runtime to create chaincode containers and proxy containers.

[0202] The cckeeper in the Governor container can use the CRI-compliant container runtime to create the chaincode container and the proxy container. Specifically, cckeeper can send a command to create the chaincode container and the proxy container to the Master, and the Master notifies the kubelet in the Node of the command, and the kubelet can further use the containerd containing the CRI plug-in to create the container.

[0203] 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 repository and run in a container of the Pod, thereby generating a chaincode container.

[0204] Fig. 9 and Fig.10 Docker is used as the K8S container runtime, and the chaincode container is created by DockerEngine through containerd, and the created chaincode container and the Peer container are located in the same host machine, so the Peer container can obtain the address of the chaincode container, so that the Peer container can communicate with the chaincode container. Therefore, after the Peer container receives a transaction request to call the chaincode, it can input the parameters and other information carried in the transaction into the chaincode container, and the chaincode in the chaincode container can be run, and the running results can be fed back to the Peer container, such as the read / write set mentioned above.

[0205] Different from the above Fig. 9 and Fig.10 The implementation in Fig.14 In the example, the chaincode container is created by the Governor using a CRI-compliant container runtime and is created according to the client's install chaincode command. In this case, the chaincode container acts as a gRPC client. To provide services to different Peer containers like the external chaincode container mentioned above, the Peer container also needs to act as a gRPC client.

[0206] In this way, both the Peer container and the chaincode container are gRPC clients. The two cannot establish a communication link and cannot communicate. The transaction initiated by the client to call the chaincode cannot be implemented.

[0207] Therefore, the Governor container can use a CRI-compliant container runtime to create a Proxy container, and the Proxy container can open up a communication link between the Peer container and the chaincode container, both of which are gRPC clients. Specifically, the cckeeper in the Governor container can send a command to create a Proxy container to the Master, and the Master notifies the kubelet in the Node of the command, and the kubelet can further use containerd containing the CRI plug-in to create a container in a Pod. This container. The ccproxy module can 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-chaincode server. The pseudo-chaincode server is responsible for interacting with the chaincode container established by cckeeper in the traditional chaincode manner, while the pseudo-Peer server is responsible for interacting with the Peer container in the external chaincode manner.

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

[0209] Specifically, the cckeeper in the Governor can send a command to install the second chain code to the Peer container. Fig.13 The installation external chain code command in the sent second chain code installation command may include the address and port of the chain code service. Specifically, cckeeper may send a connection.json file, which contains the address and port of the chain code service.

[0210] After the Peer container receives the command to install the second chain code, it can be set as a gRPC client after obtaining the address and port information of the chain code Proxy container through connection.json. 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 can interact with the Proxy container in a manner similar to that of an external chain code and can maintain a long connection. On the other hand, as mentioned above, the chain code container can interact with the pseudo-chain code server in a manner similar to that of a traditional chain code and can maintain a long connection.

[0211] In fact, it can include a c7 step, in which cckeeper can establish a chaincode service, as shown in the figure. After the Peer container receives the command to install the second chaincode, it obtains the address and port of the chaincode service container through connection.json, and then 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 chaincode service can interact with the pseudo-chaincode server in the Proxy container, so that the Peer container can interact with the Proxy container in a similar way to the external chaincode 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 similar way to the traditional chaincode and can maintain a long connection. This is a more specific deformation method.

[0212] In short, the connection between the chaincode container and the Peer container can be established through the Proxy container. Later, the Client initiates a transaction to call the chaincode to the Peer container, and the Peer container can initiate the transaction to the chaincode container and connect to the chaincode container. The Proxy container can communicate and interact with the chaincode container, and the chaincode container can simulate the transaction and return the read / write set. In this way, the Client calls the chaincode, and the interactive link can be as follows: Fig.14 As shown by the dotted line in .

[0213] Through the above process, developers can still write the chaincode source code in the traditional way without making any changes, which does not add additional development costs to chaincode developers. At the same time, by receiving the first chaincode installation command received by the Governor container, and creating chaincode containers, proxy containers and chaincode services, the created chaincode container can be service-oriented like an external chaincode container, which is more flexible and can serve different Peer containers. More importantly, the above solution uses Governor to build chaincode images and create chaincode containers, getting rid of the dependence on Docker; at the same time, it still has compatibility with traditional chaincode installation, which is conducive to unified management of Fabric resources in the K8s cluster.

[0214] In the 1990s, it was very clear whether the improvement of a technology was a hardware improvement (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or a software improvement (improvement of the method flow). However, with the development of technology, many improvements in the method flow today can be regarded as direct improvements in the hardware circuit structure. 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 the improvement of a method flow cannot be implemented with a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming themselves, without having to ask 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 by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, 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. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0215] The controller may be implemented in any suitable manner, for example, the controller may take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (e.g., software or firmware) executable by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, and the memory controller may also be implemented as part of the control logic of the memory. It is also known to those skilled in the art that, in addition to implementing the controller in a purely computer-readable program code manner, the controller may be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller may be considered as a hardware component, and the devices for implementing various functions included therein may also be considered as structures within the hardware component. Or even, the devices for implementing various functions may be considered as both software modules for implementing the method and structures within the hardware component.

[0216] 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, the present application does not exclude 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, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0217] Although one or more embodiments of the present 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-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, product or device including a series of elements includes not only those elements, but also other elements that are not explicitly listed, or also includes elements inherent to such process, method, product or device. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or device including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any specific order.

[0218] For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in the same or more software and / or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0219] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0220] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0221] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

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

[0223] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0224] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules 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), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0225] It should be understood by those skilled in the art that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0226] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. 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 this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0227] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference term "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, in the absence of mutual contradiction, a person skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0228] The above description is only an example of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the scope of the claims.

Claims

1. A method for deploying chain code in a consortium chain, comprising: 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 calls the container image building tool to build the chain code image based on the chain code source code and the adapted operating environment; The third-party construction module creates and starts a 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, 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.

2. According to the method of claim 1, the third-party construction 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 to compile 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, adds the chain code program to the adapted operating environment and generates a chain code image.

3. According to the method of claim 2, the third-party construction module calls the container image construction tool, and the chain code source code sent by the client is compiled to obtain the chain code program, including: The third-party construction module generates a third configuration file based on the chain code source code and sends it to the container image construction tool, and creates an image construction container; The container image building tool pulls the compilation environment image according to the third configuration file, and executes the image building task in the image building container to obtain the compiled chain code program.

4. According to the method of claim 2, the third-party construction module calls a container image construction tool, adds the chain code program to an adapted operating environment and generates a chain code image, including: The third-party building module generates a fourth configuration file based on the generated chain code program; The third-party construction module calls a container image construction tool and sends the fourth configuration file to the container image construction tool; The container image building tool pulls the operating environment image according to the fourth configuration file, and generates a chain code image including the chain code program and the operating environment.

5. The method of claim 1, wherein the third party creates and starts a chaincode container based on the chaincode image, comprising: After the third-party building module completes building the chaincode, it starts the chaincode container and loads and starts the chaincode image in the traditional chaincode container; or, After receiving the transaction request to call the chain code, the Peer container triggers the third-party construction module to start the chain code container, and loads and starts the chain code image in the traditional chain code container.

6. The method of claim 1, 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.

7. The method according to any one of claims 1 to 6, wherein: The third-party construction module is arranged in the Peer container or outside the Peer container.

8. The method of claim 7, wherein: The third-party building module is set outside the Peer container, including: Third-party building blocks are set up in the governance node.

9. A system for deploying chain code in a consortium chain, comprising: The third-party construction module receives the command for installing the first chain code and the chain code source code sent by the client. The third-party construction module calls the container image construction tool, builds the chain code image based on the chain code source code and the adapted operating environment, 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, and establishes two communication servers on the proxy server, one as a pseudo Peer server and the other as a pseudo chain code server; sends the IP address and port information of the pseudo chain code server to the chain code container, and sends the IP address and port information of the pseudo Peer server to the Peer container; The Peer container is set as a communication client, receives the chaincode transaction request initiated by the user through the communication server, and sends the request to the chaincode container through the communication server; The chaincode container is set as a communication client. After receiving the chaincode transaction request through the communication server, it executes the transaction and returns the execution result to the Peer container through the communication server. Proxy server, set as the communication server.

10. The system of claim 9, wherein the third-party construction module calls a container image construction tool to build a chain code image based on the chain code source code and an adapted operating environment, including: The third-party building module calls the container image building tool to compile 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, adds the chain code program to the adapted operating environment and generates a chain code image.

11. As claimed in the system of claim 10, the third-party construction module calls the container image construction tool, and the chain code source code sent by the client is compiled to obtain the chain code program, including: The third-party construction module generates a third configuration file based on the chain code source code and sends it to the container image construction tool, and creates an image construction container; The container image building tool pulls the compilation environment image according to the third configuration file, and executes the image building task in the image building container to obtain the compiled chain code program.

12. The system of claim 10, wherein the third-party construction module calls a container image construction tool, adds the chain code program to an adapted operating environment and generates a chain code image, including: The third-party building module generates a fourth configuration file based on the generated chain code program; The third-party construction module calls a container image construction tool and sends the fourth configuration file to the container image construction tool; The container image building tool pulls the operating environment image according to the fourth configuration file, and generates a chain code image including the chain code program and the operating environment.

13. The system of claim 9, wherein the third party creates and starts a chaincode container based on the chaincode image, comprising: After the third-party building module completes building the chaincode, it starts the chaincode container and loads and starts the chaincode image in the traditional chaincode container; or, After receiving the transaction request to call the chain code, the Peer container triggers the third-party construction module to start the chain code container, and loads and starts the chain code image in the traditional chain code container.

14. The system of claim 9, 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.

15. The system of any one of claims 9 to 14, wherein: The third-party construction module is arranged in the Peer container or outside the Peer container.

16. The system of claim 15, wherein: The third-party building module is set outside the Peer container, including: Third-party building blocks are set up in the governance node.

Images