Dynamic load-oriented block chain node cooperation method, system and device, and medium

Abstract

The invention provides a dynamic load-oriented block chain node cooperation method, system and device, and a medium, and belongs to the technical field of block chains. The method comprises the following steps: dividing the operation time of a block chain system into continuous time slots; a parallelism degree parameter is dynamically set according to a real-time load, a current time slot is divided into mutually independent proposed positions, and nodes compete at different positions through proof of workload to generate candidate blocks in parallel; all the nodes execute whole-network integrity verification on the candidate blocks, after effective blocks are confirmed, the effective blocks are linked by adopting a prefix link structure, and a unique main chain is determined based on an accumulated workload rule; and dynamically calculating the parallelism degree parameter of the next time slot according to the load index, thereby realizing the self-adaptive adjustment of the system processing capability. According to the method, on the premise of keeping single chain security and consistency, the throughput, the resource utilization rate and the response efficiency of a block chain system under a dynamic load are improved through a dynamic parallel block output and elastic adjustment mechanism.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to blockchain node collaboration methods, systems, devices and media for dynamic loads. Background Technology

[0002] Blockchain technology faces severe scalability challenges in practical applications due to dynamic business loads. Traditional single-chain serial block generation structures are limited by inherent throughput limits and are prone to performance bottlenecks when transaction volume suddenly increases, leading to a significant increase in transaction confirmation delays and making it difficult to meet the needs of high-volatility scenarios such as decentralized finance and high-frequency trading.

[0003] To improve performance, the industry has explored various parallelization techniques, including: directed acyclic graph (DAG) structures, which face complex challenges in transaction ordering and eventual consistency; sharded chain structures, which rely on complex cross-shard coordination and may sacrifice global verification security; multi-chain parallel architectures, which introduce trust and complexity overhead in cross-chain communication; and parallel execution engines, whose optimization is limited by transaction dependencies and do not change the serial block generation nature of the consensus layer. However, none of these solutions fundamentally solve a key contradiction: how to achieve effective throughput improvement while maintaining the same global security and consistency model as a single chain.

[0004] Of particular note is that existing solutions for improving throughput generally rely on static protocol parameter configurations, such as a fixed number of shards, a fixed number of parallel chains, or a fixed block interval. This static design exposes inherent flaws when facing the highly dynamic and unpredictable load fluctuations of real-world network environments: during low-load periods, system capacity is excessive, and the fixed parallel structure leads to a significant waste of computing, storage, and bandwidth resources due to idle capacity. During high-load or sudden load surges, the static parallelism limit cannot be exceeded, and system throughput quickly reaches its ceiling, unable to scale elastically to absorb transaction spikes, resulting in a sharp increase in transaction backlog and confirmation latency, and a deterioration in user experience.

[0005] Therefore, existing technologies are caught in a fundamental dilemma where performance, security, and resilience are difficult to balance simultaneously: If high performance and scalability are pursued, it is often necessary to weaken global verification (such as sharding) or introduce complex cross-domain coordination mechanisms (such as multi-chain and cross-shard communication). This essentially sacrifices the simple and robust security model of traditional blockchain and increases the complexity and attack surface of the system.

[0006] If priority is given to ensuring the security of the entire chain and the simplicity of the model, then only the traditional single-chain serial architecture can be maintained. However, its fixed performance limit cannot respond to dynamic loads, resulting in the system's performance becoming rigid and its scalability insufficient during actual business fluctuations.

[0007] In summary, the current blockchain technology field urgently needs an innovative node collaboration method. This method must be able to allow nodes to collaborate in parallel to improve processing power without compromising the global security boundaries of traditional single chains or introducing additional cross-domain coordination overhead. Crucially, it must also have the ability to dynamically adjust the system's parallelism based on real-time load, thereby truly achieving a balance between high throughput, strong security, and elastic scalability to support the needs of next-generation high-performance blockchain applications. Summary of the Invention

[0008] The purpose of this invention is to provide a blockchain node collaboration method, system, device, and medium for dynamic load conditions, in order to solve the technical problems of limited throughput, low resource utilization, and difficulty in balancing security and scalability in existing blockchain technologies under dynamic load environments. It aims to effectively improve system processing capacity, reduce transaction confirmation delays, and optimize resource utilization through dynamic parallel block generation and adaptive adjustment mechanisms without changing the traditional single-chain security model.

[0009] To achieve the above objectives, this invention provides a blockchain node collaboration method for dynamic loads, comprising the following steps: Step S1: Divide the running time of the blockchain system into continuous independent time intervals; Step S2: For the current time interval, dynamically set the parallelism parameter according to the real-time load of the system. ,in A positive integer, representing the maximum number of candidate blocks that can be generated in parallel within the current time slot; Step S3: Divide the current time interval into Each node has an independent proposal position, and the nodes compete for the right to generate blocks at different proposal positions through proof-of-work, thereby generating multiple candidate blocks in parallel within the same time interval. Step S4: All nodes perform integrity verification on the candidate blocks generated in the current time gap, and jointly confirm the candidate blocks that pass the verification as valid blocks for that time gap. Step S5: Connect the valid blockchains at different time intervals using a prefix linking structure, and determine the unique main chain from the candidate chains based on the cumulative workload rule; Step S6: Dynamically calculate the parallelism parameter for the next time interval based on the current system load indicators. To adaptively adjust the system's processing capacity.

[0010] Preferably, in step S3, the current time interval is divided into The proposed locations are independent of each other, including: For each proposed location Establish an independent proof-of-work competition domain, where is the proposed location. Generate a unique hash field identifier , The location number of the proposal The summary information of all valid blocks in the previous time interval is determined; Node at the proposal position To perform proof-of-work calculations, a random number search is required. To satisfy: ; in, This refers to all fields in the block header except for the random number. The difficulty target is set uniformly for the system. For collision-resistant hash functions, This is for splicing operations.

[0011] Preferably, integrity verification includes transaction legality verification, state conflict checking, prefix linking verification, and proof-of-work difficulty verification.

[0012] Preferably, in step S5, determining a unique main chain based on the cumulative workload rule includes: The total workload of the chain is obtained by treating the workload of all valid blocks within the same time interval as a whole and summing them up. The node selects the chain branch with the highest cumulative workload as the system's main chain.

[0013] Preferably, when a chain fork occurs, the fork is resolved by comparing the total cumulative workload of each branch, and the branch with the higher cumulative workload is accepted as the valid main chain.

[0014] Preferably, in step S6, the load metric includes transaction arrival speed or transaction pool backlog; the dynamic calculation specifically involves increasing the load metric when it increases. Decrease when load indicators decrease .

[0015] Preferably, the method is implemented in a single-chain architecture that does not rely on sharding, multi-chain, or cross-chain communication coordination mechanisms.

[0016] This invention also provides a blockchain node collaboration system for dynamic loads, comprising: The time segmentation module is used to divide the running time of the blockchain system into continuous independent time intervals; The parallelism dynamic setting module is used to dynamically set the parallelism parameters for the current time interval based on the real-time load of the system. ; The parallel proposal module is used to divide the current time interval into... Each node has an independent proposal location, and the nodes compete to generate candidate blocks in parallel at different proposal locations through proof-of-work. The network-wide verification module is used to control all nodes to perform integrity verification on candidate blocks within the current time interval and confirm valid blocks; The main chain consensus module is used to organize valid blocks through a prefix linking structure and determine a unique main chain based on the cumulative workload rule; The adaptive adjustment module is used to dynamically calculate the parallelism parameter for the next time interval based on the current system load indicators. .

[0017] The present invention also provides a computer device, including: a memory and a processor; the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described blockchain node collaboration method for dynamic load.

[0018] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method for collaborative blockchain nodes under dynamic load.

[0019] Therefore, the present invention employs the above-mentioned blockchain node collaboration method, system, device, and medium oriented towards dynamic load, and the beneficial technical effects are as follows: (1) This invention allows multiple nodes to compete for block production rights in parallel by establishing multiple independent proposal positions within the same time interval, thereby increasing the block production capacity of the system from a single block in a traditional single chain to a maximum of This design eliminates the need for network or state sharding; all nodes still perform full network-wide verification of all blocks across the entire chain, maintaining a security boundary completely consistent with traditional single-chain systems. This completely resolves the fundamental flaw in existing technologies such as sharding and multi-chain systems, which sacrifice security due to reduced verification scope or reliance on external coordination, achieving a balance between high throughput and strong security.

[0020] (2) This invention monitors the transaction load in real time and dynamically calculates and adjusts the parallelism parameter for each time interval. This creates a closed-loop feedback loop. The system can automatically expand to absorb transaction surges under high load and automatically shrink to save resources under low load. This directly overcomes the core problem of resource mismatch under dynamic load in existing static parameter schemes, enabling the system to have load awareness and elastic response capabilities, and significantly improving resource utilization.

[0021] (3) By using a prefix linking structure and the longest chain rule based on cumulative workload, this invention logically integrates all parallel-generated blocks into a single unit of chain-driven progress. This ensures that no matter how many blocks are generated within a single slot, the entire network will eventually converge to a unique, linear, and ordered main chain. This method avoids the sorting complexity and confirmation uncertainty problems caused by the directed acyclic graph structure, and also eliminates the complex cross-chain state synchronization required by multi-chain architectures, maintaining the simplicity and consistency of the ledger model while improving performance.

[0022] (4) The proposal space hash binding mechanism proposed in this invention creates a unique and non-reusable hash computation domain for each proposal location. This ensures that the computation results of proof-of-work cannot be migrated or reused between different proposal locations, fundamentally preventing attackers from improperly obtaining multiple block production rights by reusing computation results across locations, and strictly maintaining the fairness and security assumptions of proof-of-work consensus.

[0023] (5) The architecture of this invention is extended without changing the traditional single-chain consensus model, transaction format, and basic consensus mechanism. Existing blockchain nodes can smoothly support this method through protocol upgrades without requiring disruptive modifications to the underlying security model or ecosystem tools. This provides a feasible practical path to solve the problem of incompatibility between performance improvement schemes and existing infrastructure in existing technologies. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating the workflow of the blockchain node collaboration method for dynamic load according to the present invention. Figure 2 This is a schematic diagram of a chain fork solution based on cumulative workload rules. Detailed Implementation

[0025] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0026] Unless otherwise defined, the technical or scientific terms used in this invention shall have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains.

[0027] Example 1 This embodiment specifically illustrates the implementation process of the method of the present invention in a blockchain system based on proof-of-work consensus.

[0028] 1. Basic Design and Principles.

[0029] The foundation of this invention is a parallel proposal structure designed to enable multiple nodes to generate multiple candidate blocks simultaneously within the same time slot, thereby breaking the inherent limitation of traditional chain structures where "only one node is allowed to generate one block per slot." Through this structure, in a slot... The maximum number of generators that can be generated is [number]. Multiple candidate blocks. Multiple nodes can simultaneously participate in the mining competition at different proposed positions, thus increasing the system's effective block production capacity from a single block in a serial structure to a maximum of [number missing]. This significantly increases system throughput. The parallel proposal structure of this invention requires no sharding, no cross-chain synchronization, and no reduction in the verification scope, maintaining the structural integrity of the chain ledger while possessing inherent scalability.

[0030] To achieve multi-node collaborative proposal within the same slot, the "proposal position" is first strictly defined. The proposal position represents the contestable block-producing position within a slot and is the most basic unit of the parallel structure of this invention. For a given slot, if the system sets the parallelism of that slot to... This indicates that there exists within that time window. Each proposal position is an independent one. Each proposal position corresponds to a competitive channel that nodes can participate in mining. Nodes can freely choose any proposal position for computation, and can also participate in the computation of multiple positions simultaneously, as long as the node has sufficient computing resources. The proposal positions are completely independent of each other; a node's successful computation at one position will not affect its competitive behavior at other positions.

[0031] To ensure that proposed positions do not interfere with each other, this invention provides a unified system-level definition for the identity of each proposed position. Each proposed position has a unique integer number, ranging from one to... Arranged sequentially. In this way, within a given slot, all nodes in the system have access to... A consensus is reached on the set of proposed locations, preventing inconsistencies in the understanding of the number or order of proposed locations. This explicit numbering method allows nodes to clearly identify the block candidate corresponding to each proposed location, avoiding different nodes generating different versions of blocks for the same proposed location. Furthermore, this invention requires all proposed locations to generate corresponding block headers according to unified rules. While different proposed locations do not interfere with each other in mining competition, they are completely consistent in their structural definitions, including block header fields, transaction payloads, and prefix information. This ensures consistency in subsequent verification and linear combination processes for blocks generated from multiple proposed locations. All nodes start from the same set of proposed locations within the same slot, significantly simplifying the collaboration process and ensuring the overall predictability and protocol transparency of the system.

[0032] In the multi-proposal structure proposed in this invention, different proposal positions must have mutually isolated competition domains to ensure that parallel block production does not introduce additional security risks. To this end, this invention designs a "proposal space hash binding mechanism" to establish an independent and non-compatible hash space for each proposal position. This prevents nodes from copying computation results, reusing workloads, or transferring mining results between different proposal positions, thus strictly maintaining the competitive independence of each position. In this invention, each proposal position has a unique hash identifier within a slot. This identifier is determined by the proposal position number and the prefix information of the previous slot. The prefix information comes from all valid blocks in the previous slot, which are processed by the system to form a single digest value. Since the digest value changes continuously as the chain progresses, the hash identifier of each slot is unique, cannot be pre-computed, and cannot be predicted or reused by attackers.

[0033] In this invention, since multiple valid proposal blocks may be generated within each slot, the system requires a main chain selection mechanism that can uniformly process parallel blocks, maintain ledger uniqueness, and fully utilize the workload of all blocks when advancing the chain structure. To this end, this invention designs a longest chain selection rule based on cumulative workload to ensure that the entire network eventually converges to a unique chain structure when multiple candidate block sets exist. This invention stipulates that the valid block set of each slot contributes a total workload value. When calculating the total workload of the chain, nodes accumulate the workload of each slot in chronological order to form the cumulative workload of the chain. If multiple candidate chain prefixes exist in the network, nodes select the chain with the highest cumulative workload as the main chain branch, thereby maintaining the security and determinism consistent with traditional single chains. Under this mechanism, even if a slot contains multiple blocks, these blocks do not cause splits in the chain's advancement; instead, they contribute workload together, allowing the slot to appear as a whole in the chain structure.

[0034] 2. Specific workflow.

[0035] Based on the above design principles, the system workflow is as follows ( Figure 1 ): (1) System model and time division.

[0036] This invention employs a time-driven model based on time slots, dividing the blockchain system's operational cycle into continuous, independent slots. The network model is an asynchronous communication model, with all nodes maintaining complete local ledgers and transaction pools. The system model of this invention maintains the consistency assumptions of traditional blockchains, and the threat model is consistent with proof-of-work consensus.

[0037] (2) Setting of dynamic parallelism parameters.

[0038] In slot Initially, the system dynamically sets the parallelism parameter of the slot based on the real-time load. This parameter is a positive integer, representing the number of proposed locations within this time interval.

[0039] (3) Parallel proposal and candidate block generation.

[0040] Divide the current slot into Each independent proposal position constitutes a set For each proposed location The "proposal space hash binding mechanism" is applied to generate its unique hash field identifier. Each node selects one or more proposal locations and calculates the right to generate a competing block at the corresponding location using proof-of-work, subject to the following difficulty conditions: ; in, This refers to all fields in the block header except for the random number. The difficulty target is set uniformly for the system. For collision-resistant hash functions, This is for splicing operations.

[0041] The node that successfully finds the random number generates and broadcasts the candidate block for the corresponding proposed position, thus forming a set of parallel blocks within the same slot.

[0042] (4) Full network verification and valid block confirmation.

[0043] All nodes perform a full verification of all candidate blocks broadcast within the current slot, including transaction validity verification, state conflict checking, prefix link verification, and proof-of-work difficulty checking. All candidate blocks that pass verification are collectively recognized as the valid block set for that slot and written to the node's local ledger, thereby ensuring the overall network state is maintained. Figure 1 To.

[0044] (5) Prefix link construction and main chain confirmation based on cumulative workload.

[0045] Each valid block's header contains a digest of the set of all valid blocks in the previous slot, forming a prefix link structure. Nodes determine the main chain using the longest chain selection rule based on cumulative work: the work of all valid blocks within the same slot is treated as a single unit, and the work of each slot is accumulated in chronological order to obtain the chain's cumulative work; the node selects the chain branch with the highest cumulative work as the system's unique main chain.

[0046] like Figure 2 As shown, in the block A fork occurred at this point. In this example, the upper branch is considered the longest chain because its effective length is 5. Although the lower branch has more blocks in total, parallel blocks generated in the same slot are treated as a single unit in length calculation, so its effective length is only 4, thus it is judged as an invalid chain. From a computational power consumption perspective, assuming the basic proof-of-work difficulty is... The expected number of hash queries required for the upper branch is: ; in, For safety parameters.

[0047] The expected number of hash queries required for the lower branch is: .

[0048] Therefore, since the upper branch represents a higher investment of computing resources, the system ultimately accepts the upper branch as the valid chain.

[0049] Furthermore, this invention ensures consistency in the results for the block sets within each slot across different nodes through a prefix linking structure. Each block's prefix points to the complete block set of the previous slot, allowing nodes to accurately identify the chain's structural state when updating their local chain state. If two branch chains exist in the network with different block sets in certain slots, nodes will automatically determine which branch to continue based on the accumulated workload. Since the workload calculation method is not biased towards a particular path due to the existence of parallel blocks, attackers cannot gain an additional advantage by manipulating multiple blocks within a single slot.

[0050] (6) Adaptive parallelism adjustment.

[0051] After completing block processing for the current slot, the node calculates and updates the parallelism parameters for the next slot based on the system's current workload and transaction backlog, according to predefined rules. Automatically increases when the load increases. The value decreases automatically when the load drops. This value allows for adaptive and dynamic adjustment of the system's processing capacity.

[0052] The present invention will be further illustrated by specific examples below.

[0053] To verify the effectiveness of this invention, simulation performance comparisons were conducted under the same basic conditions as traditional single-chain blockchain systems. Specific experimental parameter settings are as follows: System size: 200 logical nodes; Consensus mechanism: Based on Proof-of-Work (PoW); Block interval: The average block generation time is approximately 10 seconds; Network conditions: The network bandwidth between nodes is set to 20Mbps; Block capacity: A single block can hold a maximum of 2,000 transactions.

[0054] In comparative experiments, traditional single-chain systems follow a serial mode that generates only one block per slot. In contrast, the proposed solution dynamically enables different degrees of parallelism, setting the number of parallel proposal blocks accordingly. Conduct testing (when) When =1, its behavior is equivalent to a traditional single chain. For each configuration, 100 consecutive slots were simulated, and the average throughput (unit: transactions / second) was calculated. The performance comparison results are shown in Table 1.

[0055] Table 1. Performance Comparison of the Invention and Single-Chain System

[0056] As shown in Table 1, under identical implementation conditions, the throughput of a traditional single-chain system is limited by its inherent serial block generation mechanism, stabilizing at approximately 198 transactions / second. In contrast, this invention introduces an adjustable parallel block proposal mechanism, increasing system throughput with the degree of parallelism. The increase in parallelism shows a near-linear improvement trend. When the parallelism is set to 8, the system throughput reaches 1568 transactions / second, which is about 7 times higher than that of a traditional single-chain system. This result fully demonstrates the significant effect of the dynamic parallel block generation mechanism proposed in this invention in improving the processing capacity of blockchain systems.

[0057] Example 2 This invention also provides a blockchain node collaboration system for dynamic loads, comprising: The time segmentation module is used to divide the running time of the blockchain system into continuous independent time intervals; The parallelism dynamic setting module is used to dynamically set the parallelism parameters for the current time interval based on the real-time load of the system. ; The parallel proposal module is used to divide the current time interval into... Each node has an independent proposal location, and the nodes compete to generate candidate blocks in parallel at different proposal locations through proof-of-work. The network-wide verification module is used to control all nodes to perform integrity verification on candidate blocks within the current time interval and confirm valid blocks; The main chain consensus module is used to organize valid blocks through a prefix linking structure and determine a unique main chain based on the cumulative workload rule; The adaptive adjustment module is used to dynamically calculate the parallelism parameter for the next time interval based on the current system load indicators. .

[0058] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0059] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0060] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0061] It is worth noting that all contents not described in detail in this invention are existing technologies and are well known to those skilled in the art.

[0062] Therefore, this invention adopts the aforementioned blockchain node collaboration method, system, device, and medium for dynamic loads. By dynamically setting parallelism parameters and dividing independent proposal positions to achieve parallel block production, using full network verification to maintain security, and a collaborative method based on prefix links and cumulative workload to ensure chain consistency, it solves the technical problems of fixed throughput, rigid resource utilization, and difficulty in balancing security and scalability in existing blockchains under dynamic loads. This results in elastic scaling of system processing capacity, a significant improvement in transaction confirmation efficiency, and lossless maintenance of the global security model.

[0063] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for dynamic load-oriented blockchain node collaboration, characterized in that, The method comprises the following steps: S1, dividing the running time of the blockchain system into continuous independent time intervals; Step S2, dynamically setting the parallelism parameter according to the real-time load of the system for the current time interval ; Step S3, dividing the current time interval into independent proposal positions, and nodes compete for block generation rights of different proposal positions through proof of work, thereby generating multiple candidate blocks in parallel within the same time interval. S4, all nodes verifying the integrity of the candidate blocks generated in the current time interval, and jointly confirming the verified candidate blocks as valid blocks of the time interval; S5, linking the valid blocks of different time intervals by using a prefix link structure, and determining a unique main chain from the candidate chains based on a cumulative work amount rule; Step S6, dynamically calculate the parallelism parameter of the next time interval according to the current load index of the system to adaptively adjust the system processing capacity. 2.The dynamic load oriented blockchain node cooperation method according to claim 1, characterized in that, In step S3, the current time slot is divided into mutually independent offer positions, comprising: For each proposed position An independent proof-of-work competition domain is established, wherein, for the proposed position A unique hash domain identification is generated , The summary information of all valid block sets in the last time gap is determined by the proposed position number ​ The node is at a proposed location To perform proof-of-work calculations, a random number must be searched To satisfy: ； wherein, is all fields in the block header except the nonce, is a difficulty target set uniformly for the system, is a hash function resistant to collision, is a concatenation operation. 3.The dynamic load oriented blockchain node cooperation method according to claim 1, characterized in that, The integrity verification includes transaction legality verification, state conflict checking, prefix link verification, and work amount proof difficulty verification. 4.The dynamic load oriented blockchain node cooperation method according to claim 1, characterized in that, In step S5, the determination of the unique main chain based on the cumulative work amount rule comprises: Adding the work amounts of all valid blocks in the same time interval as a whole unit to obtain the cumulative work amount of the chain; The node selects the chain branch with the highest cumulative work amount as the system main chain. 5.The dynamic load oriented blockchain node cooperation method according to claim 4, characterized in that, When a chain fork occurs, the fork is resolved by comparing the cumulative work amount sums of the branches, and the branch with higher cumulative work amount is accepted as the valid main chain. 6.The dynamic load oriented blockchain node cooperation method according to claim 1, characterized in that, In step S6, the load indicator includes the transaction arrival rate or the transaction pool backlog level; the dynamic calculation is specifically: increasing the number of threads when the load indicator rises , and decreasing the number of threads when the load indicator falls . 7.The dynamic load oriented blockchain node cooperation method according to claim 1, characterized in that, The method is implemented in a single-chain architecture without relying on sharding, multi-chain, or cross-chain communication coordination mechanisms.

8. A blockchain node collaboration system oriented to dynamic load, characterized in that, It comprises: a time division module for dividing the running time of the blockchain system into continuous independent time intervals; The parallelism dynamic setting module is configured to dynamically set the parallelism parameter for a current time interval according to real-time load of the system ; a parallel proposal module, configured to divide a current time interval into a plurality of independent proposal positions, and control the node to generate candidate blocks in different proposal positions in parallel through proof-of-work competition; a full-network verification module for controlling all nodes to verify the integrity of the candidate blocks in the current time interval, and confirming the valid blocks; a main chain consensus module for organizing the valid blocks by using a prefix link structure, and determining a unique main chain based on a cumulative work amount rule; An adaptive adjustment module is configured to dynamically calculate the parallelism parameter of the next time interval according to the current load index of the system .

9. A computer device comprising: a memory and a processor; The memory stores a computer program, and the processor executes the computer program to implement the steps of the dynamic load-oriented blockchain node collaboration method according to any one of claims 1-7.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the dynamic load-oriented blockchain node collaboration method according to any one of claims 1-7.

Images