WO2023185054A1 - 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
WO2023185054A1
WO2023185054A1 PCT/CN2022/135521 CN2022135521W WO2023185054A1 WO 2023185054 A1 WO2023185054 A1 WO 2023185054A1 CN 2022135521 W CN2022135521 W CN 2022135521W WO 2023185054 A1 WO2023185054 A1 WO 2023185054A1
Authority
WO
WIPO (PCT)
Prior art keywords
container
chain code
image
chaincode
peer
Prior art date
Application number
PCT/CN2022/135521
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 WO2023185054A1 publication Critical patent/WO2023185054A1/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/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.
  • 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
  • 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.
  • the third-party building module builds a chain code image based on the chain code source code, and creates and starts the chain code container based on the chain code image. , set the Peer container and chain code container as the communication client, establish a proxy server as the communication server, and notify the Peer container of the communication server information;
  • the Peer container is set as a communication client, receives the chain code transaction request initiated by the user through the communication server, and sends the request to the chain code container through the communication server;
  • the chain code container is set as a communication client. After receiving the chain code transaction request through the communication server, the transaction is executed, and the execution result is returned to the Peer container through the communication server;
  • Proxy server set as communication server.
  • 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 12 is a schematic diagram of deploying external chain code after removing Docker in this disclosure
  • 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 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.
  • 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 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 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.
  • 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.
  • 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.
  • 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 assigned by the Master. Transfer to other Node.
  • 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 k8smaster (not shown in the figure).
  • 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.
  • 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.
  • 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 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, the Dockerpull command and the 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.
  • 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 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 container is, for example, container3.
  • 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:
  • 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.
  • 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 Peer container and chaincode container as the gRPC client, establishes a proxy server as the gRPC server, and notifies the gRPC server information to Peer container.
  • 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.
  • third-party building blocks can set up the chaincode container as a gRPC client.
  • the chaincode container is created by the Governor using a CRI-compliant container runtime and is created according to the client's first chaincode installation command. In this case, the chaincode container acts as a gRPC client. To use the created chaincode container to provide services for different Peer containers like the aforementioned external chaincode container, the Peer container also needs to serve as a gRPC client.
  • the Peer container and the chain code container are both gRPC clients.
  • the two cannot establish a communication link and cannot communicate.
  • the transaction initiated by the client to call the chain code cannot be realized.
  • the governor container can use a CRI-compliant container runtime to create a Proxy container, and the Proxy container can open a communication link between the Peer container and the chain code container, which are both gRPC clients.
  • the cckeeper in the governor container can send a command to create a Proxy 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 a Pod. This container.
  • the ccproxy module can be run in the Proxy container.
  • the image containing the ccproxy module can be pulled from the image repository and then started.
  • the ccproxy module can establish two gRPC servers, one is a pseudo Peer server and the other is a pseudo chain code server.
  • the pseudo chaincode server is responsible for interacting with the chain code container established by cckeeper in the traditional chain code manner, while the pseudo Peer server is responsible for interacting with the Peer container in the external chain code manner.
  • cckeeper can send information such as the IP address and port number of the Proxy container to the Peer container through the connection.json file.
  • the Peer container can be set up as a gRPC client. After the Peer container obtains the address, port and other information of the Proxy container through connection.json, it can initiate a connection with the Proxy chain code container through the gRPC client and maintain a long connection.
  • the Peer container After the transaction calling the chain code is executed in the 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.
  • third-party building modules to build chain code images, we get rid of dependence on Docker.
  • the chain code container and the Peer container are both set as gRPC clients, the connection between the chain code container and the Peer container can be opened through the proxy server, thereby decoupling the chain code container and the Peer container. This enables 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 node can be set up in each organization to manage 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.
  • 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 chaincode containers and Proxy containers.
  • Chaincode containers and Proxy containers can be created by cckeeper in the Governor container using a CRI-compliant container runtime. Specifically, cckeeper can send commands to create chaincode containers and Proxy containers 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.
  • 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 is created by the Governor using a CRI-compliant container runtime and is created according to the client's installation chaincode command.
  • the chaincode container acts as a gRPC client.
  • the Peer container also needs to serve as a gRPC client.
  • the Peer container and the chain code container are both gRPC clients.
  • the two cannot establish a communication link and cannot communicate.
  • the transaction initiated by the client to call the chain code cannot be realized.
  • the governor container can use a CRI-compliant container runtime to create a Proxy container, and the Proxy container can open a communication link between the Peer container and the chain code container, which are both gRPC clients.
  • the cckeeper in the governor container can send a command to create a Proxy 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 a Pod. This container.
  • the ccproxy module can be run in the Proxy container.
  • the image containing the ccproxy module can be pulled from the image repository and then started.
  • the ccproxy module can establish two gRPC servers, one is a pseudo Peer server and the other is a pseudo chain code server.
  • the pseudo chaincode server is responsible for interacting with the chain code container established by cckeeper in the traditional chain code manner, while the pseudo Peer server is responsible for interacting with the Peer container in the external chain code manner.
  • the Governor container sends the command to install the second chain code to the Peer container.
  • the cckeeper in the governor can send the command to install the second chain code to the Peer container. Similar to the above-mentioned installation of external chain code instructions in Figure 13, the address and port of the chain code service may be included in the command to install the second chain code sent. Specifically, cckeeper can send a connection.json file, which contains information such as the address and port of the above-mentioned 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 Proxy container through connection.json, the Peer container can be set as a gRPC client. Furthermore, the Peer container can initiate a connection with the Proxy container through the gRPC client and maintain a long connection.
  • the chain code service can interact with the pseudo chain code server in the Proxy container, so that the Peer container interacts with the Proxy container in a similar way to the external chain code and can maintain a long connection.
  • the chaincode container can interact with the pseudo chaincode server in a manner similar to traditional chaincode and can maintain a long connection.
  • the Peer container can include a c7 step, in which cckeeper can establish a chain code service, as shown in the figure.
  • 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 container 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 container through the gRPC client and maintain a long connection.
  • the chain code service can interact with the pseudo chain code server in the Proxy container, so that the Peer container interacts with the Proxy container in a similar way to the external chain code and can maintain a long connection.
  • the chaincode container can interact with the pseudo chaincode server in a manner similar to traditional chaincode and can maintain a long connection. This is a more specific form of transformation.
  • the connection between the chaincode container and the Peer container can be opened through the Proxy container.
  • the Client initiates a transaction to call the chain code to the Peer container.
  • the Peer container can initiate the transaction to the chain code container and connect to the chain code container. It can communicate and interact with the chain code container through the Proxy container, and the chain code container can simulate the transaction. Execute and return the read/write set. In this way, the client calls the chain code, and the interactive link can be shown as the dotted line in Figure 14.
  • 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

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 première commande de montage de code de chaîne et un code source de code de chaîne envoyé par un client ; le module de construction de tiers construit une image de miroir de code de chaîne sur la base du code source de code de chaîne ; et le module de construction de tiers crée et démarre un conteneur de code de chaîne sur la base de l'image de miroir de code de chaîne, configure un conteneur homologue et le conteneur de code de chaîne afin qu'ils soient des clients gRPC, établit un serveur mandataire en tant que serveur gRPC, et notifie au conteneur homologue des informations du serveur gRPC. Au moyen de la solution décrite, un développeur peut toujours compiler selon une méthode classique de compilation de code de chaîne pendant le développement d'un code source de code de chaîne, sans effectuer de changement, de telle sorte qu'il n'y a pas de coût de développement supplémentaire pour un développeur de code de chaîne ; pendant ce temps, l'image de miroir de code de chaîne est construite par le module de construction de tiers, de telle sorte que la dépendance à un Docker est éliminée ; d'autre part, bien que le conteneur de code de chaîne et le conteneur homologue soient tous deux configurés pour être les clients gRPC, la connexion entre le conteneur de code de chaîne et le conteneur homologue peut être réalisée au moyen du serveur mandataire, de telle sorte que le conteneur de code de chaîne peut être découplé du conteneur homologue, ce qui permet d'obtenir une desserte.
PCT/CN2022/135521 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 WO2023185054A1 (fr)

Applications Claiming Priority (2)

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

Publications (1)

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

Family

ID=82075558

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135521 WO2023185054A1 (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) CN114675935A (fr)
WO (1) WO2023185054A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114675935A (zh) * 2022-03-30 2022-06-28 蚂蚁区块链科技(上海)有限公司 联盟链中部署链码的方法和系统
CN115426269A (zh) * 2022-11-03 2022-12-02 土豆数据科技集团有限公司 一种基于容器资源的垂直扩缩容方法、装置及存储介质

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 北京京东尚科信息技术有限公司 区块链网络服务平台及其链码安装方法、存储介质
CN110149376A (zh) * 2019-04-30 2019-08-20 广州科创空间信息科技有限公司 提高hyperledger composer链码部署效率的方法
US20190354614A1 (en) * 2018-05-15 2019-11-21 International Business Machines Corporation Configuration drift prevention across multiple systems using blockchain
CN112631728A (zh) * 2020-12-28 2021-04-09 杭州趣链科技有限公司 联盟链的链码容器管理方法、装置、设备及存储介质
CN114675935A (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
US20190354614A1 (en) * 2018-05-15 2019-11-21 International Business Machines Corporation Configuration drift prevention across multiple systems using blockchain
CN108965468A (zh) * 2018-08-16 2018-12-07 北京京东尚科信息技术有限公司 区块链网络服务平台及其链码安装方法、存储介质
CN110149376A (zh) * 2019-04-30 2019-08-20 广州科创空间信息科技有限公司 提高hyperledger composer链码部署效率的方法
CN112631728A (zh) * 2020-12-28 2021-04-09 杭州趣链科技有限公司 联盟链的链码容器管理方法、装置、设备及存储介质
CN114675935A (zh) * 2022-03-30 2022-06-28 蚂蚁区块链科技(上海)有限公司 联盟链中部署链码的方法和系统

Also Published As

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

Similar Documents

Publication Publication Date Title
WO2023185054A1 (fr) Procédé et système de déploiement de code de chaîne dans une chaîne d'alliance
US11138030B2 (en) Executing code referenced from a microservice registry
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
WO2023185058A1 (fr) Procédé et système de déploiement de code de chaîne dans une chaîne de blocs de consortium
Sharma et al. A complete survey on software architectural styles and patterns
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
WO2023185055A1 (fr) Procédé et système de déploiement de code de chaîne dans une chaîne d'alliance
US11366703B2 (en) Dynamic application management across multi-cloud computing environment
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
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
Stoicescu et al. From design for adaptation to component-based resilient computing
Benomar et al. Deviceless: A serverless approach for the Internet of Things
JP2024503440A (ja) クラウドプラットフォームに構成されたデータセンタ上に継続的配信を介して配備されるサービスのシステム構成フリーズ及び変更管理
Sharma et al. Getting Started with Istio Service Mesh
Pham et al. Flexible deployment of component-based distributed applications on the Cloud and beyond
US20230376501A1 (en) Asik: modular interface to blockchain
Vettor et al. EDITION v1. 2
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: 22934872

Country of ref document: EP

Kind code of ref document: A1