Resource scheduling method and device of blockchain node

Abstract

A resource scheduling method and device of a blockchain node, a computing device, and a storage medium. The method includes obtaining historical running information of a plurality of blockchain nodes, the historical running information including at least load information and node status of the corresponding blockchain node in a plurality of consecutive historical time intervals. For any blockchain node in the plurality of blockchain nodes, the historical running information of the blockchain node is processed by a pre-trained machine learning model to obtain target load information of the blockchain node in a target time interval in the future. According to the current node status of the plurality of blockchain nodes, priority information of the plurality of blockchain nodes is determined. According to the priority information and the target load information of the plurality of blockchain nodes, a resource scheduling strategy is determined. According to the resource scheduling strategy, resources used by the plurality of blockchain nodes in the target time interval are scheduled.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of computer technology, and in particular relate to a resource scheduling method and apparatus for blockchain nodes. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain has received increasing attention and attention.

[0003] With the widespread adoption of blockchain technology across various industries, a single institution / organization may deploy / manage multiple blockchain nodes belonging to one or more blockchain systems. The resources required for a single blockchain node to operate, such as CPU resources, memory resources, storage resources (disk / data storage system), and network resources, are typically configured statically.

[0004] However, for any blockchain node, the actual load of the blockchain node, that is, the actual use of related resources during the operation of the blockchain node, is usually dynamic rather than fixed. It is very easy for the blockchain node to have low resource utilization and waste resources, as well as insufficient resource allocation and inefficient operation. Moreover, different blockchain nodes may run in the same environment, such as the same computing device, and there may be resource competition between multiple blockchain nodes. Summary of the Invention

[0005] The purpose of this invention is to provide a method and apparatus for resource scheduling of blockchain nodes.

[0006] In a first aspect, a resource scheduling method for blockchain nodes is provided, comprising: acquiring historical operating information of multiple blockchain nodes, wherein the historical operating information includes at least load information and node status of the corresponding blockchain node within m consecutive historical time intervals; for any blockchain node among the multiple blockchain nodes, processing the historical operating information of the blockchain node through a pre-trained machine learning model to obtain target load information of the blockchain node within a future target time interval; determining priority information of the multiple blockchain nodes based at least on the current node status of the multiple blockchain nodes; determining a resource scheduling strategy based on the priority information and target load information of the multiple blockchain nodes; and scheduling the resources used by the multiple blockchain nodes within the target time interval according to the resource scheduling strategy.

[0007] Secondly, a resource scheduling device for blockchain nodes is provided. The device includes: a data acquisition unit for acquiring historical operating information of multiple blockchain nodes, wherein the historical operating information includes at least the load information and node status of the corresponding blockchain node within m consecutive historical time intervals; a model invocation unit for processing the historical operating information of any blockchain node among the multiple blockchain nodes using a pre-trained machine learning model to obtain the target load information of the blockchain node within a future target time interval; a priority determination unit for determining the priority information of the multiple blockchain nodes based at least on the current node status of the multiple blockchain nodes; a strategy planning unit for determining a resource scheduling strategy based on the priority information and target load information of the multiple blockchain nodes; and a resource scheduling unit for scheduling the resources used by the multiple blockchain nodes within the target time interval according to the resource scheduling strategy.

[0008] Thirdly, a computing device is provided, including a memory and a processor, wherein the memory stores computer programs / instructions, and the processor executes the computer programs / instructions to implement the method described in the first aspect.

[0009] Fourthly, a computer-readable storage medium is provided having a computer program stored thereon, wherein when the computer program is executed in a computing device, the computing device performs the method described in the first aspect.

[0010] The technical solutions provided in the embodiments of this specification are conducive to improving the resource utilization rate of blockchain nodes, while ensuring that higher priority blockchain nodes have sufficient resources to operate efficiently. Attached Figure Description

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

[0012] Figure 1 This is a system architecture diagram of the technical solutions provided in the embodiments of this specification;

[0013] Figure 2 This is a flowchart of a resource scheduling method for a blockchain node provided in the embodiments of this specification;

[0014] Figure 3 This is a schematic diagram of the structure of a resource scheduling device for a blockchain node provided in the embodiments of this specification. Detailed Implementation

[0015] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0016] A single blockchain system comprises multiple interconnected blockchain nodes. These nodes can store the entire ledger, that is, the state of all blocks and all accounts. Each node in the blockchain system can produce the same state by executing the same transactions, thus each node can store the same state database.

[0017] This specification provides a resource scheduling method, apparatus, computing device, and computer-readable non-volatile storage medium for blockchain nodes, which is beneficial to improving the resource utilization of multiple blockchain nodes. At the same time, it can also ensure that higher priority blockchain nodes can operate efficiently when there is resource competition among different blockchain nodes.

[0018] Figure 1 This is a system architecture diagram of the technical solutions provided in the embodiments of this specification. (Refer to...) Figure 1 As shown, a single institution / organization may need to deploy / manage multiple blockchain nodes belonging to one or more blockchain systems; for example, an institution may need to deploy blockchain nodes A1, A2, B1, B2, C1, and C2, where A1 and A2 belong to blockchain system A, B1 and B2 belong to blockchain system B, and C1 and C2 belong to blockchain system C. For any given blockchain node, it may run directly on the host operating system of a computing device, or it may run as a container in a computing cluster comprising multiple computing devices, or it may run as a virtual machine on various other possible cloud computing platforms.

[0019] As an example, the blockchain nodes A1, A2, B1, B2, C1, and C2 in the aforementioned example may run in a computing cluster managed by a container orchestration tool such as Kubernetes (k8s). This computing cluster may include, but is not limited to, multiple computing devices such as computing device 1, computing device 2, computing device 3, and computing device 4. The k8s control plane may run on the computing device acting as the master node, or it may run distributed across multiple computing devices.

[0020] The Kubernetes control plane may include, but is not limited to, the following components:

[0021] The API Server (kube-apiserver) serves as the entry point to the computing cluster. All internal components, client tools (such as kubectl), and user requests are scheduled through the API Server, and etcd is read and written on demand.

[0022] Etcd is a highly available key-value store database where all configuration data for all Kubernetes clusters is stored.

[0023] The Scheduler manages newly created Pods that are not yet assigned to any worker nodes. A Pod is the smallest deployable unit and typically consists of one or a group of containers, such as containers used to run blockchain nodes.

[0024] The Controller Manager is a daemon responsible for ensuring that the current state of the computing cluster matches the expected state.

[0025] Computing devices in a computing cluster can act as worker nodes, responsible for running containerized applications. Worker nodes may run a node agent (Kubelet), a container runtime, and a network proxy (Kube-proxy). The Kubelet is primarily responsible for receiving Pod definitions from the API Server, ensuring the healthy operation of the containers described in those Pods, and also reporting the worker node's status to the control plane. The container runtime is the software responsible for running the containers. Kube-proxy maintains network rules on each worker node, implementing the Kubernetes Service concept, using the operating system's packet filtering or direct traffic forwarding.

[0026] For example, users can create Pod-1, Pod-2, Pod-3, Pod-4, Pod-5, and Pod-6 on demand through the Kubernetes control plane, and schedule Pod-1 and Pod-2 to compute device 2, Pod-3 and Pod-4 to compute device 3, and Pod-5 and Pod-6 to compute device 4. Kubelet can then trigger the container runtime to start and run the corresponding containers based on the Pods scheduled to their respective compute devices, thereby enabling the running of corresponding blockchain nodes on the compute devices. For example, blockchain nodes A1 and A2 can run on compute device 2, B1 and C1 on compute device 3, and B2 and C2 on compute device 4.

[0027] The following will combine Figure 1 The system architecture shown describes a resource scheduling method for blockchain nodes.

[0028] Figure 2 This is a flowchart illustrating a resource scheduling method for a blockchain node provided in the embodiments of this specification. It is understood that this method can be executed by any device, platform, equipment, or cluster of devices with computing / processing capabilities, such as a computing device deployed with a resource scheduling device for a blockchain node provided in the embodiments of this specification.

[0029] See Figure 2 As shown, the method may include, but is not limited to, some or all of the following steps S201 to S209.

[0030] Step S201: Obtain the historical operation information of each of the multiple blockchain nodes. The historical operation information includes at least the load information and node status of the corresponding blockchain node in m consecutive time intervals.

[0031] The length of a single time interval can usually be set as needed, such as 1 hour, 12 hours, 24 hours, etc.

[0032] Load information describes the usage of system resources by the corresponding blockchain node. Load information may include, but is not limited to, one or more of the following: processor load, memory load, storage load, and network load.

[0033] For any blockchain node's load information within any time interval, the load information of the blockchain node within that time interval can be obtained by sampling the load information of the blockchain node once or multiple times within that time interval, and by averaging or otherwise processing the load information after one or more samplings.

[0034] Continued Figure 1 For example, a node agent deployed in a computing device acting as a worker node can periodically collect load information of each container in its computing device and report it to the Kubernetes control plane. Since a single container runs a blockchain node, the container's load information can be directly used as the result of sampling the load information of the corresponding blockchain node. For instance, within any i-th time interval of length T, the node agent (i.e., Kubelet) in computing device 1 can sample the load information of Containerd-1 in Pod-1 and Containerd-2 in Pod-2 multiple times according to time interval t and report it to the Kubernetes control plane. The load information sampled for Containerd-1 is the same as the load information sampled for blockchain node A1, and the load information sampled for Containerd-2 is the same as the load information sampled for blockchain node A2.

[0035] Here, we assume the current time interval is the Nth interval. We can then obtain the load information sampled from blockchain node A1 within the Nm to Nth intervals by calling the API Server provided by the Kubernetes control plane. By averaging or otherwise processing the load information sampled from blockchain node A1 within the same interval, we can obtain the load information of blockchain node A1 within the N-m+1 to Nth intervals. Similarly, we can obtain the load information of blockchain nodes A2, B1, B2, C1, and C2 within the N-m+1 to Nth intervals.

[0036] The preceding text primarily used Kubernetes as an example to illustrate the load information of a blockchain node over m time intervals. If a blockchain node is deployed on a cloud computing platform managed by a cloud platform management tool other than Kubernetes, the control plane of the cloud platform management tool may have similar capabilities to Kubernetes. It may also sample the load information of the blockchain node (e.g., a virtual machine running a single blockchain node) through a node agent, thereby obtaining the sampled load information of the blockchain node from the control plane of the cloud platform management tool, and thus obtaining the load information from the N-m+1 to the Nth time interval.

[0037] The node status describes the state of the relevant blockchain node itself, which may include, but is not limited to, one or more of the following: whether it is a consensus node, the current number of blockchain nodes connected to the communication, and the message sending and receiving frequency.

[0038] For any blockchain node's state within any time interval, the state can be obtained by calling one or more public interfaces provided by the blockchain node within that time interval. For example, the state can be obtained by calling one or more public interfaces provided by the blockchain node at time intervals of length T.

[0039] Here, it is assumed that the current time interval is the Nth time interval. The historical operation information of any blockchain node, such as blockchain node A1, can include the node state of blockchain node A1 from the N-m+1th time interval to the Nth time interval.

[0040] Blockchain nodes may also continuously record security logs during operation; the security logs at any time interval can reflect the security status of the blockchain node within that time interval, such as the node's connectivity, whether there is abnormal access, and whether there is abnormal restart, etc. In some embodiments, the historical operation information of a blockchain node may also include the security status of the blockchain node over m consecutive historical time intervals.

[0041] In summary, assuming the current time interval is the Nth interval, and we want to predict the load information of a blockchain node in the (N+k)th interval, we can obtain m operating states of the blockchain node from the (N-m+1)th to the Nth interval as its historical operating information. The operating information of the blockchain node in any (i)th interval can include one or more of the following types of information: load information, node state, and security state. Here, m is greater than k and k is greater than 0.

[0042] The aforementioned multiple blockchain nodes are typically deployed by the same participant, such as an institution / organization. These multiple blockchain nodes may belong to one or more blockchain systems, which may be heterogeneous blockchain systems. Continuing from the above... Figure 1 For example, the node engines used by A1 and A2 in blockchain system A may be Ethereum, the node engines used by B1 and B2 in blockchain system B may be Fabric, and the node engines used by C1 and C2 in blockchain system C may be Corda. Blockchain systems A, B, and C are heterogeneous blockchain systems.

[0043] When multiple blockchain nodes belong to multiple blockchain systems, the business priorities of these blockchain systems can typically be pre-set. For example, blockchain system A is a consortium blockchain, primarily used by multiple institutions to collaborate on various financial-related business activities, such as using on-chain issued digital assets to facilitate foreign exchange purchases / exchanges or other possible cross-border / inter-organizational asset transfers. Blockchain system B is also a consortium blockchain, primarily used by multiple institutions (such as one or more brand holders, one or more digital asset issuers, or one or more digital asset operators) to collaborate on brand licensing, issuance, and circulation. The blockchain system itself is a private blockchain, primarily used to provide data storage services. Therefore, the institutions to which blockchain nodes A1, A2, B1, B2, C1, and C2 belong may pre-set the business priority L1 of blockchain system A to be greater than the business priority L2 of blockchain system B, and the business priority L2 of blockchain system B to be greater than the business priority L2 of blockchain system C. Correspondingly, different business priorities may map to different priority scores; for example, L1 corresponds to a priority score of 1, L2 to a priority score of 0.8, and L3 to a priority score of 0.5.

[0044] It is understood that the business priorities and their corresponding priority scores in the foregoing examples are only used to assist in describing the technical solutions provided in the embodiments of this specification and do not constitute a limitation thereon. For example, different blockchain systems may correspond to the same business priorities, there may be other priorities such as priority L4 which is lower than L3, and each business priority may correspond to other priority scores.

[0045] Step S203: For any blockchain node among multiple blockchain nodes, the historical operation information of the blockchain node is processed by a pre-trained machine learning model to obtain the target load information of the blockchain node within a future target time interval.

[0046] A pre-trained machine learning model can be obtained by fine-tuning a general-purpose large model using a training dataset. Alternatively, the machine learning model can also be any machine learning model capable of processing time series data, such as a Long Short-Term Memory (LSTM) network, trained using a training dataset. This paper does not limit this to any particular model.

[0047] For example, the training dataset may include the operational information of multiple blockchain nodes over L consecutive time intervals, such as the operational information of blockchain node A1 over L consecutive time intervals. During training, for these L consecutive time intervals, the operational information of a blockchain node, such as blockchain node A1, during the 1st to mth time intervals can be used as sample input data, and the load information included in the (m+1)th time interval of blockchain node A1 can be used as the sample label corresponding to the sample input data; similarly, the operational information of blockchain node A1 during the 2nd to (m+1)th time intervals can be used as sample input data, and the load information included in the (m+2)th time interval of blockchain node A1 can be used as the sample label corresponding to the sample input data; the operational information of blockchain node A1 during the 3rd to (m+2)th time intervals can be used as sample input data, and the load information included in the (m+3)th time interval of blockchain node A1 can be used as the label data corresponding to the sample input data, and so on.

[0048] Continuing with the example in step S201 above, for any blockchain node, such as blockchain node A1, the operating information of blockchain node A1 in the N-m+1 to Nth time intervals can be used as the historical operating information of blockchain node A1 and input into a pre-trained machine learning model to obtain the predicted target load information of blockchain node A1 in the N+1th time interval. If the target time interval is after the N+1th time interval, in this case, the operating information of blockchain node A1 in the N-m+2 to Nth time intervals and the predicted target load information of blockchain node A1 in the N+1th time interval can again be used as the historical operating information of blockchain node A1 and input into the machine learning model to obtain the predicted target load information of blockchain node A1 in the N+2th time interval, and so on, until the target load information of blockchain node A1 in the N+kth time interval is predicted using the pre-trained machine learning model.

[0049] Step S205: Determine the priority information of multiple blockchain nodes based on their current node status.

[0050] The current node state of a blockchain node refers to the most recently obtained node state of that blockchain node. Continuing with the example under step S201 above, the current node state of blockchain node A1 can be the node state of blockchain node A1 in the Nth time interval, which may include, but is not limited to, whether it is a consensus node, the current number of blockchain nodes connected to it, and the message sending and receiving frequency. Generally speaking, consensus nodes are more important than non-consensus nodes. The larger the current number of blockchain nodes connected to it, the greater its impact on network connectivity and the more important it is. The higher the message sending and receiving frequency, the more blockchain nodes or clients it connects to and the more important it is. The more important the blockchain node, the more it needs to be able to operate efficiently. Therefore, the priority information of a blockchain node can be evaluated by combining its node state.

[0051] In a specific example, the evaluation indicators can be whether a blockchain node is a consensus node, the current number of blockchain nodes it is connected to, and the message sending and receiving frequency. A preset scoring strategy is used to determine the evaluation scores corresponding to each piece of information indicating the security status of the blockchain node. These scores are then processed using a weighted average or other methods to obtain the priority score corresponding to the blockchain node's status. Furthermore, the priority score corresponding to the blockchain node's status can be used as the priority information for that blockchain node.

[0052] In some embodiments, when multiple nodes belong to multiple blockchain systems, the priority information of the multiple blockchain nodes can be determined based on their current node status and the business priority corresponding to their respective blockchain systems. Continuing the exemplary description of business priorities and their corresponding priority scores in step S201 above, for any blockchain node, the priority information of the blockchain node can be determined based on the priority score corresponding to the business priority of the blockchain system to which the blockchain node belongs, and the priority score corresponding to the node status of the blockchain node.

[0053] In one example, for any blockchain node, such as blockchain node A1, the priority score corresponding to the business priority L1 of blockchain system A can be weighted and summed with the priority score corresponding to the current node state of blockchain node A1. The result can be used as the priority information of blockchain node A1.

[0054] Step S207: Determine the resource scheduling strategy based on the priority information and target load information of multiple blockchain nodes.

[0055] When it is necessary to control the cost of resource consumption of multiple blockchain nodes, the resource scheduling strategy can be determined based on the priority information, target load information, and pre-determined resource cost control information of the multiple blockchain nodes.

[0056] Resource scheduling strategies may include, but are not limited to, one or more of the following: the resource scheduling order of multiple blockchain nodes and the share of target resources to be added / removed from any blockchain node. The target resources mentioned here correspond to load information and may include, for example, CPU resources, memory resources, storage resources, or network resources.

[0057] The ultimate goal of resource scheduling strategies is to ensure that more important blockchain nodes (those with higher priority scores) have sufficient CPU, memory, storage, and network resources to ensure their efficient operation. The increase / decrease in the share of a target resource for any blockchain node can be determined based on predicted target load information and the resources already allocated to blockchain nodes at the current moment. In one example, for any resource such as CPU, memory, storage, or network resources, the desired increase or decrease in the share of that resource for each blockchain node can be determined based on the target load information of each blockchain node in the N+k time interval and the allocated resources of each blockchain node in the Nth time interval. This, combined with the priority information of the blockchain nodes, determines the corresponding resource scheduling order.

[0058] The following description uses memory resources as an example to illustrate the concept.

[0059] For example, it is assumed that the allocated memory resources (the upper limit of allowed memory resources) of A1, A2, B1, B2, C1, and C2 in the Nth time interval are all 4G. If the memory utilization rate of A1 in the N+kth time interval is close to / reaches 100%, it may be determined through preset rules that blockchain node A1 expects to increase its share of memory resources by 2G. Similarly, it may be determined based on the memory load indicated by the target load information of A2, B1, B2, C1, and C2 in the N+kth time interval that A2, B1, B2, and C1 expect to increase memory by 2G, and C2 expects to decrease memory by 2G. A1, A2, B1, B2, C1, and C2 can be sorted, where the blockchain node expecting to decrease memory resources can be placed before the blockchain node expecting to increase memory resources, and the blockchain nodes expecting to increase memory resources can be arranged in descending order of priority information, thereby obtaining the resource scheduling order corresponding to the memory resources.

[0060] Here, we assume the resource scheduling order for memory resources is C2, A1, B1, C1, A2, B2. Without considering cost control, the memory resources that a blockchain node expects to increase / decrease can be considered the memory resources that the blockchain node needs to increase / decrease. Considering cost control, the share of memory resources that each blockchain node needs to increase can be determined by combining the resource cost control information of memory resources and the share of memory resources that each blockchain node expects to increase.

[0061] For example, the resource cost control information of memory resources indicates that the upper limit of memory resource allocation for A1 and A2 belonging to blockchain system A is 11G. In order to ensure the efficient operation of the more important A1, and at the same time ensure that the upper limit of memory resource allocation for A1 and A2 does not exceed 11G, it is possible to directly use the share of memory resources that A1 expects to increase by 2G as the share of memory resources that A1 needs to increase. The share of memory resources that A2 needs to increase is not the expected 2G, but only 1G of allocable share.

[0062] Similar to memory resources, we can also determine the share of CPU resources that A1, A2, B1, B2, C1, and C2 need to increase / decrease, as well as the corresponding resource scheduling order for CPU resources; we can also determine the share of storage resources that A1, A2, B1, B2, C1, and C2 need to increase / decrease, as well as the corresponding resource scheduling order for storage resources; and we can also determine the share of network resources that A1, A2, B1, B2, C1, and C2 need to increase / decrease, as well as the corresponding resource scheduling order for network resources.

[0063] Step S209: According to the resource scheduling strategy, schedule the resources used by multiple blockchain nodes within the target time interval.

[0064] Continuing with the example under step S207 above, for any target resource, such as memory resources, the target resources used by relevant blockchain nodes within the target time interval can be increased / decreased before the target time interval arrives, according to the resource scheduling order corresponding to the target resource. Still using... Figure 1 Taking the example system architecture, by calling the Kubernetes control plane, the container resource configuration information of the container to which the relevant blockchain node belongs or the Pod resource configuration information of the Pod to which the relevant blockchain node belongs can be modified, and finally, the various possible resources used by the relevant blockchain node within the target time interval can be increased or decreased.

[0065] Continuing with the example under step S207 above, since B1 and C1 operate on the same computing device 2, there may be resource contention between B1 and C1. By following the resource scheduling order corresponding to memory resources, the more important B1 can be ensured to operate efficiently as much as possible. When additional memory resources are needed for C1, it may not be possible to add 2GB of memory to C1 as needed due to insufficient remaining memory resources on computing device 2. In this case, C1, which is less important than B1, may not be able to operate efficiently.

[0066] Based on the same concept as the foregoing method embodiments, this specification also provides a resource scheduling device 300 for blockchain nodes. (Refer to...) Figure 3 As shown, the resource scheduling device 300 includes: a data acquisition unit 301, used to acquire historical operating information of multiple blockchain nodes, the historical operating information including at least the load information and node status of the corresponding blockchain node in m consecutive historical time intervals; a model invocation unit 303, used to process the historical operating information of any blockchain node among the multiple blockchain nodes through a pre-trained machine learning model to obtain the target load information of the blockchain node in a future target time interval; a priority determination unit 305, used to determine the priority information of the multiple blockchain nodes at least based on the current node status of the multiple blockchain nodes; a strategy planning unit 307, used to determine a resource scheduling strategy based on the priority information and target load information of the multiple blockchain nodes; and a resource scheduling unit 309, used to schedule the resources used by the multiple blockchain nodes in the target time interval according to the resource scheduling strategy.

[0067] This specification also provides a computer-readable storage medium storing a computer program / instruction, which, when executed in a computer, causes the computer to perform a resource scheduling method for a blockchain node provided in the foregoing embodiments.

[0068] This specification also provides a computing device in the embodiments, including a memory and a processor. The memory stores computer programs / instructions, and when the processor executes the computer programs / instructions, it implements a resource scheduling method for blockchain nodes provided in the foregoing embodiments.

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

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

[0071] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0072] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0073] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

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

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

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

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

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

[0079] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

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

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

[0082] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0083] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A resource scheduling method for blockchain nodes, the method comprising: Obtain the historical operating information of multiple blockchain nodes, wherein the historical operating information includes at least the load information and node status of the corresponding blockchain node in m consecutive historical time intervals; For any blockchain node among the plurality of blockchain nodes, the historical operation information of the blockchain node is processed by a pre-trained machine learning model to obtain the target load information of the blockchain node within a future target time interval; Priority information of the multiple blockchain nodes is determined based at least on their current node states. Based on the priority information and target load information of the multiple blockchain nodes, a resource scheduling strategy is determined; According to the resource scheduling strategy, the resources used by the multiple blockchain nodes within the target time interval are scheduled.

2. The method according to claim 1, wherein the load information includes one or more of the following: CPU load, memory load, storage load, and network load.

3. The method according to claim 1, wherein the node status includes one or more of the following: whether it is a consensus node, the current number of blockchain nodes with communication connections, and the message sending and receiving frequency.

4. The method according to claim 1, wherein the historical operation information further includes the security status of the blockchain node in multiple consecutive historical time intervals, wherein the information indicates node connectivity, whether there is abnormal access, and whether there is abnormal restart.

5. The method according to claim 1, wherein the plurality of blockchain nodes belong to multiple blockchain systems; in, The step of determining the priority information of the multiple blockchain nodes based on their current node states includes: determining the priority information of the multiple blockchain nodes based on their current node states and the business priorities corresponding to their respective blockchain systems.

6. The method according to claim 1, wherein determining the resource scheduling strategy based on the priority information and target load information of the plurality of blockchain nodes specifically includes: Based on the priority information of the multiple blockchain nodes, the target load information of the multiple blockchain nodes, and the pre-determined resource cost control information, a resource scheduling strategy is determined.

7. The method according to any one of claims 1-7, wherein the resource scheduling strategy comprises: The resource scheduling order of the multiple blockchain nodes and the share of target resources to be added / reduced for any blockchain node.

8. The method according to any one of claims 1-7, wherein the machine learning model is trained using a training dataset, the training dataset comprising the operating information of multiple blockchain nodes over L consecutive time intervals; wherein when the operating information of any blockchain node over any m consecutive time intervals is used as sample input data, the load information included in the operating information of the blockchain node in the next time interval of the m time intervals is used as the corresponding sample label.

9. A resource scheduling device for a blockchain node, the device comprising: The data acquisition unit is used to acquire the historical operating information of multiple blockchain nodes, wherein the historical operating information includes at least the load information and node status of the corresponding blockchain node in m consecutive historical time intervals. The model invocation unit is used to process the historical operation information of any blockchain node among the plurality of blockchain nodes through a pre-trained machine learning model to obtain the target load information of the blockchain node within a future target time interval. A priority determination unit is used to determine the priority information of the plurality of blockchain nodes based at least on the current node status of the plurality of blockchain nodes. The strategy planning unit is used to determine the resource scheduling strategy based on the priority information and target load information of the multiple blockchain nodes. The resource scheduling unit is used to schedule the resources used by the multiple blockchain nodes within the target time interval according to the resource scheduling strategy.

10. A computing device comprising a memory and a processor, wherein the memory stores a computer program / instructions, and the processor, when executing the computer program / instructions, implements the method of any one of claims 1-8.

Images