Block chain network management method and related equipment

Abstract

The block chain network management method is applied to a management system of a block chain network, the block chain network comprises a public node pool and an external node, the management system comprises a controller, a checker and a router, and the method comprises the following steps: the controller receives a node creation request, the controller creates a new node in the block chain network in response to the node creation request, and the new node is used for storing the new node in the block chain network; and switching the traffic routed to the new node to a target node in the public node pool, checking the state of the new node or the blockchain height of an account book maintained by the new node by a checker, and when the state of the new node or the blockchain height of the account book maintained by the new node meets a condition, switching the traffic routed to the new node by the router. And switching the traffic guided to the target node in the block chain network to the new node. According to the method, the public node pool and the external nodes are introduced for data pre-synchronization, the new nodes can perform account book synchronization based on the account book snapshots of the nodes in the public node pool, a large number of bandwidth resources do not need to be occupied, and the account book synchronization time can also be greatly shortened.

Description

[0001] This application claims the priority of a Chinese patent application with the application number 202311743446.9 and the invention title "A Blockchain Management Method and Related Devices" submitted to the National Intellectual Property Administration on December 18, 2023, the entire content of which is incorporated herein by reference. Technical Field

[0002] This application relates to the field of blockchain technology, and in particular, to a method for managing a blockchain network, a management system for a blockchain network, a computing device cluster, a computer-readable storage medium, and a computer program product. Background Art

[0003] Blockchain refers to a distributed database technology in which multiple nodes in a peer-to-peer network jointly maintain a continuously growing chain list ledger constructed by timestamps and ordered recorded data blocks through a consensus mechanism designed based on cryptographic technology. Blockchain enables any number of nodes participating in the system to calculate and record the data of information exchange in the system for a period of time into a data block through cryptographic algorithms, and generate a fingerprint of the data block for linking the next data block and verification. All participating nodes in the system jointly determine whether the record is true.

[0004] Cloud-native based blockchain nodes can provide resources for customers on demand, and thus are widely used. Specifically, a user can purchase an Elastic Cloud Server (ECS) virtual machine on a cloud platform, then deploy a blockchain node on the ECS virtual machine, configure a large-capacity storage for synchronizing node data, and configure an Elastic IP Address (EIP) for point-to-point data propagation with nodes in the blockchain network.

[0005] Each blockchain node needs to synchronize and propagate a large amount of data. Therefore, each new node added to the blockchain network consumes a large amount of bandwidth resources. Taking the example of full nodes in a public chain, the average data volume of full nodes is about 1 terabyte (TB). A new node synchronizes 1TB of data in the ledger in a point-to-point synchronization mode, which requires a large amount of bandwidth and affects normal on-chain transactions. Moreover, it takes a week for the new node to complete data synchronization before it can be used. Summary of the Invention

[0006] The present application provides a management method for a blockchain network. In this method, a public node pool and external nodes in the blockchain network are introduced for data pre-synchronization. New nodes created by users can synchronize the ledger based on the ledger snapshots of the nodes in the public node pool, without occupying a large amount of bandwidth resources, and the ledger synchronization time can also be significantly shortened. Moreover, during the creation of new nodes or during ledger synchronization, the traffic of the blockchain network is switched to the target nodes that are operating normally in the public node pool, ensuring that the business is not interrupted. The present application also provides a management system for the blockchain network, a computing device cluster, a computer-readable storage medium, and a computer program product corresponding to the above method.

[0007] In a first aspect, the present application provides a management method for a blockchain network. This method can be applied to a management system for a blockchain network, or can be simply referred to as a management system. The management system can be a software system, which is used to meet the business requirements of tenants through a node pool in a multi-tenant scenario of a cloud platform. The above software system can be deployed on a computing device cluster, and the computing device cluster executes the program code of the software system, thereby executing the management method for the blockchain network of the present application. In some examples, the management system can also be a hardware system, such as a computing device cluster that supports quickly creating blockchain nodes and realizing features such as second-level startup. When the computing device cluster runs, it executes the management method for the blockchain network of the present application.

[0008] Among them, the blockchain network includes a public node pool and external nodes, and the management system includes a controller, an inspector, and a router. The controller can receive a node creation request, and then, in response to the node creation request, the controller creates a new node in the blockchain network and switches the traffic routed to the new node to a target node in the public node pool. The public node pool is used for data pre-synchronization with external nodes in the blockchain network, and the target node is a node that is operating normally in the public node pool. The inspector checks the status of the new node or the blockchain height (which can also be simply referred to as the block height) of the ledger maintained by the new node. The router switches the traffic in the blockchain network that is directed from the new node to the target node to the new node when the status of the new node or the blockchain height of the ledger maintained by the new node meets the conditions.

[0009] This method introduces a public node pool in the blockchain network. The public node pool can perform data pre-synchronization with external nodes in the blockchain network. New nodes can synchronize the ledger based on the ledger snapshots of the nodes in the public node pool, without occupying a large amount of bandwidth resources, and the ledger synchronization time can also be significantly shortened, for example, from one week to the minute level. Moreover, during the creation of new nodes or during ledger synchronization, the traffic of the blockchain network is switched to the target nodes that are operating normally in the public node pool, ensuring that the business is not interrupted.

[0010] In some possible implementation manners, the controller may further receive node configuration information of a common node pool, where the node configuration information includes at least one of a blockchain type, an image location, a ledger backup policy, or a ledger backup frequency. The controller creates shared nodes in the common node pool according to the node configuration information, determines the number of non-snapshot ledger nodes among the shared nodes, and configures snapshot ledger nodes and non-snapshot ledger nodes in the common node pool according to this number. Among them, the services running in the snapshot ledger nodes are interrupted during the generation of ledger snapshots, and the non-snapshot ledger nodes run services normally.

[0011] In this way, pre-creation (or called prefabrication) of the common node pool can be realized, laying a foundation for subsequent ledger synchronization of new nodes based on the common node pool and accelerating the startup of new nodes.

[0012] In some possible implementation manners, the controller instructs a new node to copy a ledger snapshot from a storage snapshot pool corresponding to the common node pool, and performs ledger synchronization according to the ledger snapshot. Among them, the storage snapshot pool stores ledger snapshots generated by snapshot ledger nodes in the common node pool. Performing ledger synchronization based on the ledger snapshot can greatly shorten the ledger synchronization time, enabling the new node to be immediately available.

[0013] In some possible implementation manners, the controller may further receive a ledger synchronization method of a new node configured by a user, where the ledger synchronization method includes performing ledger synchronization based on a ledger snapshot.

[0014] This method supports user-defined ledger synchronization methods. When the user defines the ledger synchronization method as performing ledger synchronization based on a ledger snapshot, the ledger snapshot is used to perform ledger synchronization on the new node. When the user defines the ledger synchronization method as other synchronization methods, such as a normal synchronization method, point-to-point or other methods are used to perform ledger synchronization. In this way, it has good compatibility.

[0015] In some possible implementation manners, the blockchain network further includes a user node pool, and the node creation request is used to create a new node in the user node pool.

[0016] Among them, the nodes in the common node pool that synchronize with external nodes can be regarded as seed nodes. The common node pool pre-synchronizes data such as blocks through the seed nodes to achieve data synchronization with external nodes and construct the latest ledger in real time. The user node pool is used to meet the node usage requirements and provide users with the ability to use quickly. The user node pool and the common node pool can perform fast data synchronization through the intranet to provide the ability to create or start in seconds.

[0017] In some possible implementation manners, the node creation request is used to create a new node in the common node pool. Correspondingly, the controller adds the traffic of the blockchain network (such as transaction requests, transaction transactions txs) to the shared transaction pool. The shared transaction pool is configured with a quota for users who use the shared transaction pool. The quota is used to indicate the maximum traffic that a user adds to the shared transaction pool. The traffic in the shared transaction pool is routed to the target node in the common node pool. Among them, the shared transaction pool can be regarded as a message queue, and the traffic of the blockchain network can be scheduled to the target node in the common node pool for processing through the publisher-consumer mechanism.

[0018] By introducing the shared transaction pool and using the quota configured for the users of the shared transaction pool, this method can achieve traffic control and ensure the normal operation of the service.

[0019] In some possible implementation manners, the target node is a node whose load is less than a threshold or whose load ranks among the top n from low to high, where n is a positive integer. Among them, the traffic in the shared transaction pool can be scheduled to the target nodes whose load is less than the threshold or whose load ranks among the top n from low to high through load balancing, reducing congestion.

[0020] In some possible implementation manners, the controller can also receive a version update request, which is used to update the version of at least one node in the blockchain network. The controller upgrades the version of at least one node according to the version update request and switches the traffic of at least one node to the target node. When at least one node completes the version update, the router switches the traffic in the blockchain network that is directed from at least one node to the target node to at least one node. In this way, the service can be uninterrupted during version upgrade to meet the service requirements.

[0021] In some possible implementation manners, the version update request is used to update the version of at least one node in the common node pool of the blockchain network. Correspondingly, the controller can switch the traffic of at least one node to the non-upgraded nodes that are operating normally in the common node pool. For example, the controller can switch the traffic of at least one node to the non-rolling upgrade nodes that are operating normally in the common node pool. In this way, high availability of the service can be achieved.

[0022] In some possible implementation manners, the checker can also monitor the blockchain height of the ledger maintained by the nodes in the common node pool. When the difference between the blockchain height of the ledger maintained by the nodes in the common node pool and the blockchain height of the ledger maintained by the external nodes is greater than a first value, reset the ledger in the node and restore the ledger of the node according to the ledger snapshot. In this way, faults can be detected in time and rapid fault recovery can be performed.

[0023] Second aspect, this application provides a management system for a blockchain network. The blockchain network includes a public node pool and external nodes, and the management system includes a controller, an inspector, and a router.

[0024] The controller is configured to receive a node creation request;

[0025] The controller is further configured to, in response to the node creation request, create a new node in the blockchain network, and switch the traffic routed to the new node to a target node in the public node pool, where the public node pool is used to perform data pre-synchronization with external nodes in the blockchain network, and the target node is a node that is operating normally in the public node pool;

[0026] The inspector is configured to check the status of the new node or the blockchain height of the ledger maintained by the new node;

[0027] The router is configured to, when the status of the new node or the blockchain height of the ledger maintained by the new node meets the conditions, switch the traffic in the blockchain network that is directed from the new node to the target node to the new node.

[0028] In some possible implementation manners, the controller is further configured to:

[0029] Receive node configuration information of the public node pool, where the node configuration information includes at least one of blockchain type, mirror location, ledger backup policy, or ledger backup frequency;

[0030] Create shared nodes in the public node pool according to the node configuration information;

[0031] Determine the number of non-snapshot ledger nodes in the shared nodes, and configure the snapshot ledger nodes and non-snapshot ledger nodes in the public node pool according to the number. The services running in the snapshot ledger nodes are interrupted during the generation of ledger snapshots, and the non-snapshot ledger nodes operate normally.

[0032] In some possible implementation manners, the controller is further configured to:

[0033] Instruct the new node to copy a ledger snapshot from the storage snapshot pool corresponding to the public node pool, and perform ledger synchronization according to the ledger snapshot, where the storage snapshot pool stores the ledger snapshots generated by the snapshot ledger nodes in the public node pool.

[0034] In some possible implementation manners, the controller is further configured to:

[0035] Receive the ledger synchronization method of the new node configured by the user, where the ledger synchronization method includes performing ledger synchronization based on a ledger snapshot.

[0036] In some possible implementations, the blockchain network further includes a user node pool, and the node creation request is used to create the new node in the user node pool.

[0037] In some possible implementations, the node creation request is used to create the new node in the public node pool, and the controller is further configured to:

[0038] Add the traffic of the blockchain network to a shared transaction pool, where the shared transaction pool is configured with a quota for users using the shared transaction pool, and the quota is used to indicate the maximum traffic that the user can add to the shared transaction pool, and the traffic in the shared transaction pool is routed to the target node in the public node pool.

[0039] In some possible implementations, the target node is a node with a load less than a threshold or a node ranked among the top n in ascending order of load, where n is a positive integer.

[0040] In some possible implementations, the controller is further configured to:

[0041] Receive a version update request, which is used to update the version of at least one node in the blockchain network;

[0042] According to the version update request, perform a version upgrade on the at least one node, and switch the traffic of the at least one node to the target node;

[0043] The router is further configured to:

[0044] When the at least one node completes the version update, switch the traffic in the blockchain network that is directed from the at least one node to the target node to the at least one node.

[0045] In some possible implementations, the version update request is used to update the version of at least one node in the public node pool of the blockchain network;

[0046] Specifically, the controller is configured to:

[0047] Switch the traffic of the at least one node to a non-upgraded node that is operating normally in the public node pool.

[0048] In some possible implementations, the checker is further configured to:

[0049] Monitor the blockchain height of the ledger maintained by nodes in the public node pool. When the difference between the blockchain height of the ledger maintained by nodes in the public node pool and the blockchain height of the ledger maintained by external nodes is greater than a first value, reset the ledger in the nodes and restore the ledger in the nodes according to the ledger snapshot.

[0050] In a third aspect, the present application provides a computing device cluster. The computing device cluster includes at least one computing device, and the at least one computing device includes at least one processor and at least one memory. The at least one processor and the at least one memory communicate with each other. The at least one processor is configured to execute instructions stored in the at least one memory so that the computing device or the computing device cluster executes the blockchain network management method as described in the first aspect or any implementation manner of the first aspect.

[0051] In a fourth aspect, the present application provides a computer-readable storage medium storing instructions that instruct a computing device or a computing device cluster to execute the blockchain network management method as described in the first aspect or any implementation manner of the first aspect.

[0052] In a fifth aspect, the present application provides a computer program product including instructions that, when running on a computing device or a computing device cluster, cause the computing device or the computing device cluster to execute the blockchain network management method as described in the first aspect or any implementation manner of the first aspect.

[0053] Based on the implementation manners provided in the above aspects of the present application, further combinations can be made to provide more implementation manners. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] To more clearly illustrate the technical solutions of the embodiments of the present application, the accompanying drawings required for the embodiments will be briefly introduced below.

[0055] Figure 1 It is a schematic diagram of a node pool in a blockchain network provided by the present application;

[0056] Figure 2 It is a schematic diagram of a user-specific node pool provided by the present application;

[0057] Figure 3 It is a schematic diagram of a user-shared node pool provided by the present application;

[0058] Figure 4 It is a schematic diagram of the architecture of a blockchain network management system provided by the present application;

[0059] Figure 5 It is a flowchart of a blockchain network management method provided by the present application;

[0060] Figure 6 A schematic flowchart for creating a common node pool provided by this application;

[0061] Figure 7 A schematic diagram of an application scenario of a management method for a blockchain network provided by this application;

[0062] Figure 8 A schematic diagram of an application scenario of another management method for a blockchain network provided by this application;

[0063] Figure 9 A schematic diagram of the structure of a computing device provided by this application;

[0064] Figure 10 A schematic diagram of the structure of a computing device cluster provided by this application;

[0065] Figure 11 A schematic diagram of the structure of another computing device cluster provided by this application;

[0066] Figure 12 A schematic diagram of the structure of yet another computing device cluster provided by this application. Detailed implementation manners

[0067] In the embodiments of this application, the terms "first" and "second" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of such features.

[0068] First, some technical terms involved in the embodiments of this application are introduced.

[0069] A blockchain network, which can also be simply referred to as a blockchain, refers to a peer-to-peer (P2P) network constructed based on blockchain technology. A blockchain network includes multiple blockchain nodes, and each blockchain node is a peer node (for the convenience of description, this application may also simply refer to a blockchain node as a chain node or a node). In a blockchain network, multiple blockchain nodes jointly maintain a continuously growing blockchain ledger (or simply referred to as a ledger) constructed by ordered data blocks. Each blockchain node stores a copy of the above blockchain ledger and maintains the consistency between the copies. Therefore, the blockchain ledger is a public ledger of the blockchain network. Since this public ledger is a distributed ledger, a blockchain network can essentially be regarded as a distributed ledger system.

[0070] A distributed ledger system is a special type of distributed database system that only performs append operations and is suitable for use in untrusted environments. Specifically, in a distributed ledger system, new data can be appended to the local copy of each node through transactions, and through certain encryption mechanisms, it is ensured that the data in the ledger cannot be randomly deleted or modified. It should be noted that the distributed ledger system allows for Byzantine faults, including but not limited to node crashes, inaccessibility, network latency, or Byzantine faults caused by malicious behavior of nodes. Among them, the Byzantine fault is also known as the Byzantine problem, which refers to the problem of how to reach consensus in scenarios where a small number of nodes may act maliciously (messages may be forged). In order to achieve data consistency among various nodes in a distributed ledger system, each distributed ledger system will use a consensus mechanism.

[0071] A consensus mechanism is an algorithm for negotiating the current valid state of the ledger among different nodes in a distributed ledger system. The goal of the consensus mechanism can be to achieve the ultimate consistency of the ledger among different nodes in a distributed system through consensus. If all nodes can successfully commit blocks and store the same ledger copy, it means that the distributed ledger system has achieved ultimate consistency.

[0072] Cloud Computing is a computing model that provides dynamically scalable virtualized resources as a service over a network. Platform as a Service (PaaS) is one of the main multi-tenant models of cloud computing. Different tenants can be registered on the PaaS platform to use the resources and services of the PaaS platform. For example, the PaaS platform can provide Blockchain-As-A-Service (BaaS), and the blockchain service can be used as a public cloud service to provide the ability to create or deploy blockchain nodes for public cloud tenants.

[0073] Serverless computing (abbreviated as serverless) is an execution model of cloud computing. Under the serverless architecture, cloud providers or cloud manufacturers allocate machine resources on demand and manage the servers on behalf of customers. Developers of serverless applications do not care about the capacity planning, configuration, management, maintenance, fault tolerance, or scaling of containers, virtual machines, or physical servers. Serverless computing does not store resources in volatile memory; the computing is completed in a short time, and the results are saved to storage. When the application is not in use, no computing resources are allocated to the application. Therefore, it can effectively reduce the application operation and maintenance costs.

[0074] Serverless-based blockchain services have become the mainstream solution for cloud blockchain hosting applications. Among them, cloud-native blockchain nodes can provide resources for customers on demand and can also save a large amount of internal resources, so they are widely used. In fields that are extremely concerned about resource consumption and costs, such as the web3 field, building blockchain node services through serverless capabilities has great advantages for creating low-cost blockchain nodes.

[0075] Currently, adding a new node to a blockchain network usually involves a user purchasing an ECS virtual machine on a cloud platform and then directly deploying a blockchain node on the ECS virtual machine. However, this new node needs to occupy a large amount of bandwidth to synchronize the ledger with the original nodes in the blockchain network. Taking the Ethereum blockchain network as an example, there are approximately 7,000 - 10,000 nodes distributed in various cities around the world in the blockchain network. The new node pulls the ledger from these nodes for ledger synchronization. In public blockchains such as Ethereum, the average data volume of full nodes is about 1TB, and the data volume of some full nodes can even reach several TB. The new node needs to occupy more bandwidth resources for ledger synchronization, which can affect the operation of on-chain transactions. Every time a new node is started, the above synchronization process needs to be carried out, resulting in repeated consumption of bandwidth resources. Moreover, according to the gossip peer-to-peer synchronization mode, it usually takes a new node about one week to complete data synchronization before it can be used, which is difficult to meet business requirements.

[0076] In view of this, the present application provides a management method for a blockchain network. This method can be executed by the management system of the blockchain network. For the sake of convenience of description, the management system of the blockchain network in the present application can also be simply referred to as the management system. The management system can be a software system, which is used to meet the tenant's business needs through a node pool in a multi-tenant scenario of a cloud platform, and at the same time support blockchain features such as blockchain node changes. Blockchain features include but are not limited to quickly creating new nodes (for example, creating blockchain nodes in seconds), updating blockchain nodes (for example, updating the version of blockchain nodes), and repairing blockchain node failures. The solution of the present application can reduce the consumption of bandwidth resources, enabling the service provider to build service capabilities with fewer resources. Moreover, the blockchain nodes created in seconds eliminate the ledger synchronization time and can be made immediately available. The above software system can be deployed in a computing device cluster, and the computing device cluster executes the program code of the software system to thereby execute the management method of the blockchain network of the present application. In some examples, the management system can also be a hardware system, such as a computing device cluster that supports the above blockchain features. When the computing device cluster runs, it executes the management method of the blockchain network of the present application.

[0077] Among them, the blockchain network includes a public node pool and external nodes. The management system may include a controller, a checker, and a router. Specifically, the controller can receive a node creation request. In response to the node creation request, the controller creates a new node in the blockchain network and switches the traffic routed to the new node to a target node in the public node pool. The public node pool is used for pre-synchronizing data with external nodes. Among them, the external nodes refer to the blockchain nodes in the external network, such as the nodes managed by other organizations in the blockchain network. The nodes in the public node pool usually need to use EIP to interact with external nodes. The target node is a node that is operating normally in the public node pool. The checker can check the status of the new node or the blockchain height (referred to as block height) of the ledger maintained by the new node. When the status of the new node or the block height of the ledger maintained by the new node meets the conditions, the router switches the traffic in the blockchain network directed from the new node to the target node to the new node.

[0078] This method introduces a public node pool in the blockchain network. The public node pool can pre-synchronize data with external nodes in the blockchain network. The new node can synchronize the ledger based on the ledger snapshot of the nodes in the public node pool, without occupying a large amount of bandwidth resources, and the ledger synchronization time can also be significantly shortened, for example, shortened from one week to the minute level. Moreover, during the creation of the new node or during the ledger synchronization, the traffic of the blockchain network is switched to the target node that is operating normally in the public node pool, ensuring that the business is not interrupted.

[0079] Furthermore, this application also introduces a user node pool. The node pool (such as the public node pool, user node pool) refers to a public resource area constructed by blockchain nodes and can include multiple blockchain nodes internally. The nodes in the public node pool that synchronize with external nodes can be regarded as seed nodes. The public node pool pre-synchronizes data such as blocks through the seed nodes to achieve data synchronization with external nodes and construct the latest ledger in real time. The user node pool is used to meet the node usage requirements and provide users with the ability to use quickly. For example, the user node pool and the public node pool can perform fast data synchronization through the internal network, providing the ability to create or start in seconds.

[0080] The management method of the blockchain network provided by this application ensures that different blockchain networks can adapt to the serverless architecture based on the node pool. Through the serverless architecture capabilities, it can achieve capabilities such as fast synchronization of the blockchain ledger, fast recovery of node failures, and uninterrupted business during version upgrades. At the same time, based on the node pool, it can reduce the consumption of bandwidth resources by new nodes (nodes newly added to the blockchain network) and provide the ability to start nodes in seconds. Moreover, relying on internal detection devices such as checkers, it can automatically repair node failures.

[0081] To facilitate the understanding of the technical solution of this application, the node pool introduced in this application will be introduced below in conjunction with the accompanying drawings.

[0082] Refer to Figure 1 The schematic diagram of a node pool in a blockchain network as shown. The blockchain network 10 includes a public node pool 100. The public node pool 100 includes multiple nodes. The nodes in the public node pool 100 can be shared nodes. The nodes in the public node pool 100 can be distributed at different locations, for example, distributed in different Availability Zones (AZs). Figure 1 Taking the example that the public node pool 100 includes 3 nodes, and the 3 nodes are respectively distributed in AZ1, AZ2, and AZ3 for illustration. The nodes in the public node pool 100 are also configured with EIPs. The nodes in the public node pool 100 can interact with the node network in the blockchain network 10 through the EIPs to synchronize the ledger with external nodes in the node network to construct the latest ledger. Among them, the node network can be a network formed by nodes managed by other organizations in the blockchain network 10.

[0083] The nodes in the public node pool 100 can also back up the ledger. Specifically, the nodes can generate a ledger snapshot through the snapshot function to achieve ledger backup. The ledger snapshot is a fully available copy of the ledger, and this copy includes the state of the ledger at a certain time point (such as the time point when the copy starts). The nodes in the public node pool 100 that back up the ledger through snapshots are also called snapshot ledger nodes. The snapshot ledger nodes can generate ledger snapshots according to the configured backup frequency. For example, the snapshot ledger nodes can generate a ledger snapshot every 10 minutes. Considering that when the snapshot ledger nodes back up the ledger, the services on the snapshot ledger nodes can be interrupted. In other words, the services running on the snapshot ledger nodes can be interrupted during the generation of the ledger snapshot. In the public node pool 100, non-snapshot ledger nodes can also be set to ensure that the services are not interrupted. The non-snapshot ledger nodes can support the normal operation of the services. In Figure 1 the example, the public node pool 100 includes 2 snapshot ledger nodes and 1 non-snapshot ledger node.

[0084] Furthermore, the blockchain network 10 may further include a user node pool 200. A user can trigger an operation to create a blockchain node in the user node pool 200. Among them, the user can create a blockchain node as needed, and the above-mentioned blockchain node created by the user is a new node. When creating a new node, for example, when creating a new node in the user node pool 200, the user can configure the ledger synchronization method of the new node, and the ledger synchronization method includes ledger synchronization based on a ledger snapshot. When the user configures the ledger synchronization method to be ledger synchronization based on a ledger snapshot, the node creation request may further include an identifier or flag bit for ledger synchronization based on a ledger snapshot. In this way, after the above-mentioned new node is created, a ledger snapshot generated by backing up nodes in the public node pool can be obtained, and ledger synchronization can be performed based on the ledger snapshot to obtain the latest ledger. Among them, the new node can obtain the ledger snapshot with the largest ledger block height (the latest ledger snapshot) for ledger synchronization to further improve the synchronization efficiency. Compared with the traditional solution, the ledger synchronization time of this application can be reduced to the minute level, which can meet the business requirements.

[0085] It should be noted that this application can provide the ability to build dedicated nodes on the cloud or the ability to build shared nodes. The following will be described separately with reference to the accompanying drawings.

[0086] As Figure 2 shown, the blockchain nodes built in the user node pool 200 can be user dedicated nodes. The user node pool 200 may include a user dedicated node pool. Each node in the user dedicated node pool is dedicated to one user. For example, the user dedicated node pool may include 3 user dedicated nodes, and the 3 user dedicated nodes belong to different users.

[0087] As Figure 3 shown, the blockchain nodes built in the user node pool 200 can be user shared nodes. The user node pool 200 may include a user shared node pool, which can also be simply referred to as a shared node pool. Each node in the user shared node pool can be shared by multiple users. In the non-dedicated mode, the resources in the user shared node pool can be shared for all users to use, so as to improve the resource utilization rate (reuse rate).

[0088] The following will introduce the system architecture of the management system of the blockchain network provided by this application with reference to the accompanying drawings.

[0089] Refer to Figure 4 As shown in the schematic diagram of the architecture of a management system, the management system 400 includes a controller 402, an inspector 404, and a router 406. The functions of the controller 402, the inspector 404, and the router 406 will be introduced separately below.

[0090] The controller 402 is used to receive a node creation request. The controller 402 is also used to, in response to the node creation request, create a new node in the blockchain network and switch the traffic routed to the new node (for example, the traffic scheduled to the new node through load balancing) to a target node in the public node pool. The public node pool is used to perform pre-synchronization of data with external nodes, and the target node is a node for the public node pool to operate its business normally. For example, the public node pool may include snapshot ledger nodes and non-snapshot ledger nodes. The business running in the snapshot ledger nodes is interrupted during the generation of the ledger snapshot, and the non-snapshot ledger nodes operate their business normally. Based on this, the target node may be a non-snapshot ledger node. In some examples, the snapshot ledger nodes may include a first node during the generation of the ledger snapshot or a second node not during the generation of the ledger snapshot, and the target node may also be the second node. The non-snapshot ledger nodes or the second node not during the generation of the ledger snapshot in the snapshot ledger nodes may be collectively referred to as available nodes in the public node pool, and these available nodes may form an available public node pool.

[0091] The checker 404 is used to check the status of the new node or the blockchain height of the ledger maintained by the new node. The blockchain height, abbreviated as block height, refers to the maximum number of blocks generated on the current blockchain. The block height can be characterized by the number or count of blocks in the blockchain. The number of a block is the number of blocks between this block and the genesis block, where the genesis block is the first block generated on the blockchain, and the number of the genesis block is usually 0.

[0092] The router 406 is used to, when the status of the new node or the blockchain height of the ledger maintained by the new node meets the conditions, switch the traffic in the blockchain network directed from the new node to the target node to the new node. The status of the new node meeting the conditions may be that the new node is created successfully. The blockchain height of the ledger maintained by the new node meeting the conditions may be that the difference between the block height of the ledger maintained by the new node and the block height of the ledger maintained by the external node is less than a first value. This difference can be characterized by the difference between the block height of the ledger maintained by the external node and the block height of the ledger maintained by the new node, or by the absolute value of the above difference. The first value can be determined according to the block generation rate.

[0093] Based on Figure 4 the management system 400 shown above, the present application also provides a management method for a blockchain network. The management method for the blockchain network of the present application will be introduced below with reference to the accompanying drawings.

[0094] See Figure 5Flowchart of a management method for a blockchain network. The blockchain network includes a public node pool and external nodes. Among them, the external nodes can be nodes managed by other organizations, and the nodes in the public node pool support interaction with the external network. For example, they can interact with external nodes through EIP. This method is executed by a management system 400, and the management system 400 includes a controller 402, an inspector 404, and a router 406. This method includes the following steps:

[0095] S502. The controller 402 receives a node creation request.

[0096] The node creation request, in some cases, can also be called a node activation request. The node creation request is used to create a new node, and the new node is a blockchain node. The blockchain node is responsible for storing data blocks, is a storage unit in the blockchain network, and can keep the data synchronized and up-to-date. A unitized architecture can be built inside the blockchain node, and the unitized architecture includes a consensus client and an execution client. The consensus client and the execution client can communicate through Remote Procedure Call (RPC). Among them, the consensus client is responsible for broadcasting blocks, and the execution client is responsible for broadcasting transactions. For example, the consensus client can receive a block from other nodes according to the block gossip protocol, check whether the format of the block is valid, and then send it to the execution client. The execution client puts all the transactions in the block into the Ethereum Virtual Machine (EVM) for execution, updates the Merkle Patricia Trie (MPT) data. MPT is a data structure for recording transactions in the abstraction layer, and then checks whether the hash value of the block header is correct. The execution client passes the verification data to the consensus client, indicating that the block is valid. The consensus client saves the block to the head of the local blockchain and then broadcasts it in the consensus layer network.

[0097] Specifically, the node creation request can also be used to create a new node in the public node pool 100. In some examples, the blockchain network can also include a user node pool, and the node creation request can be used to create a new node in the user node pool 200. The new node can be a user-specific node or a user-shared node.

[0098] Among them, the controller 402 can provide a configuration interface, through which a user can configure the node information of a new node to be created. The node information may include the node pool to which the node belongs. Further, the node information may also include the node type. The node pool to which the node belongs includes the user node pool 200 or the public node pool 100. When the node belongs to the user node pool 200, the node information may further include the node type, which may be a user-dedicated node or a user-shared node.

[0099] In some possible implementation manners, the controller 402 may also receive a version update request, which is also referred to as a version upgrade request or a node upgrade request in some cases. The version update request is used to perform a version upgrade (such as a background version upgrade) so as to update the chain nodes (at least one node in the blockchain network). To avoid service interruption, a rolling update method may be adopted to perform the version update or upgrade of the chain nodes. The rolling update means that a batch of blockchain nodes are updated each time, rather than all blockchain nodes being updated at the same moment. When a batch of blockchain nodes are updated, the next batch of blockchain nodes are updated.

[0100] Similarly, the controller 402 can provide a configuration interface, through which a user can configure the node information of the node to be updated. The node information may include a node identifier for indicating the node to be updated. The user can also configure the path or address of the code file of the new version in the configuration interface, so that the node to be updated can perform the version update based on the path or address of the code file of the new version.

[0101] S504. In response to the node creation request, the controller 402 creates a new node in the blockchain network and switches the traffic routed to the new node in the blockchain network to the target node in the public node pool.

[0102] The public node pool 100 is used to perform data pre-synchronization with external nodes. Specifically, the nodes in the public node pool 100 are configured with EIPs, and the nodes in the public node pool 100 can interact with external nodes in the node network through the EIPs to perform ledger pre-synchronization so as to construct the latest ledger in real time.

[0103] The target node is a node that is operating normally in the public node pool 100. The following is a separate description.

[0104] In some possible implementations, the node creation request is used to create a new node in the common node pool 100. Specifically, the node creation request indicates that the node pool to which the new node belongs is the common node pool 100. The controller 402 may, in response to the node creation request, create a new node in the common node pool 100. To avoid service interruption, the controller 402 also switches the traffic routed to the new node in the blockchain network to a target node in the common node pool 100. The target node may be, for example, a low-load node in the available common node pool. Herein, the available common node pool includes the available nodes in the common node pool, and the available nodes are the nodes that are operating their services normally. The low-load node may be a node with a load less than the load threshold or a node ranked among the top n in terms of load from low to high. Herein, n is a positive integer.

[0105] In some other possible implementations, the blockchain network includes a user node pool 200, and the node creation request may be used to create a new node in the user node pool 200. The node creation request indicates that the node pool to which the new node belongs is the user node pool 200. The controller 402 may, in response to the node creation request, create a new node in the user node pool 200. To avoid service interruption, the controller 402 also switches the traffic routed to the new node in the blockchain network to a target node in the common node pool 100. The target node may be, for example, a node in the available common node pool, that is, an available node in the common node pool 100. The service of the target node is operating normally. Herein, the target node may be a non-snapshot ledger node in the common node pool. Alternatively, the target node may also be a snapshot ledger node in the common node pool that is not in the period of generating a ledger snapshot, such as the second node.

[0106] Further, when the node creation request indicates to create a new node in the user node pool 200, the controller 402 may create a new node of the corresponding type in the user node pool 200 according to the node type indicated by the node creation request. For example, if the node type indicated by the node creation request is a user-specific node, the controller 402 may create a user-specific node in the user node pool 200. Another example is that if the node type indicated by the node creation request is a user-shared node, the controller 402 may create a user-shared node in the common node pool 100.

[0107] It should be noted that when the node creation request is used to create a new node in the common node pool 100, the controller 402 may also add the traffic of the blockchain network to the shared transaction pool. The shared transaction pool is configured with a quota for the users using the shared transaction pool, and the quota is used to indicate the maximum traffic that the user can add to the shared transaction pool. The traffic in the shared transaction pool may be routed to the target node in the common node pool 100. This can avoid excessive bandwidth resources being occupied by data synchronization and ensure the normal operation of the application services.

[0108] The snapshot ledger nodes in the public node pool 100 can also generate ledger snapshots, which can be stored in the storage snapshot pool. In the scenario of creating a node, the controller 402 can also instruct the new node to copy the ledger snapshot from the storage snapshot pool corresponding to the public node pool 100 and perform ledger synchronization based on the ledger snapshot. Among them, the controller 402 can also receive the ledger synchronization method configured by the user for the new node. Among them, the ledger synchronization method can include performing ledger synchronization based on the ledger snapshot. When the user configures the ledger synchronization method to be based on the ledger snapshot for ledger synchronization, the node creation request can also include an identifier or flag for performing ledger synchronization based on the ledger snapshot. Correspondingly, when the controller 402 pulls up a new node, for example, a user-specific node, the node can use the target ledger snapshot for ledger synchronization. This can significantly shorten the ledger synchronization time and reduce the consumption of bandwidth resources.

[0109] Further, when the controller 402 receives a version update request, the controller 402 can perform a version upgrade on at least one node (chain node) according to the version update request and switch the traffic of at least one node to the target node. When at least one node completes the version update, the router 406 switches the traffic in the blockchain network from at least one node to the target node. The target node can be a non-upgraded node in the public node pool 100. The non-upgraded node can be a non-rolling upgrade node.

[0110] Among them, the controller 402 can adopt a rolling upgrade method to update a batch of blockchain nodes in the blockchain network. The controller 402 can update a batch of blockchain nodes corresponding to the node identifier in the version update request in the blockchain network. In addition, the controller 402 can switch the traffic of at least one node in the blockchain network that is undergoing version update to the target node in the public node pool 100. When the blockchain network includes the user node pool 200 and the nodes undergoing version update are the nodes in the user node pool 200, the target node can be an available node in the public node pool 100 with a load meeting the requirements, such as the low-load node that is normally running business as described above. When the blockchain network does not include the user node pool 200, the target node can be a non-upgraded node, such as a non-rolling upgrade node.

[0111] S506. The checker 404 checks the status of the new node or the blockchain height of the ledger maintained by the new node.

[0112] Specifically, when the new node is created, it can send a heartbeat message, and the checker 404 can check the status of the new node by checking the heartbeat message. For example, when the checker 404 receives the heartbeat message of the new node, it means that the new node is created. Otherwise, it means that the new node is not created. For example, when the checker 404 does not receive the heartbeat message of the new node within the set time, it means that the new node is not created.

[0113] The blockchain height, simply referred to as the block height, is specifically the maximum number of blocks produced on the current blockchain. The block height can be characterized by the number or serial number of the blocks in the blockchain. The checker 404 can read the serial number of the latest block of the ledger maintained by the new node, thereby obtaining the block height of the ledger maintained by the new node.

[0114] S508. When the status of the new node or the blockchain height of the ledger maintained by the new node meets the conditions, the router 406 switches the traffic in the blockchain network directed from the new node to the target node to the new node.

[0115] The condition that the status of the changed node is met can be that the change is completed, for example, the creation of the new node is completed. The condition that the blockchain height of the ledger maintained by the new node is met can be that the difference between the blockchain height of the ledger maintained by the new node and the blockchain height of the ledger maintained by the external node (simply referred to as the block height difference between the new node and the external node) is less than the first value. Among them, the status of the new node is completed, or the block height difference between the new node and the external node is less than the first value, indicating that the new node is available, and the router 406 can switch the traffic in the blockchain network directed from the new node to the target node back to the new node. In some examples, the router 406 can also switch the traffic in the blockchain network directed from the new node to the target node back to the new node when both the status of the new node and the blockchain height of the ledger maintained by the new node meet the conditions.

[0116] Among them, the first value can be determined according to the block production rate. For example, the first value can be determined by the following formula:

[0117] s = 60 * m / a (1)

[0118] Among them, a represents the block production rate, specifically the number of blocks produced per second, m is the number of minutes, for example, it can take the value of 2, and s represents the first value.

[0119] Furthermore, for at least one node in the blockchain network that is undergoing version upgrade, the router 406 can switch the traffic in the blockchain network directed from the at least one node to the target node to the at least one node when the at least one node completes the version update. Specifically, the router 406 can call the checker 404 to check the status of the at least one node or the blockchain height of the ledger maintained by the at least one node. When the status of the at least one node is updated and completed, or the difference between the blockchain height of the ledger maintained by the at least one node and the blockchain height of the ledger maintained by the external node (that is, the block height difference between the at least one node and the external node) is less than the first value, indicating that the at least one node is available, the router 406 can switch the traffic in the blockchain network directed from the new node to the target node back to the at least one node that has completed the update (upgrade completed).

[0120] In some possible implementations, the checker 404 can also monitor the blockchain height of the ledger maintained by the nodes in the common node pool 100. Among them, when the new node is a node created in the common node pool 100, the blockchain height of the ledger maintained by the nodes in the common node pool 100 can include the blockchain height of the ledger maintained by the new node. When the difference between the blockchain height of the ledger maintained by the nodes in the common node pool 100 and the blockchain height of the ledger maintained by the external nodes is greater than the first value, it indicates that the ledger of the node is abnormal. The checker 404 can reset the ledger in the node and restore the ledger of the node according to the ledger snapshot.

[0121] Based on the above description, this method introduces a common node pool in the blockchain network. The common node pool and the external nodes in the blockchain network perform data pre-synchronization. The new node can perform ledger synchronization based on the ledger snapshot of the nodes in the common node pool, without occupying a large amount of bandwidth resources, and the ledger synchronization time can also be greatly shortened, for example, from one week to the minute level. Moreover, during the creation of a new node, the traffic routed to the new node in the blockchain network (for example, the traffic scheduled to the new node through load balancing) is switched to the target node that is operating normally in the common node pool, ensuring that the business is not interrupted and can operate normally.

[0122] It should be noted that the common node pool 100 of this application is different from the node-based resource pool in the related art. The node-based resource pool in the related art cannot be directly used and is usually used after the ledger synchronization is completed. Moreover, all blockchain nodes in the related art are open-source nodes, and some unpredictable problems may occur in different versions, such as the soft fork problem. Among them, a soft fork means that when a new consensus rule is released, the un-upgraded nodes produce illegal blocks because they do not know the new consensus rule, resulting in a temporary fork. Therefore, it is necessary to check the block height difference between the current data block and the external data block and repair it in time when the block height difference has problems. Moreover, after a transaction is initiated, each transaction will generate a fee, and the user will incur consumption. If the data in the memory is not sent successfully, resulting in an abnormal ledger of the node (node failure), it is necessary to repair and reconstruct the memory data, otherwise the transaction will be lost.

[0123] In the solution of this application, the user (such as an administrator) can first complete the creation of the preset common node pool and complete the ledger synchronization to ensure the availability of the ledger, so as to realize subsequent node creation, node update, or fault repair.

[0124] See Figure 6 A schematic flowchart of the creation of a common node pool as shown, including the following steps:

[0125] S602. The controller 402 receives the node configuration information of the common node pool.

[0126] The node configuration information includes at least one of the blockchain type, the mirror location, the ledger backup strategy, or the ledger backup frequency. The blockchain type may include various types of blockchains in permissionless blockchains, including but not limited to Ethereum. The mirror location may include the location of the mirror file used to create or start a node.

[0127] The ledger backup strategy refers to the strategy for backing up the ledger maintained by nodes in the public node pool. For example, it is a strategy for generating snapshots of the ledger. In some examples, the ledger backup strategy can be determined according to high availability requirements. To achieve high availability, the following formula usually needs to be satisfied:

[0128] count = 2F + 1, F = 1, 2, 3… (2)

[0129] Where F is the number of nodes conducting transactions in the public node pool, for example, the number of non-snapshot ledger nodes. count is the total number of nodes in the public node pool. Taking the example of a public node pool including 3 nodes, the ledger backup strategy can be that 2 nodes are snapshot ledger nodes to take snapshots of the ledger for backup, and 1 node is a non-snapshot ledger node, which is used to conduct transactions when the snapshot ledger nodes interrupt their services for backup to ensure the normal operation of the business.

[0130] The ledger backup frequency can be the frequency of generating ledger snapshots. This frequency can be set according to experience. In some examples, the ledger backup frequency can be 10 minutes (min).

[0131] In some possible implementation manners, the node configuration information may further include configuration of the content of the configuration file, such as the number of external connections and the frequency of pulling up blocks.

[0132] S604. The controller 402 creates shared nodes in the public node pool according to the node configuration information.

[0133] The controller 402 can call a blockchain service, such as BaaS, to create shared nodes in the public node pool according to the node configuration information. Specifically, the controller 402 can generate blockchain nodes of the corresponding blockchain type through BaaS according to the blockchain type and the mirror location in the node configuration information. The blockchain node is a shared node. The mirror file obtained from the corresponding mirror location is deployed in the blockchain node.

[0134] S606. The controller 402 determines the number of non-snapshot ledger nodes among the shared nodes, and configures the snapshot ledger nodes and non-snapshot ledger nodes in the public node pool according to the number.

[0135] Considering that generating a ledger snapshot by a blockchain node usually requires interrupting the business, for example, interrupting the in-memory transaction writing, and then starting to receive or synchronize the latest transactions after the ledger snapshot is generated. Therefore, the controller 402 can configure non-snapshot ledger nodes to ensure that the business can still run normally when some blockchain nodes generate ledger snapshots for ledger backup. In addition, the controller 402 also configures snapshot ledger nodes for generating ledger snapshots for ledger backup. On the one hand, it can enable new nodes to synchronize the ledger based on the ledger snapshot, shortening the synchronization time. On the other hand, it can perform fast fault recovery based on the ledger snapshot in case of a failure.

[0136] Among them, the controller 402 can determine the number of non-snapshot ledger nodes in the shared nodes according to the ledger backup policy in the node configuration information. For example, the number of non-snapshot ledger nodes can be 1, and the number of snapshot ledger nodes can be 2. The controller 402 can configure the corresponding number of nodes in the common node pool as non-snapshot ledger nodes according to the above number.

[0137] Furthermore, the controller 402 can also configure the ledger backup frequency of the above snapshot ledger nodes according to the ledger backup frequency in the node configuration information.

[0138] It should be noted that Figure 6 The relevant content of the embodiments can also be combined with the foregoing embodiments, and this application does not make any restrictions on this.

[0139] Next, the management method of the blockchain network of this application will be introduced in combination with a specific application scenario.

[0140] See Figure 7 The schematic diagram of the application scenario of a management method of a blockchain network shown. In this scenario, the administrator needs to complete the creation of the preconfigured common node pool, complete the ledger synchronization, and ensure the availability of the ledger before starting to build the user node pool. Among them, the management method of the blockchain network can be jointly executed by the controller, checker, and router in the blockchain network management system. In this embodiment, the controller can be the Chain-serverless-controller component, the checker can be the Chain-serverless-checker component, and the router can be the Chain-serverless-router component. This embodiment takes Tenant A creating nodes and Tenant C upgrading nodes as examples to illustrate, and specifically includes the following steps:

[0141] 1. The administrator inputs the node configuration information and the pooling management policy.

[0142] Node configuration information, also known as chain node information, can specifically include blockchain type, image location, and configuration file content configuration. Among them, the administrator can initialize the public node pool by configuring the above chain node information. The administrator can also configure the pooling management strategy of the public node pool, which can specifically include ledger backup strategy and ledger backup frequency.

[0143] 2. Chain-serverless-controller creates shared nodes in the public node pool according to the node configuration information, determines the number of non-snapshot ledger nodes according to the ledger backup strategy, and configures the non-snapshot ledger nodes based on this number. Chain-serverless-controller configures the ledger backup frequency of the snapshot ledger nodes.

[0144] Among them, the snapshot ledger nodes can generate ledger snapshots corresponding to their respective nodes in the storage snapshot pool at regular intervals according to the configured ledger backup frequency. The snapshot ledger nodes can also record the block height in the ledger snapshot.

[0145] 3. Chain-serverless-checker runs synchronously and checks each node in the public node pool in real time, excludes and repairs nodes, expands the nodes in synchronization, listens to the block height of the completed nodes, and if the block height difference exceeds s, schedules the repair module to repair the node.

[0146] Among them, excluding and repairing nodes means excluding the repair nodes (nodes being repaired) from the routing table and not routing through the repair nodes. Expanding the nodes in synchronization can be to expand the capacity of the nodes in synchronization. The completed nodes can be nodes that have been created or updated. Chain-serverless-checker can schedule the repair module to repair the node when the block height difference between the completed node and the external node is greater than s.

[0147] The main role of Chain-serverless-checker is to ensure the normal state of the nodes in the public node pool and the user node pool, and automatically repair the faulty nodes. The main inspection and repair actions of Chain-serverless-checker can include:

[0148] (a) Exclude and repair nodes, listen to the block height of the completed nodes, and if the block height difference exceeds s, schedule the repair module to repair the current node.

[0149] (b) Schedule the node reset module to reset the ledger maintained by the node, and restore the ledger maintained by the node from the new based on the ledger snapshot. For example, Chain-serverless-checker can restore the ledger of the node based on the latest ledger snapshot.

[0150] (c) Monitor the block heights of external nodes (such as external public synchronization nodes) and the block heights of internal nodes in the public node pool. If the difference is greater than or equal to s, trigger an alarm.

[0151] Specifically, the repair node can reset the ledger maintained by the node and then restore the node's ledger based on the ledger snapshot. For example, it can restore the node's ledger based on the latest ledger snapshot.

[0152] 4. Tenant A triggers a node creation action. Chain-serverless-controller starts creating a new node in the user node pool and simultaneously switches the traffic routed to the new node in the blockchain network to the public node pool.

[0153] Among them, switching the traffic to the public node pool can enable the use of nodes in the public node pool to provide services. At the same time, the user node pool can quickly start up nodes and synchronize data based on the ledger snapshot of the highest block.

[0154] 5. Chain-serverless-router can schedule chain-serverless-checker to detect the status and block height of nodes in the user node pool. When the status and block height of the nodes in the user node pool meet the conditions, Chain-serverless-router switches the traffic back to the user node pool to achieve the serverless startup of the nodes.

[0155] 6. Tenant C triggers a version update operation. The background upgrade will also first switch the traffic to the nodes in the public node pool, and then Chain-serverless-router schedules chain-serverless-checker to detect the status and block height of the upgraded nodes. When the conditions are met, Chain-serverless-router switches the traffic back to the user node pool to complete the background seamless upgrade.

[0156] The Chain-serverless-router component, as the user's access entry to the nodes, interacts closely with the Chain-serverless-checker component to obtain the status of different nodes and connects to the available nodes in different node pools in a series of switching scenarios such as node creation, upgrade, and failure, ensuring that the customer's business is not interrupted.

[0157] Specifically, in the node creation scenario, Chain-serverless-router calls Chain-serverless-checker to detect the creation status of the user node pool and the ledger block height. If the creation is not completed or the block height difference is greater than s, the traffic is directed to the available public node pool. In the upgrade process, the traffic is switched to the available public node pool. After the user node upgrade is completed and the block height difference is less than s, the traffic is switched back to the user node pool.

[0158] See Figure 8 The application scenario schematic diagram of another blockchain network management method shown in the figure. In this scenario, the administrator needs to initialize the public node pool and configure the pooling management policy, such as configuring the ledger backup policy and the ledger backup frequency. After the creation of the preset public node pool is completed and the ledger synchronization is completed to ensure the availability of the ledger, node creation and version update can be triggered. This embodiment still takes tenant A creating a node and tenant C upgrading a node as an example for illustration.

[0159] As Figure 8 Shown in the figure, tenant A initiates the process of opening a node, such as triggering the operation of opening a node. Chain-serverless-controller receives the node creation request. Tenant C initiates the version upgrade process, and Chain-serverless-controller receives the version upgrade request. Figure 8 The embodiment shown also introduces a shared transaction pool to implement serverless in the shared node mode. Specifically, Chain-serverless-checker adds node creation requests, version upgrade requests, etc. to the shared transaction pool. The shared transaction pool is configured with quotas for users (such as tenants) using the shared transaction pool, and the quota can indicate the maximum traffic that the user can add to the shared transaction pool. The traffic in the shared transaction pool can be routed to the target nodes in the public node pool. Among them, Chain-serverless-checker and Chain-serverless-router detect and switch among the nodes in the public node pool, thereby realizing traffic switching. Further, for the full-load situation, such as the load being greater than the threshold, the embodiment of the present application also supports dynamic expansion of the public node pool.

[0160] Based on the foregoing blockchain network management method, the present application provides a blockchain network management system. The blockchain network management system of the embodiment of the present application will be introduced below from the perspective of functional modularization with reference to the accompanying drawings.

[0161] See Figure 4A schematic structural diagram of a management system for a blockchain network is shown. The blockchain network includes a public node pool and external nodes. The management system 400 includes a controller 402, an inspector 404, and a router 406.

[0162] The controller 402 is configured to receive a node creation request.

[0163] The controller 402 is further configured to, in response to the node creation request, create a new node in the blockchain network, switch the traffic routed to the new node to a target node in the public node pool, where the public node pool is used to perform data pre-synchronization with external nodes in the blockchain network, and the target node is a node that is operating normally in the public node pool.

[0164] The inspector 404 is configured to check the status of the new node or the blockchain height of the ledger maintained by the new node.

[0165] The router 406 is configured to, when the status of the new node or the blockchain height of the ledger maintained by the new node meets the conditions, switch the traffic in the blockchain network that is directed from the new node to the target node to the new node.

[0166] Exemplarily, the above-mentioned controller 402, inspector 404, and router 406 can be implemented by hardware or can be implemented by software.

[0167] Among them, when implemented by software, the controller 402, the checker 404, and the router 406 can be application programs running on a computing device, such as a computing engine. This application program can be provided to users through virtualization services. The above virtualization services can include virtual machine (VM) services, bare metal server (BMS) services, and container services. Among them, the VM service can be a service that virtualizes a virtual machine (VM) resource pool on multiple physical hosts through virtualization technology to provide VMs for users on demand. The BMS service is a service that virtualizes a BMS resource pool on multiple physical hosts to provide BMS for users on demand. The container service is a service that virtualizes a container resource pool on multiple physical hosts to provide containers for users on demand. A VM is a simulated virtual computer, that is, a computer logically. A BMS is a highly scalable high-performance computing service with computing performance no different from that of a traditional physical machine and the characteristic of secure physical isolation. A container is a kernel virtualization technology that can provide lightweight virtualization to achieve the purpose of isolating user space, processes, and resources. It should be understood that the VM service, the BMS service, and the container service in the above virtualization services are only specific examples. In actual applications, the virtualization service can also be other lightweight or heavyweight virtualization services, which are not specifically limited here.

[0168] When implemented by hardware, at least one computing device, such as a server, can be included in the controller 402, the checker 404, and the router 406. Alternatively, the controller 402, the checker 404, and the router 406 can also be devices implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). Among them, the above PLD can be implemented by a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0169] In some possible implementation manners, the controller 402 is further configured to:

[0170] Receive node configuration information of a common node pool, where the node configuration information includes at least one of a blockchain type, an image location, a ledger backup policy, or a ledger backup frequency;

[0171] Create shared nodes in the common node pool according to the node configuration information;

[0172] Determine the number of non-snapshot ledger nodes among the shared nodes, and configure the snapshot ledger nodes and non-snapshot ledger nodes in the common node pool according to the number. The services running in the snapshot ledger nodes are interrupted during the generation of the ledger snapshot, and the non-snapshot ledger nodes operate normally.

[0173] In some possible implementation manners, the controller 402 is further configured to:

[0174] Instruct the new node to copy the ledger snapshot from the storage snapshot pool corresponding to the common node pool, perform ledger synchronization according to the ledger snapshot, and the storage snapshot pool stores the ledger snapshots generated by the snapshot ledger nodes in the common node pool.

[0175] In some possible implementation manners, the controller 402 is further configured to:

[0176] Receive the ledger synchronization method of the new node configured by the user, and the ledger synchronization method includes performing ledger synchronization based on the ledger snapshot.

[0177] In some possible implementation manners, the blockchain network further includes a user node pool, and the node creation request is used to create a new node in the user node pool.

[0178] In some possible implementation manners, the node creation request is used to create a new node in the common node pool, and the controller 402 is further configured to:

[0179] Add the traffic of the blockchain network to the shared transaction pool. The shared transaction pool is configured with a quota for the users using the shared transaction pool, and the quota is used to indicate the maximum traffic added by the user to the shared transaction pool. The traffic in the shared transaction pool is routed to the target nodes in the common node pool.

[0180] In some possible implementation manners, the target node is the node with a load less than the threshold or the top n nodes ranked from low to high in terms of load, and n is a positive integer.

[0181] In some possible implementation manners, the controller 402 is further configured to:

[0182] Receive a version update request, which is used to update the version of at least one node in the blockchain network;

[0183] According to the version update request, upgrade the version of at least one node, and switch the traffic of at least one node to the target node;

[0184] The router 406 is further configured to:

[0185] When the version update is completed on at least one node, switch the traffic in the blockchain network from at least one node to the at least one node that is directed to the target node.

[0186] In some possible implementation manners, the version update request is used to perform version update on at least one node in the public node pool of the blockchain network;

[0187] The controller 402 is specifically configured to:

[0188] Switch the traffic of at least one node to the non-upgraded nodes that are operating normally in the public node pool.

[0189] In some possible implementation manners, the checker 404 is further configured to:

[0190] Monitor the blockchain height of the ledger maintained by the nodes in the public node pool. When the difference between the blockchain height of the ledger maintained by the nodes in the public node pool and the blockchain height of the ledger maintained by the external nodes is greater than the first value, reset the ledger in the nodes and restore the ledger of the nodes according to the ledger snapshot.

[0191] This application also provides a computing device 900. As Figure 9 shown, the computing device 900 includes: a bus 902, a processor 904, a memory 906, and a communication interface 908. The processor 904, the memory 906, and the communication interface 908 communicate with each other through the bus 902. The computing device 900 may be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 900.

[0192] The bus 902 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience of representation, Figure 9 only one line is shown herein, but it does not mean that there is only one bus or one type of bus. The bus 902 may include a path for transmitting information between various components (for example, the memory 906, the processor 904, the communication interface 908) of the computing device 900.

[0193] The processor 904 may include any one or more of processors such as a central processing unit (CPU), a graphics processing unit (GPU), a micro processor (MP), or a digital signal processor (DSP).

[0194] The memory 906 may include volatile memory, such as random access memory (RAM). The memory 906 may also include non-volatile memory, such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0195] The memory 906 stores executable program code, and the processor 904 executes the executable program code to implement the foregoing management method of the blockchain network. Specifically, the memory 906 stores instructions for the management system 400 of the blockchain network to execute the management method of the blockchain network.

[0196] The communication interface 908 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 900 and other devices or a communication network.

[0197] The embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device may be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device may also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0198] As Figure 10 shown, the computing device cluster includes multiple computing devices 900. Instructions for the same management system 400 of the blockchain network to execute the management method of the blockchain network may be stored in the memory 906 of the computing devices 900 in the computing device cluster.

[0199] In some possible implementation manners, one or more computing devices 900 in the computing device cluster may also be used to execute some instructions of the management system 400 of the blockchain network for executing the management method of the blockchain network. In other words, the combination of one or more computing devices 900 may jointly execute the instructions of the management system 400 of the blockchain network for executing the management method of the blockchain network.

[0200] It should be noted that the memories 906 in different computing devices 900 in the computing device cluster may store different instructions for executing some functions of the management system 400 of the blockchain network. For example, the memories 906 of some computing devices 900 in the computing device cluster store instructions for executing the functions of the controller 402, and the memories 906 of some other computing devices 900 in the computing device cluster store instructions for executing the functions of the checker 404 and the router 406.

[0201] Figure 11 A possible implementation manner is shown. As Figure 11 shown, two computing devices 900A and 900B are connected through the communication interface 908. The memory in the computing device 900A stores instructions for executing the functions of the controller 402. The memory in the computing device 900B stores instructions for executing the functions of the checker 404 and the router 406. In other words, the memories 906 of the computing devices 900A and 900B jointly store the instructions of the management system 400 of the blockchain network for executing the management method of the blockchain network.

[0202] Figure 11 The connection manner between the computing device clusters shown is considered because the management method of the blockchain network provided in this application needs to check the status of new nodes and the ledger block heights maintained by new nodes for more resources. Therefore, it is considered to hand over the functions implemented by the checker 404 and the router 406 to different computing devices for execution.

[0203] It should be understood that Figure 11 the functions of the computing device 900A shown may also be completed by multiple computing devices 900. Similarly, the functions of the computing device 900B may also be completed by multiple computing devices 900.

[0204] In some possible implementation manners, one or more computing devices in the computing device cluster may be connected through a network. Among them, the network may be a wide area network or a local area network, etc. Figure 12 A possible implementation manner is shown. As Figure 12As shown, two computing devices 900C and 900D are connected via a network. Specifically, they are connected to the network through the communication interfaces in each computing device. In this possible implementation, the memory 906 in computing device 900C stores instructions for performing the functions of the execution controller 402. At the same time, the memory 906 in computing device 900D stores instructions for performing the functions of the inspector 404 and the router 406.

[0205] It should be understood that Figure 12 the functions of computing device 900C shown in can also be completed by multiple computing devices 900. Similarly, the functions of computing device 900D can also be completed by multiple computing devices 900.

[0206] The embodiments of the present application also provide a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc. The computer-readable storage medium includes instructions that direct a computing device to execute the above-mentioned management system 400 for a blockchain network to perform the management method for the blockchain network.

[0207] The embodiments of the present application also provide a computer program product containing instructions. The computer program product can be software or a program product containing instructions that can run on a computing device or be stored in any available medium. When the computer program product runs on at least one computing device, it causes at least one computing device to execute the above-mentioned management method for the blockchain network. The embodiments of the present application also provide a computer program product containing instructions. When the computer program product runs on at least one computing device, it causes at least one computing device to execute the above-mentioned management method for the blockchain network.

[0208] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for managing a blockchain network, characterized in that: A management system applied to a blockchain network, the blockchain network comprising a public node pool and external nodes, the management system comprising a controller, a checker and a router, the method comprising: The controller receives a node creation request; The controller creates a new node in the blockchain network in response to the node creation request, switches the traffic routed to the new node to a target node in the public node pool, the public node pool is used to perform data pre-synchronization with external nodes in the blockchain network, and the target node is a node in the public node pool that operates normally; The checker checks the state of the new node or the blockchain height of the ledger maintained by the new node; When the state of the new node or the blockchain height of the ledger maintained by the new node meets the condition, the router switches the traffic directed from the new node to the target node in the blockchain network to the new node.

2. The method according to claim 1, characterized in that The method further comprises: The controller receives node configuration information of the public node pool, where the node configuration information includes at least one of a blockchain type, a mirror location, a ledger backup strategy, or a ledger backup frequency; The controller creates a shared node in the public node pool according to the node configuration information; The controller determines the number of non-snapshot ledger nodes in the shared node, configures the snapshot ledger nodes and non-snapshot ledger nodes in the public node pool according to the number, and the business running in the snapshot ledger node is interrupted during the generation of the ledger snapshot, and the non-snapshot ledger node runs the business normally.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: The controller instructs the new node to copy a ledger snapshot from a storage snapshot pool corresponding to the public node pool, and performs ledger synchronization according to the ledger snapshot, wherein the storage snapshot pool stores the ledger snapshot generated by the snapshot ledger node in the public node pool.

4. The method according to claim 3, characterized in that The method further comprises: The controller receives a ledger synchronization mode of the new node configured by a user, where the ledger synchronization mode includes performing ledger synchronization based on a ledger snapshot.

5. The method according to any one of claims 1 to 4, characterized in that: The blockchain network also includes a user node pool, and the node creation request is used to create the new node in the user node pool.

6. The method according to any one of claims 1 to 4, characterized in that: The node creation request is used to create the new node in the public node pool, and the method further includes: The controller adds the traffic of the blockchain network to a shared transaction pool. The shared transaction pool is configured with a quota for users using the shared transaction pool. The quota is used to indicate the maximum traffic added by the user to the shared transaction pool. The traffic in the shared transaction pool is routed to the target node in the public node pool.

7. The method according to claim 5 or 6, characterized in that: The target node is the node whose load is less than a threshold or the top n nodes whose load is ranked from low to high, where n is a positive integer.

8. The method according to any one of claims 1 to 7, characterized in that: The method further comprises: The controller receives a version update request, where the version update request is used to perform a version update on at least one node in the blockchain network; The controller upgrades the version of the at least one node according to the version update request, and switches the traffic of the at least one node to the target node; When the at least one node completes the version update, the router switches the traffic directed from the at least one node to the target node in the blockchain network to the at least one node.

9. The method according to claim 8, characterized in that The version update request is used to perform a version update on at least one node in the public node pool of the blockchain network; The controller switches the traffic of the at least one node to the target node, including: The controller switches the traffic of the at least one node to a non-upgraded node in the public node pool that is operating normally.

10. The method according to any one of claims 1 to 9, characterized in that: The method further comprises: The checker monitors the blockchain height of the ledger maintained by the node in the public node pool, and when the difference between the blockchain height of the ledger maintained by the node in the public node pool and the blockchain height of the ledger maintained by the external node is greater than a first value, resets the ledger in the node, and restores the ledger of the node according to the ledger snapshot.

11. A management system for a blockchain network, characterized in that: The blockchain network includes a public node pool and external nodes, and the management system includes a controller, a checker, and a router; The controller is used to receive a node creation request; The controller is further used to create a new node in the blockchain network in response to the node creation request, and switch the traffic routed to the new node to a target node in the public node pool, wherein the public node pool is used to perform data pre-synchronization with external nodes in the blockchain network, and the target node is a node in the public node pool that operates the business normally; The checker is used to check the status of the new node or the blockchain height of the ledger maintained by the new node; The router is used to switch the traffic directed to the target node in the blockchain network to the new node when the state of the new node or the blockchain height of the ledger maintained by the new node meets the conditions.

12. The system according to claim 11, characterized in that The controller is also used for: Receiving node configuration information of the public node pool, the node configuration information including at least one of a blockchain type, a mirror location, a ledger backup strategy, or a ledger backup frequency; Creating a shared node in the public node pool according to the node configuration information; The number of non-snapshot ledger nodes in the shared node is determined, and the snapshot ledger nodes and non-snapshot ledger nodes in the public node pool are configured according to the number, and the business running in the snapshot ledger node is interrupted during the generation of the ledger snapshot, and the non-snapshot ledger node operates the business normally.

13. The system according to claim 11 or 12, characterized in that The controller is also used for: Instruct the new node to copy the ledger snapshot from the storage snapshot pool corresponding to the public node pool, and perform ledger synchronization according to the ledger snapshot, wherein the storage snapshot pool stores the ledger snapshot generated by the snapshot ledger node in the public node pool.

14. The system according to claim 13, characterized in that The controller is also used for: A ledger synchronization mode of the new node configured by a user is received, where the ledger synchronization mode includes performing ledger synchronization based on a ledger snapshot.

15. The system according to any one of claims 11 to 14, characterized in that: The blockchain network also includes a user node pool, and the node creation request is used to create the new node in the user node pool.

16. The system according to any one of claims 11 to 14, characterized in that: The node creation request is used to create the new node in the public node pool, and the controller is further used to: The traffic of the blockchain network is added to a shared transaction pool, wherein the shared transaction pool is configured with a quota for users using the shared transaction pool, wherein the quota is used to indicate the maximum traffic added by the user to the shared transaction pool, and the traffic in the shared transaction pool is routed to the target node in the public node pool.

17. The system according to claim 15 or 16, characterized in that The target node is the node whose load is less than a threshold or the top n nodes whose load is ranked from low to high, where n is a positive integer.

18. The system according to any one of claims 11 to 17, characterized in that The controller is also used for: Receiving a version update request, where the version update request is used to update the version of at least one node in the blockchain network; According to the version update request, upgrade the version of the at least one node, and switch the traffic of the at least one node to the target node; The router is also used to: When the at least one node completes the version update, the traffic directed from the at least one node to the target node in the blockchain network is switched to the at least one node.

19. The system according to claim 18, characterized in that The version update request is used to perform a version update on at least one node in the public node pool of the blockchain network; The controller is specifically used for: Switch the traffic of the at least one node to a non-upgraded node in the public node pool that is operating normally.

20. The system according to any one of claims 11 to 19, characterized in that The inspector is also used to: The blockchain height of the ledger maintained by the node in the public node pool is monitored, and when the difference between the blockchain height of the ledger maintained by the node in the public node pool and the blockchain height of the ledger maintained by the external node is greater than a first value, the ledger in the node is reset, and the ledger of the node is restored according to the ledger snapshot.

21. A computing device cluster, characterized in that: The computing device cluster includes at least one computing device, and the at least one computing device includes at least one processor and at least one memory, wherein the at least one memory stores computer-readable instructions; the at least one processor executes the computer-readable instructions so that the computing device cluster executes the method as described in any one of claims 1 to 10.

22. A computer-readable storage medium, characterized in that: The method comprises computer-readable instructions; the computer-readable instructions are used to implement the method according to any one of claims 1 to 10.

23. A computer program product, characterized in that The method comprises computer-readable instructions; the computer-readable instructions are used to implement the method according to any one of claims 1 to 10.

Images