WO2023185055A1 - Procédé et système de déploiement de code de chaîne dans une chaîne d'alliance - Google Patents

Procédé et système de déploiement de code de chaîne dans une chaîne d'alliance Download PDF

Info

Publication number
WO2023185055A1
WO2023185055A1 PCT/CN2022/135532 CN2022135532W WO2023185055A1 WO 2023185055 A1 WO2023185055 A1 WO 2023185055A1 CN 2022135532 W CN2022135532 W CN 2022135532W WO 2023185055 A1 WO2023185055 A1 WO 2023185055A1
Authority
WO
WIPO (PCT)
Prior art keywords
container
chain code
image
chaincode
code
Prior art date
Application number
PCT/CN2022/135532
Other languages
English (en)
Chinese (zh)
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 WO2023185055A1 publication Critical patent/WO2023185055A1/fr

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/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 third-party building module receives the command to install the first chain code and the chain code source code sent by the client;
  • the third-party building module builds a chaincode image based on the chaincode source code
  • the third-party building module creates and starts the chain code container based on the chain code image, sets the chain code container as the communication server, sets the Peer container as the communication client, and notifies the communication client of the information of the communication server.
  • a system for deploying chaincode in a consortium chain including:
  • the third-party building module receives the command to install the first chain code and the chain code source code sent by the client, builds a chain code image based on the chain code source code, and also creates and starts a chain code container based on the chain code image;
  • Peer container set as a communication client, receives user-initiated chain code transaction requests and sends the request to the chain code container;
  • the chain code container is set as the communication server. After receiving the chain code transaction request, it executes the transaction and returns the execution result to the Peer container.
  • the above solution allows developers to write in the traditional chain code method without making changes when developing chain code source code, thus adding no additional development costs to chain code developers.
  • by building chain code images from third-party building modules we get rid of dependence on Docker.
  • the advantage of setting the chain code container as the communication server is that the external chain code container can be decoupled from the Peer container, thus enabling service-oriented services.
  • Figure 1 is an architectural diagram of HyperledgerFabric in some embodiments of the present disclosure
  • Figure 2 is a schematic diagram of the transaction process of HyperledgerFabric in some embodiments of the present disclosure
  • Figure 3 shows the ledger structure of HyperledgerFabric 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 schematic diagram of deploying external chain code after removing Docker in this disclosure
  • Figure 13 is a flow chart of deploying chaincode containers after removing Docker in this disclosure
  • Figure 14 is a schematic diagram of the deployment chain code container after removing Docker in this disclosure.
  • 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. Different from public chains such as Bitcoin and Ethereum, nodes in the Hyperledger Fabric network generally need to be authorized and authenticated before joining, thereby avoiding the resource overhead of POW (Proof of Work, proof of work), greatly improving transaction processing efficiency, and meeting the requirements of Enterprise-level applications require processing performance, and the system does not require token support to operate.
  • 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 (LeaderPeer) and anchor nodes (AnchorPeer).
  • 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.
  • SmartContract 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.
  • EndorsePolicy endorsement policy
  • Endorsement policies generally include nodes organized by relationships such as and, or, majorityof, etc., which can be specified in the chain code. and ⁇ endorsement node 1, endorsement node 2, endorsement node 3 ⁇ can indicate that the transaction needs to be endorsed by endorsement node 1, endorsement node 2, and endorsement node 3. or ⁇ endorsement node 1, endorsement node 2, endorsement node 3 ⁇ can mean endorsement by any one of endorsement node 1, endorsement node 2, and endorsement node 3.
  • majorityof ⁇ endorsing node 1, endorsing node 2, endorsing node 3 ⁇ can mean that the transaction needs to be endorsed by at least half of the nodes among endorsing node 1, endorsing node 2, and endorsing node 3. Here, it means that at least half of the three endorsing nodes need to be endorsed. 2.
  • the application sends the transaction to the endorsement node 1, endorsement node 2, and endorsement node 3 respectively.
  • a2 After the endorsement node verifies the received transaction proposal, it simulates execution of the transaction and endorses it, and returns a proposal response (proposalresponse) to the application.
  • 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 (ReadSet, Rset or RS) and/or write set (WriteSet, Wset or WS) (RS and WS can be collectively referred to as read and write sets, or written as RWset). These read and write sets can eventually be written to the blockchain ledger maintained locally by the Peer node. Read sets and write sets generally use Key-Value expressions. In addition, the read-write set generally also carries version information, which indicates the version for which the operations in the read-write set are generated.
  • 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, CurrentBlockHash), and the hash value of the previous block header (PH0, PH1, PH2, etc. in Figure 3, PH is PreviousBlockHash
  • PH PreviousBlockHash
  • the abbreviation of is also the block hash of the previous block). In this way, all blocks in the blockchain are arranged in order and cryptographically linked together. This hashing and linking makes blockchain ledger data extremely secure.
  • 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.
  • 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 to install a complete operating system before it can install/run applications. If every time an application is released, a virtual machine is used to virtualize a complete operating system and a complete dependency environment is set up, which will be a relatively tedious task.
  • Container technology is relatively lightweight. The operating system can be removed from the container, and instead it contains the application and the system environment on which the application depends. Through container technology, applications and dependent environments can be packaged, and the packaged content can still run normally when transplanted to other hosts with the same operating system.
  • 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 (DockerHost), and the Docker Daemon decomposes the request and executes it.
  • Docker Daemon distributed process
  • DockerHost 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 a copy of the complete container image into memory and runs it. This copy loaded into memory can be modified by the container, but it is limited to running in memory; any modifications to the Container layer will not take effect on the underlying image, and the modifications made when the container dies will also be included.
  • 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 containers so that containerd is not needed 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 created by the specified kubelet in 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 Fabric2.0 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 endorsing node can use docker (docker here mainly includes docker-shim and dockerengine in the figure) to create the corresponding temporary container.
  • the corresponding temporary container contains the compilation environment of the corresponding source language.
  • the local or remote image warehouse of the endorsing node contains compilation environment images for compiling various chain code source codes, and can be pulled and used by docker. In this way, the endorsing node receives a type of source code and can use docker to create a temporary container containing the corresponding compilation environment.
  • 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 Dockerbuild command and the dockerfile_1 to docker-shim, and then send it to dockerEngine.
  • Docker Engine can pull the compilation environment image suitable for compiling chain code source code based on the (local or remote) image warehouse specified in dockerfile_1, and send the request to containerd, which then calls runC.
  • the result of executing the above command is that runC pulls up a temporary container built based on the compilation ring mirror image.
  • This temporary container is, for example, container2.
  • 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 Dockerbuild command and this dockerfile_2 to reach the dockerEngine through the Docker-shim call.
  • Docker Engine can pull the operating environment image suitable for running the chain code program based on the (local or remote) image warehouse specified in dockerfile_2, and pull the target code from the aforementioned storage path. In this way, a new image containing the chaincode program and running environment can be regenerated and stored in the local/remote warehouse.
  • This newly generated chain code image can be run by containers on the current host or other hosts on the Fabric network, thereby achieving one-time packaging and multiple executions.
  • the host here can be a physical machine or a virtual machine, or even a container.
  • 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 Dockerrun command to dockerEngine through docker-shim, and the command is sent to containerd, and then containerd calls runC. In this way, runC pulls up a traditional chaincode container built based on the chaincode image.
  • This traditional chaincode container is, for example, container3.
  • 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 dockerEngine. This instruction is sent to containerd through docker-shim and dockerEngine, and then containerd calls runC. In this way, runC pulls up a traditional chaincode container built based on the chaincode image.
  • This traditional chaincode 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.
  • dockerengine in the above process is to build the image, and most communication with dockerengine needs to be carried out through Dockershim.
  • docker-shim specifically docker-shim and dockerEngine.
  • kubelet needs to first call DockerEngine 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 DockerEngine. When Docker was first created, it did not consider container orchestration or Kubernetes. However, Kubernetes used Docker as its default container runtime when it was first created. The subsequent code contains a lot of Docker-related operating logic. Later, in order to be able to decouple and be compatible with more container runtimes, Kubernetes separated the entire logic related to operating Docker to form docker-shim.
  • Containerd is a product of the standardization of container technology. In order to be compatible with OCI (Open Container Organization) standards, the container runtime and its management functions are separated from Docker Daemon. containerd can provide an interface for DockerDaemon upwards, so that Docker Daemon can shield the following structural changes and ensure that the original interface is downwardly compatible. downwards, it can be combined with runC through containerd-shim, so that the engine can be upgraded independently, avoiding all the previous upgrades of Docker Daemon. Container unavailability problem. runc is a command line tool that can create and run containers according to OCI standards.
  • 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).
  • external chain codes can also be deployed in Hyperledger Fabric.
  • a process of deploying external chaincode is shown in Figure 12. Similar to Figure 9, it is assumed that a Peer container has been deployed in a Container using kubernetes and docker technology. This Peer container runs in a cloud service environment.
  • traditional chaincode is generally deployed and executed on nodes within the blockchain.
  • External chain codes are generally deployed and run on nodes outside the blockchain to facilitate users to independently manage each external node and its operating environment.
  • the user environment includes Client. The process can include the following:
  • d1 Client builds and starts the external chain code container in the user environment where it is located.
  • the Client After the Client starts the external chain code container, it can also obtain the address (such as IP address) and port where the external chain code container runs. Since the external chaincode container needs to execute the chaincode and is located outside the blockchain network, subsequent nodes on the blockchain must forward the transaction calling the chaincode to the external chaincode container, and the nodes on the blockchain will It is necessary to obtain information such as the address and port of the external chain code container (for example, including certificate configuration for TLS (Transport Layer Security, Transport Layer Security Protocol) communication) in order to communicate with the external chain code container.
  • TLS Transport Layer Security, Transport Layer Security Protocol
  • the communication method can use RPC (Remote Procedure Call, remote procedure call).
  • RPC can encapsulate a service call in a local method, allowing the caller to call the service as if it were a local method, while shielding it from the underlying implementation details. Therefore, it is a lightweight and imperceptible way of cross-process communication.
  • the specific implementation can be through a set of agreements between the caller and the server, and data interaction can be carried out based on TCP long connections.
  • gRPC is an RPC implementation developed by Google. It is a high-performance, open source and universal RPC framework designed for mobile and HTTP/2. It supports many common programming languages and also provides powerful streaming calling capabilities. , has become one of the most mainstream RPC frameworks.
  • gRPC is a preferred implementation in this application. In fact, both communication clients and communication servers with similar functions can be implemented in this application. The following explanation will still take gRPC as an example.
  • the Client starts an external chaincode container and can set the external chaincode container as the gRPC server.
  • Client sends the instruction to install the external chain code to the Peer container in the cloud service environment.
  • the instruction sent by the Client to install the external chain code may include the IP address and port of the external chain code container.
  • the Client can send a connection.json file, which contains the IP address, port and other information of the above-mentioned external chain code container.
  • the Client can also send a metadata.json file, which indicates that the specified installed chain code is an external chain code.
  • the Peer container initiates a connection with the external chain code container to call the chain code.
  • the Peer container After the Peer container receives the instruction to install the external chain code, through metadata.json, the Peer container can know that the external chain code is currently installed. Furthermore, the Peer container can be set up as a gRPC client. After the Peer container obtains the address, port and other information of the external chain code container through connection.json, it can initiate a connection with the external chain code container through the gRPC client and maintain a long connection.
  • the Peer container After the transaction calling the chain code is executed in the external chain code container, as mentioned above, the execution result, that is, the read/write set, can be returned to the gRPC client through the maintained long connection, that is, returned to the Peer container.
  • the started traditional chaincode container can be set as the gRPC client, and the Peer container can be set as the gRPC server.
  • the gRPC server will not actively initiate a connection to the gRPC client, but the gRPC client needs to actively initiate a connection to the gRPC server.
  • the Peer container as a gRPC server, can include its own address and port in the instructions for creating a traditional chain code container, and can be placed in the connection.json file and sent to the traditional chain code container.
  • a connection can be initiated to the Peer container based on the address and port of the gRPC server in the connection.json file.
  • a long connection can be maintained with the Peer container. Subsequently, the Peer container can send the transaction calling the chain code to the traditional chain code container through the long connection to simulate execution.
  • the installation chaincode instruction initiated by the Client does not need to include the connection.json and metadata.json files.
  • the client needs to inform the peer through the installation chain code instructions of connection.json and metadata.json that contain the address and port of the external chain code container.
  • the container is currently installed with external chaincode.
  • the user since the user can build and start the external chain code container in advance in the user environment where the client is located or the environment specified by the user, there is no need for the Peer container to participate in the construction and startup process, so the construction and startup of the external chain code container are omitted here. detailed process.
  • the advantage of setting the external chain code container as the gRPC server is that the external chain code container can be decoupled from the Peer container, so that it can be service-oriented.
  • the external chain code container does not need to run on the same host as the Peer, but can run on a different host from the Peer container, which is more flexible; on the other hand, the external chain code container can be used as a service Provided to different Peer containers, for example, serving different Peer containers in the same organization. In this case, the Peer container acts as a gRPC client.
  • the third-party building module receives the command to install the first chain code and the chain code source code sent by the client.
  • the client can be similar to the b1 process in Figure 9, initiate a command to install the first chain code to the endorsement node to be deployed, and package and send the created chain code source code and endorsement policy to the node.
  • developers create the chaincode source code, they can package the chaincode source code and set the endorsement policy. Then they can send the packaged chaincode source code and the set endorsement policy through the client to the endorsement node where the chaincode is to be deployed.
  • the endorsement nodes to be deployed with chaincode generally include the endorsement nodes included in the endorsement policy.
  • the first chaincode command here is very similar to the traditional chaincode command mentioned above. It does not include the connection.json and metadata.json files, and it does not include the IP address and port of the gRPC server.
  • the fabric can include multiple organizations, and each organization can have multiple peers.
  • a governor node can be set up in each organization to manage peer nodes in the current organization.
  • a Peer node has been deployed in a container using kubernetes and containerd technology, which can be called a Peer container, and a governor node has been deployed in another container, which can be called a governor container.
  • the governor container can also have a built-in cckeeper module.
  • the cckeeper module can also be built into the Peer container.
  • S120 The third-party building module builds a chaincode image based on the chaincode source code.
  • the peer container After the peer container receives the command to install the first chain code and the chain code source code from the client, it can send the command to install the first chain code and the chain code source code to the built-in or external cckeeper module.
  • This cckeeper is a third-party Building blocks.
  • the client can also send the command to install the first chain code and the chain code source code directly to the governor container, so that cckeeper can obtain the command to install the first chain code and the chain code source code.
  • the cckeeper module can receive the chain code source code sent by the client, and then generate a third configuration file (dockerfile), here set to dockerfile_3. Dockerfile_3 can include a description of creating an image and building a container.
  • Building a chaincode image includes compiling the chaincode program and adding the compiled chaincode program to a running environment to generate an image.
  • the cckeeper module can send the task of creating an image and building a container to the k8s Master.
  • 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, either through the Peer container or directly.
  • 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.
  • imgbuilder After imgbuilder completes building the chaincode image, it can send a notification to cckeeper.
  • the third-party building module creates and starts a chaincode container based on the chaincode image, sets the chaincode container as the gRPC server, sets the Peer container as the gRPC client, and notifies the gRPC server information to the gRPC client end.
  • the chain code container can be started after cckeeper completes building the chain code container, or the Peer container can trigger cckeeper to start the chain code container after receiving a transaction request to call the chain code.
  • the former is, for example, that the Peer container starts the chaincode container through cckeeper and installs and instantiates the chaincode in it based on the chaincode image. Specifically, after imgbuilder completes building the chaincode image, it can send a notification to cckeeper. After receiving the notification, cckeeper can pull up a traditional chaincode container built based on the chaincode image. That is to say, once the chain code image is built, the traditional chain code container built by the chain code image can be pulled up. In this way, the traditional chain code container is pulled up in advance. After the subsequent peer node receives the transaction request to call the chain code, it can directly call the chain code for simulated execution, instead of temporarily pulling up the traditional chain code container and then calling the chain code. Carry out simulated execution. Obviously, this method can improve the execution speed of the contract.
  • the latter is, for example, that after the Peer container receives the transaction that calls the chain code, it starts the chain code container through cckeeper and installs and instantiates the chain code in it based on the chain code image. Specifically, after imgbuilder completes building the chain code image, it can send a notification to cckeeper, so that cckeeper can obtain the storage path of the chain code image.
  • the Peer container receives the transaction calling the chain code, if the traditional chain code container has not been started, the Peer container can call cckeeper, and the cckeeper will pull up a traditional chain code container based on the chain code image.
  • This traditional chain code container is, for example, It's a container.
  • the Peer container can input the parameters in the transaction to the chaincode container, and perform chaincode simulation to execute the transaction.
  • the third-party building module can set the chain code container as a gRPC server, so that the chain code container will have information such as IP address and port number.
  • the third-party building module can send the connection.json file and metadata.json file to the Peer container.
  • the connection.json file states the IP address, port and other information of the above-mentioned chaincode container.
  • the Peer container can be set up as a gRPC client. After the Peer container obtains the address, port and other information of the external chain code container through connection.json, it can initiate a connection with the external chain code container through the gRPC client and maintain a long connection.
  • the Peer container After the transaction calling the chain code is executed in the external chain code container, as mentioned above, the execution result, that is, the read/write set, can be returned to the gRPC client through the maintained long connection, that is, returned to the Peer container.
  • the above solution allows developers to write the chain code source code according to the traditional chain code method without making changes, thus adding no additional development costs to the chain code developers.
  • by building chain code images from third-party building modules we get rid of dependence on Docker.
  • the advantage of setting the chain code container as a gRPC server is that the external chain code container can be decoupled from the Peer container, thus enabling service-oriented services.
  • the client sends the first installation chaincode command to the governor container.
  • This command includes the created chaincode source code and endorsement policy.
  • the fabric can include multiple organizations, and each organization can have multiple peers.
  • a governor (governance) node can be set up in each organization to manage the peer nodes in the current organization.
  • it can be set that a Peer node has been deployed in a container using kubernetes and containerd technology, which can be called a Peer container, and a governor node has been deployed in another container, which can be called a governor container.
  • governor can also have a built-in cckeeper module.
  • the user After the user creates the chaincode source code, he can send the chaincode source code and endorsement policy to the governor container belonging to the organization through the client.
  • the first install chaincode command is similar to the install traditional chaincode command in Figure 9.
  • the governor container receives the chain code source code sent from the client and can generate a third configuration file (dockerfile). Specifically, you can use its built-in cckeeper to generate this dockerfile, which is set to dockerfile_3 here. Dockerfile_3 can include a description of creating an image and building a container.
  • the Governor container uses a CRI-compliant container runtime to create an image to build the container, and compiles the chain code source code into a target file.
  • the Governor can send the task of creating an image and building a container to the k8s Master, which can be sent by the cckeeper.
  • 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 container3.
  • 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 the relevant commands to create the container to containerd. In this way, after canceling docker-shim and docker-engine, the link is streamlined while keeping the image link open, improving performance and reducing resource usage as mentioned above.
  • c3 The image building container places the compiled target file in a certain directory and notifies the governor container.
  • 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 chaincode program in a path, such as a mirror warehouse, and notify cckeeper.
  • the Governor container uses imgbuilder to build a chaincode image containing the target file and stores it in the image warehouse.
  • the cckeeper in the Governor container can generate a fourth configuration file based on the target file, here for example dockerfile_4, the content of which describes the steps to build a chain code image, and includes the image of the running environment for executing this chain code program. and the storage path of the chaincode program.
  • cckeeper can send instructions to build chaincode mirrors to imgbuilder.
  • imgbuilder can pull the operating environment image suitable for running the chain code program according to the (local or remote) image warehouse specified in dockerfile_4, and pull the target code from the aforementioned storage path.
  • 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 building the chaincode image, it can send a notification to the governor container.
  • the Governor container uses a CRI-compliant container runtime to create a chain code container, and sets the chain code container as a gRPC server.
  • Chaincode containers can be created by cckeeper in the Governor container using a CRI-compliant container runtime. 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. Specifically, after receiving the notification, the cckeeper module can generate a fourth configuration file based on the target file, here for example dockerfile_4, the content of which describes the steps to build the chaincode image and includes the running environment for executing the chaincode program. The image and the storage path of the chaincode program. cckeeper can send instructions to build chaincode mirrors to imgbuilder.
  • imgbuilder can pull the operating environment image suitable for running the chain code program according to the (local or remote) image warehouse specified in dockerfile_4, and pull the target code from the aforementioned storage path. In this way, a new image containing the chaincode program and running environment can be regenerated and stored in the local/remote image warehouse.
  • This newly generated chain code image can be run by containers on the current host or other hosts on the Fabric network, thereby achieving one-time packaging and multiple executions.
  • the host here can be a physical machine or a virtual machine, or even a container.
  • the chaincode image can be run in the chaincode container. Through a series of instructions, the built chaincode image can be pulled from the image warehouse and run in a container of the Pod, thereby generating a chaincode container.
  • the chaincode container can be started, or the Peer container can trigger cckeeper to start the chaincode container after receiving a transaction request to call the chaincode.
  • 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.
  • imgbuilder completes building the chaincode image
  • it can send a notification to cckeeper.
  • cckeeper can pull up a traditional chaincode container built based on the chaincode image. That is to say, once the chain code image is built, the traditional chain code container built by the chain code image can be pulled up.
  • the latter is, for example, that after the Peer container receives the transaction that calls the chain code, it starts the chain code container through cckeeper and installs and instantiates the chain code in it based on the chain code image. Specifically, after imgbuilder completes building the chain code image, it can send a notification to cckeeper, so that cckeeper can obtain the storage path of the chain code image. After the Peer container receives the transaction that calls the chain code, if the traditional chain code container has not been started, the Peer container can call cckeeper, and cckeeper will pull up a traditional chain code container based on the chain code image.
  • the third-party building module can set the chain code container as a gRPC server, so that the chain code container will have information such as IP address and port number.
  • the third-party building module can send the connection.json file to the Peer container, which contains the IP address, port and other information of the above-mentioned chain code container.
  • the Peer container can be set up as a gRPC client. After the Peer container obtains the address, port and other information of the external chain code container through connection.json, it can initiate a connection with the external chain code container through the gRPC client and maintain a long connection.
  • the Peer container After the transaction calling the chain code is executed in the external chain code container, as mentioned above, the execution result, that is, the read/write set, can be returned to the gRPC client through the maintained long connection, that is, returned to the Peer container.
  • the Governor container sends the command to install the second chain code to the Peer container, and sets the Peer container as the gRPC client.
  • the cckeeper in the governor can send the command to install the second chain code to the Peer container. Similar to the above-mentioned install external chain code command in Figure 13, the sent install second chain code command may include the address and port of the chain code service. Specifically, cckeeper can send a connection.json file, which contains information such as the address and port of the above chain code service.
  • the Peer container After the Peer container receives the command to install the second chain code and obtains the address and port of the chain code service through connection.json, the Peer container can be set as a gRPC client. Furthermore, the Peer container can initiate a connection with the chaincode service through the gRPC client and maintain a long connection.
  • 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 cassettes tape magnetic disk 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

La présente demande concerne un procédé et un système de déploiement d'un code de chaîne dans une chaîne d'alliance. Le procédé comprend les étapes suivantes : un module de construction de tiers reçoit une commande d'installation d'un premier code de chaîne, et un code source de code de chaîne qui sont envoyés par un client ; le module de construction de tiers construit une image de code de chaîne sur la base du code source de code de chaîne ; et sur la base de l'image de code de chaîne, le module de construction de tiers crée et démarre un conteneur de code de chaîne, définit le conteneur de code de chaîne en tant que serveur gRPC, définit un conteneur homologue en tant que client gRPC, et notifie au client gRPC des informations du serveur gRPC. Au moyen du processus, lors du développement du code source de code de chaîne, un développeur écrit encore de la même manière qu'un code de chaîne classique sans effectuer de changements, de telle sorte qu'aucun coût de développement supplémentaire n'est appliqué au développeur de code de chaîne. De plus, par construction de l'image de code de chaîne au moyen du module de construction de tiers, la dépendance à un Docker est supprimée.
PCT/CN2022/135532 2022-03-30 2022-11-30 Procédé et système de déploiement de code de chaîne dans une chaîne d'alliance WO2023185055A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210325840.XA CN114661421A (zh) 2022-03-30 2022-03-30 联盟链中部署链码的方法和系统
CN202210325840.X 2022-03-30

Publications (1)

Publication Number Publication Date
WO2023185055A1 true WO2023185055A1 (fr) 2023-10-05

Family

ID=82032886

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135532 WO2023185055A1 (fr) 2022-03-30 2022-11-30 Procédé et système de déploiement de code de chaîne dans une chaîne d'alliance

Country Status (2)

Country Link
CN (1) CN114661421A (fr)
WO (1) WO2023185055A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114661421A (zh) * 2022-03-30 2022-06-24 蚂蚁区块链科技(上海)有限公司 联盟链中部署链码的方法和系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108810137A (zh) * 2018-06-11 2018-11-13 西安纸贵互联网科技有限公司 一种联盟区块链系统
CN108965468A (zh) * 2018-08-16 2018-12-07 北京京东尚科信息技术有限公司 区块链网络服务平台及其链码安装方法、存储介质
US20200034353A1 (en) * 2018-07-27 2020-01-30 Oracle International Corporation System and method for supporting sql-based rich queries in hyperledger fabric blockchains
CN112631728A (zh) * 2020-12-28 2021-04-09 杭州趣链科技有限公司 联盟链的链码容器管理方法、装置、设备及存储介质
CN114661421A (zh) * 2022-03-30 2022-06-24 蚂蚁区块链科技(上海)有限公司 联盟链中部署链码的方法和系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108810137A (zh) * 2018-06-11 2018-11-13 西安纸贵互联网科技有限公司 一种联盟区块链系统
US20200034353A1 (en) * 2018-07-27 2020-01-30 Oracle International Corporation System and method for supporting sql-based rich queries in hyperledger fabric blockchains
CN108965468A (zh) * 2018-08-16 2018-12-07 北京京东尚科信息技术有限公司 区块链网络服务平台及其链码安装方法、存储介质
CN112631728A (zh) * 2020-12-28 2021-04-09 杭州趣链科技有限公司 联盟链的链码容器管理方法、装置、设备及存储介质
CN114661421A (zh) * 2022-03-30 2022-06-24 蚂蚁区块链科技(上海)有限公司 联盟链中部署链码的方法和系统

Also Published As

Publication number Publication date
CN114661421A (zh) 2022-06-24

Similar Documents

Publication Publication Date Title
US11138030B2 (en) Executing code referenced from a microservice registry
WO2023185054A1 (fr) Procédé et système de déploiement de code de chaîne dans une chaîne d'alliance
WO2023185058A1 (fr) Procédé et système de déploiement de code de chaîne dans une chaîne de blocs de consortium
Petcu et al. Experiences in building a mOSAIC of clouds
Ferry et al. CloudMF: applying MDE to tame the complexity of managing multi-cloud applications
Murthy et al. Apache Hadoop YARN: moving beyond MapReduce and batch processing with Apache Hadoop 2
CN112585919A (zh) 利用基于云的应用管理技术来管理应用配置状态的方法
US10817284B2 (en) Melding of mediation flow service component architecture (SCA) components
WO2022037612A1 (fr) Procédé de fourniture de service de construction d'applications, et plate-forme de construction d'applications, procédé de déploiement d'applications et système
US11366703B2 (en) Dynamic application management across multi-cloud computing environment
WO2023185055A1 (fr) Procédé et système de déploiement de code de chaîne dans une chaîne d'alliance
US20140304716A1 (en) Software framework for a storage device
Sharma et al. Getting Started with Istio Service Mesh: Manage Microservices in Kubernetes
WO2020124459A1 (fr) Procédé employant une plate-forme informatique en nuage hybride pour fournir une fonction sans serveur en tant que service
Merzky et al. Application level interoperability between clouds and grids
US20140280767A1 (en) Web services provided from software framework
WO2023240933A1 (fr) Procédé et appareil de déploiement d'application distribuée sur la base d'une chaîne de blocs
WO2023225744A1 (fr) Asik : interface modulaire pour une chaîne de blocs
Benomar et al. Deviceless: A serverless approach for the Internet of Things
JP2024503440A (ja) クラウドプラットフォームに構成されたデータセンタ上に継続的配信を介して配備されるサービスのシステム構成フリーズ及び変更管理
Sharma et al. Getting Started with Istio Service Mesh
Chardet Reconciling parallelism expressivity and separation of concerns in reconfiguration of distributed systems
Qureshi Reduce Cost of Batch Processing Microsoft Azure Cloud
Qureshi Reduce Cost of Batch Processing Microsoft Azure Cloud (March 2019)
Salih Cloud Computing Service Interoperability and Architectural Concepts

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: 22934873

Country of ref document: EP

Kind code of ref document: A1