Method and System for Deploying Chain Codes in a Consortium Blockchain

Abstract

The present application provides a method and system for deploying chaincodes in a consortium blockchain. The method includes: a third-party construction module receives a command for installing a first chaincode and the chaincode source code sent by a client; the third-party construction module constructs 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 chaincode container as a gRPC server, sets a Peer container as a gRPC client, and notifies the information of the gRPC server to the gRPC client. Through the above process, developers can write the chaincode source code in the traditional chaincode manner without making any changes during development, thus not adding additional development costs to chaincode developers. At the same time, by constructing the chaincode image by a third-party construction module, the dependence on Docker is eliminated.

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 novel application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain system, data blocks are linked sequentially in chronological order to form a chain-like data structure, cryptographically guaranteeing an unalterable and unforgeable distributed ledger. Due to its decentralized, tamper-proof, and autonomous nature, blockchain is gaining increasing 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 chaincode in a consortium chain, comprising:

[0005] The third-party building module receives the command to install the first chaincode and the chaincode source code from 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 a chain code container based on the chain code image, sets the chain code container as a communication server, sets the peer container as a communication client, and notifies the communication client of information of the communication server.

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

[0009] A third-party construction module receives a command for installing the first chaincode and a chaincode source code from the client, builds a chaincode image based on the chaincode source code, and creates and starts a chaincode container based on the chaincode image;

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

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

[0012] This solution allows developers to continue developing chaincode source code in the traditional chaincode format without requiring modifications, thus minimizing development costs. Furthermore, by building chaincode images from third-party building blocks, reliance on Docker is eliminated. Furthermore, setting the chaincode container as the communication server offers the advantage of decoupling the external chaincode container from the peer container, enabling service-oriented development. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. 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 any creative labor.

[0014] Figure 1 An architectural diagram of Hyperledger Fabric in some embodiments of the present disclosure;

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

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

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

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

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

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

[0021] Figure 8 A schematic diagram of the communication and command chain involving Docker in this disclosure;

[0022] Figure 9 This is a schematic diagram of deploying a traditional chaincode container in this disclosure;

[0023] Figure 10 This is a schematic diagram of deploying a traditional chaincode container in this disclosure;

[0024] Figure 11 This is a schematic diagram of the communication and command chain after removing Docker in this disclosure;

[0025] Figure 12 This is a schematic diagram of deploying external chaincode after removing Docker in this disclosure;

[0026] Figure 13 This is a flowchart of deploying chaincode containers after removing Docker in this disclosure;

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

[0028] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0029] Blockchains are generally categorized into three types: public, private, and consortium. Furthermore, various combinations exist, such as private + consortium, or consortium + public. Public blockchains offer the highest degree of decentralization. Ethereum is a prime example of a public blockchain. Participants can access data on the blockchain, participate in transactions, and compete for the right to record new blocks. Furthermore, participants (i.e., nodes) can freely join and exit the network and perform related operations. In contrast, private blockchains have write permissions controlled by a specific organization or institution, while data read permissions are regulated by that organization. Simply put, a private blockchain can be a weakly centralized system with a small number of participating nodes, strictly limited in scope. This type of blockchain is more suitable for internal use within a specific organization. Consortium blockchains fall somewhere between public and private blockchains, achieving partial decentralization. Each node in a consortium chain typically has a corresponding entity or organization. Participants join the network through authorization and form a stakeholder alliance to jointly maintain the blockchain's operations.

[0030] HyperLedger Fabric is an open-source consortium blockchain implementation. Unlike public blockchains like Ethereum, nodes in the Hyperledger Fabric network generally require authorization and authentication before joining. This avoids the resource overhead of Proof of Work (PoW), significantly improves transaction processing efficiency, and meets the processing performance requirements of enterprise-level applications. Furthermore, the system can operate without token support.

[0031] Figure 1 This 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, there are Organization 1, Organization 2, and Organization 3. Each organization can have its own 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 represents.

[0032] An organization's nodes in a blockchain network are called peers. Peers store ledgers. Specifically, peers include endorsing peers, committing peers, leader peers, and anchor peers. An organization can choose which nodes to install chaincode on to implement shared business processes among alliance members, eliminating the need to install the chaincode on every node. Generally, a chaincode is installed on an endorsing peer. After the chaincode is installed on an endorsing peer and instantiated, it becomes known to other nodes within the collaborating organizations (also known as a channel) and can be invoked by applications. The most important additional information provided during instantiation is the endorsement policy, which describes which organizations must approve a transaction before it is accepted into their ledgers. A chaincode can define one or more smart contracts. Each smart contract has a unique identifier within the chaincode. Applications can access a specific smart contract within the chaincode container using the smart contract's identifier. A peer node can also be a master node; an organization typically has only one master node. Master nodes can communicate with the ordering service, obtaining the latest blocks from the service and synchronizing them across nodes within the organization. Peer nodes can also serve as anchor nodes. Anchor nodes can represent an organization in exchanging information with other organizations. Typically, each organization has one anchor node. All peer nodes can also serve as ledger nodes, verifying transactions in the ordering service node blocks and maintaining a copy of the world state and ledger. Ledger nodes can obtain blocks containing transactions from orderer nodes, verify these blocks, and then add them to the blockchain. It should be noted that the term "node" is a logical entity, and multiple nodes of different types can run on the same physical entity.

[0033] Applications (apps) can connect to blockchain nodes through the built-in SDK (Software Development Kit) and API (Application Programming Interface). Apps can then generate transaction proposals to invoke chaincode and submit them to the blockchain network. As previously mentioned, once a chaincode is installed and instantiated on a peer node, the smart contract within the chaincode becomes available to the associated channel, allowing applications to invoke the chaincode. Applications invoke chaincode by sending transaction proposals to the nodes belonging to the organizations specified in the endorsement policy. The transaction proposals serve as input to the smart contract, which simulates execution on the endorsing nodes and generates an endorsed transaction response. The blockchain network ultimately sorts these transactions, generates blocks, and submits them to the distributed ledger. Specifically, the sorting service performs transaction sorting and block generation. When this process is complete, the app receives the corresponding event.

[0034] In a simple mode often used for testing, the ordering service is a single node in the network. In many cases, the ordering service can include multiple nodes, and can be configured to have different ordering nodes in different organizations.

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

[0036] a1: The application sends a transaction proposal to the endorsing peer.

[0037] After logging into the application with an account, for example, using account A, 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 represents the account ID of the logged-in client, chaincodeID represents the ID of the called chaincode, txPayLoad represents the transaction payload, timestamp represents the timestamp of the transaction initiation, and clientSig is the signature of the client account.

[0038] Applications can send transactions to one or more endorsing nodes according to the Endorse Policy. Endorsement policies generally include nodes organized into relationships such as and, or, and majority of, and can be specified in the chaincode. and{endorsing node 1, endorsing node 2, endorsing node 3} can indicate that the transaction needs to be endorsed by endorsing node 1, endorsing node 2, and endorsing node 3. or{endorsing node 1, endorsing node 2, endorsing node 3} can indicate that any one of endorsing node 1, endorsing node 2, and endorsing node 3 must endorse the transaction. majority of{endorsing node 1, endorsing node 2, endorsing node 3} can indicate that the transaction needs to be endorsed by at least half of the endorsing nodes 1, endorsing node 2, and endorsing node 3, which here means at least two of the three endorsing nodes.

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

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

[0041] After verifying the transaction content, the endorsing node can simulate the execution of the contract in the transaction. This verification can include verifying the transaction signature using Account A's public key, verifying that the transaction has not been previously submitted (to protect against replay attacks), and verifying that the transaction initiator is a qualified initiator on the channel. Once verified, the endorsing node can simulate the execution of the sent transaction, following the example above. During this simulated execution, the endorsing node can invoke the chaincode specified in the transaction (specifically, the smart contract within the chaincode) and input the parameters specified in the transaction, thereby simulating the execution.

[0042] The results of a transaction typically include a generated read set (Rset or RS) and / or write set (Wset or WS) (RS and WS are collectively referred to as read-write sets, or RWset). These read-write sets are ultimately written to the blockchain ledger maintained locally by the peer node. Read and write sets are typically expressed in a key-value format. Furthermore, read and write sets typically include version information, indicating the version targeted by the operations in the read and write sets.

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

[0044] Continuing with the previous example, with the endorsement policy "and{endorsing node 1, endorsing node 2, endorsing node 3}," Endorsing Node 1, Endorsing Node 2, and Endorsing Node 3 each simulate and endorse the transaction, and send their endorsement results to the application. Under this endorsement policy, endorsements from different endorsing nodes for the same transaction typically differ only in signatures; otherwise, the endorsement policy is not met.

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

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

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

[0048] After the application collects consistent proposal responses from enough endorsing nodes, for example, proposal responses from Endorsing Node 1, Endorsing Node 2, and Endorsing Node 3, the application can call the SDK to send the endorsed transaction to the ordering node. The endorsed transaction can include a packaged result including the transaction proposal, read / write sets, and endorsement signatures.

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

[0050] The ordering service can continuously collect endorsed transactions, for example, including at least one endorsed transaction from different applications or the same application. Specifically, after collecting a certain number of endorsed transactions, the ordering node in the ordering service can sort these transactions. For example, the transactions can be sorted by their timestamps. The ordering node can then package the sorted transactions into blocks.

[0051] a6: The sorting service broadcasts the generated block to the master node, which then synchronizes it to other peer nodes within the organization.

[0052] In a Hyperledger Fabric network comprised of different organizations, each organization has a master node in one or more of its peer nodes. The master node communicates with the ordering node, obtaining the latest blocks from the ordering node and synchronizing them with the peer nodes within the organization.

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

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

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

[0056] The block header contains the block number ( Figure 3 The block number of each block is unique and generally increases monotonically. 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, Current Block Hash), and the hash value of the previous block header ( Figure 3 PH0, PH1, PH2, etc., PH is the abbreviation of Previous Block Hash, which is also the block hash of the previous block). In this way, all blocks in the blockchain are arranged in order and linked together in a cryptographic way. This hashing and linking makes the blockchain ledger data very secure. Even if a node that saves the blockchain ledger has its data tampered with, other nodes can quickly confirm the tampered blockchain ledger through the 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.

[0057] 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 the block. Figure 4 As shown, block data can include a series of transactions. These transactions can be sorted by transaction time. Each transaction can include a transaction header, transaction signature, transaction proposal, transaction response, and transaction endorsement.

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

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

[0060] ●A transaction proposal includes 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.

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

[0062] ●The transaction response is the output of the smart contract. If the transaction verification is successful, the transaction will be applied to the ledger, thereby updating the world state.

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

[0064] The block metadata includes the time 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 flag to each transaction, but since this information is generated at the same time as the block, it will not be included in the current block hash in the block header.

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

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

[0067] An example of a world state is recording information of two cars, CAR1 and CAR2, which can be recorded using two states respectively.

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

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

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

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

[0072] Overall, the second state is a key-value pair (abbreviated as k-v pair), where the value2 also contains k-v pairs. In the above example, there are three different k-v pairs, which are set as the three k-v pairs in v2: k21 = model: v21 = BMW, k22 = color: v22 = red, k23 = owner: v23 = Jane.

[0073] The versions of both states are 0, which is also the starting version of each state. The version number can be incremented whenever the state is updated. 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). <000,0178>The application can invoke the smart contract to finally perform operations such as put and delete on the world state. In one example, Application 1 initiated a transaction T8 to the endorsing node 1 in Organization 1, the endorsing node 2 in Organization 2, and the endorsing node 3 in 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 the endorsing node 1 in Organization 1, the endorsing node 2 in Organization 2, and the endorsing node 3 in Organization 3 according to the endorsement policy. The endorsement policy is also, for example, "and{endorsing node 1, endorsing node 2, endorsing node 3}".

[0075] Transaction T8 is, for example: <00,00181>

[0076] <clientID = Application 1,

[0077] chaincodeID = ID1,

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

[0079] timestamp,

[0080] clientSig> <00001$92>This transaction T8 invokes the chaincode numbered ID1. For example, it invokes the method Method1 therein and inputs the parameter k1. This Method1, for example, reads the value corresponding to the input parameter, that is, reads the brand of the vehicle.

[0082] Transaction T9 is, for example:

[0083] <clientID = Application 1,

[0084] chaincodeID = ID1,

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

[0086] timestamp,

[0087] clientSig>

[0088] Transaction T9 invokes the chaincode with ID1, for example, invokes Method2 therein and inputs the parameter k23. Method2, for example, modifies the name of the vehicle owner, usually in the case of vehicle transfer.

[0089] After Transactions T8 and T9 are verified, simulated, and endorsed by each endorsing node, each endorsing node returns a proposal response to Applications 1 and 2 respectively. The endorsing node simulates the execution of the transaction content. For example, the following read-write sets are generated for T8 and T9 respectively:

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

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

[0092] Version=0 indicates the state version to which the generated operation is applied.

[0093] Endorsing nodes can endorse the generated read-write set and then return proposal responses to Application 1 and Application 2. For example, for a T8 transaction, Endorsing Nodes 1, 2, and 3 simulate and endorse the transaction, and send the endorsement results to Application 1. Similarly, for a T9 transaction, Endorsing Nodes 1, 2, and 3 simulate and endorse the transaction, and send the endorsement results to Application 2.

[0094] 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 verifying the block, each accounting node will append the block to the blockchain of the local ledger and update 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:

[0095] k1-v1:

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

[0097] k2-v2:

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

[0099] These endorsing peers simulate the execution of transactions, including those invoking chaincode, using container technology, namely the aforementioned chaincode container. A chaincode container is a container environment (Docker) in which the chaincode runs, independent of the endorsing peer process. It provides an isolated sandbox environment for the chaincode to run. A container is a lightweight package of application code that also includes the dependencies required for program execution, such as specific versions of programming language runtimes and libraries required to run software services. This isolates smart contract execution and prevents the endorsing peer process from crashing due to errors or malicious code. When instantiating a chaincode, the endorsing peer populates a container image with the chaincode and deploys it using the Docker management API. If the container is not running, a new one can be started. Once running, all proposals received by the endorsing peer are transferred to the container for execution.

[0100] As mentioned above, chaincode execution requires chaincode installation. Specifically, after the chaincode is installed on an endorsing node and instantiated, it can be invoked by an application. Chaincode deployment on a blockchain includes both traditional chaincode deployment and external chaincode deployment. External chaincode can be deployed and executed on nodes external to the blockchain, allowing users to independently manage each external node and its code's runtime environment. Traditional chaincode is distinct from external chaincode, as it is deployed and executed by nodes within the blockchain.

[0101] The aforementioned container technology is a type of virtualization technology. Virtualization technology actually includes hardware virtualization and container technology. Virtual machines use hardware virtualization technology. Virtual machines require virtual hardware to install a complete operating system before they can install and run applications. Using a virtual machine to virtualize a complete operating system and set up a complete dependency environment every time an application is released would be a tedious task. Container technology is relatively lightweight. Containers eliminate the operating system and instead contain the application and the system environment it relies on. Using container technology, applications and their dependencies can be packaged and ported to other hosts running the same operating system to continue functioning properly. The advantages of container virtualization technology include being lightweight, easy to migrate, convenient to deploy, and requiring minimal resources. Furthermore, containers enable standardization. Docker is a mainstream container technology, along with other options such as Rocket, RKT, and Kata.

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

[0103] The entire operating logic of Docker is as follows Figure 5 As shown in the figure, the Docker Client sends the Docker command to be executed to the Docker Daemon (also known as the Docker Engine) on the host where Docker is running. The Docker Daemon then decomposes the request and executes it. For example:

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

[0105] Executing the Docker pull command will pull the image from the remote container image repository to the local machine;

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

[0107] 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 top of the container image. This layer loads a copy of the complete container image into the memory for execution. This copy loaded into the memory can be modified for the container, but it is limited to running in the memory; any modifications to the Container layer will not take effect on the underlying image, and the modifications 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 definition of docker images through basic syntax, and each instruction in it can describe a step in building an image. For example:

[0108] Commonly used commands in Dockerfile include the following:

[0109] FROM: What image is built based on

[0110] WORKDIR: The working directory of the container

[0111] RUN: Execute commands during container construction

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

[0113] ADD©: Add the specified file to the container image

[0114] ENV: Set environment variables

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

[0116] Specifically, such as Figure 6 As shown in the figure, the Docker client sends the creation request to the Docker Engine. As mentioned earlier, the Docker Engine is a containerized daemon process. The Docker Engine then sends the request to containerd, which calls runC. Containerd manages the container lifecycle by calling runC's API. runC directly interacts with the files that the container depends on (such as cgroups and the Linux kernel). It is responsible for configuring the cgroup and namespace environment required to start the container and creating the relevant 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 the container. The role of the container-shim is to decouple containerd from the real container (the process in it), allowing runC to exit after creating / running the container. When containerd goes down, 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, there is no need for containerd 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.

[0117] As container instances increase in number, the complexity of container management increases dramatically. This is where Kubernetes (abbreviated as k8s) comes in handy. Kubernetes is an open-source container cluster management system that enables automated deployment, scaling, and maintenance of container clusters. It helps with container deployment, release, and orchestration, significantly simplifying container management and maintenance.

[0118] 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 in the figure, a Kubernetes cluster typically consists of one Master node and multiple Node nodes. A node can be a physical machine or a virtual machine. The Master is the cluster control node for Kubernetes. Each Kubernetes cluster has a Master responsible for managing and controlling the entire cluster. Other machines in the Kubernetes cluster are called Node nodes. Node nodes are workload nodes in the Kubernetes cluster. Nodes can be assigned workloads by the Master. If a Node fails, its workload is automatically transferred to other Nodes by the Master.

[0119] Every Node runs the kubelet, a key component. Kubelet is the Master's agent on the Node. It works closely with the Master to manage the lifecycle of local containers, responsible for tasks such as creating, starting, and stopping pod-specific containers, and implementing basic cluster management functions. A pod is the smallest deployment unit in Kubernetes, a collection of containers and the fundamental unit for service orchestration and scaling.

[0120] 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 status to the Master node, such as the operating system, Docker version, CPU and memory status 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 connection" by the Master, and the Node status will be marked as unavailable (Not Ready). The Master will then trigger the automatic process of "large workload transfer".

[0121] Nodes also have a kube-proxy component, which acts as a network proxy for pods on the node. This component facilitates communication between Kubernetes services and the outside world, maintains network rules, and performs Layer 4 load balancing. The Kubernetes service sits between the kube-proxy and pods, defining a service's access point and exit point. Internal access between pods and containers can be performed directly through the service. Figure 7 The relationship between kube-proxy, service (i.e., Kubernetes Service), and pod is for illustration only. In practice, a service can correspond to multiple pods, and a pod can correspond to multiple services. Services can be created by Kubernetes, and the relationship between services and pods can also be established by a designated kubelet in the Kubernetes Master (not shown in the figure).

[0122] 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, Kubernetes was released in 2014 and used Docker as the container runtime (Container Runtime) by default, and docker-shim first officially appeared in 2016. Docker did not consider container orchestration or Kubernetes when it was first created, 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 Docker-related operation logic as a whole to form 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 leftmost pod 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 for K8S, kubelet needs to call Docker through docker-shim first, and then call containerd through Docker.

[0123] 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 chain code, the ultimate expectation is to Figure 6 The chaincode runs in the intermediate container process shown.

[0124] Running chaincode using container technology requires generating the chaincode program and the required runtime environment within the container. A chaincode program can be a binary file, a compiled target file. The runtime environment refers to the dependencies required to run the program. Traditional chaincode requires a compatible runtime environment to run containerized chaincode programs on a node. To reduce the burden on users, allowing them to focus solely on developing the chaincode source code in a high-level language, rather than on the differences in runtime environments across different blockchain nodes, the blockchain, upon receiving the user-developed chaincode source code, can compile and execute it using Kubernetes and Docker. This achieves advantages such as lightweightness, ease of migration, convenient deployment, and low resource usage. It also enables automated deployment, scaling, and maintenance of container clusters.

[0125] A process of deploying traditional chaincode in Hyperledger Fabric 2.0 is as follows: Figure 9 It should be noted that, here, a peer container has been deployed in a container using kubernetes and docker technology. This peer container is, for example, container1, in which an endorsement node is running.

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

[0127] The client here refers to the blockchain client that creates and sends the chaincode source code. After creating the chaincode source code, the developer can package it and set an endorsement policy. The packaged chaincode source code and the endorsement policy can then be sent through the client to the endorsing peers where the chaincode is to be deployed. The endorsing peers for the chaincode to be deployed typically include the endorsing peers specified in the endorsement policy. Endorsing peers are shown as Peer containers in the diagram.

[0128] b2: The endorsement node uses Docker to create a temporary container and compiles the chaincode source code into a target file in the created temporary container.

[0129] Based on the type of chaincode source code sent by the client, the endorsement node can use Docker (Docker here mainly includes Docker-shim and Docker Engine 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 compilation environment images for compiling multiple chaincode 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 the Go language, a temporary container suitable for the Go language compilation environment is created; for source code edited in the Java language, a temporary container suitable for the Java language compilation environment is created; for source code edited in the Node.js language, a temporary container suitable for the Node.js language compilation environment is created.

[0130] In the created temporary container, you can compile source code to generate target files. Similarly, source code edited in Go is compiled into binary files in the temporary container, source code edited in Java is compiled into JAR files, and source code edited in Node.js is compiled into target code.

[0131] Specifically, in the process of creating a temporary container, the Peer container can generate a first configuration file based on 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 Docker build command and the dockerfile_1 to docker-shim, and then send it to the docker engine. 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.

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

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

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

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

[0136] Specifically, after receiving the notification, the peer container can generate a second configuration file based on the target file, for example, dockerfile_2. The content of the second configuration file describes the steps for building the chaincode image and includes the image of the runtime environment for executing the chaincode program and the storage path of the chaincode program. The peer container can send the Docker build command and dockerfile_2, which are called by Docker-shim to the Docker Engine. The Docker Engine can pull the runtime environment image suitable for running the chaincode program from the (local or remote) image repository specified in dockerfile_2 and pull the target code from the aforementioned storage path. This regenerates a new image containing the chaincode program and the runtime environment and stores it in a local / remote repository. This newly generated chaincode image can be run by a container on the current host or other hosts on the Fabric network, thereby achieving one-time packaging and multiple execution. The host here can be a physical machine, a virtual machine, or even a container.

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

[0138] Subsequently, after the peer container receives the transaction to invoke the chaincode, if the traditional chaincode container is not started, the peer container can initiate a Docker run instruction to the Docker Engine through docker-shim. This instruction is sent to containerd, which in turn calls runC. In this way, runC pulls up a traditional chaincode container built based on the chaincode image, such as container3.

[0139] Furthermore, the Peer container may input the parameters in the transaction into the chaincode container to perform chaincode simulation to execute the transaction.

[0140] In addition, after b3, you can also Figure 10 As shown, use the following method:

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

[0142] In b4, as described above, after receiving the notification, the peer container uses Docker to build a chaincode image containing the target file. In addition to sending the Docker build command and the Dockerfile_2 to the Docker Engine, the peer container can also send the Docker run command to the Docker Engine. This command is sent to containerd via docker-shim and the Docker Engine, which in turn invokes runC. In this way, runC launches a traditional chaincode container based on the chaincode image, for example, container3. In other words, once the chaincode image is built, the traditional chaincode container constructed from it can be launched, without having to wait for a transaction to invoke the chaincode, as in b5, for the peer node to trigger the launch of the traditional chaincode container. This preemptive launch allows the peer node to directly invoke the chaincode for simulated execution upon receiving a subsequent transaction request to invoke the chaincode, rather than temporarily launching the traditional chaincode container and then invoking the chaincode for simulated execution. This approach significantly improves contract execution speed.

[0143] As can be seen in the above process, the primary role of the Docker engine is to build images, and communication with the Docker engine largely requires the use of the Docker shim. Deploying traditional chaincode in Fabric 2.0 (and subsequent versions), which utilizes Kubernetes and Docker technologies, relies heavily on Docker, specifically the Docker-shim and Docker Engine. Furthermore, as previously mentioned, when using Docker as the Kubernetes container runtime, the kubelet must first call the Docker Engine through the Docker-shim, which then calls containerd through the Docker Engine.

[0144] As mentioned earlier, docker-shim is a Kubernetes component primarily designed to operate Docker through the CRI, specifically the aforementioned Docker Engine. Docker wasn't initially created with container orchestration or Kubernetes in mind, but Kubernetes adopted Docker as its default container runtime. Subsequent code included a significant amount of Docker-related operational logic. Later, to decouple Kubernetes and enable compatibility with a wider range of container runtimes, Kubernetes separated the Docker-related operational logic into docker-shim.

[0145] Containerd is a product of the standardization of container technology. To ensure compatibility with the OCI (Open Container Initiative) standard, the container runtime and its management functions were separated from the Docker Daemon. Containerd provides an interface for the Docker Daemon, allowing it to shield underlying structural changes and ensure backward compatibility with the original interface. Downward, it can be integrated with runC through containerd-shim, allowing the engine to be independently upgraded, avoiding the previous issue where Docker Daemon upgrades would render all containers unavailable. runc is a command-line tool that creates and runs containers according to OCI standards.

[0146] In theory, even if Docker Engine is not running, you can manage containers directly through containerd, so you don’t need docker-shim.

[0147] 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 for K8S. In version 1.20, Kubernetes mentioned that it would no longer maintain the docker-shim shim in subsequent versions, and would begin removing the shim in version 1.23 at the earliest. 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 itself be used as an underlying container runtime. Now it has become a better choice for the Kubernete container runtime. Not only Docker, but many cloud platforms also support containerd as the underlying container runtime. In addition to containerd, there are also CRI-O and others that can be used as the underlying container runtime.

[0148] If containerd is used as the K8S container runtime, containerd can have a built-in CRI plug-in, so that kubelet can call containerd directly, such as Figure 11 As shown in the figure, kubelet can obviously shorten the communication link by calling containerd directly through CRI, thereby improving performance. In addition, removing Docker also reduces resource usage (Docker is not a pure container runtime and has many other functions, so its existence is more resource-intensive).

[0149] In addition to traditional chaincodes, external chaincodes can also be deployed in Hyperledger Fabric. A process of deploying external chaincodes is as follows: Figure 12 Indicated in the figure. Figure 9 Similar to the example above, a Peer container has been deployed in a container using kubernetes and docker technologies, and this Peer container runs in a cloud service environment. As mentioned above, traditional chaincodes are generally deployed and executed on nodes within the blockchain. External chaincodes are generally deployed and run on nodes outside the blockchain, making it easier for users to independently manage each external node and its operating environment. Figure 13 As shown in the example, the user environment includes the Client. The process may include the following:

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

[0151] After the client starts the external chaincode container, it can also obtain the address (such as the IP address) and port number of the external chaincode container. 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 transactions that call the chaincode to the external chaincode container. Therefore, the nodes on the blockchain need to obtain the address and port number of the external chaincode container (such as the certificate configuration for TLS (Transport Layer Security) communication) to communicate with the external chaincode container.

[0152] Communication can be achieved through RPC (Remote Procedure Call). RPC encapsulates a service call within a local method, allowing the caller to invoke the service as if it were a local method while shielding the caller from underlying implementation details. This provides a lightweight, non-perceptual cross-process communication method. Specific implementations can involve a set of agreements between the caller and the server, allowing data exchange over a persistent TCP connection.

[0153] 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. When the gRPC client initiates a call to the gRPC server, it 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.

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

[0155] d2: The client sends the instruction to install the external chain code to the peer container in the cloud service environment.

[0156] The client's instruction to install an external chaincode can include the IP address and port number of the external chaincode container. Specifically, the client can send a connection.json file that specifies the IP address and port number of the external chaincode container. Additionally, the client can send a metadata.json file that specifies that the chaincode being installed is external.

[0157] d3: The Peer container initiates a connection to the external chain code container to call the chain code.

[0158] After receiving the instruction to install the external chaincode, the peer container uses metadata.json to identify the external chaincode being installed. Furthermore, the peer container can be configured as a gRPC client. After obtaining the address and port of the external chaincode container through connection.json, the peer container can initiate a connection to the external chaincode container through the gRPC client, which can maintain a persistent connection.

[0159] Subsequently, after receiving a transaction to invoke an external chaincode, the peer container can send the transaction to the external chaincode container via the maintained persistent connection, thereby invoking the chaincode. After the transaction to invoke the chaincode is executed in the external chaincode container, as described above, the execution result, i.e., the read / write set, can be returned to the gRPC client, i.e., the peer container, via the maintained persistent connection.

[0160] In fact, in Figure 9 、 10 In the example, after startup, the traditional chaincode container 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 with the gRPC client; instead, the gRPC client needs to actively initiate a connection with the gRPC server. In b5, the peer container, acting as the gRPC server, can include its own address and port in the instruction for creating the traditional chaincode container. This 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 gRPC server's address and port in the connection.json file. If successful, a persistent connection can be maintained with the peer container. Subsequently, the peer container can send transactions that invoke the chaincode to the traditional chaincode container via this persistent connection to simulate execution. In b1, the client-initiated chaincode installation instruction does not need to include the connection.json and metadata.json files.

[0161] Unlike traditional chaincode container construction, during the external chaincode container construction process, the client needs to inform the peer container that the external chaincode is currently being installed by using the installation chaincode instructions in connection.json and metadata.json, which contain information such as the external chaincode container's address and port. In addition, since users can build and start the external chaincode container in advance in the client's user environment or a user-specified environment, the peer container does not need to participate in the construction and startup process. Therefore, the detailed process of building and starting the external chaincode container is omitted here.

[0162] The advantage of setting the external chaincode container as a gRPC server is that it can be decoupled from the peer container, thus enabling service-oriented operation. On the one hand, the external chaincode 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 chaincode container can be provided as a service to different peer containers, for example, serving different peer containers within the same organization. In this case, the peer container acts as a gRPC client.

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

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

[0165] The client can Figure 9 Similar to step b1 in the previous section, the developer initiates a command to install the first chaincode to the endorsing peer to be deployed. The created chaincode source code and endorsement policy are packaged and sent to the endorsing peer. After creating the chaincode source code, the developer can package it and set an endorsement policy. The packaged chaincode source code and endorsement policy can then be sent via the client to the endorsing peers to deploy the chaincode. The endorsing peers for the deployed chaincode typically include the endorsing peers specified in the endorsement policy.

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

[0167] 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 can also be other forms of setting cckeeper outside the Peer container. In addition, the cckeeper module can also be built into the Peer container.

[0168] Figure 13 The example shows the case where the cckeeper module is built into the governor container. Other cases are slightly simpler than this.

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

[0170] After receiving the command and chaincode source code from the client to install the first chaincode, the Peer container can send the command and chaincode source code to a built-in or external cckeeper module, which is a third-party build module. Alternatively, the client can send the command and chaincode source code directly to the Governor container, allowing cckeeper to obtain the command and chaincode source code. In either case, the cckeeper module can receive the chaincode source code from the client and generate a third configuration file (dockerfile), here designated as dockerfile_3. dockerfile_3 can include a description of creating an image build container.

[0171] As mentioned above, building a chaincode image includes compiling a chaincode program and adding the compiled chaincode program to a running environment to generate an image.

[0172] 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. Containerd then calls runC to create an image-based container, such as container4.

[0173] On the other hand, after the cckeeper module generates dockerfile_3, it can send dockerfile_3 to imgbuilder (a container image building tool), and then imgbuilder can pull a compilation environment image based on the content in dockerfile_3. The content in this image is suitable for compiling the chaincode source code. For example, imgbuilder can include the Kaniko container image tool, which is an open source container image building tool from 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.

[0174] imgbuilder can store the generated chaincode program in a path and notify cckeeper, either through the Peer container or directly.

[0175] After receiving the notification, the cckeeper module 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 this chain code program and the storage path of the chain code program. cckeeper can send a chain code image building instruction 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, thereby achieving 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 chain code container as the gRPC server, sets the Peer container as the gRPC client, and notifies the gRPC client of the information of the gRPC server.

[0178] Here, the chain code container can be started after cckeeper completes the chain code container construction, or the peer container can trigger cckeeper to start the chain code container after receiving the 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] In the latter case, for example, after the peer container receives a transaction to invoke the chaincode, it 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, so that cckeeper can obtain the storage path of the chaincode image. After the peer container receives a transaction to invoke the chaincode, if the traditional chaincode container is not started, the peer container can call cckeeper, which will then pull up a traditional chaincode container built based on the chaincode image. This traditional chaincode container is, for example, container.

[0181] Furthermore, the Peer container may input the parameters in the transaction into the chaincode container to perform chaincode simulation to execute the transaction.

[0182] In addition, the third-party construction module can set the chain code container as a gRPC server. In this way, the chain code container will have information such as an IP address and a port number. Furthermore, the third-party construction module can send the connection.json file and the metadata.json file to the Peer container. The connection.json file specifies the IP address, port, and other information of the chain code container. In this way, 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 the connection.json, it can initiate a connection with the external chain code container through the gRPC client and can maintain a long connection.

[0183] Subsequently, after receiving a transaction to invoke an external chaincode, the peer container can send the transaction to the external chaincode container via the maintained persistent connection, thereby invoking the chaincode. After the transaction to invoke the chaincode is executed in the external chaincode container, as described above, the execution result, i.e., the read / write set, can be returned to the gRPC client, i.e., the peer container, via the maintained persistent connection.

[0184] As mentioned above, this solution allows developers to continue developing chaincode source code in the traditional chaincode format without requiring any changes, thus minimizing development costs for chaincode developers. Furthermore, by building chaincode images from third-party building blocks, reliance on Docker is eliminated. Furthermore, configuring the chaincode container as a gRPC server offers the advantage of decoupling the external chaincode container from the peer container, enabling service-oriented development.

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

[0186] c1: The client sends the first install chaincode command to the Governor container. The command includes the created chaincode source code and endorsement policy.

[0187] like Figure 1 As described in the corresponding text, fabric can include multiple organizations, each organization can have multiple peers. Here, a governor node can be set up 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.

[0188] After the user creates the chaincode source code, he can use the client to send the chaincode source code and endorsement policy to the governor container of the organization to which he belongs.

[0189] The first installation chaincode command is similar to Figure 9 The Governor container receives the chaincode source code from the client and generates a third configuration file (Dockerfile). Specifically, it uses its built-in cckeeper to generate this Dockerfile, which is set to Dockerfile_3. Dockerfile_3 includes a description of how to create an image and build a container.

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

[0191] Governor can send the task of creating an image building 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. Containerd then calls runC to create an image-based container, such as container3.

[0192] 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 based on the content in dockerfile_3. 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 an open source container image building tool from 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.

[0193] In the above process, kubelet can communicate with containerd through the CRI, sending container creation commands to containerd. This streamlines the image building process while maintaining a smooth link, improving performance and reducing resource usage, as previously mentioned.

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

[0195] As mentioned above, 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, such as an image repository, and notify cckeeper.

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

[0197] 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 for building a chaincode image, and includes the image of the operating environment for executing this chaincode program and the storage path of the chaincode program. cckeeper can send a chaincode image building instruction to imgbuilder. imgbuilder can pull the operating environment image suitable for running the chaincode 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 chaincode program and the operating environment can be regenerated and stored in the local / remote image repository. This newly generated chaincode image can be run by the container on the current host or other host on the Fabric network, thereby achieving one-time packaging and multiple execution. The host here can be a physical machine or a virtual machine, or even a container.

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

[0199] c5: The Governor container uses a CRI-compliant container runtime to create a chaincode container and sets the chaincode container as a gRPC server.

[0200] The cckeeper module in the Governor container can create a chaincode container using a CRI-compliant container runtime. Specifically, cckeeper can send a chaincode container creation command to the Master. The Master notifies the kubelet in the Node of this command, which can then create the container using containerd, which includes the CRI plugin. Specifically, after receiving the notification, the cckeeper module can generate a fourth configuration file based on the target file, for example, dockerfile_4. This configuration file describes the steps for building a chaincode image and includes the image of the runtime environment for executing the chaincode program and the storage path for the chaincode program. cckeeper can send a chaincode image creation instruction to imgbuilder. imgbuilder can pull the runtime environment image suitable for running the chaincode program from the (local or remote) image repository specified in dockerfile_4 and retrieve the target code from the aforementioned storage path. This regenerates a new image containing the chaincode program and the runtime environment and stores it in the local or remote image repository. This newly generated chaincode image can be run by a container on the current host or other hosts on the Fabric network, achieving single-package, multi-location execution. The host machine here can be a physical machine, a virtual machine, or even a container. After imgbuilder completes the construction of the chaincode image, it can send a notification to cckeeper.

[0201] 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 to generate a chaincode container.

[0202] After cckeeper completes building the chaincode container, it can start the chaincode container, or the peer container can trigger cckeeper to start the chaincode container after receiving a transaction request to call the chaincode. In the former case, for example, 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 the latter case, for example, after the peer container receives a transaction to call the chaincode, it 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 so that cckeeper can obtain the storage path of the chaincode image. After the Peer container receives the transaction to call the chaincode, if the traditional chaincode container is not started, the Peer container can call cckeeper, and cckeeper will pull up a traditional chaincode container built based on the chaincode image.

[0203] In addition, the third-party construction module can set the chaincode container as a gRPC server. In this way, the chaincode container will have information such as the IP address and port number. Furthermore, the third-party construction module can send the connection.json file to the Peer container, which specifies the IP address, port, and other information of the chaincode container. In this way, the Peer container can be set as a gRPC client. After the Peer container obtains the address and port information of the external chaincode container through connection.json, it can initiate a connection with the external chaincode container through the gRPC client and maintain a long connection.

[0204] Subsequently, after receiving a transaction to invoke an external chaincode, the peer container can send the transaction to the external chaincode container via the maintained persistent connection, thereby invoking the chaincode. After the transaction to invoke the chaincode is executed in the external chaincode container, as described above, the execution result, i.e., the read / write set, can be returned to the gRPC client, i.e., the peer container, via the maintained persistent connection.

[0205] c6: The Governor container sends the installation second chaincode command to the Peer container and sets the Peer container as the gRPC client.

[0206] Specifically, the cckeeper in the Governor can send a command to install the second chain code to the Peer container. Figure 13 The command to install the second chaincode sent in the external chaincode installation command can include the address and port of the chaincode service. Specifically, cckeeper can send a connection.json file that specifies the address and port of the chaincode service.

[0207] After receiving the command to install the second chaincode, the peer container can be configured as a gRPC client after obtaining the chaincode service's address and port information from connection.json. Furthermore, the peer container can initiate a connection to the chaincode service through the gRPC client and maintain a persistent connection.

[0208] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system onto a PLD through their own programming, eliminating the need for chip manufacturers to design and manufacture dedicated integrated circuit chips. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly performed using "logic compiler" software. This is similar to the software compilers used during program development. Before compilation, the original code must be written in a specific programming language, called a hardware description language (HDL). There are not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0209] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0210] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle 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.

[0211] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-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 term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0212] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as 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 an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0213] 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 flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, 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 produce 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 flowcharts and / or block diagrams. 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.

[0214] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work 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 The function specified in one or more boxes.

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

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

[0217] 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. Memory is an example of a computer-readable medium.

[0218] 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 disc read-only memory (CD-ROM), digital versatile disc (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 transitory media such as modulated data signals and carrier waves.

[0219] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0220] 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, and the like 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 via a communications network. In distributed computing environments, program modules may be located in local and remote computer storage media, including storage devices.

[0221] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple; for relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples" indicates that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, where not inconsistent.

[0222] The foregoing is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification shall be included within the scope of the claims.

Claims

1. A method for deploying chaincodes in a consortium blockchain, comprising: A third-party construction module receives a command to install a first chaincode and the chaincode source code sent by a client, and the third-party construction module is a container construction module that does not depend on Docker; The third-party construction module constructs 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 chaincode container as a communication server, sets the Peer container as a communication client, and notifies the information of the communication server to the communication client.

2. The method as claimed in claim 1, wherein the third-party construction module constructs a chaincode image based on the chaincode source code, comprising: The third-party construction module calls a container image construction tool to construct a chaincode image based on the chaincode source code and the adapted running environment.

3. The method as claimed in claim 2, wherein the third-party construction module calls a container image construction tool to construct a chaincode image based on the chaincode source code and the adapted running environment, comprising: The third-party construction module calls a container image construction tool to compile the chaincode source code sent by the client to obtain a chaincode program; The third-party construction module calls a container image construction tool to add the chaincode program to the adapted running environment and generate a chaincode image.

4. The method as claimed in claim 3, wherein the third-party construction module calls a container image construction tool, and the step of compiling the chaincode source code sent by the client to obtain a chaincode program, comprising: The third-party construction module generates a third configuration file based on the chaincode source code and sends it to the container image construction tool, and creates an image construction container; The container image construction tool pulls a compilation environment image according to the third configuration file and executes an image construction task in the image construction container to obtain a compiled chaincode program.

5. The method as claimed in claim 3, wherein the third-party construction module calls a container image construction tool to add the chaincode program to the adapted running environment and generate a chaincode image, comprising: The third-party construction module generates a fourth configuration file based on the generated chaincode 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 construction tool pulls a running environment image according to the fourth configuration file and generates a chaincode image containing the chaincode program and the running environment.

6. The method as claimed in claim 1, wherein the third party creates and starts a chaincode container based on the chaincode image, comprising: After the third-party construction module finishes constructing the chaincode, it starts the chaincode container immediately and loads and starts the chaincode image in a traditional chaincode container; or, The Peer container triggers the third-party construction module to start the chaincode container after receiving a transaction request for calling the chaincode, and loads and starts the chaincode image in the traditional chaincode container.

7. The method as claimed in any one of claims 1-6, wherein, The third-party construction module is set inside or outside the Peer container.

8. The method as claimed in claim 7, wherein, The third-party construction module is set outside the Peer container, including: The third-party construction module is set in a governance node.

9. A system for deploying chaincodes in a consortium blockchain, comprising: A third-party construction module that receives a command to install a first chaincode and the chaincode source code sent by a client, constructs a chaincode image based on the chaincode source code, and also creates and starts a chaincode container based on the chaincode image. The third-party construction module is a container construction module that does not depend on Docker; A Peer container, configured as a communication client, receives a chaincode invocation transaction request initiated by a user, and sends the request to the chaincode container; A chaincode container, configured as a communication server, executes the transaction after receiving the chaincode invocation transaction request, and returns the execution result to the Peer container.

10. The system as claimed in claim 9, wherein the third-party construction module constructs a chaincode image based on the chaincode source code, comprising: The third-party construction module invokes a container image construction tool to construct a chaincode image based on the chaincode source code and the adapted operating environment.

11. The system as claimed in claim 10, wherein the third-party construction module invokes a container image construction tool to construct a chaincode image based on the chaincode source code and the adapted operating environment, comprising: The third-party construction module invokes a container image construction tool to compile the chaincode source code sent by the client to obtain a chaincode program; The third-party construction module invokes a container image construction tool to add the chaincode program to the adapted operating environment and generate a chaincode image.

12. The system as claimed in claim 11, wherein the third-party construction module invokes a container image construction tool to compile the chaincode source code sent by the client to obtain a chaincode program, comprising: The third-party construction module generates a third configuration file based on the chaincode source code and sends it to the container image construction tool, and creates an image construction container; The container image construction tool pulls a compilation environment image according to the third configuration file, and executes an image construction task in the image construction container to obtain a compiled chaincode program.

13. The system as claimed in claim 11, wherein the third-party construction module invokes a container image construction tool to add the chaincode program to the adapted operating environment and generate a chaincode image, comprising: The third-party construction module generates a fourth configuration file based on the generated chaincode program; The third-party construction module invokes a container image construction tool and sends the fourth configuration file to the container image construction tool; The container image construction tool pulls a running environment image according to the fourth configuration file, and generates a chaincode image containing the chaincode program and the running environment.

14. The system as claimed in claim 9, wherein the third party creates and starts a chaincode container based on the chaincode image, comprising: After the third-party construction module finishes constructing the chaincode, it immediately starts the chaincode container, and loads and starts the chaincode image in a traditional chaincode container; or, The Peer container triggers the third-party construction module to start the chaincode container after receiving a chaincode invocation transaction request, and loads and starts the chaincode image in the traditional chaincode container.

15. The system as claimed in any one of claims 9-14, wherein, The third-party construction module is disposed inside or outside the Peer container.

16. The system as claimed in claim 15, wherein, The third-party building module is arranged outside the Peer container and includes: The third-party building module is arranged in the governance node.

Images