WO2023185058A1 - 联盟链中部署链码的方法和系统 - Google Patents

联盟链中部署链码的方法和系统 Download PDF

Info

Publication number
WO2023185058A1
WO2023185058A1 PCT/CN2022/135655 CN2022135655W WO2023185058A1 WO 2023185058 A1 WO2023185058 A1 WO 2023185058A1 CN 2022135655 W CN2022135655 W CN 2022135655W WO 2023185058 A1 WO2023185058 A1 WO 2023185058A1
Authority
WO
WIPO (PCT)
Prior art keywords
container
chain code
image
code
chain
Prior art date
Application number
PCT/CN2022/135655
Other languages
English (en)
French (fr)
Inventor
印明亮
安子贤
Original Assignee
蚂蚁区块链科技(上海)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 蚂蚁区块链科技(上海)有限公司 filed Critical 蚂蚁区块链科技(上海)有限公司
Publication of WO2023185058A1 publication Critical patent/WO2023185058A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances

Definitions

  • the embodiments of this specification belong to the field of blockchain technology, and particularly relate to a method and system for deploying chain codes in a consortium chain.
  • Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • data blocks are combined into a chained data structure in a chronological manner and are cryptographically guaranteed to be an untamperable and unforgeable distributed ledger. Due to the characteristics of blockchain, such as decentralization, non-tamperable information, and autonomy, blockchain has also received more and more attention and applications.
  • the purpose of the present invention is to provide a method and system for deploying chain code in a consortium chain, including:
  • a method of deploying chaincode in a consortium chain including:
  • the Peer container receives the command to install the traditional chain code and the chain code source code sent by the client;
  • the Peer container uses a third-party building module to build a chaincode image based on the chaincode source code
  • the third-party building module starts a traditional chain code container, and loads and starts the chain code image in the traditional chain code container.
  • a system for deploying chaincode in a consortium chain including:
  • Peer container is used to receive the command to install traditional chain code and the chain code source code sent by the client, and also uses a third-party building module to build a chain code image based on the chain code source code;
  • the third-party building module is used to start a traditional chain code container, and load and start the chain code image in the traditional chain code container;
  • developers can still write the chain code source code according to the traditional chain code method without making changes, so that no additional development costs are added to the chain code developers.
  • developers can still write the chain code source code according to the traditional chain code method without making changes, so that no additional development costs are added to the chain code developers.
  • Figure 1 is an architectural diagram of Hyperledger Fabric in some embodiments of the present disclosure
  • Figure 2 is a schematic diagram of the transaction process of Hyperledger Fabric in some embodiments of the present disclosure
  • Figure 3 shows the ledger structure of Hyperledger Fabric in some embodiments of the present disclosure
  • Figure 4 shows the structure of blocks and transactions in some embodiments of the present disclosure
  • Figure 5 is a schematic diagram of the basic principles of Docker in some embodiments of the present disclosure.
  • Figure 6 is a schematic diagram of the operation logic of Docker in some embodiments of the present disclosure.
  • FIG. 7 is a schematic diagram of the basic principles of Kubernetes in some embodiments of the present disclosure.
  • Figure 8 is a schematic diagram of communication and command links including Docker in this disclosure.
  • Figure 9 is a schematic diagram of deploying a traditional chaincode container in the present disclosure.
  • Figure 10 is a schematic diagram of deploying a traditional chaincode container in the present disclosure
  • Figure 11 is a schematic diagram of communication and command links after removing Docker in this disclosure.
  • Figure 12 is a flow chart of deploying a traditional chaincode container after removing Docker in this disclosure
  • Figure 13 is a schematic diagram of deploying a traditional chaincode container after removing Docker in this disclosure.
  • Blockchains can usually be divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain.
  • public chains are represented by Bitcoin and Ethereum. Participants who join the public chain can read data records on the chain, participate in transactions, and compete for the accounting rights of new blocks.
  • each participant i.e., node
  • the private chain has the writing permission of the network controlled by an organization or institution, and the data reading permission is regulated by the organization.
  • a private chain can be a weakly centralized system with strict restrictions and few participating nodes.
  • the alliance chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization".
  • Each node in the alliance chain usually has a corresponding entity or organization; participants join the network through authorization and form a stakeholder alliance to jointly maintain the operation of the blockchain.
  • HyperLedger Fabric is an open source alliance chain implementation. Unlike public chains such as Bitcoin and Ethereum, nodes in the Hyperledger Fabric network generally need to be authorized and authenticated before joining, thereby avoiding the resource overhead of POW (Proof of Work, proof of work) and greatly improving transaction processing efficiency. , to meet the processing performance requirements of enterprise-level applications, and the operation of the system does not require the support of tokens.
  • POW Proof of Work, proof of work
  • FIG 1 shows a typical architecture diagram of Hyperledger Fabric 1.4 and 2.0.
  • An organization in Fabric can be a company, an enterprise, or an association in the real world. As shown in Figure 1, it includes organization 1, organization 2 and organization 3.
  • Each organization can have its own corresponding Fabric-CA (Certification Authority, certificate issuance) server.
  • An organization can have multiple peer nodes. The organization's Fabric-CA can issue certificates to Peer nodes within the organization, and the issued certificates can be used to identify the nodes and their organizations.
  • Fabric-CA Creation Authority, certificate issuance
  • Peer nodes can include endorsement nodes (Endorsing Peer), accounting nodes (Committing Peer), master nodes (Leader Peer) and anchor nodes (Anchor Peer).
  • An organization can choose which nodes to install chaincode to implement business processes shared by consortium members without having to install chaincode on every node.
  • chaincode can be installed on the endorsing node. After the chain code is installed on the endorsing node, and after instantiation, other nodes between organizations with a collaborative relationship (also called a channel) can know the chain code, and only then can the application initiate a call.
  • Smart Contract can be defined in the chain code. Each smart contract has a unique identifier in the chaincode. Applications can access the specified smart contract in the chaincode container through the smart contract's identifier.
  • the peer node can also be the master node. There is generally only one master node in an organization. The master node can communicate with the ordering service to obtain the latest blocks from the ordering service and synchronize them among the nodes within the organization. Peer nodes can also be anchor nodes. Anchor nodes can exchange information with other organizations on behalf of the organization. Generally every organization has an anchor node.
  • All peer nodes can be accounting nodes, which are used to verify transactions in the ordering service node block and maintain copies of the world state and ledger.
  • the accounting node can obtain the blocks containing transactions from the orderer node and add them to the blockchain after verifying these blocks. It should be noted that "node” is a logical entity, and multiple nodes of different types can run on the same physical entity.
  • Application can be connected to the blockchain node through the built-in SDK (Software Development Tool) and API (Application Programming Interface, Application Programming Interface).
  • the App can then generate a transaction proposal that calls the chaincode and submit the transaction proposal to the blockchain network.
  • the smart contract within the chaincode becomes available to the associated channel, which means that the application can call the chaincode.
  • the application calls the chain code by sending a transaction proposal to the node to which the organization specified by the endorsement policy belongs.
  • the transaction proposal serves as the input of the smart contract, and the smart contract on the endorsement node generates an endorsed transaction response after simulated execution.
  • the blockchain network can eventually sort these transactions and generate blocks and submit them to the distributed ledger. Specifically, the sorting service can complete the sorting of transactions and generate blocks. When this process is completed, the App can receive the corresponding event.
  • the ordering service is an independent node in the network, that is, the ordering service is composed of one ordering node.
  • an ordering service can include multiple nodes and can be configured to have different ordering nodes in different organizations.
  • a1 The application sends a transaction proposal (proposal) to the endorsement node.
  • the role of the SDK includes packaging transaction proposals into a suitable format (such as the protocol buffer used in gRPC) and generating signatures for transaction proposals based on the user's key.
  • This generated transaction can contain ⁇ clientID, chaincodeID, txPayLoad, timestamp, clientSig> and other information.
  • clientID represents the account ID of the logged-in client
  • chaincodeID represents the ID of the called chaincode
  • txPayLoad represents the transaction payload
  • timestamp represents the timestamp of transaction initiation
  • clientSig is the signature of the client account.
  • Endorsement policies generally include nodes organized by relationships such as and, or, majority of, etc., which can be specified in the chain code. and ⁇ endorsement node 1, endorsement node 2, endorsement node 3 ⁇ can indicate that the transaction needs to be endorsed by endorsement node 1, endorsement node 2, and endorsement node 3. or ⁇ endorsement node 1, endorsement node 2, endorsement node 3 ⁇ can mean endorsement by any one of endorsement node 1, endorsement node 2, and endorsement node 3.
  • endorsing node 1 endorsing node 2
  • endorsing node 3 endorsing node 3
  • the application sends the transaction to the endorsement node 1, endorsement node 2, and endorsement node 3 respectively.
  • a2 After the endorsement node verifies the received transaction proposal, it simulates the execution of the transaction and endorses it, and returns a proposal response (proposal response) to the application.
  • the endorsement node After the endorsement node verifies the transaction content, it can simulate the execution of the contract in the transaction.
  • the endorsement node's verification of the transaction may include verifying the transaction signature using the public key of account A, the transaction has not been submitted before (replay attack protection), the transaction initiator is a qualified initiator on the channel, etc.
  • the endorsing node After passing the verification, according to the above example, the endorsing node can further simulate the execution of the sent transaction. During the simulated execution process, the endorsing node can call the chain code specified in the transaction (specifically, specify the smart contract in the chain code), and input the parameters in the transaction, and then simulate the execution.
  • the execution results of the transaction generally include the generated read set (Read Set, Rset or RS) and/or write set (Write Set, Wset or WS) (RS and WS can be collectively referred to as read and write sets, or written as RWset). These read and write sets can eventually be written to the blockchain ledger maintained locally by the Peer node. Read sets and write sets generally use Key-Value expressions. In addition, the read-write set generally also carries version information, which indicates the version for which the operations in the read-write set are generated.
  • the endorsement node can endorse the generated read-write set. Specifically, the endorsement node can use its own private key to sign the read-write set according to the endorsement policy.
  • endorsing node 1, endorsing node 2, endorsing node 3 ⁇ is used as the endorsement strategy
  • the endorsing node 1, endorsing node 2, and endorsing node 3 simulate and execute the transaction respectively. , and send the endorsement results to the application respectively.
  • the endorsement results of different endorsement nodes for the same transaction generally only have different signatures, otherwise it does not comply with the endorsement strategy.
  • a3 The application collects the returned proposal response from the endorsement node.
  • the application may collect proposal responses returned by endorsing nodes. As shown in Figure 2, taking and ⁇ endorsement node 1, endorsement node 2, endorsement node 3 ⁇ as an example of the endorsement strategy, the application can collect proposal responses returned by endorsement node 1, endorsement node 2, and endorsement node 3. Specifically, the SDK in the application can be used to parse the returned proposal response. Specifically, the SDK can verify the signature of the endorsement node in the proposal response, and compare the proposal responses returned by each endorsement node to determine whether the proposal responses are consistent (normally only the signatures should be inconsistent) and whether they are executed in accordance with the specified endorsement policy.
  • a4 The application sends the endorsed transaction to the ordering node.
  • the application can call the SDK to convert the endorsed transaction Sent to ordering node.
  • the endorsed transactions can include packaged results including transaction proposals, read/write sets, and endorsement signatures.
  • the sorting service sorts these transactions and generates blocks based on the sorted results.
  • the sorting service can continuously collect endorsed transactions, including at least one endorsed transaction sent by different applications or the same application. Specifically, the sorting node in the sorting service can sort these transactions after collecting a certain amount of endorsement transactions. Specifically, for example, transactions can be sorted according to their timestamps. The sorting node can then package the sorted transactions into blocks.
  • the sorting service broadcasts the generated block to the master node, and the master node synchronizes it to other Peer nodes in the organization to which it belongs.
  • a master node in one or more Peer nodes of each organization.
  • the master node can communicate with the ordering node to obtain the latest blocks from the ordering node and synchronize them among the peer nodes in the organization.
  • the accounting node verifies the block, appends the block to the blockchain of the local ledger, and updates the world state in the local ledger based on the block.
  • All Peer nodes can be accounting nodes. Accounting nodes can maintain ledgers locally.
  • the ledger may include blockchain data and world state data, as shown in Figure 3.
  • a blockchain consists of a series of blocks linked back and forth. Each block includes three parts: block header, block data and block metadata.
  • the block header contains the block number (N0, N1, N2, N3... in Figure 3).
  • the block number of each block is unique and generally increases monotonically.
  • the block number can be generated by the ordering service during the process of packaging and generating blocks.
  • the block header can also contain the hash value of the block data of the current block (CH in Figure 3, Current Block Hash), and the hash value of the previous block header (PH0, PH1, PH2, etc. in Figure 3, PH It is the abbreviation of Previous Block Hash and is also the block hash of the previous block). In this way, all blocks in the blockchain are arranged in order and cryptographically linked together. This hashing and linking makes blockchain ledger data extremely secure.
  • its block header 2 includes the block number N2, the hash value of block data 2 of the current block, and the hash value of block header 1 of the previous block 1.
  • Block data contains an ordered list of transactions. Each transaction in the transaction list represents a query or update operation on the world state. As mentioned before, block data can be written to the block data when the ordering service packages and generates blocks. As shown in Figure 4, block data can include a series of transactions. These transactions can be sorted by transaction time. Each transaction can include transaction header, transaction signature, transaction proposal, transaction response, and transaction endorsement.
  • the transaction header records some important metadata about the transaction, such as the name and version of the relevant chain code.
  • the transaction signature contains a signature created by the client application. This field can be used to determine whether the transaction has been tampered with.
  • ⁇ Transaction proposals include encoded input parameters provided by the application to the smart contract.
  • the input parameters provided by this proposal are combined with the current world state to determine the new world state.
  • the transaction response records the values before and after the world state in the form of a read-write set.
  • the transaction response is the output of the smart contract. If the transaction verification is successful, the transaction will be applied to the ledger to update the world state.
  • ⁇ Transaction endorsement is a set of signed transaction responses. These signatures come from relevant organizations specified by the endorsement policy, and the number of these organizations must meet the requirements of the endorsement policy.
  • Block metadata includes the time the block was written, as well as the certificate, public key, and signature of the block writer. Subsequently, the submitter of the block will also add a valid or invalid flag to each transaction, but since this information is generated at the same time as the block, it will not be included in the current block hash of the block header.
  • genesis block (i.e., block 0 in Figure 3) generally does not contain any user transactions, but only some configuration transactions. Configuration transactions can be used to initialize world state.
  • the world state is a database that stores the current values of a set of ledger states.
  • the current value of a ledger state can be accessed through the world state without the need to traverse the entire transaction log to calculate the current value.
  • An example of world state records the information of two cars CAR1 and CAR2. For example, it is recorded in two states respectively.
  • the k1-v1 of the first state is:
  • the second state is a key-value pair (abbreviated as k-v pair), in which value2 also contains k-v pairs, and the above example contains three different k-v pairs, here we set them to the three in v2
  • the version of both states is 0, which is also the starting version of each state.
  • the version number can be incremented each time the status is updated. When updating the status, the version number will first be checked to ensure that the current status version is consistent with the version at the time of endorsement (to avoid concurrent updates).
  • Applications can invoke (invoke) smart contracts to ultimately implement operations such as put and delete on the world state.
  • application 1 initiated a transaction T8 to endorsement node 1 in organization 1, endorsement node 2 in organization 2, and endorsement node 3 in organization 3 according to the endorsement policy.
  • the endorsement policy is, for example, "and ⁇ endorsement node 1 , endorse node 2, endorse node 3 ⁇ ".
  • application 2 also initiated a transaction T9 to endorsement node 1 in organization 1, endorsement node 2 in organization 2, and endorsement node 3 in organization 3 according to the endorsement policy.
  • the endorsement policy is also "and ⁇ endorsement node 1" , endorse node 2, endorse node 3 ⁇ ".
  • a T8 transaction example is:
  • This T8 transaction calls the chain code numbered ID1, for example, calls the method Method1 and enters the parameter k1.
  • Method1 is to read the value corresponding to the input parameter, that is, to read the brand of the vehicle.
  • a T9 transaction example is:
  • This T9 transaction calls the chain code numbered ID1, for example, calls the method Method2 and enters the parameter k23.
  • This Method 2 is, for example, to modify the name of the vehicle owner, usually when the vehicle is transferred.
  • each endorsement node After the two transactions T8 and T9 are verified, simulated and endorsed by each endorsement node, each endorsement node returns application 1 and application 2 respectively in the proposal response.
  • the endorsement node simulates the execution of the transaction content. For example, for T8 and T9, the read and write sets are generated as follows:
  • the endorsement node can endorse the generated read-write set and return the proposal response to Application 1 and Application 2 respectively.
  • endorsement node 1, endorsement node 2, and endorsement node 3 respectively perform simulated execution and endorsement of the transaction, and send the endorsement results to the application 1 respectively.
  • endorsement node 1, endorsement node 2, and endorsement node 3 simulate and execute and endorse the transaction respectively, and send the endorsement results to the application 2 respectively.
  • the endorsed transactions can include packaged results including transaction proposals, read/write sets, and endorsement signatures.
  • the sorting service sorts transactions T8 and T9. For example, according to the timestamp of the transaction, T8 comes before T9 comes after, then the sorted result of T8 and T9 generates block 3. Subsequently, the ordering service can broadcast the generated block 3 to each master node in organization 1, organization 2 and organization 3, and synchronize it to other peer nodes in the organization to which it belongs. Each accounting node verifies the block, appends the block to the blockchain of the local ledger, and updates the world state in the local ledger based on the block. At this time, the state affected by the transaction in block 3 is as follows:
  • the above-mentioned endorsement node simulates the execution of the transaction content, including the simulated execution of the transaction that calls the chain code, and can use container technology, that is, the chain code container mentioned above.
  • the chaincode container refers to the container environment (Docker) in which the chaincode runs independently of the endorsement node process. Its function is to provide an isolated sandbox environment for the chaincode to run.
  • Containers are lightweight packages of application code that also contain the dependencies required for a program to run, such as specific versions of programming language runtimes and libraries required to run software services. In this way, the execution of smart contracts can be isolated and the endorsing node process will not crash due to errors or malicious code.
  • the endorsing node When instantiating the chaincode, the endorsing node populates the container image with the chaincode and calls the Docker management API to deploy the image. If the container is not running, you can start a new container. Once run, proposals received by the endorsing node will be transferred to the container for execution.
  • the execution of the chain code requires the installation of the chain code. That is, after the chain code is installed on the endorsing node, it can be called by the application only after it is instantiated.
  • the deployment of chain code on the blockchain includes the deployment of traditional chain code and the deployment of external chain code.
  • External chain code can be deployed and executed on nodes outside the blockchain, for example, to facilitate users to independently manage the running environment of each external node and its code.
  • Traditional chain code is different from external chain code.
  • Traditional chain code is deployed and executed by nodes inside the blockchain.
  • Virtualization technology actually includes hardware virtualization and container technology.
  • Virtual machines use hardware virtualization technology.
  • the virtual machine requires virtual hardware and a complete operating system before it can install/run applications. If every time an application is released, a virtual machine is used to virtualize a complete operating system and a complete dependency environment is set up, which will be a relatively tedious task.
  • Container technology is relatively lightweight. The operating system can be removed from the container, and instead it contains the application and the system environment on which the application depends. Through container technology, applications and dependent environments can be packaged, and the packaged content can still run normally when transplanted to other hosts with the same operating system.
  • container virtualization technology it is more lightweight, easy to migrate, convenient to deploy, and consumes less resources. Additionally, containers enable standardization.
  • One of the mainstream container technologies is docker, in addition to rocket, rkt and kata.
  • the core concepts of Docker include: Image, Container, and Registry.
  • the entire operating logic of Docker is shown in Figure 5.
  • the Docker Client sends the Docker command that needs to be executed to the Docker Daemon (daemon process, also called Docker Engine) on the host where Docker is running (Docker Host), and the Docker Daemon decomposes the request and executes it.
  • Docker Daemon distributed process
  • Docker Host Docker Engine
  • Executing the Docker build command will build an image based on the Dockerfile and store it locally;
  • Executing the Docker pull command will pull the image from the remote container image warehouse to the local one;
  • Executing the Docker run command will pull the container image and run it into a container instance.
  • Image construction includes writing the dependencies and target files that need to be installed according to the Dockerfile, and superimposing them onto an existing base image to generate a new image.
  • a Container layer is generated on top of the container image. This layer loads and runs a copy of the complete container image. This copy loaded into memory can be modified by the container, but it is limited to running in memory; any modifications to the Container layer will not take effect on the underlying image, and the modifications made when the container dies will also be included.
  • Dockerfile is a configuration file used when executing the docker build command to build a docker image. It allows the docker image to be defined through basic syntax. Each instruction in it can describe a step to build the image. For example:
  • the Docker client sends the request that needs to be created to Docker Engine.
  • Docker Engine is a containerized daemon. Docker Engine can send the request to containerd, and containerd calls runC.
  • containerd is used to manage the life cycle of the container. It implements the management of the container life cycle by calling the runC API.
  • runC directly interacts with the files that the container depends on (such as cgroup/linux kernel, etc.), and is responsible for configuring the cgroup/namespace and other environments required to start the container for the container, and creating related processes for starting the container.
  • there is an additional containerd-shim layer also called a shim carrier, similar to an adaptation layer).
  • container-shim The function of container-shim is to decouple containerd from the real container (process in it), allowing runC to create /Exit after running the container.
  • containerd-shim can be maintained, thus ensuring that the file descriptor opened by the container will not be closed (so that Dockerd can be upgraded without affecting the service).
  • Rely on containerd-shim to collect/report the exit status of the container, so that containerd is not required to monitor the created child processes.
  • a fabric peer node can eventually run in the container process on the far left in Figure 6. This container can also be called a Peer container.
  • k8s is an open source container cluster management system that can realize automatic deployment, automatic expansion and contraction, maintenance and other functions of container clusters. It can help with a series of operations such as deployment, release and orchestration of containers, and can greatly simplify the management of containers. Operation and maintenance operations.
  • a Kubernetes cluster generally contains 1 Master node and multiple Node nodes.
  • a node can be a physical machine or a virtual machine.
  • Master is the cluster control node of k8s. In each k8s cluster, a Master is responsible for the management and control of the entire cluster. Other machines in the k8s cluster are called Node nodes.
  • the Node node is the workload node in the k8s cluster. The Node can be assigned some workload by the Master; when a Node goes down, the workload on it will be automatically transferred by the Master. Go to other Node.
  • Each Node node runs the key component kubelet.
  • Kubelet is the Master's Agent on the Node node. It works closely with the Master to manage the life cycle of the local running container. It is responsible for the creation, start and stop of the container corresponding to the Pod, and implements the basic functions of cluster management.
  • Pod is the smallest deployment unit in k8s. It is a collection of containers and the basic unit for k8s to orchestrate services and scale up and down.
  • Node nodes can be dynamically added to the k8s cluster during operation, provided that some key components including the above kubelet have been correctly installed, configured and started on this node node.
  • kubelet will register itself with the Master.
  • the kubelet will regularly report its own situation to the Master node, such as the operating system, Docker version, the CPU and memory status of the machine, and what previous The Pod is running, etc., so that the Master can learn the resource usage of each Node and implement an efficient and balanced resource scheduling strategy.
  • the Master will trigger the automatic process of "large workload transfer".
  • the Node node also has the component kube-proxy, which is used to implement the network proxy of the Pod on the Node node, realize the communication between Kubernetes Service and the outside, and can maintain network rules and four-layer load balancing work.
  • Kubernetes Service is located between kube-proxy and Pod, which defines the access entrance of a service. Access between internal Pods and containers can be performed directly through service.
  • the relationship between kube-proxy, service (i.e. Kubernetes Service) and Pod in Figure 7 is only for illustration. In fact, one service can correspond to multiple Pods, and one Pod can also correspond to multiple services. Service can be created by k8s, and the relationship between service and Pod can also be specified by k8s master (not shown in the figure).
  • docker-shim is a component of Kubernetes, its main purpose is to operate Docker through CRI (Container Runtime Interface, container runtime interface). Docker appeared in 2013, Kubernetes was released in 2014 and used Docker as the container runtime (Container Runtime) by default, and docker-shim first officially appeared in 2016. When Docker was first created, it did not consider container orchestration or Kubernetes, so Docker itself does not comply with CRI, that is, it does not comply with the container runtime interface.
  • CRI Container Runtime Interface
  • a chaincode program can be a binary file, that is, a compiled object file.
  • the operating environment refers to the dependencies required for the above-mentioned program to run.
  • containerized chain code programs run on nodes and require an adapted operating environment.
  • the blockchain receives the source code of the chain code developed by the user.
  • kubernetes and docker can be combined to compile the chain code source code and execute it, thereby achieving the advantages of lightweight, easy migration, convenient deployment, and low resource usage, and realizing functions such as automated deployment, automatic expansion and contraction, and maintenance of container clusters.
  • FIG. 9 The process of deploying traditional chaincode in Hyperledger Fabric is shown in Figure 9. It should be noted that it is assumed here that a Peer container has been deployed in a Container using kubernetes and docker technology. This Peer container is, for example, container1, in which, for example, the endorsement node is running.
  • the client initiates an installation chaincode command to the endorsement node to be deployed, and packages the created chaincode source code and endorsement policy and sends them to the node.
  • the client here refers to the blockchain client that creates the chaincode source code and sends the chaincode source code.
  • developers create the chaincode source code, they can package the chaincode source code and set the endorsement policy. Then they can send the packaged chaincode source code and the set endorsement policy through the client to the endorsement node where the chaincode is to be deployed.
  • the endorsement nodes to be deployed with chaincode generally include the endorsement nodes included in the endorsement policy.
  • the endorsement node is a Peer container as shown in the figure.
  • the endorsement node uses docker to create a temporary container, and compiles the chain code source code into a target file in the created temporary container.
  • the endorsement node can use docker (docker here mainly includes docker-shim and docker engine in the figure) to create the corresponding temporary container.
  • the corresponding temporary container contains the compilation environment of the corresponding source language.
  • the local or remote image warehouse of the endorsing node contains compilation environment images for compiling various chain code source codes, and can be pulled and used by docker. In this way, the endorsing node receives a type of source code and can use docker to create a temporary container containing the corresponding compilation environment.
  • source code edited in Go language create a temporary container suitable for the Go language compilation environment
  • source code edited in Java language create a temporary container suitable for the Java language compilation environment
  • Java language compilation environment For example, for source code edited using Node.js language, create a temporary container suitable for the Java language compilation environment.
  • source code create a temporary container suitable for the node.js language compilation environment.
  • the source code can be compiled and then the target file can be generated.
  • the source code edited in the Go language is compiled into a binary file in a temporary container
  • the Java language source code is compiled into a jar file in the temporary container
  • the node.js language source code is compiled into target code.
  • the peer container can generate a first configuration file based on the language of the chain code source code uploaded by the client, here for example dockerfile_1, the content of which describes the steps for creating a temporary container.
  • the Peer container can send the Docker build command and the dockerfile_1 to docker-shim, and then send it to docker Engine.
  • Docker Engine can pull the compilation environment image suitable for compiling chain code source code based on the (local or remote) image warehouse specified in dockerfile_1, and send the request to containerd, which then calls runC.
  • the result of executing the above command is that runC pulls up a temporary container built based on the compilation ring mirror image.
  • This temporary container is, for example, container2.
  • the chain code source code can be compiled based on the compilation ring mirror, thereby obtaining the chain code program, that is, the above target file.
  • the temporary container is activated directly by the Peer container through Docker-shim without going through k8s.
  • the temporary container places the compiled target file in a certain directory and notifies the Peer container.
  • the Peer container After receiving the notification, the Peer container uses docker to build a chain code image containing the target file.
  • the Peer container can generate a second configuration file based on the target file, here for example dockerfile_2, the content of which describes the steps to build a chain code image, and includes the image of the running environment for executing the chain code program. and the storage path of the chaincode program.
  • the Peer container can send the Docker build command and the dockerfile_2 to reach the docker Engine through the Docker-shim call.
  • Docker Engine can pull the operating environment image suitable for running the chain code program based on the (local or remote) image warehouse specified in dockerfile_2, and pull the target code from the aforementioned storage path. In this way, a new image containing the chaincode program and running environment can be regenerated and stored in the local/remote warehouse.
  • This newly generated chain code image can be run by containers on the current host or other hosts on the Fabric network, thereby achieving one-time packaging and multiple executions.
  • the host here can be a physical machine or a virtual machine, or even a container.
  • the Peer container After the Peer container receives the transaction that calls the chain code, it starts the chain code container through docker and installs and instantiates the chain code in it based on the chain code image.
  • the Peer container can initiate a Docker run command to the docker Engine through docker-shim, and the command is sent to containerd, and then containerd calls runC. In this way, runC pulls up a traditional chaincode container built based on the chaincode image.
  • This traditional chaincode container is, for example, container3.
  • the Peer container can input the parameters in the transaction to the chaincode container, and perform chaincode simulation to execute the transaction.
  • the Peer container starts the chaincode container through docker and installs and instantiates the chaincode based on the chaincode image.
  • the Peer container uses docker to build a chain code image containing the target file.
  • the Peer container can also send the Docker run command to docker Engine. This instruction is sent to containerd through docker-shim and docker Engine, and then containerd calls runC. In this way, runC pulls up a traditional chaincode container built based on the chaincode image.
  • This traditional chaincode is, for example, container3.
  • the traditional chain code container built by the chain code image can be pulled up, without having to wait for the transaction of calling the chain code to be triggered by the Peer node to pull up the traditional chain like in b5. code container.
  • the traditional chain code container is pulled up in advance.
  • the subsequent peer node After the subsequent peer node receives the transaction request to call the chain code, it can directly call the chain code for simulated execution, instead of temporarily pulling up the traditional chain code container and then calling the chain code. Carry out simulated execution. Obviously, this method can improve the execution speed of the contract.
  • docker engine in the above process is to build the image, and most communication with docker engine needs to be carried out through Docker shim.
  • docker-shim specifically docker-shim and docker Engine.
  • kubelet needs to first call Docker Engine through docker-shim, and then call containerd through Docker Engine.
  • docker-shim is a component of Kubernetes. Its main purpose is to operate Docker through CRI, specifically the above-mentioned Docker Engine. When Docker was first created, it did not consider container orchestration or Kubernetes. However, Kubernetes used Docker as its default container runtime when it was first created. The subsequent code contains a lot of Docker-related operating logic. Later, in order to be able to decouple and be compatible with more container runtimes, Kubernetes separated the entire logic related to operating Docker to form docker-shim.
  • Containerd is a product of the standardization of container technology. In order to be compatible with OCI (Open Container Organization) standards, the container runtime and its management functions are separated from Docker Daemon. containerd can provide interfaces for Docker Daemon upwards, so that Docker Daemon can shield the following structural changes and ensure downward compatibility of the original interfaces. downwards, it can be combined with runC through containerd-shim, so that the engine can be upgraded independently to avoid the previous upgrade of Docker Daemon. All containers are unavailable. runc is a command line tool that can create and run containers according to OCI standards.
  • gRPC is an RPC implementation developed by Google. It is a high-performance, open source and universal RPC framework designed for mobile and HTTP/2. It supports many common programming languages and also provides powerful streaming calling capabilities. , has become one of the most mainstream RPC frameworks.
  • the gRPC client initiates a call to the gRPC server, it needs to obtain the address, port and other information of the gRPC server.
  • the gRPC server will not actively initiate a connection to the gRPC client, but the gRPC client needs to actively initiate a connection to the gRPC server.
  • gRPC is a preferred implementation in this application. In fact, both communication clients and communication servers with similar functions can be implemented in this application. The following explanation will still take gRPC as an example.
  • the Peer container can be set as a gRPC server.
  • the address and port of the Peer container itself can be included in the instructions to create a traditional chaincode container, and can be placed in the connection.json file and sent to the traditional chaincode container.
  • the traditional chaincode container created can be set up as a gRPC client.
  • a connection can be initiated to the Peer container based on the address and port of the gRPC server in the connection.json file.
  • the traditional chaincode container can maintain a long connection after initiating a connection with the Peer container through the gRPC client.
  • the Peer container After the transaction calling the chain code is executed in the traditional chain code container, as mentioned above, the execution result, that is, the read/write set, can be returned to the gRPC server through the maintained long connection, that is, returned to the Peer container.
  • containers can be managed directly through containerd, which eliminates the need for docker-shim.
  • K8S releases CRI (Container Runtime Interface), which unifies the container runtime interface.
  • CRI Container Runtime Interface
  • Any container runtime that supports CRI can be used as the underlying container runtime of K8S.
  • Kubernetes mentioned in version 1.20 that it will no longer maintain the docker-shim shim in subsequent versions, and will begin to remove the shim as early as version 1.23. Docker-shim has been removed, thus removing support for Docker as a container runtime.
  • containerd is a project separated from Docker and can serve as an underlying container runtime in its own right. Now it has become a better choice for Kubernete container runtime. Not only Docker, but also many cloud platforms also support containerd as the underlying container runtime. In addition to containerd, there are also CRI-O and others that can be used as the underlying container runtime.
  • containerd can have a built-in CRI plug-in, so that kubelet can directly call containerd, as shown in Figure 11.
  • kubelet directly calls containerd through CRI, which can shorten the communication link, thereby improving performance, and the resource usage will become smaller after removing docker (Docker is not a pure container runtime and has a lot of other functions, so its existence consume more resources).
  • FIG. 12 A process of deploying chaincode in Hyperledger Fabric can be shown in Figure 12. It is still assumed here that a Peer container has been deployed in a Container using kubernetes and docker technology.
  • This Peer container is, for example, container1, in which an endorsement node is running. and include the following:
  • S110 The Peer container receives the command to install the traditional chain code and the chain code source code sent by the client.
  • the client can be similar to the b1 process in Figure 9, initiate the installation chain code command to the endorsement node to be deployed, and package and send the created chain code source code and endorsement policy to the node.
  • developers create the chaincode source code, they can package the chaincode source code and set the endorsement policy. Then they can send the packaged chaincode source code and the set endorsement policy through the client to the endorsement node where the chaincode is to be deployed.
  • the endorsement nodes to be deployed with chaincode generally include the endorsement nodes included in the endorsement policy.
  • the fabric can include multiple organizations, and each organization can have multiple peers.
  • each organization can have multiple peers.
  • the Peer node has been deployed in a container using kubernetes and containerd technology, which can be called a Peer container.
  • the Peer container can have a built-in cckeeper module, or the cckeeper module can be located outside the Peer container.
  • S120 The Peer container uses a third-party building module to build a chain code image based on the chain code source code.
  • the Peer container After the Peer container receives the command to install the traditional chain code and the chain code source code from the client, it can send the command to install the traditional chain code and the chain code source code to the built-in or external cckeeper module.
  • This cckeeper is a third-party building module. .
  • the cckeeper module receives the chain code source code sent from the client and can generate a third configuration file (dockerfile), which is set to dockerfile_3 here. Dockerfile_3 can include a description of creating an image and building a container.
  • Building a chaincode image includes compiling the chaincode program and adding the compiled chaincode program to a running environment to generate the image.
  • the Peer container can send the task of creating an image and building a container to the k8s Master, which can be sent by the cckeeper.
  • the Master can initiate tasks to the kubelet in a node.
  • kubelet After receiving the task, kubelet sends the command to create a container to containerd through the CRI plug-in, and then containerd calls runC, so that an image building container can be created, such as container4.
  • imgbuilder can include the Kaniko container image tool, which is a container image building tool open sourced by Google and has the functions required by the imgbuilder module.
  • imgbuilder can perform image building tasks in the created image building container.
  • imgbuilder can compile the chain code source code based on the compilation ring mirror, thereby obtaining the chain code program, which is the above target file.
  • imgbuilder can store the generated chain code program in a path and notify cckeeper.
  • the cckeeper can be notified through the Peer container, or the cckeeper can be notified directly.
  • Figure 13 shows only one method, that is, the implementation of the former.
  • the cckeeper module can generate a fourth configuration file based on the target file, here for example dockerfile_4, the content of which describes the steps to build the chain code image, and includes the image of the running environment for executing the chain code program and the chain The storage path of the code program.
  • cckeeper can send instructions to build chaincode mirrors to imgbuilder.
  • imgbuilder can pull the operating environment image suitable for running the chain code program according to the (local or remote) image warehouse specified in dockerfile_4, and pull the target code from the aforementioned storage path.
  • This newly generated chain code image can be run by containers on the current host or other hosts on the Fabric network, thereby achieving one-time packaging and multiple executions.
  • the host here can be a physical machine or a virtual machine, or even a container.
  • S130 The third-party building module starts the traditional chain code container, and loads and starts the chain code image in the traditional chain code container.
  • the chain code container can be started after cckeeper completes building the chain code, or the Peer container can trigger cckeeper to start the chain code container after receiving a transaction request to call the chain code.
  • the former is, for example, that the Peer container starts the chaincode container through cckeeper and installs and instantiates the chaincode in it based on the chaincode image. Specifically, after imgbuilder completes building the chaincode image, it can send a notification to cckeeper. After receiving the notification, cckeeper can pull up a traditional chaincode container built based on the chaincode image.
  • This traditional chaincode container is, for example, container5. That is to say, once the chain code image is built, the traditional chain code container built by the chain code image can be pulled up. In this way, the traditional chain code container is pulled up in advance.
  • the subsequent peer node After the subsequent peer node receives the transaction request to call the chain code, it can directly call the chain code for simulated execution, instead of temporarily pulling up the traditional chain code container and then calling the chain code. Carry out simulated execution. Obviously, this method can improve the execution speed of the contract.
  • the latter is, for example, that after the Peer container receives the transaction that calls the chain code, it starts the chain code container through cckeeper and installs and instantiates the chain code in it based on the chain code image. Specifically, after imgbuilder completes building the chain code image, it can send a notification to cckeeper, so that cckeeper can obtain the storage path of the chain code image.
  • the Peer container receives the transaction calling the chain code, if the traditional chain code container has not been started, the Peer container can call cckeeper, and the cckeeper will pull up a traditional chain code container based on the chain code image.
  • This traditional chain code container is, for example, It's container5.
  • the Peer container can input the parameters in the transaction to the chaincode container, and perform chaincode simulation to execute the transaction.
  • Peer container can be set up as a gRPC server.
  • the Peer container uses a third-party building module to build a chain code image based on the chain code source code, or the Peer container triggers cckeeper to start the chain code container after receiving a transaction request to call the chain code.
  • the Peer container can Send its own IP address, port and other information to cckeeper.
  • 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 above-mentioned Peer container. After the traditional chaincode container is started, you can know the IP address and port of the current gRPC server through connection.json.
  • 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.
  • the Peer container can initiate a call to the traditional chain code container through the maintained long connection, input the parameters in the transaction, and perform chain code simulation to execute the transaction.
  • the execution result that is, the read/write set
  • c1 The client sends the command to install the traditional chain code and the chain code source code to the Peer container, and the Peer container sends the chain code source code to cckeeper.
  • Peer container As mentioned before, it can be set that the Peer node has been deployed in a container using kubernetes and containerd technology, which can be called a Peer container.
  • the user After the user creates the chaincode source code, he can send the command to install the traditional chaincode and the chaincode source code to the connected Peer container through the client.
  • the Peer container can send the command to install the traditional chain code and the chain code source code sent by the client to cckeeper.
  • cckeeper can generate a third configuration file (dockerfile) based on the chain code source code, here it is set to dockerfile_3.
  • Dockerfile_3 can include a description of creating an image and building a container.
  • the cckeeper module can be built into the Peer container, or the cckeeper module can be set outside the Peer container. The following takes the latter as an example. The situation when the cckeeper module is built into the Peer container is similar.
  • c2 cckeeper uses a created image to build a container, and compiles the chain code source code into a target file.
  • cckeeper can send the task of creating an image and building a container to the k8s Master.
  • the Master can initiate tasks to the kubelet in a node.
  • kubelet After receiving the task, kubelet sends the command to create a container to containerd through the CRI plug-in, and then containerd calls runC, so that an image building container can be created, such as container4.
  • imgbuilder can include the Kaniko container image tool, which is a container image building tool open sourced by Google and has the functions required by the imgbuilder module.
  • imgbuilder can perform image building tasks in the created image building container.
  • imgbuilder can compile the chain code source code based on the compilation ring mirror, thereby obtaining the chain code program, which is the above target file.
  • imgbuilder can store the generated chain code program in a path and notify cckeeper.
  • kubelet can communicate with containerd through CRI, and then send related commands to build the image to containerd.
  • the link is streamlined while keeping the image link open, improving performance and reducing resource usage as mentioned above.
  • c3 The image building container places the compiled target file in a certain directory and notifies the Peer container/cckeeper.
  • c4 uses imgbuilder to build a chaincode image containing the target file and stores it in the image warehouse.
  • cckeeper can receive notifications in c3. After that, cckeeper can generate a fourth configuration file based on the target file, here for example dockerfile_4, the content of which describes the steps to build the chain code image, and includes the image of the running environment for executing the chain code program and the storage of the chain code program. path.
  • cckeeper can send instructions to build chaincode mirrors to imgbuilder.
  • imgbuilder can pull the operating environment image suitable for running the chain code program according to the (local or remote) image warehouse specified in dockerfile_4, and pull the target code from the aforementioned storage path.
  • This newly generated chain code image can be run by containers on the current host or other hosts on the Fabric network, thereby achieving one-time packaging and multiple executions.
  • the host here can be a physical machine or a virtual machine, or even a container.
  • imgbuilder After imgbuilder completes the construction of the chain code image, it can send a notification to cckeeper, and cckeeper can notify the Peer container.
  • c5 creates a traditional chaincode container, and loads and starts the chaincode image in the traditional chaincode container.
  • Peer container can be set up as a gRPC server.
  • cckeeper can create chaincode containers using CRI-compliant container runtimes. Specifically, cckeeper can send a command to create a chaincode container to the Master, and the Master will notify the kubelet in the Node of the command. The kubelet can further use containerd containing the CRI plug-in to create a container. In this process, cckeeper can send the IP address, port and other information of the Peer container to the traditional chain code container through the connection.json file.
  • the chaincode image can be run. Through a series of instructions, the built chaincode image can be pulled from the image warehouse and run in a container of the Pod, thereby generating a chaincode container. Through connection.json, you can know the IP address and port of the current gRPC server. Furthermore, 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. Furthermore, after receiving the transaction request for calling the chain code, the Peer container can initiate a call to the traditional chain code container through the maintained long connection, input the parameters in the transaction, and perform chain code simulation to execute the transaction. After the transaction calling the chain code is executed in the traditional chain code container, the execution result, that is, the read/write set, can also be returned to the gRPC server through the maintained long connection, that is, returned to the Peer container.
  • Peer container is used to receive the command to install traditional chain code and the chain code source code sent by the client, and also uses a third-party building module to build a chain code image based on the chain code source code;
  • the third-party building module is used to start a traditional chain code container, and load and start the chain code image in the traditional chain code container;
  • the Peer container uses a third-party building module to construct a chaincode image based on the chaincode source code, wherein the third-party building module calls a container image construction tool to build a chaincode image based on the chaincode source code and an adapted operating environment.
  • the third-party building module calls the container image construction tool to build the chain code image based on the chain code source code and the adapted operating environment, including:
  • the third-party building module calls the container image building tool, which compiles the chain code source code sent by the client to obtain the chain code program;
  • the third-party building module calls the container image building tool to add the chain code program to the adapted operating environment and generate a chain code image.
  • the third-party building module calls the container image construction tool, and the chain code source code sent by the client is compiled to obtain the chain code program, including:
  • the third-party building module generates a third configuration file based on the chain code source code and sends it to the container image building tool, and creates an image to build the container;
  • the container image building tool pulls the compilation environment image according to the third configuration file, and performs the image building task in the image building container to obtain the compiled chain code program.
  • the third-party building module calls the container image construction tool, adds the chain code program to the adapted running environment and generates the chain code image, including:
  • the third-party building module generates the fourth configuration file based on the generated chain code program
  • the third-party building module calls the container image building tool and sends the fourth configuration file to the container image building tool;
  • the container image building tool pulls the running environment image according to the fourth configuration file, and generates a chain code image including the chain code program and the running environment.
  • the third-party building module starts the traditional chain code container, and loads and starts the chain code image in the traditional chain code container, including:
  • the chain code container is started, and the chain code image is loaded and started in the traditional chain code container; or,
  • the peer container After receiving the transaction request for calling the chain code, the peer container triggers the third-party building module to start the chain code container, and loads and starts the chain code image in the traditional chain code container.
  • the Peer container is set as a gRPC server
  • the started traditional chain code container is set as a gRPC client
  • a long connection is maintained between the Peer container and the traditional chain code container.
  • the third-party building module is installed inside the Peer container or outside the Peer container.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • the controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor. , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers and embedded microcontrollers.
  • controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, For Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic.
  • the controller in addition to implementing the controller in the form of pure computer-readable program code, the controller can be completely programmed with logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded logic by logically programming the method steps. Microcontroller, etc. to achieve the same function. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as structures within hardware components as well as software modules implementing the methods.
  • the systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions.
  • a typical implementation device is a server system.
  • the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, or a personal digital assistant. , media player, navigation device, email device, game console, tablet, wearable device, or a combination of any of these devices.
  • the functions are divided into various modules and described separately.
  • the functions of each module can be implemented in the same or multiple software and/or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. .
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented.
  • the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.
  • These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions
  • the device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.
  • These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device.
  • Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information.
  • Information may be computer-readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and read-only memory.
  • PRAM phase change memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • RAM random access memory
  • read-only memory read-only memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • flash memory or other memory technology
  • compact disc read-only memory CD-ROM
  • DVD digital versatile disc
  • Magnetic tape magnetic tape storage, graphene storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device.
  • computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. Product form.
  • computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, etc.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • program modules may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network.
  • program modules may be located in both local and remote computer storage media including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种联盟链中部署链码的方法和系统，所述方法包括：Peer容器接收客户端发来的安装传统链码的命令和链码源码；所述Peer容器采用第三方构建模块基于所述链码源码构建链码镜像；所述第三方构建模块启动传统链码容器，并在所述传统链码容器中载入并启动所述链码镜像。通过上述过程，使得开发者在开发链码源码时还是按照传统链码的方式编写而无需做出改变，这样给链码开发者没有增加额外的开发成本。同时，通过由第三方构建模块构建链码镜像，摆脱了对Docker的依赖。

Description

联盟链中部署链码的方法和系统
本申请要求于2022年03月30日提交中国国家知识产权局、申请号为202210325838.2、申请名称为“联盟链中部署链码的方法和系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本说明书实施例属于区块链技术领域，尤其涉及一种联盟链中部署链码的方法和系统。
背景技术
区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链系统中按照时间顺序将数据区块以顺序相连的方式组合成链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。由于区块链具有去中心化、信息不可篡改、自治性等特性，区块链也受到人们越来越多的重视和应用。
发明内容
本发明的目的在于提供一种联盟链中部署链码的方法和系统，包括：
一种联盟链中部署链码的方法，包括：
Peer容器接收客户端发来的安装传统链码的命令和链码源码；
所述Peer容器采用第三方构建模块基于所述链码源码构建链码镜像；
所述第三方构建模块启动传统链码容器，并在所述传统链码容器中载入并启动所述链码镜像。
一种联盟链中部署链码的系统，包括：
Peer容器，用于接收客户端发来的安装传统链码的命令和链码源码，还采用第三方构建模块基于所述链码源码构建链码镜像；
所述第三方构建模块，用于启动传统链码容器，并在所述传统链码容器中载入并启动所述链码镜像；
传统链码容器，用于运行链码。
上述实施例中，使得开发者在开发链码源码时还是按照传统链码的方式编写而无需做出改变，这样给链码开发者没有增加额外的开发成本。同时，通过由第三方构建模块构建链码镜像，摆脱了对Docker的依赖。
附图说明
为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本公开的一些实施例中Hyperledger Fabric的架构图；
图2为本公开的一些实施例中Hyperledger Fabric的交易流程示意图；
图3为本公开的一些实施例中Hyperledger Fabric的账本结构；
图4为本公开的一些实施例中区块和交易的结构；
图5为本公开的一些实施例中Docker的基本原理示意图；
图6为本公开的一些实施例中Docker的运行逻辑示意图；
图7为本公开的一些实施例中Kubernetes的基本原理示意图；
图8为本公开中包含Docker的通信和命令链路示意图；
图9为本公开中部署传统链码容器的示意图；
图10为本公开中部署传统链码容器的示意图；
图11为本公开中去除Docker后的通信和命令链路示意图；
图12为本公开中去除Docker后的部署传统链码容器的流程图；
图13为本公开中去除Docker后的部署传统链码容器的示意图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。
区块链通常可以分为三种类型：公有链(Publick Blockchain)、私有链(Private Blockchain)和联盟链(Consortium Blockchain)。此外，还有多种类型的结合，比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表，加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等。而且，各参与者(即节点)可自由加入以及退出网络，并进行相关操作。私有链则相反，该网络的写入权限由某个组织或者机构控制，数据读取权限受组织规定。简单来说，私有链可以为一个弱中心化系统，参与节点具有严格限制且少。这种类型的区块链更适合于特定机构内部使用。联盟链则是介于公有链以及私有链之间的区块链，可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织；参与者通过授权加入网络并组成利益相关联盟，共同维护区块链运行。
HyperLedger Fabric是一种开源的联盟链实现。与比特币和以太坊这类公有链不同，Hyperledger Fabric网络中的节点一般需要经过授权认证后才能加入，从而避免了POW(Proof of Work，工作量证明)的资源开销，大幅提高了交易处理效率，满足企业级应用对处理性能的诉求，而且系统的运行可以不需要token(通证)的支持。
图1为一个典型的Hyperledger Fabric 1.4和2.0的架构图。通常多个组织作为一个联盟聚集在一起形成区块链网络。换句话说，组织是区块链系统的参与方。Fabric中的组织在现实世界中可以是一个公司、一个企业，或者一个协会。如图1所示，包括组织1、组织2和组织3。每个组织都可以有自己对应的Fabric-CA(Certification Authority，证书颁发)服务器。组织可以具有多个Peer节点。组织的Fabric-CA可以给组织内的Peer节点颁发证书，颁发的证书可以用来标识节点及其所述的组织。
区块链网络中组织的节点称为Peer。其中，Peer节点上可以保存账本ledger。 具体的，Peer节点可以包括背书节点(Endorsing Peer)、记账节点(Committing Peer)、主节点(Leader Peer)和锚节点(Anchor Peer)。一个组织可以选择哪个节点安装链码，以实现联盟成员共享的业务流程，而不需要在每个节点上都安装链码。一般的，背书节点上可以安装链码。背书节点上安装链码之后，经过实例化，具有协作关系的组织之间(也称为通道，channel)的其它节点才能知道链码，才可以由应用发起调用。实例化时提供的最重要的附加信息是背书策略，它描述了哪些组织必须批准交易，然后才会被接受到他们的账本上。实际上，链码中可以定义一个或多个的智能合约(Smart Contract)。每个智能合约在链码中有一个唯一的标识。应用可以通过智能合约的标识去访问链码容器内指定的智能合约。peer节点还可以是主节点，一个组织中一般只有一个主节点。主节点可以与排序服务通信，从而从排序服务获取最新的区块并在组织内的节点间同步。Peer节点还可以是锚节点。锚节点可以代表组织与其他组织进行信息交换。一般每个组织都有一个锚节点。所有的peer节点都可以是记账节点，记账节点用于验证排序服务节点区块里的交易，维护世界状态和账本的副本。记账节点可以从orderer节点获取包含交易的区块，在对这些区块进行验证之后加入到区块链中。需要说明的是，“节点”是一个逻辑实体，不同类型的多个节点可以运行在同一个物理实体上。
应用(Application，简写为App)可以通过内置的SDK(软件开发工具)及API(Application Programming Interface，应用编程接口)连接到区块链节点上。App随后可以生成调用链码的交易提案，并向区块链网络提交该交易提案。如前所述，一旦在Peer节点上安装了链码并完成实例化，链码内的智能合约对于相关联的通道来说就变得可用，也就是说应用就可以调用链码了。应用通过向背书策略指定的组织所属的节点发送交易提案来实现调用链码。交易提案作为智能合约的输入，背书节点上的智能合约模拟执行后生成一个经过背书的交易响应。区块链网络最终可以将这些交易排序并生成区块后提交到分布式账本上，具体的，可以由排序服务完成对交易的排序并生成区块。当这一过程完成时，App可以接收到对应的事件。
在一个常用于测试的简单模式中，排序服务在网络中是一个独立的节点，即由一个排序节点构成排序服务。很多时候，排序服务可以包括多个节点，并且可以配置为不同的组织中拥有不同的排序节点。
具体，结合图1所示的Hyperledger Fabric的架构，一个典型的交易的过程如下：
a1：应用发送交易提案(proposal)至背书节点。
账户登陆应用后，例如采用账户A登陆应用后，可以使用应用中的SDK生成一笔交易。SDK的作用包括将交易提案打包成合适的格式(例如gRPC中使用的protocol buffer)以及根据用户的密钥对交易提案生成签名。这个生成的交易可以包含<clientID,chaincodeID,txPayLoad,timestamp,clientSig>等信息。其中，clientID表示登陆客户端的账户ID,chaincodeID表示调用的链码的ID,txPayLoad表示交易净荷,timestamp表示交易发起的时间戳,clientSig为客户端账户的签名。
应用可以按照背书策略(Endorse Policy)将交易发送至一个或多个背书节点。背书策略一般包括and、or、majority of等关系组织而成的节点，可以在链码中 指定。and{背书节点1，背书节点2，背书节点3}可以表示需要由背书节点1，背书节点2，背书节点3均对该交易背书。or{背书节点1，背书节点2，背书节点3}可以表示由背书节点1，背书节点2，背书节点3中的任一个进行背书。majority of{背书节点1，背书节点2，背书节点3}可以表示需要由背书节点1，背书节点2，背书节点3中的至少一半以上的节点该交易背书，这里即为3个背书节点中的至少2个。
如图2中所示，以and{背书节点1，背书节点2，背书节点3}作为背书策略为例，所述应用将所述交易分别发送至背书节点1，背书节点2，背书节点3。
a2：所述背书节点对收到的交易提案进行验证后，模拟执行所述交易并背书，并返回提案响应(proposal response)至所述应用。
背书节点对交易内容进行验证后，可以模拟执行所述交易中的合约。背书节点对交易的验证，可以包括用账户A的公钥对所述交易签名进行验证，该交易之前没有被提交过(重放攻击保护)，交易发起者是通道上的合格发起者等。通过验证后，按照上述的例子，背书节点进一步可以模拟执行发来的交易。在模拟执行的过程中，背书节点可以调用所述交易中指明的链码(具体是指明链码中的智能合约)，并输入所述交易中的所述参数，进而模拟执行。
交易的执行结果，一般包括产生的读集(Read Set，Rset或RS)和/或写集(Write Set，Wset或WS)(RS和WS可以统称为读写集，或写为RWset)。这些读写集最终可以写入Peer节点本地维护的区块链账本中。读集和写集，一般会采用Key-Value的表达形式。此外，读写集中一般还会带入版本(Version)信息，表示读写集中的操作产生时所针对的版本。
对交易经过模拟执行并产生读写集之后，背书节点可以对产生的读写集背书。具体的，可以是背书节点根据背书策略用自身私钥对读写集进行签名。
延续前述例子，以and{背书节点1，背书节点2，背书节点3}作为背书策略的情况下，所述应背书节点1，背书节点2，背书节点3分别对所述交易进行模拟执行和背书，并分别发送背书结果至所述应用。这种背书策略下，不同背书节点对同一交易的背书结果一般仅是签名不同，否则不符合所述背书策略。
a3：所述应用收集背书节点的返回的提案响应。
所述应用可以收集背书节点返回的提案响应。如图2中所示，以and{背书节点1，背书节点2，背书节点3}作为背书策略为例，所述应用可以收集背书节点1，背书节点2，背书节点3返回的提案响应。具体的，所述应用中的SDK可以用于解析返回的提案响应。具体的，SDK可以验证提案响应中背书节点的签名，并比较各背书节点返回的提案响应，判断各提案响应是否一致(正常情况下应当是仅签名不一致)以及是否按照指定的背书策略执行。
a4：所述应用将所述背书的交易发送至排序节点。
当所述应用收集到足够多背书节点返回的一致的提案响应后，例如收集齐背书节点1，背书节点2，背书节点3返回的提案响应后，所述应用可以调用SDK将所述背书的交易发送至排序节点。其中背书的交易可以包括交易提案、读/写集和背书签名在内的打包结果。
a5：所述排序服务对这些交易排序，并基于排序后的结果生成区块。
排序服务可以持续的收集背书的交易，例如包括不同应用或者同一应用发来的至少一个经过背书的交易。具体的，排序服务中的排序节点在收集一定量的 背书交易后，可以对这些交易排序。具体的，例如可以是按照交易的时间戳对交易排序。排序节点进而可以将排序后的交易打包成区块。
a6：所述排序服务将生成的所述区块广播至主节点，并由主节点同步至所属组织内其它Peer节点。
不同组织组成的Hyperledger Fabric网络中，每个组织的一个或多个Peer节点中都存在一个主节点。主节点能与排序节点通信，从而从排序节点获取最新的区块并在组织内的Peer节点中同步。
a7：记账节点对所述区块进行验证后将所述区块追加至本地账本的区块链中，并基于所述区块更新本地账本中的世界状态。
所有Peer节点可以是记账节点。记账节点可以在本地维护账本。所述账本可以包括区块链数据和世界状态数据，如图3所示。
区块链包括一系列前后链接的区块。每个区块包括了区块头、区块数据和区块元数据三部分内容。
区块头包含区块编号(图3中的N0、N1、N2、N3...)，每个区块的区块编号都是唯一的，且一般是单调递增的。区块编号可以由排序服务在打包生成区块的过程中生成。区块头还可以包含当前区块的区块数据的哈希值(图3中的CH，Current Block Hash)，以及前一个区块头的哈希值(图3中的PH0、PH1、PH2等，PH为Previous Block Hash的缩写，也是前一区块的区块hash)。这样，区块链中的所有区块都被按序排列，并以密码学的方式连接在一起。这种哈希和链接使区块链账本数据变得非常安全。即使某个保存区块链账本的节点被篡改了数据，通过区块的Hash值，其它节点可以快速的确认被篡改的区块链账本。例如图3中的区块2，其区块头2中，包括区块号N2，当前区块的区块数据2的hash值，前一区块1的区块头1的hash值。
区块数据包含了一个有序的交易列表。交易列表中的每个交易代表了一个对世界状态的查询或更新操作。如前所述，区块数据可以是在排序服务打包生成区块时写入到区块数据中。如图4所示，区块数据内可以包括一系列交易。这些交易可以是按照交易的时间进行排序的。每个交易可以包括交易头，交易签名，交易提案，交易响应，交易背书。
●交易头记录了关于交易的一些重要元数据，例如相关链码的名字以及版本。
●交易签名包含一个由客户端应用程序创建的签名，该字段可以用于判断交易是否被篡改。
●交易提案包括经编码的应用程序提供给智能合约的输入参数。智能合约运行时，这个提案提供的输入参数和当前的世界状态一起决定新的世界状态。
●交易响应以读写集的形式记录下世界状态之前和之后的值。
●交易响应是智能合约的输出，如果交易验证成功，那么该交易会被应用到账本上，从而更新世界状态。
●交易背书是一组签名的交易响应，这些签名来自背书策略规定的相关组织，并且这些组织的数量必须满足背书策略的要求。
区块元数据包含区块被写入的时间，还有区块写入者的证书、公钥以及签名。随后，区块的提交者也会为每一笔交易添加一个有效或无效的标记，但由于这一信息与区块同时产生，所以它不会被包含在区块头的当前区块哈希中。
需要说明的是，创始块(即图3中的区块0)一般不包含任何用户交易，而只包含一些配置交易。配置交易可以用来初始化世界状态。
世界状态是一个数据库，其存储了一组账本状态的当前值。通过世界状态可以访问一个账本状态的当前值，而不需要遍历整个交易日志来计算当前值。
世界状态的一个示例，记录的是两辆车CAR1和CAR2的信息，例如分别用两个状态来记录。
第一个状态的k1-v1是：
{key＝CAR1,value＝Audi}version＝0
第二个状态中有一个更复杂的value值：
{key＝CAR2,value＝{model:BMW,color:red,owner:Jane}}version＝0
整体上，第二个状态是一个key-value对(简写为k-v对)，其中，value2中包含的也是k-v对，且上述示例中包含了三个不同的k-v对，这里设为v2中的三个k-v对分别为k21＝model:v21＝BMW，k22＝color:v22＝red，k23＝owner:v23＝Jane。
两个状态的版本都是0，这也是每个状态的起始版本。每当状态更新时版本号可以递增。状态更新时会首先检查版本号version，以确保当前状态的版本与背书时的版本一致(避免并发更新)。
应用程序可以调用(invoke)智能合约来最终实现对世界状态进行put和delete等操作。一个例子中，应用1按照背书策略向组织1内的背书节点1、组织2内的背书节点2和组织3内的背书节点3发起了一笔交易T8，背书策略例如是“and{背书节点1，背书节点2，背书节点3}”。类似的，应用2也按照背书策略向组织1内的背书节点1、组织2内的背书节点2和组织3内的背书节点3发起了一笔交易T9，背书策略例如也是“and{背书节点1，背书节点2，背书节点3}”。
T8交易例如是：
<clientID＝应用1,
chaincodeID＝ID1,
txPayLoad＝[Method1(k1)],
timestamp,
clientSig>
该T8交易调用编号为ID1的链码，例如是调用其中的方法Method1，并输入参数k1。该Method1例如是读取输入的参数所对应的value，即读取车辆的品牌。
T9交易例如是：
<clientID＝应用1,
chaincodeID＝ID1,
txPayLoad＝[Method2(k23，"Paul")]
timestamp,
clientSig>
该T9交易调用编号为ID1的链码，例如是调用其中的方法Method2，并输入参数k23。该Method2例如是修改车辆所属人的名字，一般是车辆发生转让的 情形。
T8、T9两个交易由各背书节点验证、模拟执行和背书后，各背书节点分别返回提案响应所述应用1和应用2。背书节点对交易内容进行模拟执行，例如对于T8、T9分别产生读写集如下：
T8：Read<k1>version＝0
T9：Write<k23,Paul>version＝0
其中的version＝0表示产生的操作所针对的状态版本。
背书节点可以对产生的读写集背书后分别返回提案响应所述应用1和应用2。例如对于T8交易，背书节点1、背书节点2、背书节点3分别对所述交易进行模拟执行和背书，并分别发送背书结果至所述应用1。对于T9交易，类似的，背书节点1、背书节点2、背书节点3分别对所述交易进行模拟执行和背书，并分别发送背书结果至所述应用2。
应用1和应用2各自分别收集齐背书节点返回的提案响应后，可以将所述背书的交易发送至排序节点。其中背书的交易可以包括交易提案、读/写集和背书签名在内的打包结果。由所述排序服务对交易T8、T9排序，例如根据交易的时间戳，T8在前T9在后，则对T8、T9排序后的结果生成区块3。后续，排序服务可以将生成的区块3广播至组织1、组织2和组织3中的各个主节点，并由主节点同步至所属组织内其它Peer节点。各个记账节点对所述区块进行验证后将所述区块追加至本地账本的区块链中，并基于所述区块更新本地账本中的世界状态。这时，区块3中的交易所影响的状态例如如下：
k1-v1：
{key＝CAR1,value＝Audi}version＝1
k2-v2：
{key＝CAR2,value＝{model:BMW,color:red,owner:Paul}}version＝1
上述背书节点对交易内容进行模拟执行，包括对调用链码的交易进行模拟执行，可以采用容器技术，即前述提到的链码容器。链码容器是指链码所运行的独立于背书节点进程的容器环境(Docker)中，其作用是提供链码运行的隔离沙盒环境。容器是轻量级应用代码包，它还包含程序运行所需的依赖项，例如编程语言运行时的特定版本和运行软件服务所需的库。这样，智能合约的执行可以被隔离，也就不会因为错误或恶意代码而导致背书节点进程崩溃。在实例化链代码时，背书节点使用链码填充容器映像，并调用Docker管理API来部署该映像。如果容器未运行，可以启动一个新容器。一旦运行，背书节点接收的提议都将被传输到该容器中以执行。
前述提到，链码的执行需要安装链码，即背书节点上安装链码之后，经过实例化后才可以由应用发起调用。区块链上链码的部署包括对传统链码的部署和对外部链码的部署。外部链码可以在例如区块链的外部的节点上部署与执行，以方便用户独立管理每个外部节点及其代码的运行环境。传统链码是区别于外部链码而言的，传统链码由区块链内部的节点部署与执行。
前述提到的容器技术，属于虚拟机化技术的一种。虚拟化技术实际上包括硬件虚拟化和容器技术。虚拟机使用的是硬件虚拟化技术。虚拟机需要虚拟硬件 后安装完整的操作系统，进而才能安装/运行应用。如果每次发布应用，都采用虚拟机虚拟化出一个完整的操作系统，并设置好完整的依赖环境，将是比较繁琐的工作。容器技术相对而言更加轻量。容器中可以去除操作系统，而是包含应用程序和运行应用程序所依赖的系统环境。通过容器技术，可以把应用和依赖的环境打包，该打包的内容移植到其它相同操作系统的主机上仍然能正常运行。可见容器虚拟化技术的优势在于更加轻量化、容易迁移、部署方便、资源占用少等。此外，容器能够实现标准化。主流的一种容器技术是docker，此外还有诸如Rocket、rkt和kata等。
Docker的核心概念包括：镜像(Image)、容器(Container)、仓库(Registry)。
Docker的整个运行逻辑如图5所示。Docker Client(客户端)将需要执行的Docker命令发送给Docker运行的主机(Docker Host)上的Docker Daemon(守护进程，也称为Docker Engine)，Docker Daemon将该请求分解执行。例如：
执行Docker build命令，会根据Dockerfile构建一个镜像存放于本地；
执行Docker pull命令，会从远端的容器镜像仓库拉取镜像到本地；
执行Docker run命令，会将容器镜像拉取并运行成为容器实例。
镜像构建，包括将需要进行安装的依赖和目标文件根据Dockerfile进行编写，并叠加进一个已有的基础镜像，生成新的镜像。容器运行时，会在容器镜像的上层生成一个Container层，这个层是将这个完整的容器镜像的副本加载并中运行。加载进内存中的这个副本对于容器来说是可以进行修改的，但是仅限于运行在内存中；对Container层的任何修改都不会对底层镜像生效，当容器消亡时所做的修改也一并消亡。Dockerfile是上述执行docker build命令构建docker镜像时用到的一种的配置文件，它允许通过基本的语法来定义docker镜像，其中的每一条指令可以描述一个构建镜像的步骤。例如：
在Dockerfile中常用的命令包括以下几个：
·FROM：基于什么镜像构建
·WORKDIR：容器的工作目录
·RUN：执行容器构建过程中的命令
·CMD&ENTRYPOINT：执行容器启动后的命令
·ADD&COPY：添加指定的文件到容器镜像中
·ENV：设置环境变量
·EXPOSE：设置容器暴露的端口
具体的，如图6所示，Docker客户端将需要创建的请求发送给Docker Engine，如前所述Docker Engine是容器化的守护进程。Docker Engine可以将请求发送给containerd，并由containerd调用runC。containerd用于管理容器的生命周期，通过调用runC的API来实现对容器生命周期的管理。runC直接与容器所依赖的文件(如cgroup/linux kernel等)进行交互，负责为容器配置cgroup/namespace等启动容器所需的环境，创建启动容器的相关进程。图6中多了一个containerd-shim层(也称为垫片载体，类似于适配层)，该container-shim的作用是将containerd和真实的容器(里的进程)解耦，允许runC在创建/运行容器之后退出。当containerd宕机时，containerd-shim能够保持，因此可以保证容器打开的文件描述符不会被关掉(从而可以对Dockerd进行升级而服务不受影响)。依靠containerd-shim来收集/报告容器的退出状态，这样就不需要containerd来 监视创建的子进程。例如，一个fabric的peer节点可以最终运行于图6最左侧的容器进程中，这个容器也可以称为Peer容器。
当容器实例越来越多的时候，容器管理的复杂性陡升。这时，kubernetes(简称为k8s)就派上了用场。k8s是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能，能帮助对容器进行部署、发布、编排等一系列操作，可以极大的简化容器的管理运维操作。
在Kubernetes中，可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。Kubernetes集群架构以及相关的核心组件如图7所示：一个Kubernetes集群一般包含1个Master节点和多个Node节点，一个节点可以是一台物理机或虚拟机。Master是k8s的集群控制节点，每个k8s集群里由一个Master来负责整个集群的管理和控制。k8s集群中的其它机器被称为Node节点，Node节点是k8s集群中的工作负载节点，Node可以被Master分配一些工作负载；当某个Node宕机时，其上的工作负载会被Master自动转移到其它Node上去。
每个Node节点上都运行着kubelet这一关键组件。kubelet是Master在Node节点上的Agent(代理)，与Master密切协作，管理本机运行容器的生命周期，负责Pod对应的容器的创建、启停等任务，实现集群管理的基本功能。Pod是k8s中最小的部署单元，是一组容器的集合，也是k8s进行服务编排和缩扩容的基本单位。
Node节点可以在运行期间动态增加到k8s集群中，前提是这个node节点上已经正确安装、配置和启动了包括上述kubelet在内的一些关键组件。在默认情况下，kubelet会向Master注册自己，一旦Node被纳入集群管理范围，kubelet就会定时向Master节点汇报自身的情况，例如操作系统、Docker版本、机器的CPU和内存情况，以及之前有哪些Pod在运行等，这样Master可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略。而某个Node超过指定时间不上报信息时，会被Master判定为“失联”，Node的状态被标记为不可用(Not Ready)，随后Master会触发“工作负载大转移”的自动流程。
此外，Node节点还具有组件kube-proxy，用于在Node节点上实现Pod的网络代理，实现Kubernetes Service与外部的通信，并可以维护网络规则和四层负载均衡工作。Kubernetes Service位于kube-proxy和Pod之间，其定义了一个服务的访问出入口。对于内部Pod、container之间的访问可以直接通过service进行。图7中的kube-proxy，service(即Kubernetes Service)和Pod之间的关系仅作为示意。实际上，一个service可以对应多个Pod，一个Pod也可以对应多个services。service可以由k8s创建，service与Pod的关系也可以由k8s master中指定(图中未示出)。
使用Docker作为K8S容器运行时的话，kubelet需要先要通过docker-shim去调用Docker Engine，再通过Docker Engine调用containerd。docker-shim是Kubernetes的一个组件，主要目的是为了通过CRI(Container Runtime Interface，容器运行时接口)操作Docker。Docker在2013年就出现了，2014年Kubernetes发布并默认使用Docker作为容器运行时(Container Runtime)，而docker-shim首次正式出现是在2016年。Docker在创建之初并没有考虑到容器编排或者是考 虑Kubernetes，因此Docker本身并不符合CRI，即不符合容器运行时接口。因此，Kubernetes在创建之初便采用Docker作为它的默认容器运行时，后续代码当中包含了很多对Docker相关的操作逻辑。后期，Kubernetes为了能够做解耦，兼容更多的容器运行时，将操作Docker相关逻辑整体独立起来组成了docker-shim。整体上，使用Docker作为K8S容器运行时的架构可以如图7所示，该图中在每个node最左侧的pod中示意了kubelet与Pod中的多个Container命令关系，而对其它pod中的Container做了省略。其中，通信和命令关系可以如图8所示，如果使用Docker作为K8S的容器运行时，kubelet需要先要通过docker-shim去调用Docker，再通过Docker去调用containerd。
现有的Fabric的Peer节点大多通过kubernetes部署。如图6左下方左侧的容器进程中显示，该容器进程实际上可以运行一个Peer节点，这个容器进程也可以称为Peer容器。利用容器技术运行链码，最终期望在如图6所示的中间的容器进程中运行链码。
利用容器技术运行链码，需要在容器中生成链码程序和该连码程序执行所需的运行环境。链码程序可以是一种二进制文件，即经过编译后得到的目标文件。运行环境即上述所说程序运行所需的依赖项等。传统链码中，节点上运行容器化的链码程序，需要与之适配的运行环境。为了降低用户的负担，让用户只需关注在高级语言层面开发链码的源码，而不用关注其在不同区块链节点上运行环境的差异，区块链接收到用户开发的链码的源代码后，可以结合kubernetes和docker来编译链码源代码并执行，从而实现轻量化、容易迁移、部署方便、资源占用少等优势，并实现容器集群的自动化部署、自动扩缩容、维护等功能。
一种Hyperledger Fabric中部署传统链码的过程如图9中示意。需要说明的是，这里设定在采用kubernetes和docker技术的一个Container中已经部署了Peer容器，这个Peer容器例如是container1，其中例如运行了背书节点。
b1：客户端发起安装链码命令至要部署的背书节点，并将创建的链码源码及背书策略打包发送至所述节点。
这里的客户端，指创建链码源码发送该链码源码的区块链客户端。开发人员创建链码源码后，可以打包链码源码并设定背书策略，之后可以将打包的链码源码和设定的背书策略通过客户端发送至要部署链码的背书节点。要部署链码的背书节点一般包括背书策略中所包含的背书节点。背书节点如图中所示为Peer容器。
b2：背书节点采用docker创建临时容器，并在创建的临时容器中将链码源码的编译为目标文件。
根据客户端发送的链码源码的类型，背书节点可以采用docker(这里的docker主要包括图中的docker-shim和docker engine)创建相应的临时容器。对应的临时容器中包含对应源码语言的编译环境。背书节点本地或远程的镜像仓库中包含了编译多种链码源码的编译环境镜像，并可以由docker拉取和使用。这样，背书节点接收到一种类型的源码，可以采用docker创建包含对应编译环境的临时容器。例如，对于采用go语言编辑的源码，则创建适于go语言编译环境的临时容器；对于采用java语言编辑的源码，则创建适于java语言编译环境的临时容器；对于采用node.js语言编辑的源码，则创建适于node.js语言编译环境的临时容器。
在创建的临时容器中，可以对源码进行编译，进而生成目标文件。类似的，对于go语言编辑的源码在临时容器中编译为binary文件，对于java语言源码在临时容器中编译为jar文件，对于node.js语言源码编译为目标代码。
具体的，创建临时容器的过程中，Peer容器可以根据客户端上传的链码源码的语言来生成一个第一配置文件，这里例如为dockerfile_1，其中的内容描述了创建临时容器的步骤。Peer容器可以发送Docker build命令及该dockerfile_1至docker-shim，进而发送至docker Engine。docker Engine可以根据dockerfile_1中指定的(本地或远程的)镜像仓库拉取适合编译链码源码的编译环境镜像，并将请求发送给containerd，再由containerd调用runC。执行上述指令的结果，是由runC拉起一个基于该编译环镜镜像构建的临时容器，这个临时容器例如是container2。
在该临时容器中，基于该编译环镜可以对所述链码源码进行编译，从而得到链码程序，也就是上面的目标文件。
需要说明的是，该临时容器由Peer容器直接通过Docker-shim激活，而不需要经过k8s。
b3：临时容器将编译完的目标文件放至某个目录下，并通知Peer容器。
b4：Peer容器接收到通知后，采用docker构建包含所述目标文件的链码镜像。
具体的，Peer容器接收到通知后，可以根据目标文件生成一个第二配置文件，这里例如为dockerfile_2，其中的内容描述了构建链码镜像的步骤，并包括执行这个链码程序的运行环境的镜像和该链码程序的存储路径。Peer容器可以发送Docker build命令和该dockerfile_2，通过Docker-shim调用到达docker Engine。docker Engine可以根据dockerfile_2中指定的(本地或远程的)镜像仓库拉取适合运行链码程序的运行环境镜像，并从前述存储路径拉取所述目标代码。这样可以重新生成一个新的包含该链码程序和运行环境的镜像，存放在本地/远程的仓库中。这个新生成的链码镜像，可以由该Fabric网络上的当前宿主机或其它宿主机上的容器运行，从而实现一次打包、多处执行。这里的宿主机可以是物理机或虚拟机，甚至也可以是一个容器。
b5：Peer容器接收到调用所述链码的交易后，通过docker启动链码容器并在其中基于所述链码镜像安装和实例化所述链码。
后续，Peer容器接收到调用链码的交易后，如果传统链码容器并没有启动，则Peer容器可以通过docker-shim向docker Engine发起Docker run指令，该指令发送给containerd，进而由containerd调用runC。这样，由runC拉起一个基于该链码镜像构建的传统链码容器，这个传统链码容器例如是container3。
进而，Peer容器可以向链码容器输入所述交易中的所述参数，进行链码模拟执行该交易。
此外，也可以b3之后，还可以如图10所示，采用下面方式：
b5'：Peer容器通过docker启动链码容器并在其中基于所述链码镜像安装和实例化所述链码。
b4中，如前所述，Peer容器接收到通知后，采用docker构建包含所述目标文件的链码镜像。Peer容器除了可以发送Docker build命令和该dockerfile_2至docker Engine，还可以发送Docker run命令至docker Engine。该指令通过 docker-shim和docker Engine发送给containerd，进而由containerd调用runC。这样，由runC拉起一个基于该链码镜像构建的传统链码容器，这个传统链码例如是container3。也就是说，一旦链码镜像构建完成，就可以拉起该链码镜像构建的传统链码容器，而不必像b5中那样等待调用所述链码的交易后由Peer节点触发拉起这个传统链码容器。这样，提前拉起传统链码容器，后续Peer节点接收到调用该链码的交易请求后，可以直接调用该链码进行模拟执行，而不是临时再拉起传统链码容器后再调用该链码进行模拟执行，显然这样的方式可以提高合约的执行速度。
可见，上述过程中docker engine的主要作用在于构建镜像，并且与docker engine的通信大都需要通过Docker shim进行。在采用kubernetes和docker技术的Fabric 2.0(以及后续的版本)中部署传统链码的过程，都很依赖于docker，具体是很依赖于docker-shim和docker Engine。此外，如前所述，使用Docker作为K8S容器运行时的话，kubelet需要先要通过docker-shim去调用Docker Engine，再通过Docker Engine调用containerd。
如前所述，docker-shim是Kubernetes的一个组件，主要目的是为了通过CRI操作Docker，具体是上述的Docker Engine。Docker在创建之初并没有考虑到容器编排或者是考虑Kubernetes，但Kubernetes在创建之初便采用Docker作为它的默认容器运行时，后续代码当中包含了很多对Docker相关的操作逻辑。后期Kubernetes为了能够做解耦，兼容更多的容器运行时，将操作Docker相关逻辑整体独立起来组成了docker-shim。
而containerd是容器技术标准化之后的产物，为了能够兼容OCI(开放容器组织)标准，将容器运行时及其管理功能从Docker Daemon剥离。containerd向上可以为Docker Daemon提供接口，使得Docker Daemon可以屏蔽下面的结构变化，确保原有接口向下兼容，向下可以通过containerd-shim结合runC，使得引擎可以独立升级，避免之前Docker Daemon升级会导致所有容器不可用的问题。runc是一个命令行工具端，可以根据OCI的标准来创建和运行容器。
gRPC是一种RPC的实现，由Google公司开发，是一种高性能、开源和通用的RPC框架，面向移动和HTTP/2设计，支持众多常见的编程语言，还提供了强大的流式调用能力，目前已经成为最主流的RPC框架之一。在服务端实现定义的服务接口，并运行一个gRPC服务器来处理gRPC客户端调用。而gRPC客户端发起调用至gRPC服务端，需要获得gRPC服务端的地址和端口等信息。gRPC服务端并不会主动发起向gRPC客户端的连接，而需要gRPC客户端主动发起向gRPC服务端的连接。gRPC是本申请中一种优选的实现，实际上具有类似功能的通信客户端和通信服务端在本申请中都可以实现，以下仍然以gRPC为例说明。
上述方案中，Peer容器接收到所述安装传统链码的指令后，Peer容器可以设置为gRPC服务端。通过b5或这b5'创建传统链码容器，可以在创建传统链码容器的指令中包含Peer容器自身的地址和端口，并可以置于connection.json文件中发送至传统链码容器。这样，创建的传统链码容器可以设置为gRPC客户端。进而，传统链码容器被构建后，可以基于connection.json文件中gRPC服务端的地址和端口向Peer容器发起连接。传统链码容器通过gRPC客户端发起与Peer 容器的连接后可以保持长连接。
后续，Peer容器接收到调用链码的交易后，可以将该交易通过保持的长连接发送至传统链码容器，从而实现对链码的调用。传统链码容器中执行调用链码的交易后，如前所述，可以将执行结果即读/写集通过保持的长连接返回至gRPC服务端，即返回至Peer容器。
理论上，即使不运行docker Engine，也能够直接通过containerd来管理容器，这样也就可以不需要docker-shim。
K8S发布CRI(Container Runtime Interface)，统一了容器运行时接口，凡是支持CRI的容器运行时，都可以作为K8S的底层容器运行时。Kubernetes在1.20版本中提到将不再在后续的版本维护docker-shim垫片，并最早将在1.23版本中开始移除该垫片。Docker-shim被移除，这也因此移除了对Docker作为容器运行时的支持。如前所述，containerd是从Docker中分离出来的一个项目，其本身可以作为一个底层容器运行时，现在它成了Kubernete容器运行时更好的选择。不仅仅是Docker，还有很多云平台也支持containerd作为底层容器运行时。除了containerd，还有CRI-O等可以作为底层容器运行时。
如果使用containerd作为K8S容器运行时，containerd可以内置CRI插件，从而kubelet可以直接调用containerd，如图11所示。显然的，kubelet通过CRI直接调用containerd，可以缩短通信链路，从而可以提高性能，而且取出docker后资源占用也会变小(Docker不是一个纯粹的容器运行时，具有大量其它功能，因此它的存在更耗资源)。
一种Hyperledger Fabric中部署链码的过程可以如图12中所示。这里仍然设定在采用kubernetes和docker技术的一个Container中已经部署了Peer容器，这个Peer容器例如是container1，其中例如运行了背书节点。并包括如下：
S110：Peer容器接收客户端发来的安装传统链码的命令和链码源码。
客户端可以与图9中的b1过程类似，发起安装链码命令至要部署的背书节点，并将创建的链码源码及背书策略打包发送至所述节点。开发人员创建链码源码后，可以打包链码源码并设定背书策略，之后可以将打包的链码源码和设定的背书策略通过客户端发送至要部署链码的背书节点。要部署链码的背书节点一般包括背书策略中所包含的背书节点。
如图1及对应文字所述，fabric可以包括多个组织，每个组织可以有多个peer。如前所述，这里可以设定在采用kubernetes和containerd技术的一个container中已经部署了Peer节点，可以称为Peer容器。Peer容器可以内置cckeeper模块，或者该cckeeper模块位于Peer容器之外。
S120：所述Peer容器采用第三方构建模块基于所述链码源码构建链码镜像。
Peer容器接收客户端发来的安装传统链码的命令和链码源码后，可以将该安装传统链码的命令和链码源码发送至内置或外置的cckeeper模块，这个cckeeper即第三方构建模块。cckeeper模块接收到客户端发来的链码源码，可以生成一个第三配置文件(dockerfile)，这里设为dockerfile_3。dockerfile_3里可以包括对创建镜像构建容器的描述。
构建链码镜像，如前所述，包括编译得到链码程序和将编译得到链码程序加 入到一个运行环境中生成镜像。
所述Peer容器可以发送创建镜像构建容器的任务至k8s的Master，具体可以由该cckeeper发送。这样，参考图7，Master可以向一个node中的kubelet发起任务。kubelet收到该任务后，通过CRI插件发送创建container的命令至containerd，进而containerd调用runC，从而可以创建一个镜像构建容器，例如是container4。
另一方面cckeeper模块生成dockerfile_3后，可以发送dockerfile_3至imgbuilder(容器镜像构建工具)，进而imgbuilder可以根据dockerfile_3中的内容拉取一个编译环境镜像，这个镜像中的内容适于编译所述链码源码。imgbuilder例如可以包括Kaniko容器镜像工具，该工具是谷歌开源的一个容器镜像构建工具，具备了imgbuilder模块要求的功能。imgbuilder可在创建的镜像构建容器中执行镜像构建任务。在该镜像构建容器中，imgbuilder基于该编译环镜可以对所述链码源码进行编译，从而得到链码程序，也就是上面的目标文件。imgbuilder可以将生成的链码程序存储于一个路径下，并通知cckeeper。可以是通过Peer容器通知cckeeper，也可以是直接通知cckeeper，图13中仅示出了一种，即前者的实现方式。
cckeeper模块接收到通知后，可以根据目标文件生成一个第四配置文件，这里例如为dockerfile_4，其中的内容描述了构建链码镜像的步骤，并包括执行这个链码程序的运行环境的镜像和该链码程序的存储路径。cckeeper可以发送构建链码镜像指令至imgbuilder。imgbuilder可以根据dockerfile_4中指定的(本地或远程的)镜像仓库拉取适合运行链码程序的运行环境镜像，并从前述存储路径拉取所述目标代码。这样可以重新生成一个新的包含该链码程序和运行环境的镜像，并存放在本地/远程的镜像仓库中。这个新生成的链码镜像，可以由该Fabric网络上的当前宿主机或其它宿主机上的容器运行，从而实现一次打包、多处执行。这里的宿主机可以是物理机或虚拟机，甚至也可以是一个容器。
S130：第三方构建模块启动传统链码容器，并在传统链码容器中载入并启动所述链码镜像。
这里，可以是在cckeeper构建链码完成后即启动链码容器，也可以是Peer容器在接收到调用链码的交易请求后触发cckeeper启动链码容器。
前者例如是Peer容器通过cckeeper启动链码容器并在其中基于所述链码镜像安装和实例化所述链码。具体的，imgbuilder构建链码镜像完毕后，可以发送一个通知至cckeeper。cckeeper接收到通知后，可以拉起一个基于该链码镜像构建的传统链码容器，这个传统链码容器例如是container5。也就是说，一旦链码镜像构建完成，就可以拉起该链码镜像构建的传统链码容器。这样，提前拉起传统链码容器，后续Peer节点接收到调用该链码的交易请求后，可以直接调用该链码进行模拟执行，而不是临时再拉起传统链码容器后再调用该链码进行模拟执行，显然这样的方式可以提高合约的执行速度。
后者例如是Peer容器接收到调用所述链码的交易后，通过cckeeper启动链码容器并在其中基于所述链码镜像安装和实例化所述链码。具体的，imgbuilder构建链码镜像完毕后，可以发送一个通知至cckeeper，从而cckeeper可以获得链码镜像的存储路径。Peer容器接收到调用链码的交易后，如果传统链码容器并没有启动，则Peer容器可以调用cckeeper，由cckeeper拉起一个基于该链码 镜像构建的传统链码容器，这个传统链码容器例如是container5。
进而，Peer容器可以向链码容器输入所述交易中的所述参数，进行链码模拟执行该交易。
Peer容器可以设置为gRPC服务端。S120或者S130中，所述Peer容器采用第三方构建模块基于所述链码源码构建链码镜像，或Peer容器在接收到调用链码的交易请求后触发cckeeper启动链码容器中，Peer容器可以将自身的IP地址、端口等信息发送至cckeeper。进而，cckeeper创建传统链码容器时，可以发送一个connection.json文件，该文件中可以包括上述Peer容器的IP地址、端口等信息。传统链码容器启动后，通过connection.json可以知道当前gRPC服务端的IP地址和端口等信息。进而，传统链码容器可以设置自身为gRPC的客户端。传统链码容器进而可以通过gRPC客户端发起与Peer容器的连接，并可以保持长连接。进而，Peer容器在接收到调用链码的交易请求后，可以通过保持的长连接向传统链码容器发起调用，输入所述交易中的所述参数，进行链码模拟执行该交易。传统链码容器中执行调用链码的交易后，也可以将执行结果即读/写集通过保持的长连接返回至gRPC服务端，即返回至Peer容器。
通过上述过程，使得开发者在开发链码源码时还是按照传统链码的方式编写而无需做出改变，这样给链码开发者没有增加额外的开发成本。同时，通过由第三方构建模块构建链码镜像，摆脱了对Docker的依赖。
以下以一个Hyperledger Fabric中的具体例子来说明联盟链中部署链码的过程，可以如图13中所示，包括：
c1：客户端发送安装传统链码的命令和链码源码至Peer容器，Peer容器发送该连码源码至cckeeper。
如前所述，这里可以设定在采用kubernetes和containerd技术的一个container中已经部署了Peer节点，可以称为Peer容器。用户创建链码源码后，可以通过客户端将安装传统链码的命令和该链码源码发消息至相连的Peer容器。
Peer容器可以将客户端发来的安装传统链码的命令和链码源码发送至cckeeper。cckeeper可以根据链码源码生成一个第三配置文件(dockerfile)，这里设为dockerfile_3。dockerfile_3里可以包括对创建镜像构建容器的描述。
cckeeper模块可以内置于Peer容器，或者该cckeeper模块可以设置于Peer容器之外。以下以后者为例进行说明，cckeeper模块内置于Peer容器的情形与此类似。
c2：cckeeper采用创建镜像构建容器，并在其中将链码源码编译为目标文件。
具体的，cckeeper可以发送创建镜像构建容器的任务至k8s的Master。这样，参考图7，Master可以向一个node中的kubelet发起任务。kubelet收到该任务后，通过CRI插件发送创建container的命令至containerd，进而containerd调用runC，从而可以创建一个镜像构建容器，例如是container4。
另一方面cckeeper生成dockerfile_3后，可以发送dockerfile_3至imgbuilder，进而imgbuilder可以根据dockerfile_3中的内容拉取一个编译环境镜像，这个镜像中的内容适于编译所述链码源码。imgbuilder例如可以包括Kaniko容器镜像工具，该工具是谷歌开源的一个容器镜像构建工具，具备了imgbuilder模块要求的功能。imgbuilder可在创建的镜像构建容器中执行镜像构建任务。在该镜像 构建容器中，imgbuilder基于该编译环镜可以对所述链码源码进行编译，从而得到链码程序，也就是上面的目标文件。imgbuilder可以将生成的链码程序存储于一个路径下，并通知cckeeper。
上述过程中，kubelet可以通过CRI与containerd通信，进而发送构建镜像的相关命令至containerd。这样，在取消docker-shim和docker-engine后，在保持构建镜像链路畅通的情况下精简了链路，如前所述提高性能并降低了资源占用。
c3：镜像构建容器将编译完的目标文件放至某个目录下，并通知Peer容器/cckeeper。
c4：cckeeper采用imgbuilder构建包含所述目标文件的链码镜像，并存储于镜像仓库中。
cckeeper可以接收到c3中的通知。之后，cckeeper可以根据目标文件生成一个第四配置文件，这里例如为dockerfile_4，其中的内容描述了构建链码镜像的步骤，并包括执行这个链码程序的运行环境的镜像和该链码程序的存储路径。cckeeper可以发送构建链码镜像指令至imgbuilder。imgbuilder可以根据dockerfile_4中指定的(本地或远程的)镜像仓库拉取适合运行链码程序的运行环境镜像，并从前述存储路径拉取所述目标代码。这样可以重新生成一个新的包含该链码程序和运行环境的镜像，并存放在本地/远程的镜像仓库中。这个新生成的链码镜像，可以由该Fabric网络上的当前宿主机或其它宿主机上的容器运行，从而实现一次打包、多处执行。这里的宿主机可以是物理机或虚拟机，甚至也可以是一个容器。
imgbuilder完成链码镜像的构建后，可以发送通知至cckeeper，cckeeper可以通知Peer容器。
c5：cckeeper创建传统链码容器，并在所述传统链码容器中载入并启动所述链码镜像。
Peer容器可以设置为gRPC服务端。
cckeeper可以采用符合CRI的容器运行时创建链码容器。具体的，cckeeper可以发送创建链码容器的命令至Master，Master将该命令通知至Node中的kubelet，kubelet进一步可以采用包含CRI插件的containerd创建container。在这一过程中，cckeeper可以通过connection.json文件发送所述Peer容器的IP地址、端口等信息至传统链码容器。
传统链码容器启动后，可以运行所述链码镜像。通过一系列指令，可以从所述镜像仓库中拉取构建的链码镜像并在Pod的一个container中运行，从而生成链码容器。通过connection.json可以知道当前gRPC服务端的IP地址和端口等信息。进而，传统链码容器可以设置自身为gRPC的客户端。传统链码容器进而可以通过gRPC客户端发起与Peer容器的连接，并可以保持长连接。进而，Peer容器在接收到调用链码的交易请求后，可以通过保持的长连接向传统链码容器发起调用，输入所述交易中的所述参数，进行链码模拟执行该交易。传统链码容器中执行调用链码的交易后，也可以将执行结果即读/写集通过保持的长连接返回至gRPC服务端，即返回至Peer容器。
通过上述过程，使得开发者在开发链码源码时还是按照传统链码的方式编写而无需做出改变，这样给链码开发者没有增加额外的开发成本。同时，通过由 第三方构建模块构建链码镜像，摆脱了对Docker的依赖。
以下介绍本申请一种Hyperledger Fabric中部署链码的系统实施例，包括：
Peer容器，用于接收客户端发来的安装传统链码的命令和链码源码，还采用第三方构建模块基于所述链码源码构建链码镜像；
所述第三方构建模块，用于启动传统链码容器，并在所述传统链码容器中载入并启动所述链码镜像；
传统链码容器，用于运行链码。
其中，所述Peer容器采用第三方构建模块基于所述链码源码构建链码镜像，其中，第三方构建模块调用容器镜像构建工具基于所述链码源码及适配的运行环境构建链码镜像。
其中，所述第三方构建模块调用容器镜像构建工具基于所述链码源码及适配的运行环境构建链码镜像，包括：
第三方构建模块调用容器镜像构建工具，所述将客户端发来的链码源码编译得到链码程序；
第三方构建模块调用容器镜像构建工具，将所述链码程序加入到适配的运行环境中并生成链码镜像。
其中，所述第三方构建模块调用容器镜像构建工具，所述将客户端发来的链码源码编译得到链码程序，包括：
第三方构建模块基于所述链码源码生成第三配置文件并发送至容器镜像构建工具，并创建镜像构建容器；
所述容器镜像构建工具根据第三配置文件拉取编译环境镜像，并在所述镜像构建容器中执行镜像构建任务，得到编译后的链码程序。
其中，所述第三方构建模块调用容器镜像构建工具，将所述链码程序加入到适配的运行环境中并生成链码镜像，包括：
第三方构建模块基于生成的链码程序生成第四配置文件；
所述第三方构建模块调用容器镜像构建工具并将该第四配置文件发送至所述容器镜像构建工具；
所述容器镜像构建工具根据第四配置文件拉取运行环境镜像，并生成包含所述链码程序和运行环境的链码镜像。
其中，所述第三方构建模块启动传统链码容器，并在所述传统链码容器中载入并启动所述链码镜像，包括：
第三方构建模块构建链码完成后即启动链码容器，并在所述传统链码容器中载入并启动所述链码镜像；或，
Peer容器在接收到调用链码的交易请求后触发第三方构建模块启动链码容器，并在所述传统链码容器中载入并启动所述链码镜像。
其中，所述Peer容器设置为gRPC服务端，所述启动后的传统链码容器设置为gRPC客户端，且Peer容器与传统链码容器之间保持长连接。
其中，第三方构建模块设置于所述Peer容器内或Peer容器外。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对 于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为服务器系统。当然，本申请不排除随着未来计算机技术的发展，实现上述实施例功能的计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示 的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一，第二等词语用来表示名称，而并不表示任何特定的顺序。
为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
本发明是参照根据本发明实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘 (DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
本领域技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本本说明书一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
以上所述仅为本说明书一个或多个实施例的实施例而已，并不用于限制本本说明书一个或多个实施例。对于本领域技术人员来说，本说明书一个或多个实施例可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在权利要求范围之内。

Claims (16)

  1. 一种联盟链中部署链码的方法，包括：
    Peer容器接收客户端发来的安装传统链码的命令和链码源码；
    所述Peer容器采用第三方构建模块基于所述链码源码构建链码镜像；
    所述第三方构建模块启动传统链码容器，并在所述传统链码容器中载入并启动所述链码镜像。
  2. 如权利要求1中的方法，所述Peer容器采用第三方构建模块基于所述链码源码构建链码镜像，包括：
    第三方构建模块调用容器镜像构建工具基于所述链码源码及适配的运行环境构建链码镜像。
  3. 如权利要求2中的方法，所述第三方构建模块调用容器镜像构建工具基于所述链码源码及适配的运行环境构建链码镜像，包括：
    第三方构建模块调用容器镜像构建工具，所述将客户端发来的链码源码编译得到链码程序；
    第三方构建模块调用容器镜像构建工具，将所述链码程序加入到适配的运行环境中并生成链码镜像。
  4. 如权利要求3中的方法，所述第三方构建模块调用容器镜像构建工具，所述将客户端发来的链码源码编译得到链码程序，包括：
    第三方构建模块基于所述链码源码生成第三配置文件并发送至容器镜像构建工具，并创建镜像构建容器；
    所述容器镜像构建工具根据第三配置文件拉取编译环境镜像，并在所述镜像构建容器中执行镜像构建任务，得到编译后的链码程序。
  5. 如权利要求3中的方法，所述第三方构建模块调用容器镜像构建工具，将所述链码程序加入到适配的运行环境中并生成链码镜像，包括：
    第三方构建模块基于生成的链码程序生成第四配置文件；
    所述第三方构建模块调用容器镜像构建工具并将该第四配置文件发送至所述容器镜像构建工具；
    所述容器镜像构建工具根据第四配置文件拉取运行环境镜像，并生成包含所述链码程序和运行环境的链码镜像。
  6. 如权利要求1中的方法，所述第三方构建模块启动传统链码容器，并在所述传统链码容器中载入并启动所述链码镜像，包括：
    第三方构建模块构建链码完成后即启动链码容器，并在所述传统链码容器中载入并启动所述链码镜像；或，
    Peer容器在接收到调用链码的交易请求后触发第三方构建模块启动链码容器，并在所述传统链码容器中载入并启动所述链码镜像。
  7. 如权利要求1中的方法，所述Peer容器设置为通信服务端，所述启动后的传统链码容器设置为通信客户端，且Peer容器与传统链码容器之间保持长连接。
  8. 如上述任一项所述的方法，其中，第三方构建模块设置于所述Peer容器内或Peer容器外。
  9. 一种联盟链中部署链码的系统，包括：
    Peer容器，用于接收客户端发来的安装传统链码的命令和链码源码，还采用第三方构建模块基于所述链码源码构建链码镜像；
    所述第三方构建模块，用于启动传统链码容器，并在所述传统链码容器中载入并启动所述链码镜像；
    传统链码容器，用于运行链码。
  10. 如权利要求9中的系统，所述Peer容器采用第三方构建模块基于所述链码源码构建链码镜像，其中，第三方构建模块调用容器镜像构建工具基于所述链码源码及适配的运行环境构建链码镜像。
  11. 如权利要求10中的系统，所述第三方构建模块调用容器镜像构建工具基于所述链码源码及适配的运行环境构建链码镜像，包括：
    第三方构建模块调用容器镜像构建工具，所述将客户端发来的链码源码编译得到链码程序；
    第三方构建模块调用容器镜像构建工具，将所述链码程序加入到适配的运行环境中并生成链码镜像。
  12. 如权利要求11中的系统，所述第三方构建模块调用容器镜像构建工具，所述将客户端发来的链码源码编译得到链码程序，包括：
    第三方构建模块基于所述链码源码生成第三配置文件并发送至容器镜像构建工具，并创建镜像构建容器；
    所述容器镜像构建工具根据第三配置文件拉取编译环境镜像，并在所述镜像构建容器中执行镜像构建任务，得到编译后的链码程序。
  13. 如权利要求11中的系统，所述第三方构建模块调用容器镜像构建工具，将所述链码程序加入到适配的运行环境中并生成链码镜像，包括：
    第三方构建模块基于生成的链码程序生成第四配置文件；
    所述第三方构建模块调用容器镜像构建工具并将该第四配置文件发送至所述容器镜像构建工具；
    所述容器镜像构建工具根据第四配置文件拉取运行环境镜像，并生成包含所述链码程序和运行环境的链码镜像。
  14. 如权利要求9中的系统，所述第三方构建模块启动传统链码容器，并在所述传统链码容器中载入并启动所述链码镜像，包括：
    第三方构建模块构建链码完成后即启动链码容器，并在所述传统链码容器中载入并启动所述链码镜像；或，
    Peer容器在接收到调用链码的交易请求后触发第三方构建模块启动链码容器，并在所述传统链码容器中载入并启动所述链码镜像。
  15. 如权利要求9中的系统，所述Peer容器设置为通信服务端，所述启动后的传统链码容器设置为通信客户端，且Peer容器与传统链码容器之间保持长连接。
  16. 如上述任一项所述的系统，其中，第三方构建模块设置于所述Peer容器内或Peer容器外。
PCT/CN2022/135655 2022-03-30 2022-11-30 联盟链中部署链码的方法和系统 WO2023185058A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210325838.2A CN114675934A (zh) 2022-03-30 2022-03-30 联盟链中部署链码的方法和系统
CN202210325838.2 2022-03-30

Publications (1)

Publication Number Publication Date
WO2023185058A1 true WO2023185058A1 (zh) 2023-10-05

Family

ID=82076080

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135655 WO2023185058A1 (zh) 2022-03-30 2022-11-30 联盟链中部署链码的方法和系统

Country Status (2)

Country Link
CN (1) CN114675934A (zh)
WO (1) WO2023185058A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114675934A (zh) * 2022-03-30 2022-06-28 蚂蚁区块链科技(上海)有限公司 联盟链中部署链码的方法和系统
CN115550375B (zh) * 2022-08-31 2024-03-15 云南电网有限责任公司信息中心 基于容器化技术实现区块链轻量化的系统、方法及设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108965468A (zh) * 2018-08-16 2018-12-07 北京京东尚科信息技术有限公司 区块链网络服务平台及其链码安装方法、存储介质
CN112631728A (zh) * 2020-12-28 2021-04-09 杭州趣链科技有限公司 联盟链的链码容器管理方法、装置、设备及存储介质
CN113721921A (zh) * 2021-09-01 2021-11-30 杭州云象网络技术有限公司 一种联盟链多语言外部链码离线编译方法与系统
CN114020403A (zh) * 2021-10-26 2022-02-08 杭州趣链科技有限公司 一种联盟链的链码管理方法、装置及终端设备
CN114675934A (zh) * 2022-03-30 2022-06-28 蚂蚁区块链科技(上海)有限公司 联盟链中部署链码的方法和系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108965468A (zh) * 2018-08-16 2018-12-07 北京京东尚科信息技术有限公司 区块链网络服务平台及其链码安装方法、存储介质
CN112631728A (zh) * 2020-12-28 2021-04-09 杭州趣链科技有限公司 联盟链的链码容器管理方法、装置、设备及存储介质
CN113721921A (zh) * 2021-09-01 2021-11-30 杭州云象网络技术有限公司 一种联盟链多语言外部链码离线编译方法与系统
CN114020403A (zh) * 2021-10-26 2022-02-08 杭州趣链科技有限公司 一种联盟链的链码管理方法、装置及终端设备
CN114675934A (zh) * 2022-03-30 2022-06-28 蚂蚁区块链科技(上海)有限公司 联盟链中部署链码的方法和系统

Also Published As

Publication number Publication date
CN114675934A (zh) 2022-06-28

Similar Documents

Publication Publication Date Title
CN112585919B (zh) 利用基于云的应用管理技术来管理应用配置状态的方法
WO2023185058A1 (zh) 联盟链中部署链码的方法和系统
US11138030B2 (en) Executing code referenced from a microservice registry
WO2023185054A1 (zh) 联盟链中部署链码的方法和系统
US11886929B2 (en) Deploying cloud-native services across control planes
Ferry et al. CloudMF: applying MDE to tame the complexity of managing multi-cloud applications
Petcu et al. Experiences in building a mOSAIC of clouds
Sharma et al. A complete survey on software architectural styles and patterns
WO2022037612A1 (zh) 提供应用构建服务的方法及应用构建平台、应用部署方法和系统
US10346160B2 (en) Melding of mediation flow service component architecture (SCA) components
WO2023185055A1 (zh) 联盟链中部署链码的方法和系统
US9110758B2 (en) Cross-platform software framework for embedded systems on data storage device
Sharma et al. Getting Started with Istio Service Mesh: Manage Microservices in Kubernetes
WO2020124459A1 (zh) 基于混合云计算平台的无服务函数的服务方法
Merzky et al. Application level interoperability between clouds and grids
WO2023240933A1 (zh) 一种基于区块链的分布式应用部署方法及装置
US20140280767A1 (en) Web services provided from software framework
Benomar et al. Deviceless: A serverless approach for the Internet of Things
Greenberg Building Applications on Mesos: Leveraging Resilient, Scalable, and Distributed Systems
Sharma et al. Getting Started with Istio Service Mesh
JP2024503440A (ja) クラウドプラットフォームに構成されたデータセンタ上に継続的配信を介して配備されるサービスのシステム構成フリーズ及び変更管理
WO2024179400A1 (zh) 一种实例的启动加速方法及相关装置
WO2023274014A1 (zh) 容器集群的存储资源管理方法、装置及系统
Chardet Reconciling parallelism expressivity and separation of concerns in reconfiguration of distributed systems
Qureshi Reduce Cost of Batch Processing Microsoft Azure Cloud

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22934876

Country of ref document: EP

Kind code of ref document: A1