Blockchain network management method and related device

Abstract

A blockchain network management method, which is applied to a blockchain network management system. A blockchain network comprises a public node pool and external nodes. The management system comprises a controller, an inspector and a router. The method comprises: a controller receiving a node creation request, and in response to the node creation request, the controller creating a new node in a blockchain network, and switching to a target node in a public node pool traffic routed to the new node; an inspector inspecting the state of the new node or a blockchain height of a ledger maintained by the new node; and when the state of the new node or the blockchain height of the ledger maintained by the new node meets conditions, a router switching to the new node the traffic directed to the target node in the blockchain network. In the method, a public node pool is introduced to perform data pre-synchronization with external nodes, and a new node can perform ledger synchronization on the basis of a ledger snapshot from a node in the public node pool, so that it is not necessary to occupy a large amount of bandwidth resources, and the ledger synchronization time can also be significantly shortened.

Description

A blockchain network management method and related equipment

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on December 18, 2023, with application number 202311743446.9, entitled “A blockchain management method and related equipment”, and claims priority to the Chinese patent application filed with the State Intellectual Property Office on March 22, 2024, with application number 202410338240.6, entitled “A blockchain network management method and related equipment”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of blockchain technology, and in particular to a blockchain network management method, a blockchain network management system, 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, through a consensus mechanism based on cryptography, jointly maintain a continuously growing, linked list ledger consisting of time-stamped and ordered data blocks. Blockchain allows any number of participating nodes in the system to calculate and record the data exchanged over a period of time into a data block using cryptographic algorithms. The block's fingerprint is then generated for linking to the next block and verification. All participating nodes in the system jointly determine the authenticity of the record.

[0004] Cloud-native blockchain nodes can provide resources to customers on demand, leading to their widespread adoption. Specifically, users can purchase an Elastic Cloud Server (ECS) virtual machine on a cloud platform, deploy a blockchain node on the ECS virtual machine, configure a large-capacity storage device for synchronizing node data, and configure an Elastic IP Address (EIP) for peer-to-peer data transmission with nodes in the blockchain network.

[0005] Each blockchain node needs to synchronize and transmit a large amount of data. Therefore, adding a new node to a blockchain network consumes significant bandwidth resources. For example, the average data volume of a full node in a public blockchain is approximately 1 terabyte (TB). Synchronizing 1TB of data from the ledger using a peer-to-peer synchronization model consumes significant bandwidth, impacting normal on-chain transactions. Furthermore, it takes a week for the new node to complete data synchronization before it becomes available.

[0006] Summary of the Invention

[0007] This application provides a method for managing a blockchain network. This method introduces a public node pool and external nodes in the blockchain network to pre-synchronize data. New nodes created by users can synchronize their ledgers based on the ledger snapshots of nodes in the public node pool, eliminating the need to consume large amounts of bandwidth resources and significantly reducing ledger synchronization time. Furthermore, during the creation of new nodes or ledger synchronization, traffic on the blockchain network is switched to target nodes in the public node pool that are operating normally, ensuring uninterrupted business operations. This application also provides a blockchain network management system, computing device cluster, computer-readable storage medium, and computer program product corresponding to the above method.

[0008] In a first aspect, this application provides a blockchain network management method. This method can be applied to a blockchain network management system, also referred to as a management system. The management system can be a software system that is used to meet tenant business needs through a node pool in a multi-tenant cloud platform scenario. This software system can be deployed on a computing device cluster, which executes the software system's program code to implement the blockchain network management method of this application. In some examples, the management system can also be a hardware system, such as a computing device cluster that supports rapid blockchain node creation and instant startup. While the computing device cluster is running, it executes the blockchain network management method of this application.

[0009] Among them, 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 can receive a node creation request, and then the controller responds to the node creation request to create a new node in the blockchain network and switches the traffic routed to the new node to the target node in the public node pool. The public node pool is used to pre-synchronize data with external nodes in the blockchain network, and the target node is a node in the public node pool that is operating normally. The checker checks the status of the new node or the blockchain height (also referred to as block height) of the ledger maintained by 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, the router switches the traffic directed from the new node to the target node in the blockchain network to the new node.

[0010] This method introduces a public node pool into the blockchain network. This public node pool can pre-synchronize data with external nodes in the blockchain network. New nodes can then synchronize their ledgers based on the ledger snapshots of nodes in the public node pool, eliminating the need for significant bandwidth resources and significantly reducing ledger synchronization time, for example, from a week to minutes. Furthermore, during new node creation or ledger synchronization, blockchain network traffic is redirected to the target node in the public node pool, ensuring uninterrupted service.

[0011] In some possible implementations, the controller may further receive node configuration information from the public node pool, the node configuration information including at least one of the blockchain type, mirror location, ledger backup strategy, or ledger backup frequency. Based on the node configuration information, the controller creates shared nodes in the public node pool, determines the number of non-snapshot ledger nodes in the shared nodes, and configures snapshot ledger nodes and non-snapshot ledger nodes in the public node pool based on the number of shared nodes. Services running on the snapshot ledger nodes are interrupted during the generation of the ledger snapshot, while services on the non-snapshot ledger nodes continue to operate normally.

[0012] This allows for the pre-creation (or prefabrication) of a public node pool, laying the foundation for subsequent ledger synchronization of new nodes based on the public node pool and accelerating the startup of new nodes.

[0013] In some possible implementations, the controller instructs the new node to copy a ledger snapshot from the storage snapshot pool corresponding to the public node pool and synchronize the ledger based on the ledger snapshot. The storage snapshot pool stores the ledger snapshots generated by the snapshot ledger nodes in the public node pool. Synchronizing the ledger based on the ledger snapshot can significantly shorten the ledger synchronization time, making the new node immediately available.

[0014] In some possible implementations, the controller may further receive a ledger synchronization method for a new node configured by a user, where the ledger synchronization method includes performing ledger synchronization based on a ledger snapshot.

[0015] This method supports user-defined ledger synchronization methods. When the user defines the ledger synchronization method as ledger synchronization based on ledger snapshots, the ledger snapshot is used to synchronize the ledger on the new node. When the user defines the ledger synchronization method as other synchronization methods, such as the ordinary synchronization method, the ledger is synchronized using point-to-point methods, which has better compatibility.

[0016] In some possible implementations, 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.

[0017] Nodes in the public node pool that synchronize with external nodes can be considered seed nodes. The public node pool pre-synchronizes blocks and other data with seed nodes to synchronize data with external nodes and build the latest ledger in real time. The user node pool is used to meet node usage requirements and provide users with fast access capabilities. The user node pool and the public node pool can quickly synchronize data via the intranet, providing the ability to create or start nodes in seconds.

[0018] In some possible implementations, a node creation request is used to create a new node in the public node pool. Accordingly, the controller adds blockchain network traffic (e.g., transaction requests, transaction transactions) to the shared transaction pool. The shared transaction pool is configured with a quota for users using the shared transaction pool. The quota indicates the maximum amount of traffic that a user can add to the shared transaction pool. Traffic in the shared transaction pool is routed to a target node in the public node pool. The shared transaction pool can be viewed as a message queue, and the publisher-consumer mechanism can be used to dispatch blockchain network traffic to a target node in the public node pool for processing.

[0019] This method introduces a shared transaction pool and uses user configuration quotas in the shared transaction pool to achieve flow control and ensure normal business operation.

[0020] In some possible implementations, the target node is a node with a load less than a threshold or a load ranking in the top n from lowest to highest, where n is a positive integer. Traffic in the shared transaction pool can be dispatched to the target node with a load less than a threshold or a load ranking in the top n from lowest to highest through load balancing, thereby reducing congestion.

[0021] In some possible implementations, the controller may also receive a version update request for updating at least one node in the blockchain network. Based on the version update request, the controller upgrades the at least one node and switches traffic from the at least one node to the target node. When the at least one node completes the version update, the router switches traffic from the at least one node in the blockchain network to the target node. This ensures uninterrupted service during the version upgrade, meeting service requirements.

[0022] In some possible implementations, a version update request is used to update the version of at least one node in the public node pool of a blockchain network. Accordingly, the controller may switch traffic from the at least one node to a non-upgraded node in the public node pool that is operating normally. For example, the controller may switch traffic from the at least one node to a non-rolling upgrade node in the public node pool that is operating normally. This achieves high service availability.

[0023] In some possible implementations, the checker can also monitor the blockchain height of the ledger maintained by the nodes in the public node pool. When the blockchain height of the ledger maintained by the node in the public node pool differs from the blockchain height of the ledger maintained by the external node by more than a first value, the node's ledger is reset and restored based on the ledger snapshot. This allows for timely fault detection and rapid recovery.

[0024] In a second aspect, the present 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, a checker, and a router.

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

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

[0027] The checker is used to check the status of the new node or the blockchain height of the ledger maintained by the new node;

[0028] The router is configured to switch the traffic directed from the new node 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 a condition.

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

[0030] Receive 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;

[0031] Creating a shared node in the public node pool according to the node configuration information;

[0032] Determine the number of non-snapshot ledger nodes in the shared node, configure the snapshot ledger nodes and non-snapshot ledger nodes in the public node pool according to the number, interrupt the business running in the snapshot ledger node during the generation of the ledger snapshot, and operate the business normally on the non-snapshot ledger node.

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

[0034] 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.

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

[0036] Receive a user-configured ledger synchronization method for the new node, where the ledger synchronization method includes performing ledger synchronization based on a ledger snapshot.

[0037] 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.

[0038] 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:

[0039] The traffic of the blockchain network is added 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 that the user can add to the shared transaction pool. The traffic in the shared transaction pool is routed to the target node in the public node pool.

[0040] In some possible implementations, 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.

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

[0042] receiving a version update request, wherein the version update request is used to update the version of at least one node in the blockchain network;

[0043] Performing a version upgrade on the at least one node according to the version update request, and switching traffic of the at least one node to the target node;

[0044] The router is also used to:

[0045] 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.

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

[0047] The controller is specifically used for:

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

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

[0050] Monitoring a blockchain height of a ledger maintained by a node in the public node pool; when a difference between a blockchain height of the ledger maintained by the node in the public node pool and a blockchain height of a ledger maintained by an external node is greater than a first value, resetting the ledger in the node, and restoring the node's ledger according to the ledger snapshot.

[0051] In a third aspect, the present application provides a computing device cluster. The computing device cluster includes at least one computing device, each of which 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 computing device cluster performs the blockchain network management method described in the first aspect or any implementation of the first aspect.

[0052] In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores instructions, wherein the instructions instruct a computing device or a computing device cluster to execute the blockchain network management method described in the first aspect or any one of the implementations of the first aspect.

[0053] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when run on a computing device or a computing device cluster, enables the computing device or the computing device cluster to execute the blockchain network management method described in the above-mentioned first aspect or any one of the implementations of the first aspect.

[0054] Based on the implementation methods provided in the above aspects, this application can also be further combined to provide more implementation methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] In order to more clearly illustrate the technical methods of the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments.

[0056] FIG1 is a schematic diagram of a node pool in a blockchain network provided by this application;

[0057] FIG2 is a schematic diagram of a user-specific node pool provided by the present application;

[0058] FIG3 is a schematic diagram of a user-shared node pool provided by the present application;

[0059] FIG4 is a schematic diagram of the architecture of a blockchain network management system provided by this application;

[0060] FIG5 is a flowchart of a blockchain network management method provided by this application;

[0061] FIG6 is a schematic diagram of a process for creating a public node pool provided by this application;

[0062] FIG7 is a schematic diagram of an application scenario of a blockchain network management method provided by this application;

[0063] FIG8 is a schematic diagram of an application scenario of another blockchain network management method provided by this application;

[0064] FIG9 is a schematic diagram of the structure of a computing device provided by the present application;

[0065] FIG10 is a schematic diagram of the structure of a computing device cluster provided by this application;

[0066] FIG11 is a schematic diagram of the structure of another computing device cluster provided by the present application;

[0067] FIG12 is a schematic diagram of the structure of another computing device cluster provided in this application. DETAILED DESCRIPTION

[0068] The terms "first" and "second" in the embodiments of this application are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of technical features indicated. Therefore, features specified as "first" or "second" may explicitly or implicitly include one or more of the features.

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

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

[0071] 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 each node's local copy through transactions. A certain encryption mechanism is used to ensure that the data in the ledger cannot be arbitrarily deleted or altered. It is important to note that distributed ledger systems tolerate Byzantine faults, including but not limited to those caused by node crashes, inaccessibility, network latency, or malicious node behavior. Byzantine faults, also known as the Byzantine problem, refer to the problem of reaching consensus in scenarios where a small number of nodes may act maliciously (messages may be forged). To achieve data consistency across all nodes in a distributed ledger system, each system utilizes a consensus mechanism.

[0072] A consensus mechanism is an algorithm used by different nodes in a distributed ledger system to agree on the current valid state of the ledger. The goal of a consensus mechanism can be to achieve eventual consistency of the ledger through consensus among the nodes in the distributed system. If all nodes can successfully resolve blocks and store the same copy of the ledger, the distributed ledger system has achieved eventual consistency.

[0073] Cloud computing is a computing model that provides dynamically scalable, virtualized resources as a service over the network. Platform as a Service (PaaS) is one of the primary multi-tenant models of cloud computing. A PaaS platform allows different tenants to register and access its resources and services. For example, a PaaS platform can provide blockchain services (BaaS), which can be used as a public cloud service, providing public cloud tenants with the ability to create or deploy blockchain nodes.

[0074] Serverless computing (abbreviated as serverless) is a cloud computing execution model. In a serverless architecture, cloud providers or cloud vendors allocate machine resources on demand and manage servers on behalf of customers. Developers of serverless applications do not worry about 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; computations are completed in a short period of time, and the results are saved to storage. When an application is not in use, no computing resources are allocated to it. This effectively reduces application operation and maintenance costs.

[0075] Serverless-based blockchain services have become a mainstream solution for cloud blockchain hosting applications. Cloud-native blockchain nodes are widely used because they can provide resources to customers on demand while significantly reducing internal resources. In sectors like web3, where resource consumption and costs are of paramount concern, building blockchain nodes using serverless capabilities offers significant advantages for creating low-cost blockchain nodes.

[0076] Currently, adding a new node to a blockchain network typically involves purchasing an Elastic Compute Service (ECS) virtual machine (VM) on a cloud platform and then directly deploying the blockchain node there. However, this new node requires significant bandwidth to synchronize its ledger with existing nodes in the blockchain network. For example, the Ethereum blockchain network consists of approximately 7,000-10,000 nodes distributed across various cities globally. New nodes pull ledgers from these nodes for synchronization. In public blockchains like Ethereum, the average full node holds approximately 1TB of data, with some even reaching several TB. This significant bandwidth consumption for new node ledger synchronization can impact on-chain transactions. Each new node requires this synchronization process, resulting in redundant bandwidth consumption. Furthermore, using the peer-to-peer gossip synchronization model, new nodes typically require a week to complete data synchronization before they are operational, making them difficult to meet business needs.

[0077] In light of this, the present application provides a method for managing a blockchain network. This method can be performed by a blockchain network management system. For ease of description, the present application may also refer to the blockchain network management system as simply the management system. The management system can be a software system that, in a multi-tenant cloud platform scenario, uses a node pool to meet tenant business needs while supporting blockchain features such as blockchain node changes. Blockchain features include, but are not limited to, rapid creation of new nodes (e.g., creating blockchain nodes in seconds), blockchain node updates (e.g., version updates), and blockchain node fault repair. The solution of the present application can reduce bandwidth consumption, allowing service providers to build service capabilities with minimal resources. Furthermore, blockchain nodes created in seconds eliminate ledger synchronization time, enabling immediate availability. The software system can be deployed on a computing device cluster, which executes the software system's program code to implement the blockchain network management method 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 aforementioned blockchain features. When the computing device cluster is running, it executes the blockchain network management method of the present application.

[0078] The blockchain network includes a public node pool and external nodes, and the management system can include a controller, a checker, and a router. Specifically, the controller can receive node creation requests. In response to the node creation requests, the controller creates a new node in the blockchain network and switches traffic routed to the new node to a target node in the public node pool. The public node pool is used to pre-synchronize data with external nodes. External nodes refer to blockchain nodes in external networks, such as those managed by other organizations in the blockchain network. Nodes in the public node pool typically use EIPs to interact with external nodes. The target node is a node in the public node pool that is operating normally. The checker can check the status of the new node or the blockchain height (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 meet certain requirements, the router switches traffic in the blockchain network directed from the new node to the target node to the new node.

[0079] This method introduces a public node pool into the blockchain network. This public node pool can pre-synchronize data with external nodes in the blockchain network. New nodes can then synchronize their ledgers based on the ledger snapshots of nodes in the public node pool, eliminating the need for significant bandwidth resources and significantly reducing ledger synchronization time, for example, from a week to minutes. Furthermore, during new node creation or ledger synchronization, blockchain network traffic is redirected to the target node in the public node pool, ensuring uninterrupted service.

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

[0081] The blockchain network management method provided in this application uses a node pool to ensure that different blockchain networks can adapt to the serverless architecture. This serverless architecture enables rapid synchronization of blockchain ledgers, rapid recovery from node failures, and uninterrupted service upgrades. Furthermore, the node pool reduces bandwidth consumption by new nodes (those newly added to the blockchain network) and enables node startup within seconds. Furthermore, internal detection devices, such as checkers, enable automatic repair of node failures.

[0082] To facilitate understanding of the technical solution of the present application, the node pool introduced in the present application is first introduced below with reference to the accompanying drawings.

[0083] Referring to FIG1 , a schematic diagram of a node pool in a blockchain network is shown. The blockchain network 10 includes a public node pool 100, which includes multiple nodes. The nodes in the public node pool 100 can be shared nodes, and the nodes in the public node pool 100 can be distributed in different locations, for example, in different availability zones (AZs). FIG1 illustrates an example in which the public node pool 100 includes three nodes, which are distributed in AZ1, AZ2, and AZ3, respectively. 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 ledgers with the external nodes in the node network to build the latest ledger. The node network can be a network formed by nodes managed by other organizations in the blockchain network 10.

[0084] Nodes in the public node pool 100 can also back up ledgers. Specifically, nodes can generate ledger snapshots using the snapshot function to achieve ledger backup. A ledger snapshot is a fully usable copy of the ledger, which includes the state of the ledger at a certain point in time (such as the time when the copy was started). Nodes in the public node pool 100 that back up ledgers using snapshots are also called snapshot ledger nodes. Snapshot ledger nodes can generate ledger snapshots based on the configured backup frequency. For example, a snapshot ledger node can generate a ledger snapshot every 10 minutes. Considering that the business on the snapshot ledger node may be interrupted when backing up the ledger—in other words, the business running on the snapshot ledger node may be interrupted during the generation of the ledger snapshot—the public node pool 100 can also include non-snapshot ledger nodes to ensure uninterrupted business. Non-snapshot ledger nodes can support normal business operation. In the example of Figure 1, the public node pool 100 includes two snapshot ledger nodes and one non-snapshot ledger node.

[0085] Furthermore, the blockchain network 10 may also include a user node pool 200. Users can trigger the creation of blockchain nodes in the user node pool 200. Users can create blockchain nodes on demand, and the blockchain nodes created by users are new nodes. When creating a new node, for example, in the user node pool 200, the user can configure the new node's ledger synchronization method, which includes synchronizing the ledger based on a ledger snapshot. When the user configures the ledger synchronization method to synchronize the ledger based on a ledger snapshot, the node creation request may also include an identifier or flag for synchronizing the ledger based on the ledger snapshot. After the new node is created, the ledger snapshot generated by the backup of the node in the public node pool can be obtained, and the ledger can be synchronized based on the ledger snapshot to obtain the latest ledger. The new node can synchronize the ledger with the ledger snapshot with the largest ledger block height (the latest ledger snapshot) to further improve synchronization efficiency. Compared to traditional solutions, the ledger synchronization time of this application can be reduced to minutes, which can meet business needs.

[0086] 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.

[0087] As shown in Figure 2, the blockchain nodes constructed in the user node pool 200 can be user-specific nodes. The user node pool 200 can include a user-specific node pool. Each node in the user-specific node pool is dedicated to a user. For example, the user-specific node pool can include three user-specific nodes, each of which belongs to different users.

[0088] As shown in Figure 3, the blockchain nodes constructed in the user node pool 200 can be user-shared nodes. The user node pool 200 can 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 non-dedicated mode, the resources in the user-shared node pool can be shared with all users, thereby improving resource utilization (reuse rate).

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

[0090] 4 shows a schematic diagram of a management system architecture, management system 400 includes a controller 402, an inspector 404, and a router 406. The functions of controller 402, inspector 404, and router 406 are described below.

[0091] Controller 402 is used to receive a node creation request. Controller 402 is also used to create a new node in the blockchain network in response to the node creation request and switch traffic routed to the new node (e.g., traffic dispatched to the new node via load balancing) to a target node in the public node pool. The public node pool is used to pre-synchronize data with external nodes, and the target node is a node in the public node pool that is operating normally. For example, the public node pool may include snapshot ledger nodes and non-snapshot ledger nodes. The business running on the snapshot ledger node is interrupted during the generation of the ledger snapshot, while the non-snapshot ledger node is operating normally. Based on this, the target node may be a non-snapshot ledger node. In some examples, the snapshot ledger node may include a first node that is in the process of generating a ledger snapshot or a second node that is not in the process of generating a ledger snapshot. The target node may also be the second node. The non-snapshot ledger node or the second node in the snapshot ledger node that is not in the process of generating a ledger snapshot may be collectively referred to as an available node in the public node pool, and the available nodes may form an available public node pool.

[0092] Checker 404 is used to check the status of the new node or the blockchain height of the ledger maintained by the new node. Blockchain height, also referred to as block height, refers to the maximum number of blocks produced on the current blockchain. Block height can be represented by the number or number of blocks in the blockchain. The block number is the number of blocks between the block and the genesis block. The genesis block is the first block produced on the blockchain and is typically numbered 0.

[0093] Router 406 is configured to switch traffic directed from the new node 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 a condition. The state of the new node meeting the condition may mean that the new node has been created. The blockchain height of the ledger maintained by the new node may mean 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 may be represented 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 difference. The first value may be determined based on the block output rate.

[0094] Based on the management system 400 shown in Figure 4, the present application also provides a method for managing a blockchain network. The following describes the method for managing a blockchain network of the present application in conjunction with the accompanying drawings.

[0095] Referring to FIG5 , a flowchart of a method for managing a blockchain network is shown. The blockchain network includes a public node pool and external nodes, wherein the external nodes may be nodes managed by other organizations. Nodes in the public node pool support interaction with external networks, for example, through EIPs. The method is executed by a management system 400 , which includes a controller 402 , a checker 404 , and a router 406 . The method includes the following steps:

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

[0097] A node creation request, sometimes also called a node activation request, is used to create a new node, which is a blockchain node. Blockchain nodes are responsible for storing data blocks and serve as the storage unit within a blockchain network, keeping data synchronized and up-to-date. Blockchain nodes can be internally structured as a unit, consisting of a consensus client and an execution client. These two clients can communicate via Remote Procedure Calls (RPCs). The consensus client is responsible for broadcasting blocks, while the execution client is responsible for broadcasting transactions. For example, a consensus client can receive a block from another node using the block gossip protocol, check that the block format is valid, and then send it to the execution client. The execution client then executes all transactions in the block into the Ethereum Virtual Machine (EVM), updates the Merkle Patricia Trie (MPT), a data structure that records transactions within the abstraction layer, and then checks the hash value of the block header for correctness. 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 its local blockchain and then broadcasts it to the consensus layer network.

[0098] In a specific implementation, 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 may 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-dedicated node or a user-shared node.

[0099] The controller 402 may provide a configuration interface where the user can configure the node information of the new node to be created. This node information may include the node pool to which the node belongs. Furthermore, the node information may include the node type. The node pool to which the node belongs may include 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 also include the node type, which may be a user-dedicated node or a user-shared node.

[0100] In some possible implementations, the controller 402 may also receive version update requests, which are sometimes referred to as version upgrade requests or node upgrade requests. Version update requests are used to perform version upgrades (e.g., background version upgrades) to update chain nodes (at least one node in the blockchain network). To avoid service interruptions, a rolling update approach can be used to update or upgrade chain nodes. A rolling update refers to updating a batch of blockchain nodes at a time, rather than updating all blockchain nodes at the same time. When one batch of blockchain nodes is updated, the next batch of blockchain nodes is updated.

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

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

[0103] The public node pool 100 is used to pre-synchronize data with external nodes. Specifically, the nodes in the public node pool 100 are configured with EIPs. Through EIPs, the nodes in the public node pool 100 can interact with external nodes in the node network to pre-synchronize the ledger and build the latest ledger in real time.

[0104] The target node is a node that is operating normally in the public node pool 100. The following describes each of them separately.

[0105] In some possible implementations, a node creation request is used to create a new node in the public node pool 100. Specifically, the node creation request indicates that the node pool to which the new node belongs is the public node pool 100, and the controller 402 can create a new node in the public node pool 100 in response to the node creation request. To avoid business interruption, the controller 402 also switches the traffic routed to the new node in the blockchain network to the target node in the public node pool 100. The target node can be, for example, a low-load node in the available public node pool. The available public node pool includes available nodes in the public node pool, which are nodes that are operating normally. A low-load node can be a node with a load threshold value or a load ranked in the top n from low to high. Wherein, n is a positive integer.

[0106] In some other possible implementations, the blockchain network includes a user node pool 200, and a node creation request can 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, and the controller 402 can create a new node in the user node pool 200 in response to the node creation request. To avoid business interruption, the controller 402 also switches the traffic routed to the new node in the blockchain network to the target node in the public node pool 100. The target node can be, for example, a node in the available public node pool, that is, an available node in the public node pool 100. The business of the target node runs normally. Among them, the target node can be a non-snapshot ledger node in the public node pool. Alternatively, the target node can also be a snapshot ledger node in the public node pool that is not in the period of generating a ledger snapshot, such as the second node.

[0107] Furthermore, when the node creation request indicates that a new node is to be created in the user node pool 200, the controller 402 may create a new node of the corresponding type in the user node pool 200 based on the node type indicated in the node creation request. For example, if the node type indicated in the node creation request is a user-dedicated node, the controller 402 may create the user-dedicated node in the user node pool 200. For another example, if the node type indicated in the node creation request is a user-shared node, the controller 402 may create a user-shared node in the public node pool 100.

[0108] It should be noted that when a node creation request is used to create a new node in the public node pool 100, the controller 402 can also add traffic from the blockchain network to the shared transaction pool. The shared transaction pool is configured with a quota for users using the shared transaction pool, which indicates the maximum amount of traffic a user can add to the shared transaction pool. Traffic in the shared transaction pool can be routed to the target node in the public node pool 100. This prevents data synchronization from occupying excessive bandwidth resources and ensures the normal operation of application services.

[0109] The snapshot ledger node in the public node pool 100 can also generate a ledger snapshot, which can be stored in the storage snapshot pool. In the node creation scenario, 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 synchronize the ledger according to the ledger snapshot. Among them, the controller 402 can also receive the ledger synchronization method of the new node configured by the user. Among them, the ledger synchronization method can include synchronizing the ledger based on the ledger snapshot. When the user configures the ledger synchronization method to synchronize the ledger based on the ledger snapshot, the node creation request can also include an identifier or flag for synchronizing the ledger based on the ledger snapshot. Accordingly, when the controller 402 pulls up a new node, such as a user-dedicated node, the node can use the target ledger snapshot to synchronize the ledger. This can greatly shorten the ledger synchronization time and reduce the consumption of bandwidth resources.

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

[0111] Controller 402 can utilize a rolling upgrade approach to update a batch of blockchain nodes in the blockchain network. Based on the node identifiers in the version update request, controller 402 can update a batch of blockchain nodes in the blockchain network corresponding to the node identifiers. Furthermore, controller 402 can switch traffic from at least one node in the blockchain network undergoing a version update to a target node in the public node pool 100. When the blockchain network includes a user node pool 200, the node undergoing the version update is a node in the user node pool 200, and the target node can be an available node in the public node pool 100 that meets load requirements, such as the aforementioned low-load node operating normally. When the blockchain network does not include a user node pool 200, the target node can be a non-upgraded node, such as a node not undergoing a rolling upgrade.

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

[0113] Specifically, a new node may send a heartbeat message upon completion of creation, and checker 404 may check the status of the new node by checking the heartbeat message. For example, if checker 404 receives a heartbeat message from the new node, it indicates that the new node has been created. Otherwise, it indicates that the new node has not been created. For example, if checker 404 does not receive a heartbeat message from the new node within a set time, it indicates that the new node has not been created.

[0114] The blockchain height, also referred to as the block height, is specifically the maximum number of blocks produced on the current blockchain. The block height can be represented by the number or number of blocks in the blockchain. Checker 404 can read the number of the latest block in the ledger maintained by the new node to obtain the block height of the ledger maintained by the new node.

[0115] S508 : When the state 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 directed from the new node to the target node in the blockchain network to the new node.

[0116] The condition that the status of the changed node meets the requirement may be that the change is completed, for example, the new node is created. The condition that the blockchain height of the ledger maintained by the new node meets the requirement may 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 (referred to as the block height difference between the new node and the external node) is less than a first value. Wherein, the status of the new node is creation 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 directed from the new node to the target node in the blockchain network back to the new node. In some examples, the router 406 can also switch the traffic directed from the new node to the target node in the blockchain network 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 requirements.

[0117] The first value can be determined based on the block generation rate. For example, the first value can be determined by the following formula:

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

[0119] Wherein, a represents the block rate, specifically the number of blocks per second, m is the number of minutes, for example, it can be 2, and s represents the first value.

[0120] Furthermore, for at least one node in the blockchain network undergoing a version upgrade, the router 406 may switch traffic directed from the at least one node to the target node in the blockchain network to the at least one node when the at least one node completes the version upgrade. Specifically, the router 406 may 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 update 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 (i.e., the difference in block height between the at least one node and the external node) is less than a first value, indicating that the at least one node is available, the router 406 may switch traffic directed from the new node to the target node in the blockchain network back to the at least one node that has completed the update (upgrade).

[0121] In some possible implementations, the checker 404 may also monitor the blockchain height of the ledger maintained by the nodes in the public node pool 100. Specifically, when the new node is a node created in the public node pool 100, the blockchain height of the ledger maintained by the node in the public node pool 100 may 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 node in the public node pool 100 and the blockchain height of the ledger maintained by the external node is greater than a first value, indicating that the node's ledger is abnormal, the checker 404 may reset the node's ledger and restore the node's ledger based on a ledger snapshot.

[0122] Based on the above description, this method introduces a public node pool into the blockchain network. The public node pool and external nodes in the blockchain network perform data pre-synchronization. New nodes can synchronize their ledgers based on the ledger snapshots of nodes in the public node pool, eliminating the need to consume large amounts of bandwidth resources and significantly reducing ledger synchronization time, for example, from one week to minutes. Furthermore, during the creation of a new node, traffic routed to the new node in the blockchain network (for example, traffic dispatched to the new node via load balancing) is switched to the target node in the public node pool that is operating normally, ensuring uninterrupted business operations.

[0123] It should be noted that the public node pool 100 of the present application is different from the node-based resource pool in the related art. The node-based resource pool in the related art cannot be used directly 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 soft fork problems. Among them, soft fork refers to a temporary fork caused by the production of illegal blocks by non-upgraded nodes due to ignorance of the new consensus rules after the new consensus rules are released. To this end, it is necessary to check the block height difference between the current data block and the external data block, and to repair it in time when there is a problem with the block height difference. Moreover, after the transaction is initiated, each transaction will incur fees and the user will incur consumption. If the data in the memory is not sent successfully, resulting in an abnormality in the node's ledger (node ​​failure), the memory data needs to be repaired and rebuilt, otherwise the transaction will be lost.

[0124] In the solution of this application, users (such as administrators) can first complete the creation of a preset public node pool and complete the ledger synchronization to ensure the availability of the ledger to achieve subsequent node creation, node update or fault repair.

[0125] 6 shows a schematic diagram of a process for creating a public node pool, which includes the following steps:

[0126] S602 : The controller 402 receives node configuration information of a public node pool.

[0127] Node configuration information includes at least one of the following: blockchain type, image location, ledger backup policy, or ledger backup frequency. The blockchain type may include various types of permissionless blockchains, including but not limited to Ethereum. The image location may include the location of the image file used to create or start the node.

[0128] A ledger backup strategy refers to a strategy for backing up ledgers maintained by nodes in a public node pool, such as a strategy for generating snapshots of ledgers. In some examples, the ledger backup strategy can be determined based on high availability requirements. To achieve high availability, the following formula is typically required:

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

[0130] Where F is the number of nodes in the public node pool performing transactions, such as non-snapshot ledger nodes. Count is the total number of nodes in the public node pool. For example, if the public node pool includes three nodes, the ledger backup strategy could be to have two nodes designated as snapshot ledger nodes, snapshotting the ledger for backup purposes, and one node designated as a non-snapshot ledger node, used to perform transactions and ensure normal business operation when the snapshot ledger node is interrupted for backup.

[0131] The ledger backup frequency can be the frequency at which ledger snapshots are generated. This frequency can be set based on experience. In some examples, the ledger backup frequency can be 10 minutes.

[0132] In some possible implementations, the node configuration information may also include configuration file content configuration, such as the number of external connections and the frequency of pulling blocks.

[0133] S604 : The controller 402 creates a shared node in the public node pool according to the node configuration information.

[0134] Based on the node configuration information, controller 402 can invoke a blockchain service, such as BaaS, to create a shared node in a public node pool. Specifically, based on the blockchain type and image location in the node configuration information, controller 402 can generate a blockchain node of the corresponding blockchain type through BaaS. This blockchain node is a shared node. The blockchain node is deployed with the image file obtained from the corresponding image location.

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

[0136] Considering that blockchain nodes often need to interrupt business operations to generate ledger snapshots, such as interrupting memory transaction writing, and restarting to receive or synchronize the latest transactions after the ledger snapshot is generated, controller 402 can configure non-snapshot ledger nodes to ensure that business operations can continue to operate normally when some blockchain nodes generate ledger snapshots for ledger backup. In addition, controller 402 also configures snapshot ledger nodes to generate ledger snapshots for ledger backup. On the one hand, this allows new nodes to synchronize ledgers based on ledger snapshots, shortening synchronization time. On the other hand, it allows for rapid fault recovery based on the ledger snapshot in the event of a fault.

[0137] Controller 402 can determine the number of non-snapshot ledger nodes in the shared node pool based on 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. Controller 402 can then configure a corresponding number of nodes in the public node pool as non-snapshot ledger nodes based on the aforementioned number.

[0138] Furthermore, the controller 402 may also configure the ledger backup frequency of the snapshot ledger node according to the ledger backup frequency in the node configuration information.

[0139] It should be noted that the relevant content of the embodiment of FIG6 can also be combined with the aforementioned embodiments, and this application does not limit this.

[0140] Next, the management method of the blockchain network of this application is introduced in combination with specific application scenarios.

[0141] Referring to FIG7 , there is a schematic diagram of an application scenario of a method for managing a blockchain network. In this scenario, the administrator needs to complete the creation of a preset public node pool and complete the synchronization of the ledger to ensure that the ledger is available before starting to build the user node pool. The management method of the blockchain network can be collaboratively 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 is illustrated by an example in which tenant A creates a node and tenant C upgrades a node, and specifically includes the following steps:

[0142] 1. The administrator enters node configuration information and pool management strategy.

[0143] Node configuration information, also known as chain node information, can include blockchain type, image location, and configuration file content. Administrators can initialize the public node pool by configuring this chain node information. Administrators can also configure the public node pool's pool management policy, including ledger backup strategy and frequency.

[0144] 2. The Chain-serverless-controller creates shared nodes in the public node pool based on the node configuration information. It determines the number of non-snapshot ledger nodes based on the ledger backup policy and configures non-snapshot ledger nodes based on that number. The Chain-serverless-controller configures the ledger backup frequency for the snapshot ledger nodes.

[0145] Snapshot ledger nodes can generate ledger snapshots of their own nodes in the storage snapshot pool at a fixed time according to the configured ledger backup frequency. Snapshot ledger nodes can also record the block height of the ledger snapshot.

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

[0147] Excluding repair nodes means excluding repair nodes (nodes currently under repair) from the routing table, preventing routing through them. Expanding a syncing node involves expanding the capacity of a syncing node. A completed node refers to a node that has been created or updated. Chain-serverless-checker can schedule a repair module to repair a completed node when the block height difference between the completed node and an external node is greater than s.

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

[0149] (a) Exclude the repair node and monitor the block height of the completed node. If the block height difference exceeds s, schedule the repair module to repair the current node.

[0150] (b) Schedule the node reset module to reset the node's ledger and restore it based on the ledger snapshot. For example, Chain-serverless-checker can restore the node's ledger based on the latest ledger snapshot.

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

[0152] Specifically, repairing a node may be resetting the ledger maintained by the node, and then restoring the node's ledger based on a ledger snapshot. For example, the node's ledger may be restored based on the latest ledger snapshot.

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

[0154] Switching traffic to the public node pool allows services to be provided using nodes in the public node pool. At the same time, the user node pool can quickly pull up nodes and synchronize data based on the highest block ledger snapshot.

[0155] 5. Chain-serverless-router can schedule chain-serverless-checker to check the status and block height of nodes in the user node pool. When the status and block height of nodes in the user node pool meet the requirements, Chain-serverless-router switches the traffic back to the user node pool to start the node serverless.

[0156] 6. When tenant C triggers a version update, the background upgrade will first switch traffic to the nodes in the public node pool. Then, the Chain-serverless-router schedules the chain-serverless-checker to check the status and block height of the upgraded nodes. When the conditions are met, the Chain-serverless-router switches traffic back to the user node pool, completing the background upgrade without any perception.

[0157] The Chain-serverless-router component serves as the user's node access portal. It closely interacts with the Chain-serverless-checker component to obtain the status of different nodes. In a series of switching scenarios such as node creation, upgrades, and failures, it connects to available nodes in different node pools to ensure uninterrupted customer business.

[0158] Specifically, during node creation, the Chain-serverless-router calls the Chain-serverless-checker to check the user node pool creation status and the ledger block height. If creation is incomplete or the block height difference is greater than s, traffic is directed to the available public node pool. During the upgrade process, traffic switches to the available public node pool. After the user node upgrade is complete and the block height difference is less than s, traffic is switched back to the user node pool.

[0159] Referring to Figure 8, an application scenario diagram of another blockchain network management method is shown. In this scenario, the administrator needs to initialize a public node pool and configure pool management policies, such as the ledger backup strategy and frequency. Once the pre-configured public node pool is created and ledger synchronization is complete, ensuring ledger availability, node creation and version updates can be triggered. This example uses the example of tenant A creating a node and tenant C upgrading a node.

[0160] As shown in Figure 8, tenant A initiates the node activation process, for example, triggering the node activation operation, Chain-serverless-controller receives the node creation request, tenant C initiates the version upgrade process, and Chain-serverless-controller receives the version upgrade request. The embodiment shown in Figure 8 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 a quota for users (such as tenants) using the shared transaction pool. The quota can indicate the maximum traffic that the user adds to the shared transaction pool. The traffic in the shared transaction pool can be routed to the target node in the public node pool. Among them, Chain-serverless-checker and Chain-serverless-router detect and switch each node in the public node pool to achieve traffic switching. Furthermore, for full load conditions, such as when the load is greater than the threshold, the embodiment of the present application also supports dynamic expansion of the public node pool.

[0161] Based on the aforementioned blockchain network management method, this application provides a blockchain network management system. The following describes the blockchain network management system of the present application embodiment from the perspective of functional modularization, in conjunction with the accompanying drawings.

[0162] Referring to the structural diagram of a management system of a blockchain network shown in Figure 4, the blockchain network includes a public node pool and external nodes, and the management system 400 includes a controller 402, a checker 404 and a router 406.

[0163] Controller 402, configured to receive a node creation request;

[0164] The controller 402 is further configured to create a new node in the blockchain network in response to a node creation request, and switch traffic routed to the new node to a target node in the public node pool. The public node pool is configured 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 is operating normally.

[0165] Checker 404, used to check the status of the new node or the blockchain height of the ledger maintained by the new node;

[0166] Router 406 is configured to switch traffic directed from the new node 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 a condition.

[0167] For example, the controller 402 , the inspector 404 , and the router 406 may be implemented by hardware or software.

[0168] When implemented via software, controller 402, checker 404, and router 406 can be applications running on a computing device, such as a computing engine. These applications can be provided to users via virtualization services. These virtualization services may include virtual machine (VM) services, bare metal server (BMS) services, and container services. VM services can use virtualization technology to create a virtual machine (VM) resource pool on multiple physical hosts, providing users with VMs on demand. BMS services use virtualized BMS resource pools on multiple physical hosts, providing users with BMSs on demand. Container services use virtualized container resource pools on multiple physical hosts, providing users with containers on demand. A VM is a simulated virtual computer, or logically a single computer. BMS is a scalable, high-performance computing service with computing performance comparable to traditional physical machines and secure physical isolation. Containers are a kernel virtualization technology that provides lightweight virtualization to isolate user space, processes, and resources. It should be understood that the VM service, BMS service, and container service in the above-mentioned virtualization services are merely specific examples. In actual applications, the virtualization service may also be other lightweight or heavyweight virtualization services, which are not specifically limited here.

[0169] When implemented in hardware, the controller 402, the checker 404, and the router 406 may include at least one computing device, such as a server. Alternatively, the controller 402, the checker 404, and the router 406 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

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

[0171] Receiving node configuration information of a public node pool, the node configuration information including at least one of a blockchain type, an image location, a ledger backup strategy, or a ledger backup frequency;

[0172] Create shared nodes in the public node pool based on node configuration information;

[0173] Determine the number of non-snapshot ledger nodes in the shared node pool, and configure snapshot ledger nodes and non-snapshot ledger nodes in the public node pool based on the number. The business running on the snapshot ledger node will be interrupted during the generation of the ledger snapshot, while the non-snapshot ledger node will run normally.

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

[0175] Instruct the new node to copy the ledger snapshot from the storage snapshot pool corresponding to the public node pool and synchronize the ledger based on the ledger snapshot. The storage snapshot pool stores the ledger snapshots generated by the snapshot ledger nodes in the public node pool.

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

[0177] Receives the ledger synchronization method of the new node configured by the user. The ledger synchronization method includes ledger synchronization based on ledger snapshots.

[0178] In some possible implementations, 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.

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

[0180] The traffic of the blockchain network is added to the 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 that the user can add to the shared transaction pool. The traffic in the shared transaction pool is routed to the target node in the public node pool.

[0181] In some possible implementations, the target node is the node whose load is less than the threshold or the top n nodes whose load is ranked from low to high, where n is a positive integer.

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

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

[0184] 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;

[0185] Router 406 is also used to:

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

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

[0188] The controller 402 is specifically configured to:

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

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

[0191] Monitor the blockchain height of the ledger maintained by the node in the public node pool. 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, reset the ledger in the node and restore the node's ledger according to the ledger snapshot.

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

[0193] Bus 902 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG9 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 902 may include a path for transmitting information between various components of computing device 900 (e.g., memory 906, processor 904, and communication interface 908).

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

[0195] 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, hard disk drive (HDD), or solid state drive (SSD).

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

[0197] 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.

[0198] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can 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 can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0199] As shown in Figure 10, the computing device cluster includes multiple computing devices 900. The memory 906 of the computing devices 900 in the computing device cluster may store the same blockchain network management system 400 for executing instructions of the blockchain network management method.

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

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

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

[0203] The connection method between the computing device clusters shown in Figure 11 can be considered to take into account the fact that the blockchain network management method provided by this application requires more resources to check the status of new nodes and the high ledger blocks maintained by new nodes. Therefore, it is considered to assign the functions implemented by the checker 404 and router 406 to different computing devices.

[0204] It should be understood that the functionality of the computing device 900A shown in FIG11 may also be implemented by multiple computing devices 900. Similarly, the functionality of the computing device 900B may also be implemented by multiple computing devices 900.

[0205] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network. The network may be a wide area network (WAN) or a local area network (LAN), among others. FIG. 12 illustrates a possible implementation. As shown in FIG. 12 , two computing devices 900C and 900D are connected via a network. Specifically, the connection to the network is achieved via a communication interface within each computing device. In this type of possible implementation, the memory 906 within the computing device 900C stores instructions for executing the functions of the controller 402. Simultaneously, the memory 906 within the computing device 900D stores instructions for executing the functions of the checker 404 and the router 406.

[0206] It should be understood that the functionality of the computing device 900C shown in FIG12 may also be accomplished by multiple computing devices 900. Similarly, the functionality of the computing device 900D may also be accomplished by multiple computing devices 900.

[0207] The present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device, or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the management system 400 applied to a blockchain network to execute the management method of the blockchain network.

[0208] The present application also provides a computer program product containing instructions. The computer program product may be software or a program product containing instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute the aforementioned blockchain network management method. The present application also provides a computer program product containing instructions. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute the aforementioned blockchain network management method.

[0209] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the various 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 nodes in the public node pool. If the difference between the blockchain height of the ledger 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.

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: Monitor 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, reset the ledger in the node, and The snapshot restores the ledger of the node.

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