Lightweight block chain node consensus mechanism optimization method

Abstract

The invention discloses a lightweight block chain node consensus mechanism optimization method, and relates to the technical field of block chains. According to the method, the computing power of the lightweight nodes is accurately evaluated through a hierarchical verification aggregation algorithm, efficient participation of the lightweight nodes in a resource-constrained environment is realized, a transaction set is divided into a plurality of subsets by adopting a transaction verification fragmentation strategy, and verification results are aggregated by utilizing a Merkel tree aggregation verification technology; in addition, a dynamic storage management strategy is established, the depth of locally stored historical data is dynamically adjusted according to the node storage capacity, and network storage and retrieval are performed through a distributed hash table; the bottleneck problem of storage and network transmission is effectively solved, and the network bandwidth utilization efficiency and the storage management flexibility are improved.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, specifically a method for optimizing a lightweight blockchain node consensus mechanism. Background Technology

[0002] As the core infrastructure of distributed ledgers, blockchain technology plays a crucial role in the digital economy and decentralized applications. With the rapid proliferation of IoT devices and edge computing scenarios, the demand for lightweight blockchain nodes is becoming increasingly urgent. These nodes need to effectively participate in network consensus even in resource-constrained environments. Current mainstream blockchain consensus mechanisms generally suffer from excessive resource consumption. Traditional solutions require nodes to maintain a complete ledger and independently verify each transaction, resulting in huge computational and storage overhead. Existing lightweighting attempts often employ simple data pruning or reduced security, making it difficult to strike a balance between performance optimization and security assurance. These methods lack systematic optimization strategies and cannot fundamentally solve the challenge of lightweight node participation. Summary of the Invention

[0003] The purpose of this invention is to provide a lightweight blockchain node consensus mechanism optimization method, which enables lightweight blockchain nodes to participate efficiently in resource-constrained environments, optimizes transaction verification and ledger synchronization processes, and improves network bandwidth utilization efficiency and storage management flexibility.

[0004] The objective of this invention can be achieved through the following technical solutions: This application provides a lightweight blockchain node consensus mechanism optimization method, including the following steps: A hierarchical verification aggregation algorithm is used to obtain the computing power evaluation value of lightweight nodes. The comprehensive performance index is calculated based on the node's processor frequency and memory size. When the comprehensive performance index is lower than a preset threshold, the node is judged to be a resource-constrained type. Establish a node heterogeneous classification mechanism, construct a node hierarchical matrix based on storage capacity and network bandwidth, and classify nodes by setting thresholds to obtain the node distribution status at different levels; An adaptive consensus weighting algorithm is used to allocate different consensus participation weights, and a dynamic participation mechanism that adapts to the heterogeneous characteristics of nodes is obtained through weight differentiation. After obtaining the weight allocation of each node, a transaction verification sharding strategy is established to divide the complete transaction set into multiple subsets. Lightweight nodes only verify the allocated transaction subsets instead of all transactions, and the number of transactions allocated is determined based on the node's computing power value. The Merkle tree aggregation verification technique is used to verify the transaction sharding results. Each node submits the hash value of the local verification result to build a verification tree structure. When the verification of a shard fails, the reallocation and verification process of that shard is triggered to obtain the aggregated verification result of the complete transaction set. Based on the aggregated verification results, a ledger synchronization optimization mechanism is implemented. Lightweight nodes only store block header information and related transaction indexes. The state root hash value is used to verify ledger consistency. When the local state root does not match the network broadcast state root, an incremental synchronization process is triggered. Establish a dynamic storage management strategy to dynamically adjust the depth of locally stored historical data based on the node's storage capacity. Historical block data exceeding the storage limit is stored and retrieved over the network using a distributed hash table.

[0005] Furthermore, a hierarchical verification aggregation algorithm is used to obtain the computational capability evaluation value of the lightweight node, specifically including: The computing power data of lightweight nodes is obtained through a tiered verification method. Initial data collection is performed on processor frequency and memory capacity. The processor frequency and memory capacity are weighted and calculated using preset weighting coefficients to determine the comprehensive performance index value. The comprehensive performance index value is compared with the preset threshold. If the comprehensive performance index value is lower than the preset threshold, the node is determined to be a resource constraint type. The node data of the resource constraint type is obtained. Combined with the results of hierarchical verification, the performance data of the node is classified and organized using an aggregation method to obtain the classified node performance status. By analyzing the performance status of the classified nodes, we can determine the distribution of resource-constrained nodes in the overall system, identify the proportion of restricted nodes, and use a logistic regression model to predict and analyze node performance to obtain performance trend data for a future period of time. For performance trend data, an optimization scheduling strategy is generated by combining aggregation methods to determine whether the resource allocation is reasonable. If the allocation is uneven, the computing task load of the restricted nodes is adjusted.

[0006] Furthermore, a node heterogeneity classification mechanism is established based on the resource constraint assessment results, specifically including: Based on the resource constraint assessment results, an initial framework for classifying heterogeneous nodes is constructed using data on storage capacity and network bandwidth. Nodes are initially classified using a hierarchical matrix approach to obtain the distribution status of node levels. The ratio data of lightweight nodes and standard nodes is obtained, and the ratio data is structured to determine the resource distribution characteristics of nodes at different levels. Using pre-established classification rules, the proportion of lightweight nodes in the overall architecture is determined. When the proportion is higher than a preset threshold, the lightweight nodes are marked as resources to obtain the marked node dataset. Detailed resource information of lightweight nodes is obtained from the labeled node dataset. Combined with the constraints of storage capacity and network bandwidth, resource bottlenecks are analyzed through information processing to determine the priority ranking of restricted nodes. A logistic regression model is used to analyze the trend of node resource usage, obtain dynamic change data of resource allocation, obtain the basis for adjusting resource allocation, and adjust the task allocation strategy by information matching for the resource differences between standard-level nodes and lightweight nodes, and determine the final task allocation scheme. The adjusted node operating status is obtained, and combined with the updated distribution status data, the node level is dynamically calibrated through information processing to obtain the optimized node distribution status.

[0007] Furthermore, an adaptive consensus weighting algorithm is used to assign different consensus participation weights, specifically including: Node hierarchical data is obtained from the node network. Node categories are determined based on node performance and resource consumption to obtain the hierarchical results of lightweight nodes and standard nodes. The basic weight values ​​are determined by calculating the basic weight of each node and using a preset resource evaluation model. When the node category is a lightweight node, the base weight is multiplied by 0.3 to obtain the consensus weight of the lightweight node; when the node category is a standard node, the base weight is multiplied by 1.0 to obtain the consensus weight of the standard node. By allocating consensus weights, an adaptive consensus weight algorithm is constructed. A dynamic participation mechanism is generated based on weight differentiation. Based on the execution results of the dynamic participation mechanism, the participation frequency of nodes in the consensus process is analyzed to determine the degree of adaptation to the heterogeneous characteristics of nodes. For nodes whose adaptability is below a preset threshold, the consensus weight allocation strategy is adjusted, and the K-means clustering algorithm is used to regroup the node performance to obtain the updated node stratification results. The consensus weight is then recalculated, and the weight allocation and dynamic participation mechanism are executed cyclically to obtain an optimized consensus participation scheme.

[0008] Furthermore, after obtaining the weight allocation for each node, a transaction verification sharding strategy is established, specifically including: The computing power value of each node is obtained by collecting hardware performance data and current load status through the node monitoring module in the distributed system. The computing power value of each node is then combined with the preset average computational complexity of the transaction to calculate the transaction allocation ratio and obtain the transaction allocation number for each node. A partitioning algorithm is used to divide the complete transaction set into multiple transaction subsets. When the computing power of a node is higher than a preset threshold, a large transaction subset is allocated, resulting in a set of partitioned transaction subsets. The allocated transaction subsets are obtained through lightweight nodes, and a verification algorithm is called to check the legality of the transactions in the subsets to obtain the verification results. A consistent hashing algorithm is used to map the verification results to the global transaction verification pool. The global transaction verification status is judged. When the global transaction verification status meets the preset consistency conditions, the verified transaction subset is merged into the verification result of the complete transaction set. Then, the confirmation status is distributed to all nodes through a distributed broadcast mechanism to obtain the network-wide transaction verification consistency.

[0009] Furthermore, the verification results through transaction sharding are validated using Merkle tree aggregation verification technology, specifically including: The complete transaction set is divided into multiple transaction shards using transaction sharding technology. The Merkle tree algorithm is used to calculate the hash value of the local verification result from each transaction shard. A verification tree structure is constructed based on the hash value to generate the root node hash value containing the hashes of all shards. If the hash value of the root node of the verification tree does not match the preset threshold, it is determined that there is a sharding failure, triggering a reallocation process. The failed shard is reallocated to other nodes through a reallocation algorithm to obtain a new local verification result. The verification tree structure is then updated, and the root node hash value is recalculated to obtain the aggregated verification result. This aggregated verification result is then compared with the complete transaction set to determine the final verification result.

[0010] Furthermore, a ledger synchronization optimization mechanism is implemented based on the aggregated verification results, specifically including: Obtain block header information and transaction index from lightweight nodes, calculate the local state root hash value S_root, where S_root is the Merkle tree root hash based on the block header and transaction index, and obtain the local state root hash; The current network state root hash value S_root_net is obtained through network broadcast, where S_root_net is the ledger state root hash of the whole network consensus. The network state root hash is obtained, and a hash value comparison algorithm is used. If the local state root hash S_root does not match the network state root hash S_root_net, the ledger is determined to be inconsistent, and an inconsistent state is obtained. Based on the inconsistency state, an incremental synchronization process is triggered to obtain the missing transaction data and block headers from the network, update the local ledger, obtain the synchronization task, and use the Merkle tree reconstruction algorithm to recalculate the local state root hash S_root_new, where S_root_new is the root hash of the updated ledger, and obtain the new state root hash. When the new state root hash S_root_new matches the network state root hash S_root_net, the ledger is considered consistent, synchronization is completed, and a consistency verification result is obtained. Then, the transaction index and block header information of the lightweight node are updated, and the index storage is optimized using a Bloom filter to obtain the optimized ledger state.

[0011] Furthermore, a dynamic storage management strategy is established using incremental synchronization results, specifically including: The latest data update status of the nodes is obtained through an incremental synchronization mechanism. The data is sharded using a distributed computing framework to obtain a synchronized data set. The ratio of the storage capacity of each node to the value of a single block is calculated to determine the local storage depth parameter. When the local storage depth parameter exceeds the preset capacity limit, a dynamic storage adjustment process is triggered to obtain the excess block data, determine whether to transfer it to distributed hash table storage, generate corresponding storage index records based on the excess block data, and obtain the network storage mapping relationship. Construct a data retrieval path, use a consistent hashing algorithm to locate the storage location, determine the access entry point for the target data, obtain the corresponding historical data content for the located access entry point, and check the data integrity. When the integrity check passes, the data retrieval process is completed. The storage status of the local node is updated based on the output of the data retrieval process, and the adjusted storage capacity record is generated. The dynamic storage management process is then executed cyclically.

[0012] Furthermore, after network storage and retrieval through a distributed hash table, the system also includes: achieving network bandwidth optimization through a distributed storage mechanism; using a differential synchronization protocol between nodes to transmit only incremental state changes rather than complete state data; and enabling data compression transmission mode when the bandwidth is below a threshold, thus obtaining an efficient consensus participation scheme adapted to lightweight nodes.

[0013] Furthermore, network bandwidth optimization is achieved through distributed storage mechanisms, specifically including: The state data between nodes is obtained through a distributed storage mechanism, and the state change increment is calculated, where represents the difference between the current state and the previous state. The state change increment data is obtained, and the data is encapsulated using a differential synchronization protocol to generate transmission data packets, ensuring that the data packets contain only incremental information. When the network bandwidth is lower than the preset threshold, a data compression algorithm is applied to the transmitted data packets. The LZ77 algorithm is used to generate compressed data packets, and the compressed data packets are transmitted to the target node through the inter-node communication mechanism. A transmission completion confirmation signal is obtained to confirm that the data transmission was successful. The decompressed state change increment is obtained from the target node, and distributed to the distributed storage nodes using a consistent hashing algorithm to obtain the storage allocation result. The local state data of the lightweight node is then updated. The Raft consensus algorithm is used to verify the state consistency among nodes, and a consensus verification result is obtained. If the consensus verification result shows that the states are inconsistent, the state change increment is recalculated, a new transmission data packet is generated, and the node state is synchronized.

[0014] The beneficial effects of this invention are as follows: This invention uses a hierarchical verification aggregation algorithm to accurately evaluate the computing power of lightweight nodes and combines it with an adaptive consensus weight algorithm to assign reasonable consensus weights to nodes with different performance levels. This enables lightweight nodes to participate in network consensus efficiently in resource-constrained environments, solving the problem that lightweight nodes cannot effectively participate due to insufficient resources in traditional consensus mechanisms, and improving the resource utilization efficiency and overall performance of the entire blockchain network. A transaction verification sharding strategy is adopted, dividing the transaction set into multiple subsets. Lightweight nodes only verify the assigned subset. At the same time, Merkle tree aggregation verification technology is used to aggregate the verification results, and a ledger synchronization optimization mechanism is implemented. Lightweight nodes only store necessary information and verify consistency through state root hash value, which significantly reduces the computation and storage burden of lightweight nodes, improves transaction processing efficiency and ledger synchronization reliability, solves the problem of huge computation and storage overhead caused by lightweight nodes independently verifying all transactions in traditional schemes, and achieves a balance between performance optimization and security assurance. By establishing a dynamic storage management strategy, the depth of locally stored historical data is dynamically adjusted according to the node's storage capacity, and network storage and retrieval are performed through a distributed hash table. At the same time, a differential synchronization protocol is adopted to transmit only the incremental state change, and a data compression transmission mode is enabled in low-bandwidth environments. This effectively solves the bottleneck problems of lightweight nodes in terms of storage and network transmission, reduces the amount of data transmission, improves the utilization efficiency of network bandwidth and the flexibility of storage management, and enables lightweight nodes to operate efficiently in resource-constrained environments, further improving the performance and scalability of the entire blockchain network. Attached Figure Description

[0015] To better understand and implement this application, the technical solution is described in detail below with reference to the accompanying drawings.

[0016] Figure 1 A flowchart illustrating a lightweight blockchain node consensus mechanism optimization method provided in this application; Figure 2 A flowchart illustrating the process of obtaining the computational power evaluation value of a lightweight node using a lightweight blockchain node consensus mechanism optimization method provided in this application; Figure 3 The flowchart of the lightweight blockchain node consensus mechanism optimization method provided in this application illustrates the process of allocating different consensus participation weights using an adaptive consensus weight algorithm. Detailed Implementation

[0017] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, exemplary embodiments will be described in detail below, examples of which are illustrated in the accompanying drawings. In the following description relating to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of methods and systems consistent with some aspects of this application as detailed in the appended claims.

[0018] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0019] The following detailed description of the specific implementation methods, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided in detail.

[0020] Please see Figures 1-3 This embodiment provides a lightweight blockchain node consensus mechanism optimization method, including the following steps: S1. Use a hierarchical verification aggregation algorithm to obtain the computing power evaluation value of the lightweight node. Calculate the comprehensive performance index P = α × CPU frequency + β × memory capacity based on the node's processor frequency and memory size, where α represents the processor weight coefficient and β represents the memory weight coefficient. If the P value is lower than the preset threshold T1, the node is judged to belong to the resource constraint type. Furthermore, a hierarchical verification aggregation algorithm is used to obtain the computational capability evaluation value of the lightweight node, specifically including: S11. Obtain the computing power data of the lightweight node through a hierarchical verification method, initially collect the processor frequency and memory capacity, and use preset weighting coefficients to perform weighted calculations on the processor frequency and memory capacity to determine the comprehensive performance index value. S12. Compare the comprehensive performance index value with the preset threshold. If the comprehensive performance index value is lower than the preset threshold, the node is determined to be a resource constraint type. Obtain the node data of the resource constraint type. Combine the results of hierarchical verification and use the aggregation method to classify and organize the node performance data to obtain the classified node performance status. S13. Analyze the distribution of resource-constrained nodes in the overall system based on the classified node performance status, determine the proportion range of restricted nodes, use a logistic regression model to predict and analyze node performance, and obtain performance trend data for a future period of time. S14. For performance trend data, combine the aggregation method to generate an optimized scheduling strategy, determine whether the resource allocation is reasonable, and adjust the computing task load of the restricted nodes when the allocation is uneven.

[0021] By using a hierarchical verification aggregation algorithm to accurately evaluate the computing power of lightweight nodes, identify nodes with resource constraints, and generate optimized scheduling strategies based on performance trend predictions, this approach solves the problem in traditional blockchains where lightweight nodes are unable to effectively participate in network consensus due to resource limitations. This effectively improves the participation of lightweight nodes and the overall operating efficiency of the system.

[0022] S2. Establish a node heterogeneous classification mechanism based on the resource constraint evaluation results. Construct a node hierarchical matrix M[i,j] based on storage capacity S and network bandwidth B. When S < threshold S0 and B < threshold B0, the node is determined to be lightweight. When S ≥ S0 and B ≥ B0, the node is determined to be standard. Obtain the node distribution status of different levels. Furthermore, a node heterogeneity classification mechanism is established based on the resource constraint assessment results, specifically including: Based on the resource constraint assessment results, an initial framework for classifying heterogeneous nodes is constructed using data on storage capacity and network bandwidth. Nodes are initially classified using a hierarchical matrix approach to obtain the distribution status of node levels. The ratio data of lightweight nodes and standard nodes is obtained, and the ratio data is structured to determine the resource distribution characteristics of nodes at different levels. Using pre-established classification rules, the proportion of lightweight nodes in the overall architecture is determined. When the proportion is higher than a preset threshold, the lightweight nodes are marked as resources to obtain the marked node dataset. Detailed resource information of lightweight nodes is obtained from the labeled node dataset. Combined with the constraints of storage capacity and network bandwidth, resource bottlenecks are analyzed through information processing to determine the priority ranking of restricted nodes. A logistic regression model is used to analyze the trend of node resource usage, obtain dynamic change data of resource allocation, obtain the basis for adjusting resource allocation, and adjust the task allocation strategy by information matching for the resource differences between standard-level nodes and lightweight nodes, and determine the final task allocation scheme. The adjusted node operating status is obtained, and combined with the updated distribution status data, the node level is dynamically calibrated through information processing to obtain the optimized node distribution status.

[0023] Specifically, a node heterogeneity classification mechanism is established based on the resource constraint assessment results. Nodes are classified into layers according to storage capacity and network bandwidth. This solves the problem in traditional blockchains where lightweight nodes are unable to effectively participate in network consensus due to resource constraints. It achieves accurate identification and optimized resource allocation for nodes at different levels, thereby improving the participation of lightweight nodes and the overall operating efficiency of the system.

[0024] S3. Based on the node layering results, an adaptive consensus weighting algorithm is used to allocate different consensus participation weights. The weight of lightweight nodes is W1 = 0.3 × base weight, and the weight of standard nodes is W2 = 1.0 × base weight. Through weight differentiation, a dynamic participation mechanism that adapts to the heterogeneous characteristics of nodes is obtained. Furthermore, an adaptive consensus weighting algorithm is used to assign different consensus participation weights, specifically including: S31. Obtain node hierarchical data from the node network, determine the node category based on node performance and resource consumption, obtain the hierarchical results of lightweight nodes and standard nodes, and determine the basic weight value by calculating the basic weight of each node and using a preset resource evaluation model. S32. When the node category is a lightweight node, the basic weight is multiplied by 0.3 to obtain the consensus weight of the lightweight node; when the node category is a standard node, the basic weight is multiplied by 1.0 to obtain the consensus weight of the standard node. S33. Through consensus weight allocation, construct an adaptive consensus weight algorithm, generate a dynamic participation mechanism based on weight differentiation, and analyze the participation frequency of nodes in the consensus process based on the execution results of the dynamic participation mechanism to determine the degree of adaptation of node heterogeneity. S34. For nodes whose adaptability is lower than the preset threshold, adjust the consensus weight allocation strategy, use the K-means clustering algorithm to regroup the node performance, obtain the updated node stratification results, recalculate the consensus weight, and repeatedly execute the weight allocation and dynamic participation mechanism to obtain an optimized consensus participation scheme.

[0025] Specifically, by assigning differentiated consensus weights to nodes at different levels through an adaptive consensus weight algorithm, the problem of lightweight nodes being unable to effectively participate in consensus due to resource constraints in traditional blockchains is solved. This achieves a dynamic balance between lightweight nodes and standard nodes in the consensus process, thereby improving the overall performance and resource utilization of the system.

[0026] S4. After obtaining the weight allocation of each node, establish a transaction verification sharding strategy, divide the complete transaction set T into multiple subsets Ti, and lightweight nodes only verify the allocated transaction subsets instead of all transactions. The number of transactions N allocated is determined based on the node's computing power value: N = P / average computational complexity. Furthermore, after obtaining the weight allocation for each node, a transaction verification sharding strategy is established, specifically including: The computing power value of each node is obtained by collecting hardware performance data and current load status through the node monitoring module in the distributed system. The computing power value of each node is then combined with the preset average computational complexity of the transaction to calculate the transaction allocation ratio N, and thus obtain the transaction allocation number for each node. The complete transaction set T is divided into multiple transaction subsets Ti using a partitioning algorithm. When the computing power of a node is higher than a preset threshold, a larger transaction subset Ti is allocated, resulting in a set of partitioned transaction subsets. The allocated transaction subset Ti is obtained through a lightweight node, and the verification algorithm is called to check the legality of the transactions in subset Ti, thus obtaining the verification result. A consistent hashing algorithm is used to map the verification results to the global transaction verification pool. The global transaction verification status is judged. When the global transaction verification status meets the preset consistency conditions, the verified transaction subset Ti is merged into the verification result of the complete transaction set T. Then, the confirmation status is distributed to all nodes through a distributed broadcast mechanism to obtain the network-wide transaction verification consistency.

[0027] Specifically, by establishing a transaction verification sharding strategy, the complete transaction set is divided into multiple subsets, and the transaction subsets are allocated for verification according to the node's computing power. This solves the problem in traditional blockchains where lightweight nodes are unable to independently verify all transactions due to resource constraints. It effectively reduces the computing burden of lightweight nodes, improves transaction verification efficiency, and ensures the consistency of transaction verification across the entire network through a consistent hashing algorithm, thereby improving the performance and scalability of the entire blockchain network.

[0028] S5. Merkle tree aggregation verification technology is used to verify the transaction sharding results. Each node submits the hash value of the local verification result to build a verification tree structure. When the verification of a shard fails, the reallocation and verification process of that shard is triggered to obtain the aggregated verification result of the complete transaction set. Furthermore, the verification results through transaction sharding are validated using Merkle tree aggregation verification technology, specifically including: The complete transaction set is divided into multiple transaction shards using transaction sharding technology. The Merkle tree algorithm is used to calculate the hash value of the local verification result from each transaction shard. A verification tree structure is constructed based on the hash value to generate the root node hash value containing the hashes of all shards. If the hash value of the root node of the verification tree does not match the preset threshold, it is determined that there is a sharding failure, triggering a reallocation process. The failed shard is reallocated to other nodes through a reallocation algorithm to obtain a new local verification result. The verification tree structure is then updated, and the root node hash value is recalculated to obtain the aggregated verification result. This aggregated verification result is then compared with the complete transaction set to determine the final verification result.

[0029] Specifically, by using Merkle tree aggregation verification technology to process the verification results of transaction shards, each node submits the hash value of the local verification result to construct a verification tree structure, and triggers a reallocation and verification process when shard verification fails. This solves the problem in traditional blockchains where lightweight nodes are unable to efficiently complete the verification of the entire transaction set due to resource constraints, effectively improving the efficiency and accuracy of transaction verification, while reducing the computational and storage burden of lightweight nodes and enhancing the performance and reliability of the entire blockchain network.

[0030] S6. Implement a ledger synchronization optimization mechanism based on the aggregated verification results. Lightweight nodes only store block header information and related transaction indexes. The state root hash value S_root is used to verify ledger consistency. When the local state root does not match the network broadcast state root, the incremental synchronization process is triggered. Furthermore, a ledger synchronization optimization mechanism is implemented based on the aggregated verification results, specifically including: Obtain block header information and transaction index from lightweight nodes, calculate the local state root hash value S_root, where S_root is the Merkle tree root hash based on the block header and transaction index, and obtain the local state root hash; The current network state root hash value S_root_net is obtained through network broadcast, where S_root_net is the ledger state root hash of the whole network consensus. The network state root hash is obtained, and a hash value comparison algorithm is used. If the local state root hash S_root does not match the network state root hash S_root_net, the ledger is determined to be inconsistent, and an inconsistent state is obtained. Based on the inconsistency state, an incremental synchronization process is triggered to obtain the missing transaction data and block headers from the network, update the local ledger, obtain the synchronization task, and use the Merkle tree reconstruction algorithm to recalculate the local state root hash S_root_new, where S_root_new is the root hash of the updated ledger, and obtain the new state root hash. When the new state root hash S_root_new matches the network state root hash S_root_net, the ledger is considered consistent, synchronization is completed, and a consistency verification result is obtained. Then, the transaction index and block header information of the lightweight node are updated, and the index storage is optimized using a Bloom filter to obtain the optimized ledger state.

[0031] Specifically, by implementing a ledger synchronization optimization mechanism, lightweight nodes only store block header information and related transaction indexes, and use state root hash values ​​to verify ledger consistency. This solves the problem in traditional blockchains where lightweight nodes are unable to store a complete ledger due to limited storage resources, effectively reducing the storage burden on lightweight nodes. At the same time, the incremental synchronization process ensures ledger consistency and improves the storage efficiency and synchronization speed of the entire blockchain network.

[0032] S7. A dynamic storage management strategy is established using incremental synchronization results. The depth of locally stored historical data D = S / average size of a single block is dynamically adjusted according to the node storage capacity S. Historical block data exceeding the storage limit is stored and retrieved over the network through a distributed hash table.

[0033] Furthermore, a dynamic storage management strategy is established using incremental synchronization results, specifically including: The latest data update status of the nodes is obtained through an incremental synchronization mechanism. The data is sharded using a distributed computing framework to obtain a synchronized data set. The ratio of the storage capacity of each node to the value of a single block is calculated to determine the local storage depth parameter. When the local storage depth parameter exceeds the preset capacity limit, a dynamic storage adjustment process is triggered to obtain the excess block data, determine whether to transfer it to distributed hash table storage, generate corresponding storage index records based on the excess block data, and obtain the network storage mapping relationship. Construct a data retrieval path, use a consistent hashing algorithm to locate the storage location, determine the access entry point for the target data, obtain the corresponding historical data content for the located access entry point, and check the data integrity. When the integrity check passes, the data retrieval process is completed. The storage status of the local node is updated based on the output of the data retrieval process, and the adjusted storage capacity record is generated. The dynamic storage management process is then executed cyclically.

[0034] Specifically, by establishing a dynamic storage management strategy, the depth of locally stored historical data is dynamically adjusted according to the node's storage capacity, and historical block data exceeding the storage limit is stored and retrieved over the network through a distributed hash table. This solves the problem in traditional blockchains where lightweight nodes have limited storage capacity and cannot store complete historical data, effectively improving the storage efficiency and data retrieval speed of lightweight nodes, and enhancing the scalability and flexibility of the entire blockchain network.

[0035] Furthermore, after network storage and retrieval through a distributed hash table, the system also includes: achieving network bandwidth optimization through a distributed storage mechanism; using a differential synchronization protocol between nodes to transmit only the state change increment ΔS rather than the complete state data; and enabling data compression transmission mode when the bandwidth B is below the threshold B_min, thus obtaining an efficient consensus participation scheme adapted to lightweight nodes.

[0036] Furthermore, network bandwidth optimization is achieved through distributed storage mechanisms, specifically including: The state data between nodes is obtained through a distributed storage mechanism, and the state change increment ΔS is calculated, where ΔS represents the difference between the current state and the previous state. The state change increment data is obtained, and the data is encapsulated using a differential synchronization protocol to generate transmission data packets. It is determined that the data packets contain only incremental information. When the network bandwidth B is lower than the preset threshold B_min, a data compression algorithm is applied to the transmitted data packets. The LZ77 algorithm is used to generate compressed data packets, and the compressed data packets are transmitted to the target node through the inter-node communication mechanism. A transmission completion confirmation signal is obtained to confirm that the data transmission was successful. The decompressed state change increment ΔS is obtained from the target node, and distributed to the distributed storage node using a consistent hashing algorithm to obtain the storage allocation result. The local state data of the lightweight node is then updated. The Raft consensus algorithm is used to verify the state consistency among nodes, and a consensus verification result is obtained. If the consensus verification result shows that the states are inconsistent, the state change increment ΔS is recalculated, a new transmission data packet is generated, and node state synchronization is determined.

[0037] Specifically, by using a distributed storage mechanism and differential synchronization protocol, only incremental state changes rather than complete state data are transmitted, and a data compression transmission mode is enabled in low-bandwidth environments. This solves the problem of low data transmission efficiency caused by limited network bandwidth in lightweight nodes in traditional blockchains, effectively improves data transmission efficiency, reduces network resource consumption, enables efficient consensus participation of lightweight nodes in low-bandwidth environments, and enhances the adaptability and performance of the entire blockchain network.

[0038] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A lightweight blockchain node consensus mechanism optimization method, characterized in that: Includes the following steps: A hierarchical verification aggregation algorithm is used to obtain the computing power evaluation value of lightweight nodes. The comprehensive performance index is calculated based on the node's processor frequency and memory size. When the comprehensive performance index is lower than a preset threshold, the node is judged to be a resource-constrained type. Establish a node heterogeneous classification mechanism, construct a node hierarchical matrix based on storage capacity and network bandwidth, and classify nodes by setting thresholds to obtain the node distribution status at different levels; An adaptive consensus weighting algorithm is used to allocate different consensus participation weights, and a dynamic participation mechanism that adapts to the heterogeneous characteristics of nodes is obtained through weight differentiation. After obtaining the weight allocation of each node, a transaction verification sharding strategy is established to divide the complete transaction set into multiple subsets. Lightweight nodes only verify the allocated transaction subsets instead of all transactions, and the number of transactions allocated is determined based on the node's computing power value. The Merkle tree aggregation verification technique is used to verify the transaction sharding results. Each node submits the hash value of the local verification result to build a verification tree structure. When the verification of a shard fails, the reallocation and verification process of that shard is triggered to obtain the aggregated verification result of the complete transaction set. Based on the aggregated verification results, a ledger synchronization optimization mechanism is implemented. Lightweight nodes only store block header information and related transaction indexes. The state root hash value is used to verify ledger consistency. When the local state root does not match the network broadcast state root, an incremental synchronization process is triggered. Establish a dynamic storage management strategy to dynamically adjust the depth of locally stored historical data based on the node's storage capacity. Historical block data exceeding the storage limit is stored and retrieved over the network using a distributed hash table.

2. The lightweight blockchain node consensus mechanism optimization method according to claim 1, characterized in that: A hierarchical verification aggregation algorithm is used to obtain the computational capability evaluation value of lightweight nodes, specifically including: The computing power data of lightweight nodes is obtained through a tiered verification method. Initial data collection is performed on processor frequency and memory capacity. The processor frequency and memory capacity are weighted and calculated using preset weighting coefficients to determine the comprehensive performance index value. The comprehensive performance index value is compared with the preset threshold. If the comprehensive performance index value is lower than the preset threshold, the node is determined to be a resource constraint type. The node data of the resource constraint type is obtained. Combined with the results of hierarchical verification, the performance data of the node is classified and organized using an aggregation method to obtain the classified node performance status. By analyzing the performance status of the classified nodes, we can determine the distribution of resource-constrained nodes in the overall system, identify the proportion of restricted nodes, and use a logistic regression model to predict and analyze node performance to obtain performance trend data for a future period of time. For performance trend data, an optimization scheduling strategy is generated by combining aggregation methods to determine whether the resource allocation is reasonable. If the allocation is uneven, the computing task load of the restricted nodes is adjusted.

3. The lightweight blockchain node consensus mechanism optimization method according to claim 1, characterized in that: A node heterogeneity classification mechanism is established based on resource constraint assessment results, specifically including: Based on the resource constraint assessment results, an initial framework for classifying heterogeneous nodes is constructed using data on storage capacity and network bandwidth. Nodes are initially classified using a hierarchical matrix approach to obtain the distribution status of node levels. The ratio data of lightweight nodes and standard nodes is obtained, and the ratio data is structured to determine the resource distribution characteristics of nodes at different levels. Using pre-established classification rules, the proportion of lightweight nodes in the overall architecture is determined. When the proportion is higher than a preset threshold, the lightweight nodes are marked as resources to obtain the marked node dataset. Detailed resource information of lightweight nodes is obtained from the labeled node dataset. Combined with the constraints of storage capacity and network bandwidth, resource bottlenecks are analyzed through information processing to determine the priority ranking of restricted nodes. A logistic regression model is used to analyze the trend of node resource usage, obtain dynamic change data of resource allocation, obtain the basis for adjusting resource allocation, and adjust the task allocation strategy by information matching for the resource differences between standard-level nodes and lightweight nodes, and determine the final task allocation scheme. The adjusted node operating status is obtained, and combined with the updated distribution status data, the node level is dynamically calibrated through information processing to obtain the optimized node distribution status.

4. The lightweight blockchain node consensus mechanism optimization method according to claim 1, characterized in that: An adaptive consensus weighting algorithm is used to assign different consensus participation weights, specifically including: Node hierarchical data is obtained from the node network. Node categories are determined based on node performance and resource consumption to obtain the hierarchical results of lightweight nodes and standard nodes. The basic weight values ​​are determined by calculating the basic weight of each node and using a preset resource evaluation model. When the node category is a lightweight node, the base weight is multiplied by 0.3 to obtain the consensus weight of the lightweight node; when the node category is a standard node, the base weight is multiplied by 1.0 to obtain the consensus weight of the standard node. By allocating consensus weights, an adaptive consensus weight algorithm is constructed. A dynamic participation mechanism is generated based on weight differentiation. Based on the execution results of the dynamic participation mechanism, the participation frequency of nodes in the consensus process is analyzed to determine the degree of adaptation to the heterogeneous characteristics of nodes. For nodes whose adaptability is below a preset threshold, the consensus weight allocation strategy is adjusted, and the K-means clustering algorithm is used to regroup the node performance to obtain the updated node stratification results. The consensus weight is then recalculated, and the weight allocation and dynamic participation mechanism are executed cyclically to obtain an optimized consensus participation scheme.

5. The lightweight blockchain node consensus mechanism optimization method according to claim 1, characterized in that: After obtaining the weight allocation for each node, a transaction verification sharding strategy is established, which specifically includes: The computing power value of each node is obtained by collecting hardware performance data and current load status through the node monitoring module in the distributed system. The computing power value of each node is then combined with the preset average computational complexity of the transaction to calculate the transaction allocation ratio and obtain the transaction allocation number for each node. A partitioning algorithm is used to divide the complete transaction set into multiple transaction subsets. When the computing power of a node is higher than a preset threshold, a large transaction subset is allocated, resulting in a set of partitioned transaction subsets. The allocated transaction subsets are obtained through lightweight nodes, and a verification algorithm is called to check the legality of the transactions in the subsets to obtain the verification results. A consistent hashing algorithm is used to map the verification results to the global transaction verification pool. The global transaction verification status is judged. When the global transaction verification status meets the preset consistency conditions, the verified transaction subset is merged into the verification result of the complete transaction set. Then, the confirmation status is distributed to all nodes through a distributed broadcast mechanism to obtain the network-wide transaction verification consistency.

6. The lightweight blockchain node consensus mechanism optimization method according to claim 1, characterized in that: The verification results are validated using Merkle tree aggregation technology through transaction sharding, specifically including: The complete transaction set is divided into multiple transaction shards using transaction sharding technology. The Merkle tree algorithm is used to calculate the hash value of the local verification result from each transaction shard. A verification tree structure is constructed based on the hash value to generate the root node hash value containing the hashes of all shards. If the hash value of the root node of the verification tree does not match the preset threshold, it is determined that there is a sharding failure, triggering a reallocation process. The failed shard is reallocated to other nodes through a reallocation algorithm to obtain a new local verification result. The verification tree structure is then updated, the root node hash value is recalculated, and the aggregated verification result is obtained. The aggregated verification result is then compared with the complete transaction set to determine the final verification result.

7. The lightweight blockchain node consensus mechanism optimization method according to claim 1, characterized in that: Based on the aggregated verification results, a ledger synchronization optimization mechanism is implemented, specifically including: Obtain block header information and transaction index from lightweight nodes, calculate the local state root hash value S_root, where S_root is the Merkle tree root hash based on the block header and transaction index, and obtain the local state root hash; The current network state root hash value S_root_net is obtained through network broadcast, where S_root_net is the ledger state root hash of the whole network consensus. The network state root hash is obtained, and a hash value comparison algorithm is used. If the local state root hash S_root does not match the network state root hash S_root_net, the ledger is determined to be inconsistent, and an inconsistent state is obtained. Based on the inconsistency state, an incremental synchronization process is triggered to obtain the missing transaction data and block headers from the network, update the local ledger, obtain the synchronization task, and use the Merkle tree reconstruction algorithm to recalculate the local state root hash S_root_new, where S_root_new is the root hash of the updated ledger, and obtain the new state root hash. When the new state root hash S_root_new matches the network state root hash S_root_net, the ledger is considered consistent, synchronization is completed, and a consistency verification result is obtained. Then, the transaction index and block header information of the lightweight node are updated, and the index storage is optimized using a Bloom filter to obtain the optimized ledger state.

8. The lightweight blockchain node consensus mechanism optimization method according to claim 1, characterized in that: A dynamic storage management strategy is established using incremental synchronization results, specifically including: The latest data update status of the nodes is obtained through an incremental synchronization mechanism. The data is sharded using a distributed computing framework to obtain a synchronized data set. The ratio of the storage capacity of each node to the value of a single block is calculated to determine the local storage depth parameter. When the local storage depth parameter exceeds the preset capacity limit, a dynamic storage adjustment process is triggered to obtain the excess block data, determine whether to transfer it to distributed hash table storage, generate corresponding storage index records based on the excess block data, and obtain the network storage mapping relationship. Construct a data retrieval path, use a consistent hashing algorithm to locate the storage location, determine the access entry point for the target data, obtain the corresponding historical data content for the located access entry point, and check the data integrity. When the integrity check passes, the data retrieval process is completed. The storage status of the local node is updated based on the output of the data retrieval process, and the adjusted storage capacity record is generated. The dynamic storage management process is then executed cyclically.

9. The lightweight blockchain node consensus mechanism optimization method according to claim 8, characterized in that: After network storage and retrieval through a distributed hash table, the process also includes: optimizing network bandwidth through a distributed storage mechanism; using a differential synchronization protocol between nodes to transmit only incremental state changes rather than complete state data; and enabling data compression transmission mode when bandwidth is below a threshold, thus obtaining an efficient consensus participation scheme adapted to lightweight nodes.

10. The lightweight blockchain node consensus mechanism optimization method according to claim 9, characterized in that: Network bandwidth optimization is achieved through distributed storage mechanisms, specifically including: The state data between nodes is obtained through a distributed storage mechanism, and the state change increment is calculated, where represents the difference between the current state and the previous state. The state change increment data is obtained, and the data is encapsulated using a differential synchronization protocol to generate transmission data packets, ensuring that the data packets contain only incremental information. When the network bandwidth is lower than the preset threshold, a data compression algorithm is applied to the transmitted data packets. The LZ77 algorithm is used to generate compressed data packets, and the compressed data packets are transmitted to the target node through the inter-node communication mechanism. A transmission completion confirmation signal is obtained to confirm that the data transmission was successful. The decompressed state change increment is obtained from the target node, and distributed to the distributed storage nodes using a consistent hashing algorithm to obtain the storage allocation result. The local state data of the lightweight node is then updated. The Raft consensus algorithm is used to perform state consistency verification between nodes to obtain consensus verification results. If the consensus verification results show that the states are inconsistent, the state change increment is recalculated, a new transmission data packet is generated, and the node state synchronization is determined.

Images