Self-adaptive node operation method and device, storage medium and electronic equipment

Abstract

The invention discloses a self-adaptive node operation method and device, a storage medium and electronic equipment. The method comprises the following steps: determining a target consensus mechanism according to a load mode matched with a current node set; obtaining request description information of the current object request, and determining node operation information of at least one object node responding to the current object request under the target consensus mechanism according to the request description information; under the condition that the at least one object node successfully executes the node operation according to the respective corresponding node operation information, determining a target response result matched with the current object request according to an operation result of the at least one node operation, the target block used for indicating the target response result is added to the target block chain corresponding to the current node set. According to the method and the device, the technical problems of poor performance and low efficiency of a traditional block chain consensus mechanism in a high-concurrency scene in the prior art are solved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology. Specifically, it relates to an adaptive node operation method, apparatus, storage medium, and electronic device. Background Art

[0002] In recent years, blockchain technology has developed rapidly. Blockchain provides a decentralized, transparent, and secure trading environment. With the popularization of blockchain applications, the processing volume has increased sharply. Especially when there are large-scale events, listings, or market fluctuations, the processing peak is very high, posing challenges to the performance of the blockchain network.

[0003] Since the consensus mechanism is essentially serial processing, this leads to serious delays and throughput limitations in high-concurrency transaction scenarios; and reaching a consensus is a key step in ensuring transaction validity and data consistency in blockchain. In the PoW mechanism, the consensus time depends on the difficulty of finding the proof of work, which will in turn lead to a relatively long interval time for block generation; in the PoS mechanism, although the consensus time is relatively short, when the processing volume in the network suddenly increases, the interaction and voting processes between nodes may also slow down significantly, prolonging the transaction confirmation time. That is to say, the traditional blockchain consensus mechanism in the prior art faces the technical problems of poor performance and low efficiency in high-concurrency scenarios.

[0004] In response to the above problems, no effective solution has been proposed yet. Summary of the Invention

[0005] Embodiments of this application provide an adaptive node operation method, apparatus, storage medium, and electronic device to at least solve the technical problems of poor performance and low efficiency faced by the traditional blockchain consensus mechanism in high-concurrency scenarios in the prior art.

[0006] According to one aspect of the embodiments of this application, an adaptive node operation method is provided, including: determining a target consensus mechanism according to a load pattern matching the current node set, where the target consensus mechanism is used to instruct at least one object node in the current node set to perform at least one node operation; obtaining request description information of the current object request, and determining node operation information of at least one object node in response to the current object request under the target consensus mechanism according to the request description information, where the node operation information is used to instruct at least one node operation performed by the object node in response to the current object request; when at least one object node successfully performs node operations according to their respective corresponding node operation information, determining a target response result matching the current object request according to the operation results of at least one node operation, where the target block indicating the target response result will be added to the target blockchain corresponding to the current node set.

[0007] According to another aspect of the embodiments of the present application, an adaptive node operation device is further provided, including: a first determination unit, which determines a target consensus mechanism according to a load pattern matching the current node set, where the target consensus mechanism is used to instruct at least one object node in the current node set to perform at least one node operation; an acquisition unit, which acquires the request description information of the current object request and determines the node operation information of at least one object node in response to the current object request under the target consensus mechanism, where the node operation information is used to instruct at least one node operation performed by the object node in response to the current object request; a second determination unit, which, in the case where at least one object node successfully performs node operations according to their respective corresponding node operation information, determines a target response result matching the current object request according to the operation results of at least one node operation, where a target block indicating the target response result will be added to a target blockchain corresponding to the current node set.

[0008] Optionally, the above acquisition unit includes a detection unit, which is configured to, in the case where load fluctuation information matching the current node set detected within a target period satisfies a first switching condition, add at least one reference object node to the current node set and determine the node operation information respectively matching at least one reference object node, where the load fluctuation information is used to indicate the change trend of the number of operations of node operations assigned to at least one object node; and in the case where load fluctuation information matching the current node set detected within a target period satisfies a second switching condition, reduce at least one reference object node in the current node set.

[0009] Optionally, the above detection unit is further configured to acquire the number of operations of node operations assigned to at least one object node in the current node set; in the case where the number of operations is greater than a first quantity threshold, determine that the load fluctuation information matching the current node set satisfies the first switching condition; determine a first quantity of reference object nodes from at least one candidate object node according to the respective corresponding node types of at least one candidate node and the priority order corresponding to the node types; acquire the number of operations of node operations assigned to at least one object node in the current node set; in the case where the number of operations is less than a second quantity threshold, determine that the load fluctuation information matching the current node set satisfies the second switching condition; determine a second quantity of reference object nodes from at least one candidate object node according to the respective corresponding node types of at least one candidate node and the priority order corresponding to the node types.

[0010] Optionally, the first determining unit includes: a matching module, configured to obtain a set of object requests to be processed; respectively determine the load level corresponding to each of at least one object request according to the task attributes of at least one object request in the set of object requests; and determine a load pattern matching the current node set according to the load levels corresponding to each of the at least one object request.

[0011] Optionally, the first determining unit is further configured to, when the load pattern is a low load pattern, determine the target consensus mechanism as a fast verification mechanism, where the load level corresponding to the low load pattern is less than or equal to a first reference threshold, and the execution mode of node operations in the fast verification mechanism is sequential execution; when the load pattern is a medium load pattern, determine the target consensus mechanism as a partition consensus mechanism, where the load level corresponding to the medium load pattern is greater than the first reference threshold and less than or equal to a second reference threshold, and the partition consensus mechanism is to determine partition information matching the current object request, and the verification operations in each partition are executed in parallel, and the partition information is used to indicate the partition matching relationship between node operations and object nodes, and the first reference threshold is less than the second reference threshold; when the load pattern is a high load pattern, determine the target consensus mechanism as a node expansion mechanism, where the load level corresponding to the high load pattern is greater than the second reference threshold, and the node expansion mechanism is to expand new object nodes, determine the matching relationship between node operations and object nodes according to the priority order, and the verification operations in each partition are executed asynchronously.

[0012] Optionally, the first determining unit further includes a third determining module, configured to determine the operation priority corresponding to each of at least one node operation according to the request priority indicated by the request description information; and determine the target partition for executing the node operation according to the operation priorities corresponding to each of the at least one node operation and the node partition information, where the node partition information is used to indicate the available resource information in each partition, and the target partition is composed of different types of target object nodes.

[0013] Optionally, the first determining unit further includes: an adjustment module, configured to obtain the data state stored in the current blockchain, where the data state is used to indicate the stability degree of transactions; and modify the parameter rule when the data state meets the rule adjustment condition, where the parameter rule is used to determine the operation result of node operations.

[0014] According to another aspect of the embodiments of the present application, there is also provided a computer-readable storage medium, in which a computer program is stored, where the computer program is configured to execute the above-mentioned adaptive node operation method when running.

[0015] According to another aspect of the embodiments of the present application, an electronic device is further provided, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to execute the above-mentioned adaptive node operation method through the computer program.

[0016] In the embodiments of the present application, first, a target consensus mechanism is determined according to the load pattern matching the current node set, ensuring that requests are processed under a suitable consensus mechanism; the request description information of the current object request is obtained, and at least one node operation information of the object nodes in response to the current object request is determined according to the request description information under the target consensus mechanism, where the node operation information is used to indicate at least one node operation performed by the object nodes in response to the current object request. Designing node operations matching the object nodes according to the request description information under the target consensus mechanism improves the execution efficiency; further, when at least one object node successfully executes node operations according to their respective corresponding node operation information, a target response result matching the current object request is determined according to the operation results of at least one node operation, where a target block indicating the target response result will be added to the target blockchain corresponding to the current node set, thus completing the chain-up, thereby solving the technical problems of poor performance and low efficiency faced by traditional blockchain consensus mechanisms in high-concurrency scenarios in the prior art. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The schematic embodiments of the present application and their descriptions are used to explain the present application, and do not constitute an improper limitation of the present application. In the drawings:

[0018] Figure 1 is a schematic structural diagram of an optional distributed system applied to a blockchain system according to an embodiment of the present application;

[0019] Figure 2 is a schematic structural diagram of an optional block according to an embodiment of the present application;

[0020] Figure 3 is a flowchart of an optional adaptive node operation method according to an embodiment of the present application;

[0021] Figure 4 is a flowchart of another optional adaptive node operation method according to an embodiment of the present application;

[0022] Figure 5 is a schematic structural diagram of an optional adaptive node operation device according to an embodiment of the present application;

[0023] Figure 6 is a schematic structural diagram of an optional electronic device according to an embodiment of the present application. Detailed implementation manners

[0024] In order to enable those skilled in the art of the present technology to better understand the solution of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0025] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned accompanying drawings are used to distinguish similar objects, and do not necessarily need to be used to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device including a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0026] The system involved in the embodiments of the present invention may be a distributed system formed by connecting a client and multiple nodes (any form of computing device in the access network, such as a server, a user terminal) through network communication.

[0027] Taking the distributed system as a blockchain system as an example, see Figure 1 , Figure 1 is an optional structural schematic diagram of the distributed system 100 provided by the embodiments of the present invention applied to the blockchain system, formed by multiple nodes 200 (any form of computing device in the access network, such as a server, a user terminal) and a client 300, and a peer-to-peer network is formed between the nodes. In a distributed system, any machine such as a server or a terminal can join and become a node, and a node includes a hardware layer, an intermediate layer, an operating system layer, and an application layer.

[0028] See Figure 1 shows the functions of each node in the blockchain system. The functions involved include:

[0029] 1) Routing, a basic function of a node, used to support communication between nodes.

[0030] In addition to the routing function, a node may also have the following functions:

[0031] 2) An application, which is used to be deployed in a blockchain, implements specific business according to actual business requirements, records data related to the implemented functions to form recorded data, carries a digital signature in the recorded data to indicate the source of the task data, and sends the recorded data to other nodes in the blockchain system. When other nodes verify the source and integrity of the recorded data successfully, they add the recorded data to a temporary block.

[0032] For example, the businesses implemented by the application include:

[0033] 2.1) A wallet, which is used to provide the function of conducting electronic currency transactions, including initiating a transaction (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system. After other nodes verify successfully, as a response to acknowledging the validity of the transaction, they deposit the recorded data of the transaction into the temporary block of the blockchain. Of course, the wallet also supports querying the remaining electronic currency in the electronic currency address;

[0034] 2.2) A shared ledger, which is used to provide functions such as storing, querying, and modifying account data. It sends the recorded data of the operations on the account data to other nodes in the blockchain system. After other nodes verify its validity, as a response to acknowledging the validity of the account data, they deposit the recorded data into the temporary block and can also send a confirmation to the node that initiated the operation.

[0035] 2.3) A smart contract, which is a computerized protocol that can execute the terms of a certain contract. It is implemented through code deployed on the shared ledger and executed when certain conditions are met. According to actual business requirements, the code is used to complete automated transactions, such as querying the logistics status of the goods purchased by the buyer and transferring the buyer's electronic currency to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions but can also execute contracts for processing received information.

[0036] 3) A blockchain includes a series of blocks that are sequentially connected according to the chronological order of generation. Once a new block is added to the blockchain, it will not be removed again. The block records the recorded data submitted by nodes in the blockchain system.

[0037] See Figure 2 , Figure 2It is an optional schematic diagram of the block structure provided by the embodiments of the present invention. Each block includes the hash value of the transaction records stored in this block (the hash value of this block) and the hash value of the previous block. Each block is connected through the hash value to form a blockchain. In addition, the block may further include information such as the timestamp when the block is generated. A blockchain, in essence, is a decentralized database, a string of data blocks generated by using cryptographic methods. Each data block contains relevant information for verifying the validity of its information (anti-counterfeiting) and generating the next block.

[0038] Optionally, as an alternative implementation, as Figure 3 shown, the above-mentioned adaptive node operation method includes:

[0039] S302, determining a target consensus mechanism according to the load pattern matching the current node set, where the target consensus mechanism is used to instruct at least one object node in the current node set to perform at least one node operation;

[0040] S304, obtaining the request description information of the current object request, and determining the node operation information of at least one object node in response to the current object request under the target consensus mechanism according to the request description information, where the node operation information is used to instruct at least one node operation performed by the object node in response to the current object request;

[0041] S306, when at least one object node successfully performs node operations according to their respective corresponding node operation information, determining a target response result matching the current object request according to the operation results of at least one node operation, where the target block indicating the target response result will be added to the target blockchain corresponding to the current node set.

[0042] In step S302, a target consensus mechanism is determined according to the load pattern matching the current node set, where the target consensus mechanism is used to instruct at least one object node in the current node set to perform at least one node operation.

[0043] Optionally, the above-mentioned current node set can be a set of all nodes participating in the consensus process of the blockchain network, including verification nodes, master nodes, slave nodes and possible monitoring nodes. The composition and role of the node set can change with the changes in the network state and consensus mechanism; the above-mentioned load mode can be a low-load state, a high-load state, etc. determined according to the number, frequency, complexity of transaction requests and the usage of network resources (such as CPU, memory, network bandwidth); it should be noted that the object node is a node designated to perform a specific consensus task or transaction verification under the selected consensus mechanism. Node operations include but are not limited to transaction verification of game tasks, food supply chain management, block creation, participation in consensus voting, etc. Under different consensus mechanisms, node operations can be configured for different types of nodes according to system status, request importance, priority, etc.

[0044] Master nodes, slave nodes, and monitoring nodes can be independent nodes outside the blockchain. Master nodes and slave nodes are more involved in system-level scheduling, request distribution, and transaction queue management. Monitoring nodes focus on system health monitoring and performance optimization. Verification nodes are nodes that rely on the blockchain network and are responsible for transaction legitimacy verification, consensus process participation, transaction confirmation, etc.

[0045] Further in the above step S304, the request description information of the current object request is obtained, and the node operation information of at least one object node that responds to the current object request under the target consensus mechanism is determined based on the request description information, wherein the node operation information is used to indicate at least one node operation performed by the object node in response to the current object request.

[0046] The above steps are described in one implementation mode:

[0047] For example, the current object request is: in game A, the player initiates a redemption request in the "Honor Store", and the request description is that 500 tokens A are exchanged for 5,000 honor points; this transaction is dependent, and the account balance needs to be deducted first, and then the honor points are increased. The node operations of different types of node objects under the above target consensus mechanism are as follows:

[0048] S1, initial verification from the node: Check the transaction fields: Make sure the transaction contains information such as the sender account, the receiver account, the token type, the exchange amount, etc. Verify the account status: Verify whether the sender account balance is sufficient to deduct 500 tokens A. Signature verification: Confirm that the transaction signature matches the initiator's public key. If passed, the transaction is packaged and broadcast to the verification node.

[0049] S2, Verification of Node Depth: Check the redemption rules: Verify whether the redemption ratio of Token A meets the activity requirements (e.g., 1:10). Verify the dependent transactions: Confirm that the previously initiated balance deduction transaction has been successfully completed. Voting Consensus: Multiple verification nodes vote on the legitimacy of the transaction and generate a verification result after reaching a consensus.

[0050] S3, Master Node Confirmation and Broadcasting: The master node aggregates the verification results and confirms whether the transaction is valid. If the transaction is successful, update the blockchain state and broadcast the new block to the slave nodes.

[0051] S4, Slave Node Synchronization of State: The slave node receives the new block, updates the local account state, ensuring that the sender's balance is reduced by 500 Token A and 5000 honor points are increased.

[0052] As an alternative implementation, in step S306, when at least one object node successfully executes the node operation according to its respective corresponding node operation information, determine the target response result that matches the current object request based on the operation results of at least one node operation, where the target block indicating the target response result will be added to the target blockchain corresponding to the current node set. For example, the above object node is a verification node, the corresponding node operation is to verify the operation legitimacy, and the node operation information is transaction details, transaction operation executable criteria, etc., which is only an example here.

[0053] Specifically, taking the flowchart Figure 4 to illustrate the process of the above object node executing the node operation according to its respective corresponding node operation information:

[0054] The slave node executes S402, Transaction Receiving and Preliminary Verification; specifically, after the user initiates a transaction request, the slave node receives the request and performs basic verification. If the verification passes, the transaction is packaged and broadcast to the verification node for in-depth verification.

[0055] The verification node executes S404, In-depth Verification and Consensus Voting; specifically, the verification node receives the transaction package broadcast by the slave node and performs complex rule checks and consistency verification. After the verification is completed, the verification node returns the consensus result to the slave node.

[0056] The master node and the slave node execute S406, Final Confirmation and Storage; specifically, the master node is responsible for finally confirming the transaction result (i.e., the above target response result) and generating a block. The slave node synchronously updates the blockchain state to complete the transaction storage.

[0057] Through the above embodiments of the present application, first, a target consensus mechanism is determined according to the load pattern matching the current node set, ensuring that requests are processed under an appropriate consensus mechanism; the request description information of the current object request is obtained, and according to the request description information, the node operation information of at least one object node in response to the current object request under the target consensus mechanism is determined, where the node operation information is used to indicate at least one node operation to be performed by the object node in response to the current object request. Designing node operations matching the object node according to the request description information under the target consensus mechanism improves the execution efficiency; furthermore, when at least one object node successfully executes node operations according to their respective corresponding node operation information, the target response result matching the current object request is determined according to the operation results of at least one node operation. The target block indicating the target response result will be added to the target blockchain corresponding to the current node set, thereby completing the chain-up, thus solving the technical problems of poor performance and low efficiency faced by traditional blockchain consensus mechanisms in high-concurrency scenarios in the prior art.

[0058] In an alternative embodiment, after obtaining the request description information of the current object request and determining the node operation information of at least one object node in response to the current object request under the target consensus mechanism, it includes:

[0059] S1. When it is detected that the load fluctuation information matching the current node set satisfies the first switching condition within the target period, at least one reference object node is added to the current node set, and the node operation information respectively matching at least one reference object node is determined, where the load fluctuation information is used to indicate the change trend of the number of operations of the node operations assigned to at least one object node;

[0060] S2. When it is detected that the load fluctuation information matching the current node set satisfies the second switching condition within the target period, at least one reference object node is reduced from the current node set.

[0061] In the above step S1, the load fluctuation information may be, for example, the fluctuation degree of the number of request tasks to be processed by the current system, the change of key indicators such as the transaction request volume, resource usage (such as CPU, memory, network bandwidth), transaction latency, and node health status in the system. The first switching condition includes, but is not limited to, the transaction request volume exceeding a preset high threshold, the node resource utilization rate reaching or exceeding a certain level, the transaction latency exceeding the acceptable range, etc.

[0062] Optionally, when the verification queue length or the concurrent transactions exceed the threshold, the reference object node can be determined as a verification node, and then the verification node is added to execute the verification task, reducing the pressure on the original node to process the verification task.

[0063] In the above step S2, for example, during the evening period, the system detects that the transaction request volume has significantly decreased, the node resource utilization rate has dropped below 30%, which is lower than the set resource usage threshold, and the current network is in a low-load state, meeting the second switching condition; the system selects 3 verification nodes with low resource utilization rates from the current node set. For the selected verification nodes, the system transfers the ongoing transaction verification tasks to other verification nodes with high resource utilization rates. After ensuring that all critical tasks are transferred or offloaded, the system officially removes the selected reference object nodes from the node set, optimizing the network structure.

[0064] Through the above implementation, the number of nodes is dynamically adjusted according to the load fluctuation, avoiding resource waste during low load, and at the same time being able to quickly increase the processing capacity during high load, maintaining the efficient and stable operation of the network. With the addition of these reference object nodes and task allocation, the transaction processing capacity of the platform will be significantly improved, helping to alleviate the high-load state, ensuring the timely processing of transactions and the stable operation of the system, and guaranteeing the processing performance and efficiency.

[0065] In an alternative implementation, when it is detected that the load fluctuation information matching the current node set meets the first switching condition within the target period, at least one reference object node is added to the current node set, including:

[0066] S1, obtain the number of operations of node operations assigned to at least one object node in the current node set;

[0067] S2, when the number of operations is greater than the first quantity threshold, determine that the load fluctuation information matching the current node set meets the first switching condition;

[0068] S3, determine the first quantity of reference object nodes from at least one candidate object node according to the respective node types of at least one candidate node and the priority order corresponding to the node types;

[0069] In the above steps S1 - S2, obtain the number of operations of node operations assigned to at least one object node in the current node set; when the number of operations is greater than the first quantity threshold, determine that the load fluctuation information matching the current node set meets the first switching condition.

[0070] As an alternative implementation, taking the example that the number of verification operations assigned to the verification nodes exceeds the threshold, that is, when the verification queue length or concurrent transactions exceed the above first quantity threshold, it is determined that the load fluctuation information matching the current node set meets the first switching condition, and it is necessary to add verification nodes to cope with the deep verification pressure;

[0071] In the above step S3, according to the node types corresponding to at least one candidate node and the priority order corresponding to the node types, a first quantity of reference object nodes is determined from at least one candidate object node.

[0072] Specifically, the node types of the above candidate nodes include verification nodes, slave nodes, monitoring nodes, etc. The expansion rules can be that verification nodes are preferentially expanded: when the verification queue length or concurrent transactions exceed the threshold, verification nodes are preferentially added to cope with the deep verification pressure. Slave nodes are secondarily expanded: when the throughput of request reception exceeds the threshold, slave nodes are expanded to balance user requests. Monitoring nodes are expanded: in high-load scenarios, monitoring nodes are added to collect system data more precisely. The master node remains constant: the master node is generally not expanded and maintains a single coordination role.

[0073] In the case where load fluctuation information matching the current node set is detected to satisfy the second switching condition within the target period, at least one reference object node is reduced in the current node set, including:

[0074] S1, obtaining the number of operations of node operations assigned to at least one object node in the current node set;

[0075] S2, when the number of operations is less than the second quantity threshold, determining that the load fluctuation information matching the current node set satisfies the second switching condition;

[0076] S3, according to the node types corresponding to at least one candidate node and the priority order corresponding to the node types, a second quantity of reference object nodes is determined from at least one candidate object node.

[0077] In the above steps S1 - S2, the number of operations of node operations assigned to at least one object node in the current node set is obtained; when the number of operations is less than the second quantity threshold, it is determined that the load fluctuation information matching the current node set satisfies the second switching condition.

[0078] As an optional implementation manner, when the number of operations assigned to the slave nodes is lower than a certain threshold, that is, when the request volume is lower than the above second quantity threshold, it is determined that the load fluctuation information matching the current node set satisfies the second switching condition, and the second quantity of slave nodes can be released;

[0079] In the above step S3, according to the node types corresponding to at least one candidate node and the priority order corresponding to the node types, a second quantity of reference object nodes is determined from at least one candidate object node.

[0080] Specifically, preferentially release verification nodes: according to the usage time and load data, release verification nodes with a longer usage time or low resource utilization. Secondarily release slave nodes: after the request volume decreases, gradually reduce the slave nodes, and retain the necessary number to ensure the basic throughput. Moderately shrink monitoring nodes: after the load decreases, reduce the collection frequency or quantity of monitoring nodes. Keep the master node constant: the master node does not shrink and continuously serves as the core coordination role of the system.

[0081] Through the above implementation manners of the present application, when the load of the system changes, the number of master nodes, slave nodes, verification nodes, and monitoring nodes is dynamically adjusted, achieving the technical effect of adapting to real-time load requirements and optimizing resource allocation, and solving the technical problems of low processing efficiency and poor performance caused by using a fixed node configuration under a fixed consensus mechanism in the prior art.

[0082] In an optional implementation manner, before determining the target consensus mechanism according to the load pattern matching the current node set, it includes:

[0083] S1. Obtain the set of object requests to be processed;

[0084] S2. According to the task attributes of at least one object request in the set of object requests, respectively determine the load degree corresponding to each of the at least one object request;

[0085] S3. Determine the load pattern matching the current node set according to the load degree corresponding to each of the at least one object request.

[0086] In the above steps S1 - S2, the set of object requests may be the set of task processes received by the current system within a period of time. The object requests matching the tasks have the above task attributes. Taking the transaction scenario as an example, they may be relevant indicators such as transaction amount, transaction frequency, transaction type, timeliness requirements, and transaction dependency; the load degree matching the object requests can be determined according to the above task attributes.

[0087] As an optional implementation manner, the above load degree can be determined by the following formula:

[0088] Load score (loadScore) = w1 * Transaction amount score (TransactionAmountScore) + w2 * Transaction frequency (TransactionFrequencyScore) + w3 * Transaction type (TransactionTypeScore) + w4 * Transaction timeliness (UrgencyScore) + w5 * Transaction dependency (TransactionDependencyScore); where w1, w2, w3, w4, w5 are weight coefficients, and w1 + w2 + w3 + w4 + w5 = 1 (the sum of the weight coefficients is 1).

[0089] The transaction amount reflects the degree of demand for system resources by the transaction. A transaction with a high amount requires more computing and verification resources. TransactionAmountScore = Amount / MaxAmount; where Amount is the amount of the current transaction and Max Amount is the maximum transaction amount allowed in the system.

[0090] The transaction frequency refers to the number of transactions initiated within a unit of time. Frequent transactions increase the system load. TransactionFrequencyScore = Transaction Count in Time Interval / Max TransactionCount in Time Interval; where Transaction Count in Time Interval is the number of transactions within the time interval and Max Transaction Count in Time Interval is the maximum number of transactions allowed in the system.

[0091] The transaction type reflects the complexity of the transaction. Certain types of transactions may require more verification steps and computing resources. TransactionTypeScore = 1 (complex transaction) TransactionTypeScore = 0.5 (medium - complex transaction) TransactionTypeScore = 0 (simple transaction); where complex transactions (such as token exchanges) receive a higher score and simple transactions (such as voting) receive a lower score.

[0092] A high load reduces the transaction timeliness, while low timeliness requirements can tolerate a higher system load. That is, transactions with high timeliness requirements have a greater impact on the system load.

[0093] The transaction dependency measures whether a transaction needs to wait for other transactions to complete before it can proceed. Highly dependent transactions require more processing time and computing resources. DependencyScore = 1 (highly dependent transaction) DependencyScore = 0.5 (medium - dependent transaction) DependencyScore = 0 (independent transaction).

[0094] Furthermore, in step S3 above, determine the load pattern matching the current node set according to the load degree corresponding to at least one object request. Specifically, the load pattern matching the current node set can be determined according to the calculated load score, which can be judged based on a certain key request or the average value of the load scores of the request set.

[0095] In an alternative embodiment, determining a target consensus mechanism according to a load pattern matching a current node set includes:

[0096] S1. When the load pattern is a low load pattern, determining the target consensus mechanism as a fast verification mechanism, where the load level corresponding to the low load pattern is less than or equal to a first reference threshold, and the execution mode of node operations in the fast verification mechanism is sequential execution;

[0097] S2. When the load pattern is a medium load pattern, determining the target consensus mechanism as a partition consensus mechanism, where the load level corresponding to the medium load pattern is greater than the first reference threshold and less than or equal to a second reference threshold, the partition consensus mechanism is to determine partition information matching a current object request, verification operations in each partition are executed in parallel, and the partition information is used to indicate the partition matching relationship between node operations and object nodes, and the first reference threshold is less than the second reference threshold;

[0098] S3. When the load pattern is a high load pattern, determining the target consensus mechanism as a node expansion mechanism, where the load level corresponding to the high load pattern is greater than the second reference threshold, the node expansion mechanism is to expand new object nodes, determine the matching relationship between node operations and object nodes according to the priority order, and verification operations in each partition are executed asynchronously.

[0099] In the above step S1, when the load pattern is a low load pattern, determining the target consensus mechanism as a fast verification mechanism, where the load level corresponding to the low load pattern is less than or equal to a first reference threshold, and the execution mode of node operations in the fast verification mechanism is sequential execution.

[0100] Optionally, for the low load pattern (Load Score ≤ 0.3), the applicable scenario is that the system load is low and all transaction requests can be easily processed. The processing method is that all transaction requests are processed sequentially or simply in parallel, and the primary node and verification nodes can process them together.

[0101] Illustrate the above process with a specific embodiment: The transaction requests are that user A requests to exchange 100 points A for 1000 platform credit values, and user B requests to exchange 50 points A for 500 platform credit values.

[0102] S1. User A and User B initiate an integral redemption request on the platform. S2. Evaluate the system load and determine it is in the low-load mode, with the target consensus mechanism being the PoS consensus mechanism (Proof of Stake). At this time, the verification process is carried out through the selected verification nodes. S3. Transaction flow: The master node receives the transaction request, checks the system load and selects the PoS mode. The transaction request is directly assigned to the appropriate verification node for processing. S4. The verification node conducts transaction verification. The verification includes: checking the account balance, calculating the redemption ratio, and confirming the legitimacy of the transaction. S5. Consensus and block generation: After the master node confirms that all verification nodes have reached an agreement, it broadcasts the transaction and generates a block. The block is approved through the PoS mechanism and finally confirmed by the master node. The final block information is synchronized to the blockchain, the transaction data (such as user ID, integral quantity, timestamp) is stored, and the transaction is successful. The user account information is updated, and User A and User B respectively receive the corresponding credit values.

[0103] In step S2 above, when the load mode is the medium-load mode, the target consensus mechanism is determined to be the partition consensus mechanism, where the load level corresponding to the medium-load mode is greater than the first reference threshold and less than or equal to the second reference threshold. The partition consensus mechanism is to determine the partition information matching the current object request, and the verification operations in each partition are executed in parallel. The partition information is used to indicate the matching relationship between the node operations and the partitions of the object nodes, and the first reference threshold is less than the second reference threshold.

[0104] Optionally, for the medium-load mode (0.3 < Load Score ≤ 0.7): The applicable scenario is that the system load increases and load balancing processing is required. The processing method is that the system will use the partition consensus mechanism to distribute the transaction requests to different partitions and jointly process them by the slave nodes and the verification nodes.

[0105] Illustrate the above process in a specific implementation manner: The transaction requests are that User A requests to redeem 100 Integral A for 1000 platform credit values, and User B requests to redeem 150 Integral A for 1500 platform credit values.

[0106] S1. User A and User B initiate an integral redemption request. S2. The current load is medium, and the system can no longer process all requests through a single node only. The master node decides to use the partition consensus mode to disperse the load. S3. The master node distributes the requests to different partitions according to the content of the requests (for example, User A's request is distributed to Partition 1, and User B's request is distributed to Partition 2). S3. Transaction flow: The master node is responsible for determining which transactions are assigned to which partitions and adjusting the configuration of the partition consensus mechanism. The slave nodes independently process transaction requests within the partitions, including balance checks, redemption ratio calculations, etc. S4. The verification nodes verify the transaction requests in parallel within each partition to ensure the legality of the transactions. Once the verification nodes in each partition reach an agreement, the transaction data will be submitted to the blockchain. S5. The master node aggregates the blocks of all partitions and coordinates the consistency of the whole network. The block information is broadcast throughout the network by the master node to ensure that all nodes agree and synchronize the blocks. Finally, the redemption transaction information of User A and User B is stored in the blockchain, and the transaction is successful.

[0107] It should be noted that the specific way of partition processing by the slave nodes can be to partition the requests according to the transaction type (such as integral redemption, integral consumption, etc.) or user area (such as by geographical location or service area); different requests can be automatically distributed to different slave nodes through a load balancer to ensure that the load of each slave node remains within a reasonable range;

[0108] The specific way of partition processing by the verification nodes can be divided by transaction type: partition the tasks of the verification nodes according to the types of transactions. For example, different transaction types such as transfers and integral redemptions are assigned to different groups of verification nodes; user partition: if the transaction request is related to a specific user, it can be partitioned according to the user's geographical location or account type; transaction dependency division: when processing highly dependent transactions, these more dependent transaction requests can be assigned to verification nodes with higher computing power and other methods to ensure the accuracy and speed of transaction verification.

[0109] The monitoring nodes can perform partition monitoring on the system status according to the region or service partition. For example, the slave nodes and verification nodes in different regions can be monitored in partitions, or the monitoring nodes can be divided according to different services (such as token transactions, integral redemptions, payments, etc.). The monitoring nodes can be divided according to the node type to conduct specialized monitoring and log analysis on different groups of nodes.

[0110] The master node can perform partition scheduling on the tasks according to the priority of the tasks and the current load situation to ensure that the tasks in different partitions can be evenly distributed to each slave node and verification node. The master node can also dynamically adjust the consensus mechanism according to the load situation, such as switching from PoW to PoS or adjusting the weights of the verification nodes under the PoA mechanism, to ensure that the system can operate efficiently under high load.

[0111] In step S3 above, when the load mode is the high-load mode, the target consensus mechanism is determined as the node expansion mechanism, where the load level corresponding to the high-load mode is greater than the second reference threshold. The node expansion mechanism is to expand and add object nodes, determine the matching relationship between node operations and object nodes according to the priority order, and the verification operations in each partition are executed asynchronously.

[0112] High-load mode (Load Score > 0.7); the applicable scenario is that the system load is very high and dynamic allocation of computing resources is required. The processing method is that high-load transactions are preferentially allocated to low-load partitions, and it may be necessary to expand the number of verification nodes. At the same time, monitoring nodes are enabled to adjust the strategy in real time.

[0113] A specific implementation manner is used to illustrate the above process: the transaction requests are that user A requests to exchange 200 points A for 2,000 platform credit values, and user B requests to exchange 300 points A for 3,000 platform credit values, and the request volume surges.

[0114] S1. User A and user B initiate point exchange requests. S2. The load evaluation module detects that the system load is too high and the number of transaction requests increases, and enables the dynamic partition consensus mode and the asynchronous verification mechanism. The master node decides to allocate the transaction requests according to importance and priority based on the load evaluation, allocating more important requests to faster partitions, and other low-priority requests to partitions with tighter resources. The slave nodes and verification nodes process the transactions independently and in parallel within each partition. S3. Due to the adoption of asynchronous verification and dynamic partitioning, the transaction requests are processed in parallel on multiple partitions and multiple verification nodes. The verification and execution of transactions are no longer synchronized but are distributed asynchronous verification, reducing the burden on a single node. S4. The verification nodes verify the legality of the transactions in each partition, such as checking the account balance, exchange ratio, exchange order, etc. The asynchronous verification mechanism ensures that the verification operations in each partition can be executed in parallel, reducing the verification pressure on a single node. S5. After processing the transactions, the slave nodes and verification nodes in each partition generate local blocks and feedback them to the master node. The master node is responsible for summarizing the blocks generated by each partition, coordinating and ensuring that the blocks reach consensus within the entire network. The master node broadcasts and synchronizes all partition blocks to ensure network-wide consistency. The transactions of user A and user B are stored in the blockchain, and the user accounts are updated.

[0115] In addition, in this solution, when the load changes rapidly, the historical trend and prediction algorithm are combined to dynamically adjust the node configuration. The node group is expanded or contracted in units of partitions to avoid system oscillations caused by frequent switching. For example, in the initial state (low-load mode): 1 master node, 4 slave nodes, 2 verification nodes, and 2 monitoring nodes. The average number of transactions per second (TPS) is 100, and the concurrent requests are 200. The length of the verification queue is about 10, and the resource utilization rate is 30%. When the load increases (medium-load mode): The transaction volume increases rapidly, the TPS reaches 600, and the concurrent requests are 1200. The length of the verification queue increases to 100, and the resource utilization rate exceeds 70%. Dynamic expansion: The verification nodes increase from 2 to 5, and the slave nodes increase from 4 to 6. Keep 3 monitoring nodes to improve the acquisition accuracy. During the peak period (high-load mode): The TPS reaches 1500, and the concurrent requests reach 3000. The length of the verification queue exceeds 300, and some transactions are delayed by more than 2 seconds. Dynamic expansion: The verification nodes increase to 10 for parallel processing in partitions. The slave nodes increase to 8 to handle high throughput. The monitoring nodes increase to 4 to monitor the status of each node in real time. When the load decreases (back to the low-load mode): The TPS drops back to 100, and the concurrent requests drop to 200. Dynamic contraction: The verification nodes decrease to 2, the slave nodes decrease to 4, and the monitoring nodes decrease to 2.

[0116] Through the above-described implementation manners recorded in this application, when the system load changes, the load evaluation module triggers the adaptive consensus module to perform a switch, ensuring that transactions are processed under an appropriate consensus mechanism, and ensuring the verification and processing efficiency of the execution node operations for processing object requests.

[0117] In an optional implementation manner, after determining the target consensus mechanism according to the load mode matching the current node set, it includes:

[0118] S1, determining the operation priority corresponding to each of at least one node operation according to the request priority indicated by the request description information;

[0119] S2, determining the target partition for executing the node operation according to the operation priority corresponding to each of at least one node operation and the node partition information, where the node partition information is used to indicate the available resource information in each partition, and the target partition is composed of different types of target object nodes.

[0120] The above steps S1 - S2 are described in a specific implementation manner. For example, there is a partition A, and the corresponding node partition information for the above is 4 slave nodes, and the resource utilization rate of each slave node is 30% (the remaining resources are sufficient to execute high - load node operations, and the types of node operations that can be executed can be account creation and account information query), 2 verification nodes, and 1 monitoring node; partition B corresponds to node partition information of 2 slave nodes, and the resource utilization rate of each slave node is 80% (the remaining resources are insufficient to execute low - load node operations, and the type of node operation that can be executed can be gift redemption), 5 verification nodes, and 2 monitoring nodes; for example, if the request description information indicates that the operation priority of account creation is higher than that of gift redemption, the target partition can be determined as partition A; or when the resource demand of the request is low, partition B is preferentially selected as the target partition, and then the object nodes corresponding to the target partition execute the node operations.

[0121] Through the above implementation manner, the system determines the priority according to the request description information, including amount, type, initiator reputation, etc. Then, the node operations with high priority are assigned to partitions with more sufficient resources and faster processing speeds to ensure that these critical operations can be completed quickly; while the node operations with low priority are assigned to partitions where resources may be relatively tight to avoid occupying too many critical resources; after determining the target partition, the system sends the node operation request to the nodes within this partition for processing.

[0122] In an optional implementation manner, after determining the target consensus mechanism according to the load pattern matching the current node set, it further includes:

[0123] S1, obtain the data status stored in the current blockchain, where the data status is used to indicate the stability degree of transactions;

[0124] S2, modify the parameter rules when the data status meets the rule adjustment conditions, where the parameter rules are used to determine the operation results of node operations.

[0125] As an optional implementation manner, for example, when it is determined that the data status is poor and the transactions are unstable due to a sharp increase in the redemption frequency of a large number of users in a certain area, the above data status meeting the rule adjustment conditions can be, for example, that the issuance of activity points is close to the budget ceiling; modifying the parameter rules can be adjusting the redemption ratio, the user credit value standard for performing redemption operations, the redemption limit, etc., thereby affecting the load pattern, dynamically evaluating the load pattern, re - selecting the target consensus mechanism, and matching node operations for the nodes to improve the processing efficiency. And the master node can dynamically adjust the consensus mechanism according to the load situation, such as switching from PoW to PoS, or adjusting the weights of verification nodes under the PoA mechanism, to ensure that the system can operate efficiently under high load.

[0126] It should be noted that, for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that this application is not limited by the described action sequence, because according to this application, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0127] According to another aspect of the embodiments of the present application, there is also provided an adaptive node operation device for implementing the above-mentioned adaptive node operation method. As Figure 5 shown, the device includes:

[0128] A first determination unit 502 determines a target consensus mechanism according to a load pattern matching the current node set, where the target consensus mechanism is used to instruct at least one object node in the current node set to perform at least one node operation;

[0129] An acquisition unit 504 acquires request description information of the current object request, and determines node operation information of at least one object node in response to the current object request according to the request description information, where the node operation information is used to instruct at least one node operation performed by the object node in response to the current object request;

[0130] A second determination unit 506 determines a target response result matching the current object request according to the operation results of at least one node operation in the case where at least one object node successfully performs node operations according to their respective corresponding node operation information, where a target block indicating the target response result will be added to a target blockchain corresponding to the current node set.

[0131] Optionally, the above-mentioned acquisition unit 504 includes a detection unit, which is used to add at least one reference object node to the current node set and determine node operation information respectively matching the at least one reference object node in the case where load fluctuation information matching the current node set detected within a target period meets a first switching condition, where the load fluctuation information is used to indicate a change trend of the number of operations of node operations assigned to at least one object node; in the case where load fluctuation information matching the current node set detected within a target period meets a second switching condition, at least one reference object node is reduced in the current node set.

[0132] Optionally, the above detection unit is further configured to obtain the number of operations of node operations assigned to at least one object node in the current node set; determine that the load fluctuation information matching the current node set meets the first switching condition when the number of operations is greater than the first quantity threshold; determine, according to the node types corresponding to at least one candidate node and the priority order corresponding to the node types, a first quantity of reference object nodes from at least one candidate object node; obtain the number of operations of node operations assigned to at least one object node in the current node set; determine that the load fluctuation information matching the current node set meets the second switching condition when the number of operations is less than the second quantity threshold; determine, according to the node types corresponding to at least one candidate node and the priority order corresponding to the node types, a second quantity of reference object nodes from at least one candidate object node.

[0133] Optionally, the above first determination unit 502 includes: a matching module, configured to obtain a set of object requests to be processed; respectively determine the load level corresponding to at least one object request according to the task attributes of at least one object request in the set of object requests; and determine the load pattern matching the current node set according to the load levels corresponding to at least one object request.

[0134] Optionally, the above first determination unit 502 is further configured to, when the load pattern is a low load pattern, determine the target consensus mechanism as a fast verification mechanism, where the load level corresponding to the low load pattern is less than or equal to a first reference threshold, and the execution mode of node operations in the fast verification mechanism is sequential execution; when the load pattern is a medium load pattern, determine the target consensus mechanism as a partition consensus mechanism, where the load level corresponding to the medium load pattern is greater than the first reference threshold and less than or equal to a second reference threshold, the partition consensus mechanism is to determine partition information matching the current object request, and the verification operations in each partition are executed in parallel, and the partition information is used to indicate the partition matching relationship between node operations and object nodes, and the first reference threshold is less than the second reference threshold; when the load pattern is a high load pattern, determine the target consensus mechanism as a node expansion mechanism, where the load level corresponding to the high load pattern is greater than the second reference threshold, the node expansion mechanism is to expand new object nodes, determine the matching relationship between node operations and object nodes according to the priority order, and the verification operations in each partition are executed asynchronously.

[0135] Optionally, the first determination unit 502 further includes a third determination module, configured to determine the operation priority corresponding to each of at least one node operation according to the request priority indicated by the request description information; and determine the target partition for executing the node operation according to the operation priority corresponding to each of at least one node operation and the node partition information, where the node partition information is used to indicate the available resource information in each partition, and the target partition is composed of target object nodes of different types.

[0136] Optionally, the first determination unit 502 further includes: an adjustment module, configured to obtain the data status stored in the current blockchain, where the data status is used to indicate the stability degree of transactions; and modify the parameter rule when the data status meets the rule adjustment condition, where the parameter rule is used to determine the operation result of the node operation.

[0137] According to another aspect of the embodiments of the present application, there is also provided a computer-readable storage medium, in which a computer program is stored, where the computer program is configured to execute the above-mentioned adaptive node operation method when running.

[0138] According to another aspect of the embodiments of the present application, there is also provided an electronic device for implementing the above-mentioned adaptive node operation method. In this embodiment, the electronic device is taken as a mobile phone or a computer as an example. As Figure 6 shown, the electronic device includes a memory 602 and a processor 604. A computer program is stored in the memory 602, and the processor 604 is configured to execute the steps in any one of the above method embodiments through the computer program.

[0139] Optionally, in this embodiment, the above-mentioned electronic device may be at least one network device among multiple network devices in a computer network.

[0140] Optionally, in this embodiment, the above-mentioned processor may be configured to execute the following steps through a computer program:

[0141] S1, determine a target consensus mechanism according to a load pattern matching the current node set, where the target consensus mechanism is used to instruct at least one object node in the current node set to execute at least one node operation;

[0142] S2, obtain the request description information of the current object request, and determine the node operation information of at least one object node in response to the current object request under the target consensus mechanism according to the request description information, where the node operation information is used to instruct at least one node operation executed by the object node in response to the current object request;

[0143] S3. When at least one object node successfully performs a node operation according to the respective corresponding node operation information, determine a target response result matching the current object request according to the operation results of at least one node operation. Among them, a target block used to indicate the target response result will be added to the target blockchain corresponding to the current node set.

[0144] Optionally, those of ordinary skill in the art can understand that Figure 6 The structure shown is only schematic. The electronic device can also be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a palm computer, and terminal devices such as Mobile Internet Devices (MID), PAD, etc. Figure 6 It does not limit the structure of the above-mentioned electronic device. For example, the electronic device may further include more or fewer components (such as a network interface, etc.) than those shown in Figure 6 or have a different configuration from that shown in Figure 6 shown.

[0145] Among them, the memory 602 can be used to store software programs and modules, such as the program instructions / modules corresponding to the adaptive node operation method and device in the embodiments of the present application. The processor 604 executes various functional applications and data processing by running the software programs and modules stored in the memory 602, that is, realizes the above-mentioned adaptive node operation. The memory 602 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some instances, the memory 602 may further include a memory remotely provided relative to the processor 604, and these remote memories can be connected to the terminal through a network. Examples of the above network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof. As an example, as Figure 6 shown, the above-mentioned memory 602 may but is not limited to include the first determination unit 502, the acquisition unit 504, and the second determination unit 506 in the above-mentioned adaptive node operation device. In addition, it may also include but is not limited to other module units in the above-mentioned adaptive node operation device, which will not be elaborated in this example.

[0146] Optionally, the above-mentioned transmission device 606 is used to receive or send data via a network. Specific examples of the above-mentioned network may include a wired network and a wireless network. In one example, the transmission device 606 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices and routers through a network cable, so as to communicate with the Internet or a local area network. In one example, the transmission device 606 is a Radio Frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0147] In addition, the above-mentioned electronic device further includes: a display 608 and a connection bus 610, which are used to connect various module components in the above-mentioned electronic device.

[0148] In other embodiments, the above-mentioned terminal device or server can be a node in a distributed system. Among them, the distributed system can be a blockchain system, and the blockchain system can be a distributed system formed by connecting the multiple nodes in the form of network communication. Among them, the nodes can form a point-to-point network, and any form of computing device, such as electronic devices such as servers and terminals, can become a node in the blockchain system by joining the point-to-point network.

[0149] According to one aspect of the present application, a computer-readable storage medium is provided. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the methods provided in the above various optional implementation manners;

[0150] Optionally, in this embodiment, the above-mentioned computer-readable storage medium can be set to store a computer program for executing the following steps:

[0151] S1, determining a target consensus mechanism according to a load pattern matching the current node set, where the target consensus mechanism is used to instruct at least one object node in the current node set to execute at least one node operation;

[0152] S2, obtaining request description information of the current object request, and determining node operation information of at least one object node in response to the current object request under the target consensus mechanism according to the request description information, where the node operation information is used to instruct at least one node operation executed by the object node in response to the current object request;

[0153] S3. When at least one object node successfully executes a node operation according to the respective corresponding node operation information, determine a target response result that matches the current object request according to the operation results of at least one node operation. Among them, a target block used to indicate the target response result will be added to the target blockchain corresponding to the current node set.

[0154] Optionally, in the embodiments of the present application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works together with other related parts to achieve a predetermined goal, and can be fully or partially implemented by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an overall module or unit that includes the functions of that module or unit.

[0155] Optionally, in this embodiment, those of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by a program instructing the relevant hardware of the terminal device. The program can be stored in a computer-readable storage medium, and the storage medium can include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disc, etc.

[0156] If the integrated unit in the above embodiments is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in the above computer-readable storage medium. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. The computer software product is stored in the storage medium and includes several instructions for causing one or more computer devices (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0157] In the above embodiments of the present application, the descriptions of the various embodiments have their own emphases. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0158] In several embodiments provided by the present application, it should be understood that the disclosed client can be implemented in other ways. Among them, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection to each other can be through some interfaces. The indirect coupling or communication connection of units or modules can be in an electrical or other form.

[0159] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0160] In addition, in each embodiment of the present application, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0161] The above is only the preferred embodiment of the present application. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present application, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present application.

Claims

1. An adaptive node operation method, characterized in that: include: Determining a target consensus mechanism according to a load pattern matching the current node set, wherein the target consensus mechanism is used to instruct at least one object node in the current node set to perform at least one node operation; Obtaining request description information of the current object request, and determining node operation information of at least one object node that responds to the current object request under the target consensus mechanism according to the request description information, wherein the node operation information is used to indicate at least one node operation performed by the object node in response to the current object request; In a case where at least one of the object nodes successfully performs the node operation according to the respective corresponding node operation information, a target response result matching the current object request is determined according to the operation result of the at least one node operation, wherein a target block indicating the target response result will be added to the target blockchain corresponding to the current node set.

2. The method according to claim 1, characterized in that After obtaining the request description information of the current object request and determining the node operation information of at least one object node that responds to the current object request under the target consensus mechanism according to the request description information, the method further comprises: When it is detected within a target period that the load fluctuation information matching the current node set satisfies the first switching condition, at least one reference object node is added to the current node set, and the node operation information matching each of the at least one reference object node is determined, wherein the load fluctuation information is used to indicate a change trend of the number of node operations allocated to at least one of the object nodes; When it is detected within the target period that the load fluctuation information matching the current node set satisfies a second switching condition, at least one of the reference object nodes is reduced in the current node set.

3. The method according to claim 2, characterized in that When it is detected within the target period that the load fluctuation information matching the current node set satisfies the first switching condition, adding at least one reference object node to the current node set comprises: Obtaining the number of operations of the node operation allocated to at least one of the object nodes in the current node set; In a case where the number of operations is greater than a first number threshold, determining that the load fluctuation information matching the current node set satisfies the first switching condition; Determine a first number of the reference object nodes from at least one candidate object node according to a node type corresponding to each of the at least one candidate nodes and a priority order corresponding to the node type; When it is detected within the target period that the load fluctuation information matching the current node set satisfies the second switching condition, reducing at least one of the reference object nodes in the current node set comprises: Obtaining the number of operations of the node operation allocated to at least one of the object nodes in the current node set; In a case where the number of operations is less than a second number threshold, determining that the load fluctuation information matching the current node set satisfies the second switching condition; A second number of the reference object nodes are determined from at least one candidate object node according to a node type corresponding to each of the at least one candidate node and a priority order corresponding to the node type.

4. The method according to claim 2, characterized in that: Before determining the target consensus mechanism according to the load pattern matching the current node set, it includes: Get the collection of pending object requests; Determining, according to a task attribute of at least one object request in the object request set, a load degree corresponding to each of the at least one object request; The load pattern matching the current node set is determined according to the load degree corresponding to each of at least one of the object requests.

5. The method according to claim 4, characterized in that Determining the target consensus mechanism according to the load pattern matching the current node set includes: In the case where the load mode is a low load mode, the target consensus mechanism is determined to be a fast verification mechanism, wherein the load level corresponding to the low load mode is less than or equal to a first reference threshold, and the execution mode of the node operation in the fast verification mechanism is sequential execution; In the case where the load mode is a medium load mode, the target consensus mechanism is determined to be a partition consensus mechanism, wherein the load level corresponding to the medium load mode is greater than the first reference threshold, and the load level is less than or equal to the second reference threshold, the partition consensus mechanism is to determine the partition information matching the current object request, the verification operations in each partition are performed in parallel, the partition information is used to indicate the partition matching relationship between the node operation and the object node, and the first reference threshold is less than the second reference threshold; When the load mode is a high load mode, the target consensus mechanism is determined as a node expansion mechanism, wherein the load level corresponding to the high load mode is greater than the second reference threshold, and the node expansion mechanism is to expand the reference object node, and the matching relationship between the node operation and the object node is determined according to the priority order, and the verification operations in each partition are executed asynchronously.

6. The method according to claim 1, characterized in that After determining the target consensus mechanism according to the load pattern matching the current node set, it includes: Determine, according to the request priority indicated by the request description information, an operation priority corresponding to each of at least one of the node operations; The target partition for executing the node operation is determined according to the operation priority corresponding to at least one of the node operations and the node partition information, wherein the node partition information is used to indicate the available resource information in each partition, and the target partition is composed of target object nodes of different types.

7. The method according to claim 1, characterized in that After determining the target consensus mechanism according to the load pattern matching the current node set, the method further includes: Obtaining the data status stored in the current blockchain, wherein the data status is used to indicate the stability of the transaction; When the data state satisfies a rule adjustment condition, a parameter rule is modified, wherein the parameter rule is used to determine an operation result of the node operation.

8. An adaptive node operation device, characterized in that: include: A first determining unit determines a target consensus mechanism according to a load pattern matching a current node set, wherein the target consensus mechanism is used to instruct at least one object node in the current node set to perform at least one node operation; an acquiring unit, acquiring request description information of a current object request, and determining node operation information of at least one object node that responds to the current object request under the target consensus mechanism according to the request description information, wherein the node operation information is used to indicate at least one node operation performed by the object node in response to the current object request; The second determination unit determines a target response result that matches the current object request according to an operation result of at least one of the node operations, when at least one of the object nodes successfully performs the node operation according to the respective corresponding node operation information, wherein a target block indicating the target response result will be added to a target blockchain corresponding to the current node set.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the program is executed by a processor to perform the method described in any one of claims 1 to 7.

10. An electronic device comprising: A memory and a processor, wherein the memory is used to store a computer program, and wherein the processor is used to execute the steps of the method according to any one of claims 1 to 7 when calling the computer program.

Images