A method, apparatus and device for deploying a consortium chain node

Abstract

The embodiments of the present specification disclose a deployment method, device and equipment of a consortium chain node. The scheme can include: a first blockchain service platform at a first institution having node management authority for a consortium chain network can obtain first communication address information of a first node device of a second institution and first network setting information of the consortium chain network, and generate a first node digital certificate of the first node device based on a CA certificate of the consortium chain network; thereby generating a first node installation file of the first node device according to the first network setting information, the first node digital certificate and the first communication address information; and sending the first node installation file to the second institution by using a non-public network transmission mode, so that the second institution deploys a consortium chain node based on the first node installation file.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a method, apparatus and device for deploying consortium blockchain nodes. Background Technology

[0002] A consortium blockchain is a type of blockchain that falls between public and private blockchains, possessing some decentralized characteristics. Its rapid adoption is due to its fewer nodes, faster processing speed, and lower transaction costs. Because consortium blockchains have an admission mechanism, permission credentials must be assigned to new nodes by the consortium blockchain administrator. Currently, when deploying consortium blockchain nodes across different regions, it is typically necessary to transmit the node deployment file carrying the permission credentials to the device used to deploy the new node over a public network environment.

[0003] Therefore, improving the security of the deployment process of consortium blockchain nodes has become an urgent technical problem to be solved. Summary of the Invention

[0004] This specification provides an embodiment of a method, apparatus, and device for deploying consortium blockchain nodes to improve the security of the deployment process.

[0005] To solve the above-mentioned technical problems, the embodiments in this specification are implemented as follows:

[0006] This specification provides an embodiment of a method for deploying consortium blockchain nodes, applied to a first blockchain service platform of a first institution, the first institution having node management authority over the consortium blockchain network, including:

[0007] Obtain the first communication address information of the first node device of the second organization;

[0008] Obtain the first node digital certificate of the first node device generated based on the CA certificate of the consortium blockchain network;

[0009] Obtain the first network configuration information of the consortium blockchain network;

[0010] Based on the first network settings information, the first node digital certificate, and the first communication address information, generate the first node installation file for the first node device;

[0011] Using a non-public network transmission method, the first node installation file is sent to the second blockchain service platform of the second institution; the second blockchain service platform is used to control the first node device to start the consortium blockchain node service based on the first node installation file.

[0012] This specification provides an embodiment of a method for deploying consortium blockchain nodes, applied to a second blockchain service platform of a second institution, comprising:

[0013] Obtain the device control permission information of the target node device of the second organization;

[0014] Obtain the node installation file of the target node device. The node installation file is a file generated by the first blockchain service platform of the first institution based on the network settings information of the consortium blockchain network, the CA certificate and the communication address information of the target node device. The node installation file is sent from the first blockchain service platform to the second blockchain service platform based on a non-public network transmission method. The first institution is an institution with node management authority over the consortium blockchain network.

[0015] Send the node installation file to the target node device;

[0016] Based on the device control permission information, a consortium blockchain node deployment instruction is sent to the target node device; the consortium blockchain node deployment instruction is used to control the target node device to start the consortium blockchain node service based on the node installation file.

[0017] This specification provides an embodiment of a consortium blockchain node deployment device, applied to a first blockchain service platform of a first institution, the first institution having node management authority over the consortium blockchain network, including:

[0018] The first acquisition module is used to acquire the first communication address information of the first node device of the second organization;

[0019] The second acquisition module is used to acquire the first node digital certificate of the first node device generated based on the CA certificate of the consortium blockchain network;

[0020] The third acquisition module is used to acquire the first network setting information of the consortium blockchain network;

[0021] The first file generation module is used to generate a first node installation file for the first node device based on the first network setting information, the first node digital certificate, and the first communication address information.

[0022] The first sending module is used to send the first node installation file to the second blockchain service platform of the second institution using a non-public network transmission method; the second blockchain service platform is used to control the first node device to start the consortium blockchain node service based on the first node installation file.

[0023] This specification provides an embodiment of a consortium blockchain node deployment device, applied to a second blockchain service platform of a second institution, comprising:

[0024] The first acquisition module is used to acquire the device control permission information of the target node device of the second organization;

[0025] The second acquisition module is used to acquire the node installation file of the target node device. The node installation file is a file generated by the first blockchain service platform of the first institution based on the network settings information of the consortium blockchain network, the CA certificate and the communication address information of the target node device. The node installation file is sent from the first blockchain service platform to the second blockchain service platform based on a non-public network transmission method. The first institution is an institution with node management authority over the consortium blockchain network.

[0026] The first sending module is used to send the node installation file to the target node device;

[0027] The second sending module is used to send a consortium blockchain node deployment instruction to the target node device based on the device control permission information; the consortium blockchain node deployment instruction is used to control the target node device to start the consortium blockchain node service based on the node installation file.

[0028] This specification provides an embodiment of a consortium blockchain node deployment device, applied to a device of a first organization having node management authority over a consortium blockchain network, comprising:

[0029] At least one processor; and,

[0030] A memory communicatively connected to the at least one processor; wherein,

[0031] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0032] Obtain the first communication address information of the first node device of the second organization;

[0033] Obtain the first node digital certificate of the first node device generated based on the CA certificate of the consortium blockchain network;

[0034] Obtain the first network configuration information of the consortium blockchain network;

[0035] Based on the first network settings information, the first node digital certificate, and the first communication address information, generate the first node installation file for the first node device;

[0036] Using a non-public network transmission method, the first node installation file is sent to the second blockchain service platform of the second institution; the second blockchain service platform is used to control the first node device to start the consortium blockchain node service based on the first node installation file.

[0037] This specification provides an embodiment of a consortium blockchain node deployment device, applied to a second organization's device, comprising:

[0038] At least one processor; and,

[0039] A memory communicatively connected to the at least one processor; wherein,

[0040] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0041] Obtain the device control permission information of the target node device of the second organization;

[0042] Obtain the node installation file of the target node device. The node installation file is a file generated by the first blockchain service platform of the first institution based on the network settings information of the consortium blockchain network, the CA certificate and the communication address information of the target node device. The node installation file is sent from the first blockchain service platform to the second blockchain service platform based on a non-public network transmission method. The first institution is an institution with node management authority over the consortium blockchain network.

[0043] Send the node installation file to the target node device;

[0044] Based on the device control permission information, a consortium blockchain node deployment instruction is sent to the target node device; the consortium blockchain node deployment instruction is used to control the target node device to start the consortium blockchain node service based on the node installation file.

[0045] At least one embodiment provided in this specification can achieve the following beneficial effects:

[0046] A first organization with node management authority over the consortium blockchain network can use a first blockchain service platform to generate a first node installation file for a second organization's first node device. This first node installation file is then sent to the second organization via a non-public network transmission method. This allows the second organization to use the second blockchain service platform to control the first node device to start the consortium blockchain node service based on the first node installation file. Since there is no need to transmit the node installation file to the device used to deploy the new consortium blockchain node via the public network, the security of the node installation file is improved, thereby enhancing the security of the consortium blockchain node deployment process. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This is a schematic diagram illustrating an application scenario of a method for deploying a consortium blockchain node, as described in the embodiments of this specification.

[0049] Figure 2 This is a flowchart illustrating a method for deploying a consortium blockchain node, as provided in an embodiment of this specification.

[0050] Figure 3 A flowchart illustrating another method for deploying a consortium blockchain node as provided in the embodiments of this specification;

[0051] Figure 4 The embodiments provided in this specification correspond to Figure 2 and Figure 3 A swimlane flowchart illustrating the deployment method of consortium blockchain nodes;

[0052] Figure 5 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of the structure of a deployment device for a consortium blockchain node;

[0053] Figure 6 The embodiments provided in this specification correspond to Figure 3 A schematic diagram of the structure of a deployment device for a consortium blockchain node;

[0054] Figure 7 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of the structure of a deployment device for a consortium blockchain node;

[0055] Figure 8 The embodiments provided in this specification correspond to Figure 3 A schematic diagram of the structure of a deployment device for a consortium blockchain node. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of one or more embodiments of this specification clearer, the technical solutions of one or more embodiments of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of one or more embodiments of this specification.

[0057] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0058] In existing technology, a blockchain can be understood as a data chain composed of multiple blocks stored sequentially. Each block's header contains a timestamp of the current block, the hash value of the previous block, and the hash value of the current block, thus enabling mutual verification between blocks and forming an immutable blockchain. Each block can be understood as a data block (a unit of data storage). As a decentralized database, a blockchain is a chain of data blocks linked together using cryptographic methods. Each data block contains information about a network transaction, used to verify the validity of the information (anti-counterfeiting) and generate the next block. The chain formed by linking blocks end-to-end constitutes the blockchain. If data within a block needs to be modified, the content of all subsequent blocks must be modified, and the data backed up by all nodes in the blockchain network must also be modified. Therefore, blockchains are difficult to tamper with or delete, and once data is stored on the blockchain, it is a reliable method for maintaining content integrity.

[0059] To address the shortcomings of existing technologies, this solution provides the following embodiments:

[0060] Figure 1 This is a schematic diagram illustrating an application scenario of a method for deploying a consortium blockchain node, as described in the embodiments of this specification.

[0061] like Figure 1 As shown, the first and second organizations can deploy consortium blockchain nodes in the consortium blockchain network 101, and these nodes can communicate with each other. The consortium blockchain nodes deployed by the first and second organizations can be either cloud nodes deployed based on computing resources from cloud services or physical nodes deployed based on computing resources from local physical devices; there is no specific limitation in this regard.

[0062] Assuming the first organization has management authority over nodes in the consortium blockchain network, when the second organization needs to deploy consortium blockchain nodes, it can use the first organization's device 102 to obtain the first communication address information of the second organization's first node device; obtain the first node digital certificate of the first node device generated based on the CA certificate of the consortium blockchain network 101; and obtain the first network setting information of the consortium blockchain network; thereby generating the first node installation file of the first node device based on the first network setting information, the first node digital certificate, and the first communication address information.

[0063] The device 102 of the first institution can also use a non-public network transmission method to send the first node installation file to the device 103 of the second institution, so that the device 103 of the second institution can use its built-in second blockchain service platform to control the first node device to start the consortium blockchain node service based on the first node installation file, thereby realizing the deployment of the consortium blockchain node for the second institution.

[0064] The consortium blockchain node deployment method provided in the embodiments of this specification involves the administrator of the consortium blockchain network generating an installation file for installing the consortium blockchain node, and transmitting the installation file to the device deploying the new consortium blockchain node via a non-public network. This improves the security of the installation file and thus enhances the security of the consortium blockchain node deployment process.

[0065] Next, a method for deploying a consortium blockchain node, as provided in the embodiments of the specification, will be described in detail with reference to the accompanying drawings:

[0066] Figure 2 This is a flowchart illustrating a method for deploying a consortium blockchain node, as provided in an embodiment of this specification. From a programmatic perspective, the entity executing this process can be a device of a first institution with node management authority over the consortium blockchain network, or an application of a first blockchain service platform mounted on the device of the first institution. The first blockchain service platform can be a platform where the first institution manages the consortium blockchain network and its nodes based on the node management authority; for example, a Blockchain as a Service (BaaS) platform.

[0067] like Figure 2 As shown, the process may include the following steps:

[0068] Step 202: Obtain the first communication address information of the first node device of the second organization.

[0069] In the embodiments described in this specification, the second organization is typically the organization that needs to deploy a new consortium blockchain node in the consortium blockchain network, while the first node device is typically the device that the second organization prepares to deploy the new consortium blockchain node. In practical applications, the first node device can be a physical device, such as a mobile phone or computer, or it can be a virtual device deployed on a physical device or cloud service, such as a virtual machine or a Docker container, etc., without specific limitations.

[0070] The first communication address information of the first node device can be used to enable other devices to establish communication connections with it. Subsequently, after deploying consortium blockchain nodes at the first node device, other consortium blockchain nodes can interact with these nodes based on this first communication address information. In practical applications, the first communication address information of the first node device is typically a wide area network (WAN) IP address.

[0071] Step 204: Obtain the first node digital certificate of the first node device generated based on the CA certificate of the consortium blockchain network.

[0072] In the embodiments described in this specification, due to the access control mechanism of the consortium blockchain network, digital certificate verification is required when deploying a new node in the consortium blockchain network. Simultaneously, since the first organization has node management authority over the consortium blockchain network, it can utilize the CA certificate of the consortium blockchain network to generate a first node digital certificate for the first node device, thereby granting the consortium blockchain node deployed at the first node device the permission to join the consortium blockchain network through this node digital certificate.

[0073] In practical applications, the CA certificate of the consortium blockchain network can be a root certificate issued by the Certificate Authority (CA) of the consortium blockchain network. Based on this CA certificate, the public key, private key, and basic information table of the consortium blockchain nodes to be deployed at the first node device can be generated. Then, a hash operation is performed on the public key and the basic information table to obtain a hash value. The hash value is then asymmetrically encrypted using the private key to obtain an encrypted hash value. Finally, the obtained public key, basic information table, and encrypted hash value are combined to generate the first node digital certificate. Of course, other existing technologies can also be used to generate the first node digital certificate based on the CA certificate of the consortium blockchain network, and no specific limitation is made thereto.

[0074] Step 206: Obtain the first network configuration information of the consortium blockchain network.

[0075] In the embodiments of this specification, the first network configuration information of the consortium blockchain network typically includes the basic configuration information of the consortium blockchain network and the basic configuration information of the consortium blockchain nodes to be deployed. For example, this includes the consortium blockchain network name, consensus protocol version, chaincode information, node type information of the consortium blockchain nodes to be deployed (e.g., consensus node, non-consensus node), communication address information, consensus queue parameters, and operating parameters. The first network configuration information can be set according to actual needs, and no specific limitations are imposed.

[0076] Step 208: Generate the first node installation file for the first node device based on the first network settings information, the first node digital certificate, and the first communication address information.

[0077] In the embodiments described in this specification, the first node installation file can be a node installation package required when deploying a consortium blockchain node on the first node device. This first node installation file typically carries the first node's digital certificate, as well as other executable files generated based on the first network settings information and the first communication address information. In practical applications, the first node installation file may also contain blockchain applications, such as blockchain chaincode, smart contract code, etc.

[0078] Step 210: Using a non-public network transmission method, send the first node installation file to the second blockchain service platform of the second institution; the second blockchain service platform is used to control the first node device to start the consortium blockchain node service based on the first node installation file.

[0079] In the embodiments of this specification, since public network transmission is vulnerable to hacker attacks and poses certain risks, and the first node installation file contains a first node digital certificate used to authenticate the newly added consortium blockchain node, if the first node digital certificate is stolen or tampered with during public network transmission, it will seriously affect the security of the consortium blockchain network and the credibility of node deployment.

[0080] Based on this, the first blockchain service platform of the first institution uses a non-public network transmission method to send the first node installation file to the second blockchain service platform of the second institution to improve the transmission security of the first node installation file. This will improve the security and feasibility of deploying consortium blockchain nodes on the first node device using the second blockchain service platform based on the first node installation file.

[0081] The second blockchain service platform of the second institution can be a platform used to manage its consortium blockchain nodes, such as a Blockchain as a Service (BaaS) platform, which is usually installed on the second institution's equipment.

[0082] In practical applications, there are various types of second blockchain service platforms. For example, if the consortium blockchain node to be deployed at the first node device of the second institution is a cloud node deployed based on cloud computing resources, then the second blockchain service platform can be a web application. Typically, the second blockchain service platform can be built by the cloud computing resource provider and authorized for use by the second institution. On the other hand, if the consortium blockchain node to be deployed at the first node device of the second institution is a physical node, then the second blockchain service platform can be an APP client on the device of the second institution. Typically, the second blockchain service platform can be deployed and used by the second institution itself based on the platform installation file.

[0083] In practical applications, there are various methods for non-public network transmission. For example, one method involves using a communication application to send the first node installation file to the device of the second institution; the device of the second institution then uploads the received first node installation file to the second blockchain service platform. This communication application can be an instant messaging application, email, or other forms of communication; there are no specific limitations. This leverages the communication application's inherent ability to enhance the security and privacy of data transmission, thereby improving the security and reliability of the first node installation file transmission process.

[0084] Alternatively, in method two, the first node installation file is stored on a physical storage device; the device of the second institution is used to upload the first node installation file read from the physical storage device to the second blockchain service platform. The physical storage device can be trusted hardware with a Trusted Execution Environment (TEE), thereby leveraging its tamper-proof function to enhance the security and trustworthiness of the first node installation file transmission process. Alternatively, the physical storage device can also be a common hardware storage device such as a USB flash drive or hard drive; there is no specific limitation. Since malicious actors typically cannot directly intercept the physical storage device, the security and trustworthiness of the first node installation file transmission process can be improved.

[0085] Method 3: Utilize a local area network (LAN) to send the first node installation file to the device of the second organization. In practical applications, when the device of the second organization and the device of the first organization are on the same LAN, the first node installation file can also be directly transmitted to the device of the second organization using that LAN.

[0086] It is worth noting that the second institution and the first institution can be either the same institution or different institutions, without specific limitations. When the second institution and the first institution are the same institution, the second blockchain service platform of the second institution and the first blockchain service platform of the first institution can be either the same platform or different platforms. For example, assuming that the second institution and the first institution are the same institution, and the first blockchain service platform is a platform used to manage the cloud nodes of the first institution in the consortium blockchain network, but the first node device needs to deploy physical nodes in the consortium blockchain network, then the second blockchain service platform can be a platform used to deploy and manage physical nodes, thus making the second blockchain service platform a different platform from the first blockchain service platform. However, if the second blockchain service platform and the first blockchain service platform are the same platform, then step 210 can be skipped, and after generating the first node installation file for the first node device in step 208, the first node installation file can be directly sent to the first node device.

[0087] In the embodiments described in this specification, Figure 2 The method involves a first blockchain platform generating a node installation file for a consortium blockchain node to be deployed, and then transmitting the generated node installation file to a second institution via a non-public network. This allows the second institution to deploy the consortium blockchain node itself using a second blockchain service platform based on the node installation file, thereby improving the security of the node installation file transmission and thus enhancing the security of the consortium blockchain node deployment process.

[0088] based on Figure 2 In addition to the method described in the embodiments of this specification, some specific implementation schemes of the method are also provided, which will be described below.

[0089] In the embodiments described in this specification, the consortium blockchain node installation package typically includes a consortium blockchain service configuration file, a genesis block configuration file, and a node digital certificate, so as to enable the blockchain service to be started based on the consortium blockchain service configuration file and the genesis block configuration file, and to prove that it has the right to join the consortium blockchain network based on the node digital certificate.

[0090] Based on this, step 208: generating the first node installation file for the first node device according to the first network setting information, the first node digital certificate, and the first communication address information specifically includes:

[0091] Based on the first network settings information and the first communication address information, generate the first consortium blockchain service configuration file and the first genesis block configuration file for the first node device;

[0092] Based on the first consortium blockchain service configuration file, the first genesis block configuration file, and the first node digital certificate, the first node installation file of the first node device is generated.

[0093] In the embodiments of this specification, consortium blockchain nodes typically require extensive configuration processing during startup, such as configuring node operating parameters, node operating environment, consensus mechanism, and interface access. Based on this, a first consortium blockchain service configuration file can be included in the first node installation file, so that when the first node device deploys the consortium blockchain node, it can automatically complete the corresponding configuration processing operations by running the first consortium blockchain service configuration file.

[0094] In the embodiments of this specification, the first block constructed in the consortium blockchain network can be called the genesis block. The genesis block can usually be generated by running the genesis block configuration file. Based on this, the first genesis block configuration file can be carried in the first node installation file so that when the first node device deploys the consortium blockchain node, it can generate the genesis block at the consortium blockchain node by running the first genesis block configuration file.

[0095] In practical applications, each node in a consortium blockchain network maintains its own ledger, recording every transaction that occurs within the network. Therefore, when deploying a new consortium blockchain node, a ledger data synchronization operation is required to obtain existing ledger data from other nodes, facilitating subsequent consensus processing. This ledger data synchronization method necessitates data interaction between the new node and other consortium blockchain nodes, resulting in significant consumption of device resources.

[0096] Based on this, some initial ledger data of the consortium blockchain network can be directly carried in the node installation package, so that newly added consortium blockchain nodes do not need to obtain this initial ledger data from other consortium blockchain nodes, thereby reducing the resources consumed during ledger data synchronization.

[0097] Based on this, before generating the first node installation file for the first node device according to the first consortium blockchain service configuration file, the first genesis block configuration file, and the first node digital certificate, the process further includes:

[0098] Obtain the initial ledger data of the consortium blockchain network;

[0099] The step of generating the first node installation file for the first node device based on the first consortium blockchain service configuration file, the first genesis block configuration file, and the first node digital certificate specifically includes:

[0100] The initial ledger data, the first consortium blockchain service configuration file, the first genesis block configuration file, and the first node digital certificate are compressed to obtain the compressed first node installation file for the first node device.

[0101] In this embodiment, the initial ledger data can be all or part of the ledger data already generated in the consortium blockchain network when the first node installation file is generated. In practical applications, the initial ledger data typically includes genesis block data generated based on the first genesis block configuration file. Therefore, when the first node device deploys a consortium blockchain node based on the first node installation file, it can generate genesis block data by running the first genesis block configuration file and obtain the ledger data already generated in the consortium blockchain network by synchronizing ledger data with other consortium blockchain nodes. Alternatively, the first node device can directly use the initial ledger data to reduce the amount of ledger data that needs to be synchronized, which not only improves node deployment efficiency but also saves device resources.

[0102] In practical applications, the consortium blockchain node deployed at the first node device can be a cloud node or a physical node. The contents of the first node installation file generated by the first blockchain service platform for cloud nodes and physical nodes are usually the same, but the same or different naming methods can be used according to actual needs, and no specific limitation is made on this.

[0103] In the embodiments described in this specification, the first institution typically needs to pre-deploy consortium blockchain nodes in the consortium blockchain network to obtain node management permissions for the consortium blockchain network. Therefore, the embodiments described in this specification also provide an implementation method for the first institution to pre-deploy its consortium blockchain nodes using a first blockchain service platform.

[0104] Specifically, before step 202: obtaining the first communication address information of the first node device of the second organization, it may also include:

[0105] Obtain the second communication address information and device control permission information of the second node device of the first organization;

[0106] Obtain the second network configuration information and CA file of the consortium blockchain network;

[0107] Based on the second network settings information, the CA file, and the second communication address information, generate the second node installation file for the second node device;

[0108] Send the second node installation file to the second node device;

[0109] Based on the device control permission information, a consortium blockchain node deployment instruction is sent to the second node device; the consortium blockchain node deployment instruction is used to control the second node device to start the consortium blockchain node service based on the second node installation file.

[0110] In the embodiments of this specification, when the first organization deploys a consortium blockchain node using an existing BaaS platform, after sending the node installation file to the node device, the blockchain service needs to be started manually by entering command lines at the node device. This is not only inconvenient but also requires a high level of technical expertise from the staff. Therefore, the embodiments of this specification provide a first blockchain service platform that simplifies the manual operation during node deployment. This first blockchain service platform can be generated by improving the existing BaaS platform. It can control the second node device to automatically start the consortium blockchain node service based on the device control permission information of the second node device, without requiring staff to enter command lines at the second node device to start the consortium blockchain node service, thereby simplifying the node deployment operation.

[0111] The device control permission information can be the information that grants the first blockchain service platform control over the second node device. For example, knowing the SSH (Secure Shell) account and password (and of course, the IP address and open SSH ports of the corresponding control device) allows the platform to log in to the device via an SSH client and remotely control it. Therefore, the SSH account and password information can serve as control permission information. Of course, control permission information can also be other types of information; there are no specific limitations on this.

[0112] In practical applications, the consortium blockchain nodes deployed at the second node device can be either cloud nodes or physical nodes. If the consortium blockchain nodes to be deployed at the second node device are cloud nodes deployed based on cloud computing resources, then the first blockchain service platform can be a web application. Typically, the first blockchain service platform can be built by the cloud computing resource provider and authorized for use by the first institution. However, if the consortium blockchain nodes to be deployed at the second node device are physical nodes, then the first blockchain service platform can be an APP client on the device of the first institution. Typically, the first blockchain service platform can be deployed and used by the first institution itself based on the platform installation files.

[0113] In the embodiments of this specification, if the consortium blockchain node deployed by the first institution is the genesis node, that is, the first node to join the consortium blockchain network, the first institution usually needs to obtain the CA file of the consortium blockchain network, the second communication address information of the second node device, and the second network setting information of the consortium blockchain network, in order to generate the second node installation file of the second node device.

[0114] The CA file can be either automatically provided by the first blockchain service platform or uploaded by the user; no specific limitation is made. The second communication address information of the second node device can be used to enable other devices to establish communication connections with it. Subsequently, after deploying consortium blockchain nodes at the second node device, other consortium blockchain nodes can interact with these nodes based on the second communication address information. In practical applications, the second communication address information of the second node device is typically a Wide Area Network (WAN) IP address.

[0115] The second network configuration information can be set according to the actual needs of the consortium blockchain network and nodes to be deployed by the first institution. This second network configuration information may or may not be identical to the aforementioned first network configuration information. For ease of understanding, an example is provided: the consortium blockchain network name information in the second network configuration information is usually the same as that in the first network configuration information. Alternatively, if the node parameters to be deployed by the first and second institutions are the same, then the consensus queue parameters and operating parameters in the second network configuration information can also be the same as those in the first network configuration information; otherwise, the consensus queue parameters and operating parameters in the two can be different.

[0116] In this embodiment of the specification, the specific process of generating the second node installation file for the second node device based on the second network setting information, the CA file, and the second communication address information may include:

[0117] Based on the second network settings information and the second communication address information, generate the second consortium blockchain service configuration file and the second genesis block configuration file for the second node device;

[0118] Generate a CA certificate for the consortium blockchain network based on the CA file;

[0119] Based on the CA certificate of the consortium blockchain network, a second node digital certificate is generated for the second node device;

[0120] Based on the second consortium blockchain service configuration file, the second genesis block configuration file, and the second node digital certificate, the second node installation file for the second node device is generated.

[0121] In this embodiment of the specification, since it is necessary to deploy a consortium blockchain node at the second node device, it is also typically necessary to generate a second node digital certificate for the second node device. If the node deployed at the second node device is a genesis node, it is usually necessary to generate a CA certificate for the consortium blockchain network using a CA file; and based on the CA certificate of the consortium blockchain network, generate a second node digital certificate for the second node device. In practical applications, the second node digital certificate of the second node device can be the public and private key certificates of the consortium blockchain node to be deployed at the second node device.

[0122] In the embodiments described in this specification, the generation principle and function of the second consortium blockchain service configuration file are generally the same as those of the aforementioned first consortium blockchain service configuration file, and will not be elaborated upon further. In practical applications, the second node installation file may also contain blockchain applications, such as blockchain chaincode and smart contract code.

[0123] In the embodiments described in this specification, the first blockchain service platform typically needs to send multiple instructions to the second node device to complete the deployment of the consortium blockchain node. This will be explained for ease of understanding.

[0124] Specifically, sending the consortium blockchain node deployment instruction to the second node device based on the device control permission information may include:

[0125] Based on the device control permission information, an environment variable configuration instruction is sent to the second node device; the second node device is used to respond to the environment variable configuration instruction, perform an environment variable configuration operation based on the second consortium blockchain service configuration file, and obtain the configured environment variable information;

[0126] A genesis block generation command is sent to the second node device; the second node device is used to respond to the genesis block generation command, perform a genesis block generation operation based on the second genesis block configuration file, and obtain genesis block information;

[0127] A node service startup command is sent to the second node device; the second node device is used to respond to the node service startup command and perform a node service initiation operation based on the configured environment variable information, the genesis block information and the second node digital certificate to start the consortium blockchain node service.

[0128] In the embodiments of this specification, when deploying a consortium blockchain node, it is usually necessary to configure the deployment environment of the consortium blockchain node first. For example, for the file generation directory in the installation file of the second node, set the corresponding permissions for users and consortium blockchain nodes, and check whether the hardware resources and application running environment meet the requirements. Based on this, the first blockchain service platform can send environment variable configuration instructions to the second node device, and remotely control the second node device to execute the environment variable configuration instructions based on the device control permission information, thereby automatically completing the environment configuration.

[0129] Since a genesis block is usually generated before the genesis node is started, the first blockchain service platform can also send a genesis block generation instruction to the second node device and remotely control the second node device to execute the genesis block generation instruction based on the device control permission information, thereby automatically generating genesis block information.

[0130] After preparing the environment and data required for the operation of the consortium blockchain node, the first blockchain service platform can send a node service start command to the second node device and, based on the device control permission information, remotely control the second node device to execute the node service start command, thereby automatically starting the consortium blockchain node service by running a blockchain application.

[0131] In this embodiment, the user can trigger a designated control (e.g., a node deployment button) in the operation interface of the first blockchain service platform to enable the first blockchain service platform to receive the user's node deployment instruction. Subsequently, the first blockchain service platform can respond to the node deployment instruction and automatically send multiple instructions to the second node device to start the consortium blockchain node service, without the user having to manually enter command lines at the second node device to start the consortium blockchain node service, thereby improving the convenience of the user's operation when deploying nodes.

[0132] In practical applications, packaging and compressing multiple files reduces disk space usage and facilitates data transfer.

[0133] Based on this, according to the second consortium blockchain service configuration file, the second genesis block configuration file, and the second node digital certificate, a second node installation file for the second node device is generated, which may specifically include:

[0134] The second consortium blockchain service configuration file, the second genesis block configuration file, and the second node digital certificate are compressed to generate a compressed second node installation file.

[0135] Correspondingly, based on the device control permission information, sending the consortium blockchain node deployment instruction to the second node device also includes:

[0136] Based on the device control permission information, a decompression command is sent to the second node device. The second node device, in response to the decompression command, performs a decompression operation on the compressed second node installation file. This allows the second node device to obtain the decompressed second node installation file and start the consortium blockchain node service based on it.

[0137] In the embodiments described in this specification, after deploying consortium blockchain nodes, it may also be necessary to monitor the operation of the consortium blockchain network and the consortium blockchain nodes in order to detect and handle abnormal issues in a timely manner.

[0138] Based on this, after sending the consortium blockchain node deployment instruction to the second node device, it may also include:

[0139] Obtain the first operational indicator data of the consortium blockchain node deployed at the second node device;

[0140] Based on the first operational metric data, determine the first operational status information of the consortium blockchain node. And / or

[0141] Obtain the second operational metric data of the consortium blockchain network;

[0142] Based on the second operational indicator data, the second operational status information of the consortium blockchain network is determined.

[0143] In practical applications, the first operational metrics data may include: node performance metrics, which may include, but are not limited to: the process working status (alive or not alive) of the consortium blockchain node service, block size, block height, block production time, block production time, transaction throughput, transaction response time, transaction pool capacity, transaction queue capacity, transaction failure rate, and pending transaction volume.

[0144] Secondary operational metrics for consortium blockchain networks may include: transactions per second, number of hit / missed requests, number of active peers, etc.

[0145] In the embodiments of this specification, since the operational metrics data of the consortium blockchain network and consortium blockchain nodes can usually reflect the operational status of the consortium blockchain network and consortium blockchain nodes, the first organization also needs to monitor the operation of the consortium blockchain network and consortium blockchain nodes after deployment, so as to detect and handle abnormal problems in a timely manner, thereby helping to maintain the normal operation of the consortium blockchain network.

[0146] In this embodiment of the specification, after obtaining the first communication address information of the first node device of the second institution, it is also necessary to store the obtained first communication address information in the consortium blockchain network so that nodes in the consortium blockchain network can communicate with newly deployed nodes at the first node device based on the first communication address, thereby activating the newly deployed nodes. However, in practical applications, network failures and other factors may cause nodes in the consortium blockchain network to be unable to communicate with the newly deployed nodes at the first node device, resulting in node activation failure.

[0147] Based on this, after obtaining the first communication address information of the first node device of the second organization, the method further includes:

[0148] Store the first communication address information of the first node device in the consortium blockchain network;

[0149] Based on the first communication address information, a target blockchain transaction is generated; the target blockchain transaction is used to change the running status of the consortium blockchain node deployed at the first node device to an active state;

[0150] Send the target blockchain transaction to the consortium blockchain network.

[0151] In the embodiments described in this specification, the initialization state of newly deployed nodes in the consortium blockchain network is usually inactive by default. Newly added consortium blockchain nodes can be activated through a consensus mechanism. That is, after the newly added consortium blockchain node completes blockchain data synchronization, it can actively send a transaction request to activate the node to the consortium blockchain network, so that the existing consensus nodes in the consortium blockchain network can set the state of the newly added consortium blockchain node to active after completing consensus on the transaction request.

[0152] In practical applications, if a newly added consortium blockchain node cannot be activated automatically based on the consensus mechanism due to network failure, it can be activated manually. That is, a first institution can generate a target blockchain transaction to change the running status of the consortium blockchain node deployed at the first node device to an active state, and send the target blockchain transaction to the consortium blockchain network for storage, thereby manually activating the newly deployed consortium blockchain node at the first node device.

[0153] Based on and Figure 1 Following the same approach as the scheme shown, this specification also provides another method for deploying consortium blockchain nodes. Figure 3This is a flowchart illustrating another method for deploying consortium blockchain nodes provided in the embodiments of this specification. The execution entity of this process can be the device of a second institution that needs to deploy nodes in the consortium blockchain network, or the application of a second blockchain service platform mounted on the device of the second institution. The second blockchain service platform can be a platform used by the second institution to manage the consortium blockchain network and its nodes, such as a Blockchain as a Service (BaaS) platform.

[0154] like Figure 3 As shown, the process may include the following steps:

[0155] Step 302: Obtain the device control permission information of the target node device of the second organization.

[0156] In the embodiments described in this specification, the second organization is typically the organization that needs to deploy a new consortium blockchain node in the consortium blockchain network, while the target node device is typically the device that the second organization prepares to deploy the new consortium blockchain node. In practical applications, the target node device can be a physical device, such as a mobile phone or computer, or it can be a virtual device deployed on a physical device or cloud service, such as a virtual machine or a Docker container, etc., without specific limitations.

[0157] In the embodiments of this specification, when a second organization deploys a consortium blockchain node using an existing BaaS platform, after sending the target node installation file to the target node device, it typically requires manual intervention by entering command lines on the target node device to start the blockchain service. This is not only inconvenient but also requires a high level of technical expertise from the staff. Therefore, the embodiments of this specification provide a second blockchain service platform that simplifies the manual operation during target node deployment. This second blockchain service platform can be generated by improving the existing BaaS platform. It can automatically start the consortium blockchain node service based on the device control permission information of the target node device, eliminating the need for staff to manually enter command lines to start the service, thus simplifying node deployment. The device control permission information can be information that grants the second blockchain service platform control over the target node device, such as SSH (Secure Shell) account and password information.

[0158] In practical applications, if the target node device needs to deploy cloud nodes, the second blockchain service platform can be a web application. Typically, the second blockchain service platform can be built by the cloud computing resource provider and authorized for use by the second organization. If the target node device needs to deploy physical nodes, the second blockchain service platform can be an APP client on the second organization's device. Typically, the second blockchain service platform can be deployed and used by the second organization itself based on the platform installation files.

[0159] Step 304: Obtain the node installation file of the target node device. The node installation file is generated by the first blockchain service platform of the first institution based on the network settings information of the consortium blockchain network, the CA certificate and the communication address information of the target node device. The node installation file is sent from the first blockchain service platform to the second blockchain service platform based on a non-public network transmission method. The first institution is an institution with node management authority over the consortium blockchain network.

[0160] In the embodiments described in this specification, the node installation file of the target node device can be the node installation package required when deploying a consortium blockchain node on the target node device. The node installation file of the target node device is... Figure 2 The first node installation file of the first node device generated by the Chinese method is used. Therefore, the generation principle, included information, and transmission method of the node installation file of the target node device will not be elaborated upon. Please refer to [reference needed]. Figure 2 The embodiments of the method are sufficient.

[0161] Step 306: Send the node installation file to the target node device.

[0162] Step 308: Based on the device control permission information, send a consortium blockchain node deployment instruction to the target node device; the consortium blockchain node deployment instruction is used to control the target node device to start the consortium blockchain node service based on the node installation file.

[0163] Figure 3 The method described requires a second organization deploying consortium blockchain network nodes to obtain the target node installation files via a non-public network. This prevents the installation files from being stolen or tampered with during public network transmission, thereby improving the security of the consortium blockchain network and the trustworthiness of node deployment. Simultaneously, since the second blockchain service platform can automatically start the consortium blockchain node service based on the target node's device control permission information, it eliminates the need for staff to manually input command lines at the target node, thus simplifying node deployment operations.

[0164] In the embodiments described in this specification, the second blockchain service platform typically needs to send multiple instructions to the target node device to complete the deployment of the consortium blockchain node. For ease of understanding, this will be explained.

[0165] Specifically, the node installation files of the target node device may include: consortium blockchain service configuration files and node digital certificates.

[0166] The step of sending the consortium blockchain node deployment instruction to the target node device based on the device control permission information may include:

[0167] Based on the device control permission information, an environment variable configuration instruction is sent to the target node device; the target node device responds to the environment variable configuration instruction by performing an environment variable configuration operation based on the consortium blockchain service configuration file to obtain the configured environment variable information.

[0168] A node service startup command is sent to the target node device; the target node device is used to respond to the node service startup command and perform a node service initiation operation based on the configured environment variable information and the node digital certificate to start the consortium blockchain node service.

[0169] In the embodiments of this specification, when deploying a consortium blockchain node, it is usually necessary to configure the deployment environment of the consortium blockchain node first. For example, for the file generation directory in the target node installation file, set the corresponding permissions for users and consortium blockchain nodes, and check whether the hardware resources and application running environment meet the requirements. Based on this, the second blockchain service platform can send environment variable configuration instructions to the target node device, and remotely control the target node device to execute the environment variable configuration instructions based on the device control permission information, thereby automatically completing the environment configuration.

[0170] After preparing the environment and data required for the operation of the consortium blockchain node, the second blockchain service platform can send a node service start command to the target node device and, based on the device control permission information, remotely control the target node device to execute the node service start command, thereby automatically starting the consortium blockchain node service by running a blockchain application.

[0171] In this embodiment, the user can trigger a designated control (e.g., a node deployment button) in the operation interface of the second blockchain service platform to enable the second blockchain service platform to receive the user's node deployment instruction. Subsequently, the second blockchain service platform can respond to the node deployment instruction and automatically send multiple instructions to the target node device to start the consortium blockchain node service, without the user having to manually enter command lines at the target node device to start the consortium blockchain node service, thereby improving the convenience of the user's operation when deploying nodes.

[0172] In this embodiment of the specification, the node installation file of the target node device may further include a genesis block configuration file. This allows the target node device to generate the genesis block at the consortium blockchain node by running the genesis block configuration file when it receives a deployment instruction.

[0173] Based on this, the step of sending the consortium blockchain node deployment instruction to the target node device based on the device control permission information may further include:

[0174] A genesis block generation instruction is sent to the target node device; the target node device is used to respond to the genesis block generation instruction, perform a genesis block generation operation based on the genesis block configuration file, and obtain genesis block information.

[0175] The target node device is specifically used to respond to the node service startup command and perform a node service revelation operation based on the configured environment variable information, the node digital certificate, and the genesis block information to start the consortium blockchain node service.

[0176] In this embodiment, since a genesis block is typically generated before starting the genesis node, the second blockchain service platform can also send a genesis block generation instruction to the target node device and, based on the device control permission information, remotely control the target node device to execute the genesis block generation instruction, thereby automatically generating the genesis block information. After preparing the environment and data required for the consortium blockchain node to run, the target node device can execute the node service start instruction sent by the second blockchain service platform to automatically start the consortium blockchain node service.

[0177] In practical applications, each node in a consortium blockchain network maintains its own ledger, recording every transaction that occurs within the network. Therefore, when deploying a new consortium blockchain node, a ledger data synchronization operation is required to obtain existing ledger data from other nodes, facilitating subsequent consensus processing. This ledger data synchronization method necessitates data interaction between the new node and other consortium blockchain nodes, resulting in significant consumption of device resources.

[0178] Based on this, some initial ledger data of the consortium blockchain network can be directly carried in the node installation package, so that newly added consortium blockchain nodes do not need to obtain this initial ledger data from other consortium blockchain nodes, thereby reducing the resources required for ledger data synchronization.

[0179] Based on this, the node installation file may also include: the initial ledger data of the consortium blockchain network.

[0180] The target node device is specifically used to respond to the node service startup command by performing a node service initiation operation based on the configured environment variable information, the node digital certificate, and the initial ledger data to start the consortium blockchain node service.

[0181] In practical applications, packaging and compressing multiple files reduces disk space usage and facilitates data transfer. Therefore, the node installation file for the target node device can be a compressed file.

[0182] Correspondingly, based on the device control permission information, sending the consortium blockchain node deployment instruction to the target node device also includes:

[0183] Based on the device control permission information, a decompression command is sent to the target node device; the target node device responds to the decompression command by performing a decompression operation on the compressed file. This allows the target node device to obtain the decompressed target node installation file and start the consortium blockchain node service based on the decompressed target node installation file.

[0184] In the embodiments described in this specification, after deploying consortium blockchain nodes, it may also be necessary to monitor the operation of the consortium blockchain network and the consortium blockchain nodes in order to detect and handle abnormal issues in a timely manner.

[0185] Based on this, after sending the consortium blockchain node deployment instruction to the target node device based on the device control permission information, the method further includes:

[0186] Obtain the operational metrics data of the consortium blockchain nodes deployed at the target node device;

[0187] Based on the operational indicator data, the operational status information of the consortium blockchain node is determined.

[0188] In practical applications, the operational metrics data of the consortium blockchain node may include: node performance metrics and / or data and node computing resource metrics data. The node performance metrics data may include, but are not limited to: the process working status (alive or not alive) of the consortium blockchain node service, block size, block height, block production time, block production time, transaction throughput, transaction response time, transaction pool capacity, transaction queue capacity, transaction failure rate, number of pending transactions, CPU utilization, CPU idle percentage, physical memory consumption, and hard disk idleness.

[0189] Since some of the operational metrics of consortium blockchain nodes can directly reflect their operational status, a second organization can monitor the operational metrics of newly deployed consortium blockchain nodes to ensure the normal operation of the consortium blockchain nodes and the consortium blockchain network.

[0190] Figure 4 The embodiments provided in this specification correspond to Figure 2 and Figure 3 The diagram illustrates the swimlane flow of the consortium blockchain node deployment method. This deployment process may involve executive entities such as a first organization and a second organization.

[0191] In the embodiments described in this specification, the first organization typically needs to pre-deploy consortium blockchain nodes in the consortium blockchain network in order to obtain node management permissions for the consortium blockchain network.

[0192] Based on this, when the first institution needs to deploy a consortium blockchain node, during the node installation file generation stage, it can utilize the first blockchain service platform mounted on the first institution's device to first obtain the second communication address information and device control permission information of the first institution's second node device; and obtain the second network setting information and CA file of the consortium blockchain network, thereby generating the second node installation file of the second node device based on the second network setting information, the CA file and the second communication address information.

[0193] During the node service startup phase, the first blockchain service platform can send the second node installation file to the second node device via a local area network, and send a consortium blockchain node deployment instruction to the second node device based on the device control permission information of the second node device, so that the second node device can automatically start the consortium blockchain node service based on the second node installation file according to the consortium blockchain node deployment instruction.

[0194] When the second organization needs to deploy a consortium blockchain node, during the node installation file generation phase, the first blockchain service platform can obtain the first communication address information of the second organization's first node device; and obtain the first node digital certificate of the first node device and the first network settings information of the consortium blockchain network. Therefore, based on the first network settings information, the first node digital certificate, and the first communication address information, the first node installation file for the first node device can be generated. Furthermore, the first node installation file can be sent to the second organization using a non-public network transmission method.

[0195] During the node service startup phase, the second organization can use the second blockchain service platform mounted on its device to obtain the device control permission information of the target node device (e.g., the first node device) and the node installation file (e.g., the first node installation file) of the target node device. Then, it can send the node installation file to the target node device through the local area network so that, based on the device control permission information, it can send the consortium blockchain node deployment instruction to the target node device, thereby enabling the target node device to automatically start the consortium blockchain node service based on the node installation file according to the node deployment instruction.

[0196] Figure 4 The proposed solution transmits the node installation files required for deploying each consortium blockchain node via a non-public network, preventing the theft or tampering of these files during public network transmission. This enhances the security of the consortium blockchain network and the reliability of node deployment. Furthermore, since both the first and second blockchain service platforms can automatically control the nodes to start the consortium blockchain service based on their device control permissions, staff no longer need to manually input command lines at the nodes. This simplifies node deployment operations for staff at both organizations.

[0197] Based on the same idea, embodiments of this specification also provide apparatus corresponding to the above methods. Figure 5 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of the structure of a deployment device for a consortium blockchain node. (See diagram below.) Figure 5 As shown, the deployment device can be applied to the equipment of the first institution, or the first blockchain service platform mounted on the equipment of the first institution may include:

[0198] The first acquisition module 502 is used to acquire the first communication address information of the first node device of the second organization.

[0199] The second acquisition module 504 is used to acquire the first node digital certificate of the first node device generated based on the CA certificate of the consortium blockchain network.

[0200] The third acquisition module 506 is used to acquire the first network setting information of the consortium blockchain network.

[0201] The first file generation module 508 is used to generate a first node installation file for the first node device based on the first network setting information, the first node digital certificate, and the first communication address information.

[0202] The first sending module 510 is used to send the first node installation file to the second blockchain service platform of the second institution using a non-public network transmission method; the second blockchain service platform is used to control the first node device to start the consortium blockchain node service based on the first node installation file.

[0203] based on Figure 5 The embodiments of this specification also provide some specific implementations of the device, which will be described below.

[0204] Optionally, the first file generation module 508 may also include:

[0205] The first configuration file generation unit is used to generate the first consortium blockchain service configuration file and the first genesis block configuration file of the first node device based on the first network setting information and the first communication address information.

[0206] The first installation file generation unit is used to generate the first node installation file of the first node device based on the first consortium blockchain service configuration file, the first genesis block configuration file, and the first node digital certificate.

[0207] Optional, Figure 5 The device may further include:

[0208] The fourth acquisition module is used to acquire the initial ledger data of the consortium blockchain network.

[0209] Optionally, the file generation unit is specifically used to: compress the initial ledger data, the first consortium blockchain service configuration file, the first genesis block configuration file, and the first node digital certificate to obtain the compressed first node installation file of the first node device.

[0210] Optional, Figure 5 The device may further include:

[0211] The fifth acquisition module is used to acquire the second communication address information and device control permission information of the second node device of the first organization.

[0212] The sixth acquisition module is used to acquire the second network setting information and CA file of the consortium blockchain network.

[0213] The second file generation module is used to generate a second node installation file for the second node device based on the second network setting information, the CA file, and the second communication address information.

[0214] The second sending module is used to send the second node installation file to the second node device.

[0215] The third sending module is used to send a consortium blockchain node deployment instruction to the second node device based on the device control permission information; the consortium blockchain node deployment instruction is used to control the second node device to start the consortium blockchain node service based on the second node installation file.

[0216] Optionally, the second file generation module may include:

[0217] The second configuration file generation unit is used to generate the second consortium blockchain service configuration file and the second genesis block configuration file of the second node device based on the second network setting information and the second communication address information.

[0218] The CA certificate generation unit is used to generate the CA certificate for the consortium blockchain network based on the CA file.

[0219] The digital certificate generation unit is used to generate a second node digital certificate for the second node device based on the CA certificate of the consortium blockchain network.

[0220] The second installation file generation unit is used to generate the second node installation file of the second node device based on the second consortium blockchain service configuration file, the second genesis block configuration file, and the second node digital certificate.

[0221] Optionally, a third sending module may include:

[0222] An environment configuration instruction sending unit is used to send an environment variable configuration instruction to the second node device based on the device control permission information; the second node device is used to respond to the environment variable configuration instruction, perform an environment variable configuration operation based on the second consortium blockchain service configuration file, and obtain the configured environment variable information.

[0223] The genesis block instruction sending unit is used to send a genesis block generation instruction to the second node device; the second node device is used to respond to the genesis block generation instruction, perform a genesis block generation operation based on the second genesis block configuration file, and obtain genesis block information.

[0224] A service startup instruction sending unit is used to send a node service startup instruction to the second node device; the second node device is used to respond to the node service startup instruction and perform a node service initiation operation based on the configured environment variable information, the genesis block information and the second node digital certificate to start the consortium blockchain node service.

[0225] Optionally, the second installation file generation unit may include:

[0226] The first compression subunit is used to compress the second consortium blockchain service configuration file, the second genesis block configuration file, and the second node digital certificate to generate a compressed second node installation file.

[0227] Optionally, the third sending module may also include:

[0228] The decompression command sending unit is used to send a decompression command to the second node device based on the device control permission information; the second node device is used to respond to the decompression command and perform a decompression operation on the compressed second node installation file.

[0229] Optional, Figure 5 The device may further include:

[0230] The seventh acquisition module is used to acquire the first operational indicator data of the consortium blockchain node deployed at the second node device;

[0231] The first state determination module is used to determine the first operating state information of the consortium blockchain node based on the first operating indicator data.

[0232] Optional, Figure 5 The device may further include:

[0233] The eighth acquisition module is used to acquire the second operational indicator data of the consortium blockchain network.

[0234] The second state determination module is used to determine the second operating state information of the consortium blockchain network based on the second operating indicator data.

[0235] Optionally, the consortium blockchain node deployed at the first node device can be a cloud node or a physical node; the consortium blockchain node deployed at the second node device can be a cloud node or a physical node.

[0236] Optional, Figure 5 The device may further include:

[0237] The storage module is used to store the first communication address information of the first node device to the consortium blockchain network.

[0238] The transaction generation module is used to generate a target blockchain transaction based on the first communication address information; the target blockchain transaction is used to change the running status of the consortium blockchain node deployed at the first node device to an active state.

[0239] The fourth sending module is used to send the target blockchain transaction to the consortium blockchain network.

[0240] Optionally, the first transmitting module may include:

[0241] The first sending unit is used to send the first node installation file to the device of the second institution using a communication application; the device of the second institution is used to upload the received first node installation file to the second blockchain service platform; or...

[0242] The second sending unit is used to store the first node installation file to a physical storage device; the device of the second organization is used to upload the first node installation file read from the physical storage device to the second blockchain service platform.

[0243] Based on the same idea, embodiments of this specification also provide apparatus corresponding to the above methods. Figure 6 The embodiments provided in this specification correspond to Figure 3 A schematic diagram of the structure of a deployment device for a consortium blockchain node. (See diagram below.) Figure 6 As shown, the deployment device can be applied to a second structural device, or to an application of a second blockchain service platform mounted on the device of a second institution, which may include:

[0244] The first acquisition module 602 is used to acquire the device control permission information of the target node device of the second organization.

[0245] The second acquisition module 604 is used to acquire the node installation file of the target node device. The node installation file is a file generated by the first blockchain service platform of the first institution based on the network settings information of the consortium blockchain network, the CA certificate and the communication address information of the target node device. The node installation file is sent from the first blockchain service platform to the second blockchain service platform based on a non-public network transmission method. The first institution is an institution with node management authority over the consortium blockchain network.

[0246] The first sending module 606 is used to send the node installation file to the target node device.

[0247] The second sending module 608 is used to send a consortium blockchain node deployment instruction to the target node device based on the device control permission information; the consortium blockchain node deployment instruction is used to control the target node device to start the consortium blockchain node service based on the node installation file.

[0248] based on Figure 6 The embodiments of this specification also provide some specific implementations of the device, which will be described below.

[0249] Optionally, the second acquisition module 604 may include:

[0250] The first acquisition unit is used to acquire the consortium blockchain service configuration file.

[0251] The second acquisition unit is used to acquire the node's digital certificate.

[0252] Optionally, the second transmitting module 608 may include:

[0253] An environment configuration instruction sending unit is used to send an environment variable configuration instruction to the target node device based on the device control permission information; the target node device is used to respond to the environment variable configuration instruction, perform an environment variable configuration operation based on the consortium blockchain service configuration file, and obtain the configured environment variable information.

[0254] A service startup instruction sending unit is used to send a node service startup instruction to the target node device; the target node device is used to respond to the node service startup instruction and perform a node service initiation operation based on the configured environment variable information and the node digital certificate to start the consortium blockchain node service.

[0255] Optionally, the second acquisition module 604 may further include:

[0256] The third acquisition unit is used to acquire the genesis block configuration file;

[0257] Optionally, the second transmitting module 608 may also include:

[0258] A genesis block instruction sending unit is used to send a genesis block generation instruction to the target node device; the target node device is used to respond to the genesis block generation instruction, perform a genesis block generation operation based on the genesis block configuration file, and obtain genesis block information.

[0259] The target node device is used to respond to the node service start command and perform a node service revelation operation based on the configured environment variable information, the node digital certificate and the genesis block information to start the consortium blockchain node service.

[0260] Optionally, the second acquisition module 604 may further include:

[0261] The fourth acquisition unit is used to acquire the initial ledger data of the consortium blockchain network;

[0262] In response to the node service startup command, the target node device performs a node service initiation operation based on the configured environment variable information, the node digital certificate, and the initial ledger data to start the consortium blockchain node service.

[0263] Optional, Figure 6 The device may further include:

[0264] The compression module is used to compress the node installation files of the target node device;

[0265] Optionally, the second transmitting module 608 may include:

[0266] The decompression command sending unit is used to send a decompression command to the target node device based on the device control permission information; the target node device is used to respond to the decompression command and perform a decompression operation on the compressed file.

[0267] Optional, Figure 6 The device may further include:

[0268] The third acquisition module is used to acquire the operational indicator data of the consortium blockchain nodes deployed at the target node device.

[0269] The status determination module is used to determine the operating status information of the consortium blockchain node based on the operating indicator data.

[0270] Based on the same idea, this specification also provides devices corresponding to the above methods in its embodiments.

[0271] Figure 7 The embodiments provided in this specification correspond to Figure 2 A schematic diagram of the structure of a deployment device for a consortium blockchain node. (See diagram below.) Figure 7 As shown, device 700 can be a device of the first mechanism, and may include:

[0272] At least one processor 710; and,

[0273] Memory 730 communicatively connected to the at least one processor; wherein,

[0274] The memory 730 stores instructions 720 that can be executed by the at least one processor 710, the instructions being executed by the at least one processor 710 to enable the at least one processor 710 to:

[0275] Obtain the first communication address information of the first node device of the second organization.

[0276] Obtain the first node digital certificate of the first node device generated based on the CA certificate of the consortium blockchain network;

[0277] Obtain the first network configuration information of the consortium blockchain network.

[0278] Based on the first network settings information, the first node digital certificate, and the first communication address information, a first node installation file for the first node device is generated.

[0279] Using a non-public network transmission method, the first node installation file is sent to the second blockchain service platform of the second institution; the second blockchain service platform is used to control the first node device to start the consortium blockchain node service based on the first node installation file.

[0280] Figure 8 The embodiments provided in this specification correspond to Figure 3 A schematic diagram of the structure of a deployment device for a consortium blockchain node. (See diagram below.) Figure 8 As shown, device 800 can be a device of a second mechanism, and may include:

[0281] At least one processor 810; and,

[0282] Memory 830 communicatively connected to the at least one processor; wherein,

[0283] The memory 830 stores instructions 820 that can be executed by the at least one processor 810, the instructions being executed by the at least one processor 810 to enable the at least one processor 810 to:

[0284] Obtain the device control permission information of the target node device of the second organization.

[0285] Obtain the node installation file of the target node device. The node installation file is a file generated by the first blockchain service platform of the first institution based on the network settings information of the consortium blockchain network, the CA certificate and the communication address information of the target node device. The node installation file is sent from the first blockchain service platform to the second blockchain service platform based on a non-public network transmission method. The first institution is an institution with node management authority over the consortium blockchain network.

[0286] Send the node installation file to the target node device.

[0287] Based on the device control permission information, a consortium blockchain node deployment instruction is sent to the target node device; the consortium blockchain node deployment instruction is used to control the target node device to start the consortium blockchain node service based on the node installation file.

[0288] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, for... Figure 7 and Figure 8 As the device shown is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0289] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

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

[0291] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0292] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0293] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0294] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0295] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0296] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0298] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0299] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can 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), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital character versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0300] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0301] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0302] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0303] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

Claims

1. A method for deploying consortium blockchain nodes, applied to a first blockchain service platform of a first institution, the first institution having node management authority over the consortium blockchain network, comprising: Obtain the first communication address information of the first node device of the second organization; Obtain the first node digital certificate of the first node device generated based on the CA certificate of the consortium blockchain network; Obtain the first network configuration information of the consortium blockchain network; Based on the first network settings information, the first node digital certificate, and the first communication address information, generate the first node installation file for the first node device; Using a non-public network transmission method, the first node installation file is sent to the second blockchain service platform of the second institution; the second blockchain service platform is used to control the first node device to start the consortium blockchain node service based on the first node installation file.

2. The method as described in claim 1, wherein generating the first node installation file for the first node device based on the first network setting information, the first node digital certificate, and the first communication address information specifically includes: Based on the first network settings information and the first communication address information, generate the first consortium blockchain service configuration file and the first genesis block configuration file for the first node device; Based on the first consortium blockchain service configuration file, the first genesis block configuration file, and the first node digital certificate, the first node installation file of the first node device is generated.

3. The method as described in claim 2, further comprising, before generating the first node installation file of the first node device based on the first consortium blockchain service configuration file, the first genesis block configuration file, and the first node digital certificate: Obtain the initial ledger data of the consortium blockchain network; The step of generating the first node installation file for the first node device based on the first consortium blockchain service configuration file, the first genesis block configuration file, and the first node digital certificate specifically includes: The initial ledger data, the first consortium blockchain service configuration file, the first genesis block configuration file, and the first node digital certificate are compressed to obtain the compressed first node installation file for the first node device.

4. The method as described in claim 1, further comprising, before obtaining the first communication address information of the first node device of the second organization: Obtain the second communication address information and device control permission information of the second node device of the first organization; Obtain the second network configuration information and CA file of the consortium blockchain network; Based on the second network settings information, the CA file, and the second communication address information, generate the second node installation file for the second node device; Send the second node installation file to the second node device; Based on the device control permission information, a consortium blockchain node deployment instruction is sent to the second node device; the consortium blockchain node deployment instruction is used to control the second node device to start the consortium blockchain node service based on the second node installation file.

5. The method as described in claim 4, wherein generating the second node installation file for the second node device based on the second network setting information, the CA file, and the second communication address information specifically includes: Based on the second network settings information and the second communication address information, generate the second consortium blockchain service configuration file and the second genesis block configuration file for the second node device; Generate a CA certificate for the consortium blockchain network based on the CA file; Based on the CA certificate of the consortium blockchain network, a second node digital certificate is generated for the second node device; Based on the second consortium blockchain service configuration file, the second genesis block configuration file, and the second node digital certificate, the second node installation file for the second node device is generated.

6. The method as described in claim 5, wherein sending the consortium blockchain node deployment instruction to the second node device based on the device control permission information specifically includes: Based on the device control permission information, an environment variable configuration command is sent to the second node device; The second node device is used to respond to the environment variable configuration command, perform environment variable configuration operation based on the second consortium blockchain service configuration file, and obtain the configured environment variable information; Send the genesis block generation command to the second node device; The second node device is used to respond to the genesis block generation instruction, perform a genesis block generation operation based on the second genesis block configuration file, and obtain genesis block information; Send the node service start command to the second node device; The second node device is used to respond to the node service startup command by performing a node service revelation operation based on the configured environment variable information, the genesis block information, and the second node digital certificate to start the consortium blockchain node service.

7. The method as described in claim 6, wherein generating the second node installation file for the second node device based on the second consortium blockchain service configuration file, the second genesis block configuration file, and the second node digital certificate specifically includes: The second consortium blockchain service configuration file, the second genesis block configuration file, and the second node digital certificate are compressed to generate a compressed second node installation file. The step of sending the consortium blockchain node deployment instruction to the second node device based on the device control permission information further includes: Based on the device control permission information, a decompression command is sent to the second node device; The second node device is used to perform a decompression operation on the compressed second node installation file in response to the decompression command.

8. The method of claim 4, further comprising, after sending the consortium blockchain node deployment instruction to the second node device: Obtain the first operational indicator data of the consortium blockchain node deployed at the second node device; Based on the first operational indicator data, the first operational status information of the consortium blockchain node is determined.

9. The method of claim 8, further comprising: Obtain the second operational metric data of the consortium blockchain network; Based on the second operational indicator data, the second operational status information of the consortium blockchain network is determined.

10. The method as described in claim 4, wherein the consortium blockchain node deployed at the first node device is a cloud node or a physical node; and the consortium blockchain node deployed at the second node device is a cloud node or a physical node.

11. The method as described in claim 1, further comprising, after obtaining the first communication address information of the first node device of the second organization: Store the first communication address information of the first node device to the consortium blockchain network; Based on the first communication address information, generate the target blockchain transaction; The target blockchain transaction is used to change the running status of the consortium blockchain node deployed at the first node device to an active state; Send the target blockchain transaction to the consortium blockchain network.

12. The method as described in claim 1, wherein sending the first node installation file to the second blockchain service platform of the second institution using a non-public network transmission method specifically includes: Using a communication application, the installation file of the first node is sent to the device of the second organization; The device of the second institution is used to upload the received first node installation file to the second blockchain service platform; or, The first node installation file is stored in a physical storage device; the device of the second institution is used to upload the first node installation file read from the physical storage device to the second blockchain service platform.

13. A method for deploying consortium blockchain nodes, applied to a second blockchain service platform of a second institution, comprising: Obtain the device control permission information of the target node device of the second organization; Obtain the node installation file of the target node device. The node installation file is a file generated by the first blockchain service platform of the first institution based on the network settings information of the consortium blockchain network, the CA certificate and the communication address information of the target node device. The node installation file is sent from the first blockchain service platform to the second blockchain service platform based on a non-public network transmission method. The first institution is an institution with node management authority over the consortium blockchain network. Send the node installation file to the target node device; Based on the device control permission information, a consortium blockchain node deployment instruction is sent to the target node device; the consortium blockchain node deployment instruction is used to control the target node device to start the consortium blockchain node service based on the node installation file.

14. The method of claim 13, wherein the node installation file comprises: Consortium blockchain service configuration files and node digital certificates; The step of sending the consortium blockchain node deployment instruction to the target node device based on the device control permission information specifically includes: Based on the device control permission information, an environment variable configuration instruction is sent to the target node device; the target node device is used to respond to the environment variable configuration instruction, perform an environment variable configuration operation based on the consortium blockchain service configuration file, and obtain the configured environment variable information; A node service startup command is sent to the target node device; the target node device is used to respond to the node service startup command and perform a node service initiation operation based on the configured environment variable information and the node digital certificate to start the consortium blockchain node service.

15. The method of claim 14, wherein the node installation file further comprises: Genesis block configuration file; The step of sending the consortium blockchain node deployment instruction to the target node device based on the device control permission information further includes: A genesis block generation instruction is sent to the target node device; the target node device is used to respond to the genesis block generation instruction, perform a genesis block generation operation based on the genesis block configuration file, and obtain genesis block information; The target node device is specifically used to respond to the node service startup command and perform a node service revelation operation based on the configured environment variable information, the node digital certificate, and the genesis block information to start the consortium blockchain node service.

16. The method of claim 14, wherein the node installation file further comprises: The initial ledger data of the consortium blockchain network; The target node device is specifically used to respond to the node service startup command by performing a node service initiation operation based on the configured environment variable information, the node digital certificate, and the initial ledger data to start the consortium blockchain node service.

17. The method as described in claim 14, wherein the node installation file of the target node device is a compressed file; The step of sending the consortium blockchain node deployment instruction to the target node device based on the device control permission information further includes: Based on the device control permission information, a decompression command is sent to the target node device; The target node device is used to perform a decompression operation on the compressed file in response to the decompression command.

18. The method of claim 13, further comprising, after sending the consortium blockchain node deployment instruction to the target node device based on the device control authority information: Obtain the operational metrics data of the consortium blockchain nodes deployed at the target node device; Based on the operational indicator data, the operational status information of the consortium blockchain node is determined.

19. A deployment device for a consortium blockchain node, applied to a first blockchain service platform of a first institution, the first institution having node management authority over the consortium blockchain network, comprising: The first acquisition module is used to acquire the first communication address information of the first node device of the second organization; The second acquisition module is used to acquire the first node digital certificate of the first node device generated based on the CA certificate of the consortium blockchain network; The third acquisition module is used to acquire the first network setting information of the consortium blockchain network; The first file generation module is used to generate a first node installation file for the first node device based on the first network setting information, the first node digital certificate, and the first communication address information. The first sending module is used to send the first node installation file to the second blockchain service platform of the second institution using a non-public network transmission method; the second blockchain service platform is used to control the first node device to start the consortium blockchain node service based on the first node installation file.

20. The apparatus of claim 19, wherein the first file generation module comprises: The configuration unit is used to generate a first consortium blockchain service configuration file and a first genesis block configuration file for the first node device based on the first network setting information and the first communication address information. The file generation unit is used to generate the first node installation file of the first node device based on the first consortium blockchain service configuration file, the first genesis block configuration file, and the first node digital certificate.

21. The apparatus of claim 20, further comprising: The fourth acquisition module acquires the initial ledger data of the consortium blockchain network; The file generation unit is specifically used for: The initial ledger data, the first consortium blockchain service configuration file, the first genesis block configuration file, and the first node digital certificate are compressed to obtain the compressed first node installation file for the first node device.

22. The apparatus of claim 19, further comprising: The fifth acquisition module is used to acquire the second communication address information and device control permission information of the second node device of the first organization; The sixth acquisition module is used to acquire the second network setting information and CA file of the consortium blockchain network; The second file generation module is used to generate a second node installation file for the second node device based on the second network setting information, the CA file, and the second communication address information. The second sending module is used to send the second node installation file to the second node device; The third sending module is used to send a consortium blockchain node deployment instruction to the second node device based on the device control permission information; the consortium blockchain node deployment instruction is used to control the second node device to start the consortium blockchain node service based on the second node installation file.

23. A deployment device for a consortium blockchain node, applied to a second blockchain service platform of a second institution, comprising: The first acquisition module is used to acquire the device control permission information of the target node device of the second organization; The second acquisition module is used to acquire the node installation file of the target node device. The node installation file is a file generated by the first blockchain service platform of the first institution based on the network settings information of the consortium blockchain network, the CA certificate and the communication address information of the target node device. The node installation file is sent from the first blockchain service platform to the second blockchain service platform based on a non-public network transmission method. The first institution is an institution with node management authority over the consortium blockchain network. The first sending module is used to send the node installation file to the target node device; The second sending module is used to send a consortium blockchain node deployment instruction to the target node device based on the device control permission information; the consortium blockchain node deployment instruction is used to control the target node device to start the consortium blockchain node service based on the node installation file.

24. A deployment device for a consortium blockchain node, the device being a device of a first organization having node management authority over a consortium blockchain network, comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: Obtain the first communication address information of the first node device of the second organization; Obtain the first node digital certificate of the first node device generated based on the CA certificate of the consortium blockchain network; Obtain the first network configuration information of the consortium blockchain network; Based on the first network settings information, the first node digital certificate, and the first communication address information, generate the first node installation file for the first node device; Using a non-public network transmission method, the first node installation file is sent to the second blockchain service platform of the second institution; the second blockchain service platform is used to control the first node device to start the consortium blockchain node service based on the first node installation file.

25. A deployment device for a consortium blockchain node, the device being a device of a second organization, comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: Obtain the device control permission information of the target node device of the second organization; Obtain the node installation file of the target node device. The node installation file is a file generated by the first blockchain service platform of the first institution based on the network settings information of the consortium blockchain network, the CA certificate and the communication address information of the target node device. The node installation file is sent from the first blockchain service platform to the second blockchain service platform based on a non-public network transmission method. The first institution is an institution with node management authority over the consortium blockchain network. Send the node installation file to the target node device; Based on the device control permission information, a consortium blockchain node deployment instruction is sent to the target node device; the consortium blockchain node deployment instruction is used to control the target node device to start the consortium blockchain node service based on the node installation file.

Images