Method and system for deploying chaincode in a consortium chain

Abstract

The application provides a method and system for deploying chaincode in a consortium chain, the method comprising: a Peer container receiving a command for installing traditional chaincode and chaincode source code sent by a client; the Peer container constructing a chaincode image based on the chaincode source code by using a third-party building module; and the third-party building module starting a traditional chaincode container and loading and starting the chaincode image in the traditional chaincode container. Through the above process, the developer still writes in the traditional chaincode manner without making changes when developing the chaincode source code, so that no additional development cost is added to the chaincode developer. Meanwhile, the chaincode image is constructed by the third-party building module, so that the dependence on Docker is eliminated.

Description

TECHNICAL FIELD

[0001] The embodiment of the present specification belongs to the technical field of blockchains, and particularly relates to a method and system for deploying chaincode in a consortium chain. BACKGROUND

[0002] A blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. In a blockchain system, data blocks are combined into a chain-type data structure in a sequential manner according to time sequence, and are guaranteed to be non-tamperable and non-forgable by cryptography. Due to the characteristics of decentralization, information non-tamperability, and autonomy, the blockchain has attracted more and more attention and application. SUMMARY

[0003] The purpose of the present application is to provide a method and system for deploying chaincode in a consortium chain, comprising:

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

[0005] A Peer container receives a command for installing traditional chaincode and chaincode source code sent by a client;

[0006] The Peer container uses a third-party build module to build a chaincode image based on the chaincode source code;

[0007] The third-party build module starts a traditional chaincode container, and loads and starts the chaincode image in the traditional chaincode container.

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

[0009] A Peer container, configured to receive a command for installing traditional chaincode and chaincode source code sent by a client, and to use a third-party build module to build a chaincode image based on the chaincode source code;

[0010] The third-party build module is configured to start a traditional chaincode container, and to load and start the chaincode image in the traditional chaincode container.

[0011] A traditional chaincode container, configured to run chaincode.

[0012] In the above embodiment, the developer still writes in the traditional chaincode manner when developing the chaincode source code without making any changes, which does not increase the additional development cost for the chaincode developer. At the same time, the chaincode image is built by the third-party build module, which eliminates the dependence on Docker. BRIEF DESCRIPTION OF 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 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 A schematic diagram of deploying a traditional chaincode container in this disclosure;

[0023] Figure 10 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 from this disclosure;

[0025] Figure 12 This is a flowchart for deploying a traditional chaincode container after removing Docker in this disclosure;

[0026] Figure 13 This is a schematic diagram of deploying a traditional chaincode container after removing Docker in this disclosure. DETAILED DESCRIPTION

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

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

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

[0030] 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 1As 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0059] The 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.

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

[0061] The transaction response is the output of the smart contract. If the transaction is successfully verified, it will be applied to the ledger, thereby updating the world state.

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

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

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

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

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

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

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

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

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

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

[0072] The version of both states is 0, which is 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 is checked first to make sure the version of the current state is consistent with the version when the endorsement (to avoid concurrent updates).

[0073] The application can invoke the smart contract to finally implement the put and delete operations on the world state. In one example, application 1 initiates a transaction T8 to endorsement node 1 in organization 1, endorsement node 2 in organization 2, and endorsement node 3 in organization 3 according to an endorsement policy, such as "and {endorsement node 1, endorsement node 2, endorsement node 3}". Similarly, application 2 also initiates a transaction T9 to endorsement node 1 in organization 1, endorsement node 2 in organization 2, and endorsement node 3 in organization 3 according to an endorsement policy, such as "and {endorsement node 1, endorsement node 2, endorsement node 3}".

[0074] The T8 transaction is, for example:

[0075] <clientID=application 1,

[0076] chaincodeID=ID 1,

[0077] txPayLoad=[Method 1 (k 1 )],

[0078] timestamp,

[0079] clientSig>

[0080] The T8 transaction invokes the chaincode with ID 1, for example, to call the method Method 1 therein and input the parameter k 1. The Method 1, for example, reads the value corresponding to the input parameter, i.e., reads the brand of the vehicle.

[0081] The T9 transaction is, for example:

[0082] <clientID=应用1,

[0083] chaincodeID=ID1,

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

[0085] timestamp,

[0086] clientSig>

[0087] The T9 transaction calls the chain code with ID1, for example, calling method Method2, and inputting parameter k23. Method2, for example, changes the name of the vehicle owner, which is usually the case when the vehicle is transferred.

[0088] After transactions T8 and T9 are verified, simulated, and endorsed by each endorsing node, each endorsing node returns a proposal response to Application 1 and Application 2, respectively. The endorsing node simulates the execution of the transaction content, and for example, the read-write sets for T8 and T9 are generated as follows:

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

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

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

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

[0093] After Application 1 and Application 2 have each collected the proposal responses returned by the endorsing nodes, they can send the endorsed transactions to the sorting node. The endorsed transactions can include a packaged result including the transaction proposal, read / write set, and endorsement signature. The sorting service sorts transactions T8 and T9. For example, based on the transaction timestamps, T8 comes first and T9 comes last. 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 within the respective organizations. After each accounting node verifies the block, it appends the block to the blockchain of the local ledger and updates the world state in the local ledger based on the block.

[0094] At this point, 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 and runs a copy of the complete container image. This copy loaded into the memory can be modified for the container, but it is limited to running in memory; any modifications to the Container layer will not take effect on the underlying image, and the modifications 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, as shown in Figure 6 The Docker client sends a request for creation to the Docker Engine, which is a containerized daemon process, as described previously. The Docker Engine can send the request to containerd, which invokes runC. containerd is used to manage the life cycle of containers, and it manages the life cycle of containers by invoking the API of runC. runC directly interacts with the files on which the container depends (such as cgroup / linux kernel, etc.), and is responsible for configuring the environment required for starting the container, such as cgroup / namespace, to create a process for starting the container. Figure 6 In the middle, there is a containerd-shim layer (also known as a shim carrier, similar to an adapter layer), which decouples containerd and the real container (process inside). The containerd-shim allows runC to exit after creating / running the container. When containerd is down, containerd-shim can remain, so that the file descriptor opened by the container can be guaranteed not to be closed (so that the service can be upgraded without affecting the Dockerd). Relying on containerd-shim to collect / report the exit status of the container, so that containerd does not need to monitor the created child process. For example, a fabric peer node can eventually run in Figure 6 The leftmost container process can also be referred to as a Peer container.

[0117] When there are more and more container instances, the complexity of container management increases. At this time, kubernetes (k8s for short) comes in handy. k8s is an open source container cluster management system that can realize the functions of automatic deployment, automatic scaling, maintenance, etc. of a container cluster, and can help to deploy, publish, orchestrate, etc. a series of operations on containers, which can greatly simplify the management and operation of containers.

[0118] In Kubernetes, multiple containers can be created, each of which runs an application instance, and then through the built-in load balancing strategy, the management, discovery, and access of this group of application instances can be realized, and these details do not need to be manually configured and processed by the operation and maintenance personnel. 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] In addition, the Node node also has a component kube-proxy, which is used to implement the Pod's network proxy on the Node node, realize the communication between Kubernetes Service and the outside world, and maintain network rules and four-layer load balancing.

[0122] A Kubernetes Service sits between the kube-proxy and the pods, defining a service's access point and exit point. Access between internal 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 specified in the Kubernetes master (not shown in the figure).

[0123] If Docker is used as the K8S container runtime, kubelet must first call Docker Engine through docker-shim, and then call containerd through Docker Engine. docker-shim is a component of Kubernetes, and its main purpose is to operate Docker through CRI (Container Runtime Interface). Docker appeared in 2013, and Kubernetes was released in 2014 and used Docker as the container runtime (Container Runtime) by default. 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.

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

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

[0126] A process of deploying traditional chaincode in Hyperledger Fabric 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.

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

[0128] The client here refers to the blockchain client that creates 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.

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

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

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

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

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

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

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

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

[0137] Specifically, after receiving the notification, the peer container can generate a second configuration file 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.

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

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

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

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

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

[0143] In b4, as 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.

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

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

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

[0147] 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. The gRPC server does not actively initiate a connection to the gRPC client, but requires the gRPC client to actively initiate a connection to the gRPC server. 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 uses gRPC as an example.

[0148] In the above scheme, after the Peer container receives the instruction to install the traditional chain code, the Peer container can be set as the gRPC server. When creating a traditional chain code container through b5 or b5', the address and port of the Peer container itself can be included in the instruction to create the traditional chain code container, and it can be placed in the connection.json file and sent to the traditional chain code container. In this way, the created traditional chain code container can be set as a gRPC client. Furthermore, after the traditional chain code container is built, it can initiate a connection to the Peer container based on the address and port of the gRPC server in the connection.json file. After the traditional chain code container initiates a connection with the Peer container through the gRPC client, it can maintain a long connection.

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

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

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

[0152] 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).

[0153] A process of deploying chaincode in Hyperledger Fabric can be as follows Figure 12 As shown in . Here, it is still assumed that 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. It includes the following:

[0154] S110: The Peer container receives the command to install the traditional chain code and the chain code source code sent by the client.

[0155] The client can Figure 9 Similar to process b1 in [1], the developer initiates the chaincode installation command to the endorsing peer to be deployed, and then packages the created chaincode source code and endorsement policy and sends them 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 peer to deploy the chaincode. The endorsing peers for the chaincode to be deployed typically include the endorsing peers specified in the endorsement policy.

[0156] like Figure 1 As mentioned above, a fabric can include multiple organizations, each of which can have multiple peers. As previously mentioned, a peer node, referred to as a peer container, can be deployed in a container using Kubernetes and containerd. The peer container can have a built-in cckeeper module, or the cckeeper module can be located outside the peer container.

[0157] S120: The Peer container uses a third-party construction module to build a chain code image based on the chain code source code.

[0158] After receiving the traditional chaincode installation command and chaincode source code from the client, the peer container can send the command and chaincode source code to the built-in or external cckeeper module, which is also known as the third-party build module. After receiving the chaincode source code from the client, the cckeeper module can generate a third-party configuration file (dockerfile), set to dockerfile_3 in this example. dockerfile_3 can include a description of creating an image build container.

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

[0160] The Peer container 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 container4.

[0161] On the other hand, after the cckeeper module generates dockerfile_3, it can send dockerfile_3 to imgbuilder (container image building tool), and then imgbuilder can pull a compilation environment image according to the content in dockerfile_3. 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 mirror to obtain the chaincode program, which is the target file above. imgbuilder can store the generated chaincode program in a path and notify cckeeper. It can be notified through the Peer container or directly to cckeeper. Figure 13 Only one implementation mode, namely the former, is shown.

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

[0163] S130: The third-party construction module starts the traditional chain code container, and loads and starts the chain code image in the traditional chain code container.

[0164] Here, the chain code container can be started after cckeeper completes chain code construction, or the peer container can trigger cckeeper to start the chain code container after receiving a transaction request to call the chain code.

[0165] 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. This traditional chaincode container is, for example, container5. 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.

[0166] 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 pull up a traditional chaincode container built based on the chaincode image. This traditional chaincode container is, for example, container5.

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

[0168] The Peer container can be set as a gRPC service end. In S120 or S130, the Peer container builds a chaincode image based on the chaincode source code by using a third-party building module, or the Peer container triggers the cckeeper to start a chaincode container after receiving a transaction request for calling the chaincode, and the Peer container can send its IP address, port and other information to the cckeeper. Then, when the cckeeper creates a traditional chaincode container, it can send a connection.json file, which can include the IP address, port and other information of the Peer container. After the traditional chaincode container is started, it can know the IP address, port and other information of the current gRPC service end through the connection.json. Then, the traditional chaincode container can set itself as a gRPC client. The traditional chaincode container can then initiate a connection with the Peer container through the gRPC client and maintain a long connection. Then, after receiving a transaction request for calling the chaincode, the Peer container can initiate a call to the traditional chaincode container through the maintained long connection, input the parameters in the transaction, and perform chaincode simulation to execute the transaction. After the traditional chaincode container executes the transaction for calling the chaincode, it can also return the execution result, i.e., the read / write set, to the gRPC service end, i.e., the Peer container, through the maintained long connection.

[0169] Through the above process, the developer still writes in the traditional chaincode manner when developing the chaincode source code without making any changes, which does not increase the additional development cost for the chaincode developer. At the same time, by building the chaincode image by the third-party building module, the dependence on Docker is eliminated.

[0170] The following describes the process of deploying chaincode in an alliance chain with a specific example in Hyperledger Fabric, which can be as shown in Figure 13

[0171] c1: The client sends a command for installing a traditional chaincode and chaincode source code to the Peer container, and the Peer container sends the chaincode source code to the cckeeper.

[0172] As described above, here it can be set that a Peer node has been deployed in a container by using kubernetes and containerd technology, which can be called a Peer container. After the user creates the chaincode source code, the client can send a command for installing a traditional chaincode and the chaincode source code to the connected Peer container.

[0173] The Peer container can send the command for installing a traditional chaincode and the chaincode source code sent by the client to the cckeeper.

[0174] ​CCkeeper can generate a third configuration file (Dockerfile) based on the chaincode source code, which is set as Dockerfile_3. Dockerfile_3 can include a description of creating an image and building a container.

[0175] The cckeeper module can be built into the Peer container, or the cckeeper module can be set outside the Peer container. The following uses the latter as an example for explanation, and the case where the cckeeper module is built into the Peer container is similar.

[0176] c2: cckeeper creates an image-building container and compiles the chaincode source code into a target file.

[0177] Specifically, cckeeper 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.

[0178] On the other hand, after cckeeper 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.

[0179] In the above process, kubelet can communicate with containerd through the CRI, and then send image build commands to containerd. This way, after removing docker-shim and docker-engine, the image build process is streamlined while maintaining a smooth link. As mentioned above, this improves performance and reduces resource usage.

[0180] c3: The image building container places the compiled target file in a directory and notifies the peer container / cckeeper.

[0181] c4: cckeeper uses imgbuilder to build a chaincode image containing the target file and stores it in the image repository.

[0182] cckeeper can receive the notification in c3. Afterwards, cckeeper 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 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 a container on the current host or other host on the Fabric network, thereby achieving one-time packaging and multiple executions. The host here can be a physical machine or a virtual machine, or even a container.

[0183] After imgbuilder completes the construction of the chaincode image, it can send a notification to cckeeper, and cckeeper can notify the Peer container.

[0184] c5: cckeeper creates a traditional chaincode container, and loads and starts the chaincode image in the traditional chaincode container.

[0185] The Peer container can be set as a gRPC server.

[0186] cckeeper can create chaincode containers using a CRI-compliant container runtime. Specifically, cckeeper sends a chaincode container creation command to the master, which in turn notifies the kubelet on the node. The kubelet then creates the container using containerd, which includes the CRI plugin. During this process, cckeeper sends the peer container's IP address, port, and other information to the traditional chaincode container using the connection.json file.

[0187] After the traditional chaincode container is started, the chaincode image can be run. Through a series of instructions, the built chaincode image can be pulled from the image repository and run in a container of a Pod, thereby generating a chaincode container. Through connection.json, the IP address and port information of the current gRPC server can be known. Further, the traditional chaincode container can set itself as a gRPC client. The traditional chaincode container can further initiate a connection with the Peer container through the gRPC client and can maintain a long connection. Further, after the Peer container receives a transaction request for calling a chaincode, the Peer container can initiate a call to the traditional chaincode container through the maintained long connection, input the parameters in the transaction, and perform chaincode simulation to execute the transaction. After the traditional chaincode container executes the transaction for calling the chaincode, the execution result, i.e., the read / write set, can also be returned to the gRPC server, i.e., the Peer container, through the maintained long connection.

[0188] Through the above process, the developer still writes in the traditional chaincode manner when developing the chaincode source code without making changes, which does not increase the additional development cost for the chaincode developer. At the same time, by building the chaincode image by the third-party building module, the dependence on Docker is eliminated.

[0189] The following introduces an embodiment of a system for deploying chaincode in Hyperledger Fabric, comprising:

[0190] A Peer container is configured to receive a command for installing a traditional chaincode and chaincode source code from a client, and to build a chaincode image based on the chaincode source code by using a third-party building module.

[0191] The third-party building module is configured to start a traditional chaincode container, and to load and start the chaincode image in the traditional chaincode container.

[0192] The traditional chaincode container is configured to run the chaincode.

[0193] The Peer container builds the chaincode image based on the chaincode source code by using the third-party building module, wherein the third-party building module calls a container image building tool to build the chaincode image based on the chaincode source code and an adapted running environment.

[0194] The third-party building module calls the container image building tool to build the chaincode image based on the chaincode source code and the adapted running environment, comprising:

[0195] The third-party building module calls the container image building tool to compile the chaincode source code from the client to obtain a chaincode program.

[0196] The third-party building module calls the container image building tool, adds the chain code program to the adapted running environment and generates a chain code image.

[0197] The third-party construction module calls a container image construction tool, and compiles the chain code source code sent by the client to obtain a chain code program, including:

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

[0199] The container image building tool pulls the compilation environment image according to the third configuration file, and executes the image building task in the image building container to obtain the compiled chain code program.

[0200] The third-party construction module calls the container image construction tool, adds the chain code program to the adapted operating environment and generates a chain code image, including:

[0201] The third-party building module generates a fourth configuration file based on the generated chaincode program;

[0202] The third-party construction module calls a container image construction tool and sends the fourth configuration file to the container image construction tool;

[0203] The container image building tool pulls the operating environment image according to the fourth configuration file and generates a chain code image including the chain code program and the operating environment.

[0204] The third-party construction module starts the traditional chain code container, and loads and starts the chain code image in the traditional chain code container, including:

[0205] After the third-party building module completes the chain code construction, it starts the chain code container and loads and starts the chain code image in the traditional chain code container; or

[0206] After receiving the transaction request to call the chain code, the peer container triggers the third-party construction module to start the chain code container, and loads and starts the chain code image in the traditional chain code container.

[0207] The Peer container is set as the gRPC server, the started traditional chain code container is set as the gRPC client, and a long connection is maintained between the Peer container and the traditional chain code container.

[0208] The third-party construction module is set in the Peer container or outside the Peer container.

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

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

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

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

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

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

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

[0216] 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 A step that specifies a function in one or more boxes.

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

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

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

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

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

[0222] 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 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, without conflict.

[0223] 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 chaincode in a consortium chain, comprising: The Peer container receives the command and chain code source code for installing the traditional chain code from the client; The Peer container uses a third-party building module to build a chain code image based on the chain code source code; The third-party construction module starts the traditional chain code container, and loads and starts the chain code image in the traditional chain code container.

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

3. The method of claim 2, wherein the third-party construction module calls a container image construction tool to build a chaincode image based on the chaincode source code and the adapted runtime environment, comprising: The third-party building module calls the container image building tool to compile the chain code source code sent by the client to obtain the chain code program; The third-party building module calls the container image building tool, adds the chain code program to the adapted running environment and generates a chain code image.

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

5. The method of claim 3, wherein the third-party construction module calls a container image construction tool, adds the chaincode program to an adapted runtime environment, and generates a chaincode image, comprising: The third-party building 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 building tool pulls the operating environment image according to the fourth configuration file and generates a chain code image including the chain code program and the operating environment.

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

7. According to the method of claim 1, the Peer container is set as a communication server, the started traditional chain code container is set as a communication client, and a long connection is maintained between the Peer container and the traditional chain code container.

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

9. A system for deploying chaincode in a consortium chain, comprising: Peer container, used to receive commands and chaincode source code from the client to install the traditional chaincode, and also uses a third-party building module to build a chaincode image based on the chaincode source code; The third-party construction module is used to start the traditional chaincode container, and load and start the chaincode image in the traditional chaincode container; Traditional chaincode container, used to run chaincode.

10. The system of claim 9, wherein the peer container uses a third-party building module to build a chain code image based on the chain code source code, wherein: The third-party building module calls the container image building tool to build the chain code image based on the chain code source code and the adapted operating environment.

11. The system of claim 10, wherein the third-party construction module calls a container image construction tool to build a chaincode image based on the chaincode source code and the adapted runtime environment, comprising: The third-party building module calls the container image building tool to compile the chain code source code sent by the client to obtain the chain code program; The third-party building module calls the container image building tool, adds the chain code program to the adapted running environment and generates a chain code image.

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

13. The system of claim 11, wherein the third-party building module calls a container image building tool to add the chaincode program to an adapted runtime environment and generate a chaincode image, comprising: The third-party building 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 building tool pulls the operating environment image according to the fourth configuration file and generates a chain code image including the chain code program and the operating environment.

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

15. The system as claimed in claim 9, wherein the Peer container is set as a communication server, the started traditional chain code container is set as a communication client, and a long connection is maintained between the Peer container and the traditional chain code container.

16. A system as described in any one of the above items, wherein: The third-party construction module is arranged in the Peer container or outside the Peer container.

Images