Transaction data verification method and system

Abstract

The present invention relates to the technical field of transaction data verification, and in particular to a transaction data verification method and system. The method comprises the following steps: collecting transaction data from blockchain network nodes to obtain an original transaction data set; performing adaptive heterogeneous sharding on the original transaction data set to obtain a sharded transaction data set; performing verification weight coefficient allocation on the sharded transaction data set to obtain a weighted sharded transaction data set; performing multi-level verification engine deployment on the verification node to obtain a hierarchical verification node network; performing asynchronous message queue mechanism configuration on the hierarchical verification node network to obtain a parallel verification network cluster; performing load balancing scheduling on the weighted sharded transaction data set based on the parallel verification network cluster to obtain a transaction verification task sequence. The present invention can effectively improve the throughput and transaction confirmation speed of the blockchain system.

Description

Technical Field

[0001] The present invention relates to the technical field of transaction data verification, and in particular to a transaction data verification method and system. Background Art

[0002] In the field of modern financial transactions, data accuracy and security are crucial, and data has become an important production factor. A large amount of transaction data needs to be processed and verified in a very short time to ensure the legitimacy and validity of the transaction. However, existing transaction data verification methods often face the challenges of large data volumes and low verification efficiency.

[0003] In terms of the application of blockchain technology and transaction data verification, although its distributed ledger characteristics provide certain guarantees for the immutability and transparency of transaction data, the existing blockchain system still faces performance bottlenecks when processing large-scale transaction data. Especially in high-concurrency transaction scenarios, the throughput and confirmation speed of the blockchain network often cannot meet actual needs. This problem is particularly evident in the network module. In the network module, bandwidth and latency form the basis of the throughput and final deterministic latency of the blockchain system. The bandwidth requirements of the network facility layer increase with the development of blockchain technology, while latency has an optimization limit, namely the speed of light. The node connection layer realizes message broadcasting in the network through communication between neighboring nodes. Its bandwidth and latency are related to the number of nodes. The more nodes, the higher the latency. The broadcast protocol layer defines specific block and transaction forwarding rules. The bandwidth mainly depends on how to reduce redundant transmission, while the latency will be amplified by the consensus protocol, affecting the final confirmation of the transaction. Summary of the invention

[0004] Based on this, it is necessary for the present invention to provide a transaction data verification method and system to solve at least one of the above technical problems.

[0005] To achieve the above purpose, a transaction data verification method includes the following steps:

[0006] Step S1: collect transaction data from blockchain network nodes to obtain an original transaction data set; perform adaptive heterogeneous sharding on the original transaction data set to obtain a sharded transaction data set; perform verification weight coefficient allocation on the sharded transaction data set to obtain a weighted sharded transaction data set;

[0007] Step S2: deploy a multi-level verification engine on the verification node to obtain a hierarchical verification node network; configure an asynchronous message queue mechanism on the hierarchical verification node network to obtain a parallel verification network cluster;

[0008] Step S3: Based on the parallel verification network cluster, load balancing scheduling is performed on the weighted sharded transaction data set to obtain a transaction verification task sequence; verification routing allocation is performed on the weighted sharded transaction data set according to the transaction verification task sequence to obtain a transaction verification routing allocation table;

[0009] Step S4: Calculate the reputation score of the verification node to obtain a node reputation score matrix; perform reputation propagation and diffusion on the verification node according to the node reputation score matrix to obtain a global node reputation set; perform weighted consensus voting verification on the global node reputation set to obtain a consensus verification node reputation set;

[0010] Step S5: Perform distributed parallel verification on the weighted sharded transaction data set according to the transaction verification routing allocation table to obtain a preliminary verification transaction data set; perform consistency proof on the preliminary verification transaction data set according to the consensus verification node reputation set to obtain a final verification transaction data set.

[0011] The present invention can effectively process large-scale transaction data through adaptive heterogeneous sharding and distributed parallel verification, improve the throughput and confirmation speed of the blockchain system in high-concurrency scenarios, and solve the performance bottleneck problem faced by the existing system. By assigning verification weight coefficients to transaction data sets, resources can be reasonably allocated according to the importance and complexity of transaction data, and optimal utilization of resources can be achieved to improve system efficiency. Through the deployment of multi-level verification engines and the configuration of asynchronous message queue mechanisms, network changes and transaction requirements can be quickly responded to, and the flexibility and response speed of the system are improved. Through the reputation scoring mechanism and weighted consensus voting verification, verification nodes with high reputation can be identified and screened, thereby improving the accuracy of transaction verification and enhancing the system's defense capabilities against malicious attacks. Through load balancing scheduling and verification routing allocation, the redundancy and unnecessary delay of message transmission can be reduced, the final confirmation of transactions can be accelerated, and the final certainty of transactions can be improved. Through optimized broadcast protocols and consensus protocols, redundant transmission in network communications is reduced, delays are reduced, and the efficiency of network communications is improved. Through the zero-knowledge proof mechanism, the consistency and integrity of transaction data can still be guaranteed in the presence of malicious nodes. By constructing a global node reputation set and generating a consensus verification node reputation set, participants can more transparently understand the reputation status of nodes in the network, thereby improving the trust of the entire system. In summary, the present invention can effectively improve the throughput and transaction confirmation speed of the blockchain system.

[0012] Preferably, the present invention further provides a transaction data verification system for executing the transaction data verification method as described above, the transaction data verification system comprising:

[0013] The data sharding module is used to collect transaction data from blockchain network nodes to obtain the original transaction data set; perform adaptive heterogeneous sharding on the original transaction data set to obtain the sharded transaction data set; perform verification weight coefficient allocation on the sharded transaction data set to obtain the weighted sharded transaction data set;

[0014] The verification engine deployment module is used to deploy multi-level verification engines on verification nodes to obtain a hierarchical verification node network; configure an asynchronous message queue mechanism on the hierarchical verification node network to obtain a parallel verification network cluster;

[0015] A routing allocation module is used to perform load balancing scheduling on the weighted sharded transaction data set based on a parallel verification network cluster to obtain a transaction verification task sequence; perform verification routing allocation on the weighted sharded transaction data set according to the transaction verification task sequence to obtain a transaction verification routing allocation table;

[0016] The consensus verification module is used to calculate the reputation score of the verification node to obtain the node reputation score matrix; to spread the reputation of the verification node according to the node reputation score matrix to obtain the global node reputation set; to perform weighted consensus voting verification on the global node reputation set to obtain the consensus verification node reputation set;

[0017] The parallel verification module is used to perform distributed parallel verification on the weighted sharded transaction data set according to the transaction verification routing allocation table to obtain a preliminary verification transaction data set; and to perform consistency proof on the preliminary verification transaction data set according to the consensus verification node reputation set to obtain a final verification transaction data set.

[0018] The present invention can effectively divide a large amount of transaction data into multiple small data sets through the adaptive heterogeneous sharding of the data sharding module, thereby improving the speed and efficiency of data processing. The verification engine deployment module enhances the security of data verification through the multi-level verification engine and asynchronous message queue mechanism, and ensures the integrity and accuracy of the data during transmission and processing. By assigning verification weight coefficients to the sharded transaction data set, resources can be intelligently allocated according to the importance and complexity of the data to achieve optimal utilization of resources. The routing allocation module ensures the uniform distribution of transaction verification tasks and improves the throughput of the system through load balancing scheduling and verification routing allocation. The consensus verification module screens out verification nodes with high credibility through reputation scoring and weighted consensus voting verification, enhances the system's defense capability against malicious attacks, and improves the robustness of the system. The parallel verification module ensures the consistency of transaction data and prevents double-spending attacks through distributed parallel verification and consistency proof. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Other features, objects and advantages of the present invention will become more apparent from the detailed description made with reference to the following drawings:

[0020] Figure 1 A schematic flow chart of the steps of a transaction data verification method according to an embodiment is shown.

[0021] Figure 2 A detailed flowchart diagram of step S176 of an embodiment is shown.

[0022] Figure 3 A detailed flow chart of step S28 of an embodiment is shown. DETAILED DESCRIPTION

[0023] The technical method of the present invention is described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by technicians in this field without creative work are within the scope of protection of the present invention.

[0024] In addition, the accompanying drawings are only schematic illustrations of the present invention and are not necessarily drawn to scale. The same reference numerals in the figures represent the same or similar parts, and their repeated description will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. The functional entities can be implemented in software form, or implemented in one or more hardware modules or integrated circuits, or implemented in different networks and / or processor methods and / or microcontroller methods.

[0025] It should be understood that, although the terms "first", "second", etc. may be used herein to describe various units, these units should not be limited by these terms. These terms are used only to distinguish one unit from another unit. For example, without departing from the scope of the exemplary embodiments, the first unit may be referred to as the second unit, and similarly the second unit may be referred to as the first unit. The term "and / or" used herein includes any and all combinations of one or more of the listed associated items.

[0026] To achieve this, please refer to Figures 1 to 3 The present invention provides a transaction data verification method, comprising the following steps:

[0027] Step S1: collect transaction data from blockchain network nodes to obtain an original transaction data set; perform adaptive heterogeneous sharding on the original transaction data set to obtain a sharded transaction data set; perform verification weight coefficient allocation on the sharded transaction data set to obtain a weighted sharded transaction data set;

[0028] Step S2: deploy a multi-level verification engine on the verification node to obtain a hierarchical verification node network; configure an asynchronous message queue mechanism on the hierarchical verification node network to obtain a parallel verification network cluster;

[0029] Step S3: Based on the parallel verification network cluster, load balancing scheduling is performed on the weighted sharded transaction data set to obtain a transaction verification task sequence; verification routing allocation is performed on the weighted sharded transaction data set according to the transaction verification task sequence to obtain a transaction verification routing allocation table;

[0030] Step S4: Calculate the reputation score of the verification node to obtain a node reputation score matrix; perform reputation propagation and diffusion on the verification node according to the node reputation score matrix to obtain a global node reputation set; perform weighted consensus voting verification on the global node reputation set to obtain a consensus verification node reputation set;

[0031] Step S5: Perform distributed parallel verification on the weighted sharded transaction data set according to the transaction verification routing allocation table to obtain a preliminary verification transaction data set; perform consistency proof on the preliminary verification transaction data set according to the consensus verification node reputation set to obtain a final verification transaction data set.

[0032] In this embodiment, the blockchain API, such as Web3.py or Ethereum's JSON-RPC, is first used to collect transaction data on network nodes to obtain the original transaction data set. A distributed database, such as Apache Cassandra, is used to store this data. Next, an adaptive heterogeneous sharding technology is used to process the original transaction data set. The data is divided into multiple shards according to the feature vector of the transaction, and each shard contains similar transaction types. The scikit-learn library of Python is used to implement this process, and the size and complexity of each shard are ensured to be moderate. Then, the verification weight coefficient is assigned to the shard transaction data set. Based on the historical transaction data and verification results, a neural network model is used to predict the verification weight of each shard. This model is built using TensorFlow, and the relationship between different transaction features and verification difficulty is learned through training. Different verification strategies are configured on multiple nodes to form a hierarchical verification node network. Containerization technologies, such as Docker and Kubernetes, are used to simplify the deployment and expansion of the verification engine. In the parallel verification network cluster, the RabbitMQ message queue is configured to implement asynchronous communication to ensure that the verification tasks can be efficiently distributed and processed in the network. The flexible routing function of RabbitMQ is used to implement complex verification task allocation logic. Based on the parallel verification network cluster, load balancing technology, such as HAProxy, is used to schedule the weighted sharded transaction data set and generate a transaction verification task sequence. Verification tasks are assigned according to the task sequence and node performance score to ensure high efficiency and load balancing. The reputation score of the verification node is calculated, and the Python Pandas library is used to analyze the verification history and performance indicators of the node to obtain the node reputation score matrix. Then, graph theory algorithms, such as PageRank, are applied to simulate the propagation and diffusion of reputation to obtain the global node reputation set. Next, the global node reputation set is verified by weighted consensus voting. Using blockchain technology, a smart contract is built to implement the voting mechanism, and nodes vote on the transaction verification results according to their reputation scores. Smart contracts are written in Solidity and deployed on the Ethereum platform. Finally, the weighted sharded transaction data set is verified in distributed parallel according to the transaction verification routing allocation table to obtain a preliminary verification transaction data set. Then, the preliminary verification transaction data set is proved to be consistent according to the consensus verification node reputation set, and encryption algorithms, such as Merkle trees, are used to finally obtain a verified transaction data set.

[0033] Preferably, step S1 comprises the following steps:

[0034] Step S11: collect transaction data from blockchain network nodes to obtain an original transaction data set;

[0035] Specifically, a data collector can be deployed that can connect to multiple nodes of the blockchain network and monitor transaction activities on these nodes in real time. Whenever a new transaction is broadcast to the network, the data collector captures the transaction information and stores it in a temporary buffer. The data in the buffer is periodically written in batches to a central database. In this process, message queues (such as Kafka) are used to process data streams, and distributed databases (such as Cassandra) are used to store raw transaction data sets.

[0036] Step S12: extracting multidimensional feature vectors from the original transaction data set to obtain a transaction feature vector set; wherein the multidimensional feature vector extraction includes transaction type identification vector extraction, geographic space coordinate vector extraction, timestamp vector extraction, transaction amount vector extraction and transaction account attribute vector extraction;

[0037] Specifically, a feature extraction framework can be defined that can identify different features in transaction data and convert them into vector form. For example, for transaction type identification vector extraction, a predefined dictionary is used to map the transaction type (such as purchase, sale, transfer, etc.) to a unique numerical vector. Geospatial coordinate vector extraction involves converting the geographical location (such as longitude and latitude) where the transaction occurred into a vector. Timestamp vector extraction converts the time information of the transaction (such as the date and time of the transaction) into a vector, which can be used to analyze the time distribution characteristics of the transaction. Transaction amount vector extraction converts the transaction amount into a vector, which can be used to identify large transactions or abnormal transaction patterns. Finally, transaction account attribute vector extraction involves converting the account information involved in the transaction (such as account type, account age, etc.) into a vector, and finally, a transaction feature vector set is obtained.

[0038] Step S13: quantifying the feature similarity of the original transaction data set according to the transaction feature vector set to obtain the number of transaction data shards;

[0039] Specifically, a clustering algorithm, such as the K-means algorithm, can be used to process the set of transaction feature vectors. The K-means algorithm groups feature vectors into different clusters based on their similarity. To determine the optimal number of clusters (i.e., the number of shards), the Elbow Method can be used, which evaluates the compactness of clusters by calculating the total internal sum of squares (SSE) under different numbers of clusters. Specifically, write a script to implement this process using the KMeans class in Python's scikit-learn library. The script iterates over different K values ​​(the number of clusters), calculates the SSE for each K value, and plots a graph of SSE vs. K value. By observing the "elbow" position of the curve, determine a suitable K value that corresponds to the optimal number of shards (the number of transaction data shards), that is, the point where adding more clusters does not significantly reduce the SSE.

[0040] Step S14: Initially sharding the original transaction data set according to the number of transaction data shards to obtain an initial sharded transaction data set;

[0041] Specifically, it can be assumed that the transaction data has been determined to be divided into 5 shards. Use a clustering algorithm (such as K-means) to cluster the feature vector set, and assign the data in each cluster to a shard. Specifically, read the original transaction data set and cluster the data using the previously trained KMeans model. Each transaction record is assigned to a specific cluster (i.e., shard) based on its feature vector. After clustering is completed, the initial sharded transaction data set is finally formed.

[0042] Step S15: performing internal similarity calculation on the initial shard transaction data set to obtain intra-shard similarity data, and performing inter-shard difference calculation on the initial shard transaction data set to obtain inter-shard difference data;

[0043] Specifically, you can use metrics such as cosine similarity or Euclidean distance to calculate intra-shard similarity. For example, use the pairwise_distances function in Python's scikit-learn library to calculate the distance between all transaction feature vectors in each shard. This function returns a distance matrix in which each element represents the distance between two transaction vectors. The average similarity within the shard (intra-shard similarity data) is obtained by calculating the average value of this matrix. For the calculation of inter-shard differences, the pairwise_distances function is also used, but this time the distance between transaction vectors of different shards is calculated. Randomly select some samples in each shard, and then calculate the average distance between these samples and the samples in another shard. In this way, inter-shard difference data can be obtained.

[0044] Step S16: adjusting the shard boundary of the initial shard transaction data set according to the intra-shard similarity data and the inter-shard difference data to obtain transaction shard boundary data, and reconstructing the boundary of the initial shard transaction data set according to the transaction shard boundary data to obtain the shard transaction data set;

[0045] Specifically, a cohesion threshold can be defined. If the similarity within a shard is lower than this threshold, it is considered that the shard needs further refinement. Use optimization algorithms, such as spectral clustering, to adjust the boundaries of the shards. Spectral clustering is a clustering method based on graph theory that uses the eigenvectors of the Laplacian matrix of the graph for clustering. Use the SpectralClustering class in Python's scikit-learn library to implement this process. Input the intra-shard similarity matrix and the inter-shard difference matrix, and then the algorithm will output a new shard boundary data. Based on these new boundary data, redistribute transaction records to the corresponding shards to obtain a shard transaction data set with reconstructed boundaries.

[0046] Step S17: Verify the weight coefficient allocation of the shard transaction data set to obtain a weighted shard transaction data set.

[0047] Specifically, please refer to the sub-steps of step S17 for the detailed implementation process of this embodiment.

[0048] The present invention can understand and manage data more meticulously and improve the pertinence and effectiveness of data processing by extracting multidimensional feature vectors from transaction data. The sharding strategy based on feature similarity quantification and internal similarity calculation can ensure the rationality and efficiency of data sharding. By calculating the cohesion of shards and the difference between shards, the shard boundaries can be adjusted more accurately to ensure that the data within each shard is highly correlated and the shards are as independent as possible. The allocation of verification weight coefficients takes into account the importance of data and the difficulty of verification, which helps to allocate appropriate resources and attention during the data verification process and enhances the security of the entire system. Unnecessary computing and communication overhead can be reduced through reasonable data sharding and weight allocation. Through precise sharding and weight allocation, the data verification process can be completed faster, reducing the delay in data processing.

[0049] Preferably, step S17 comprises the following steps:

[0050] Step S171: collect verified transaction data from blockchain network nodes to obtain a verified transaction data set, and collect transaction features from the verified transaction data set to obtain a historical transaction feature data set;

[0051] Specifically, the API interface provided by the blockchain can be used to obtain verified transaction records. Use Python's requests library to send HTTP requests to these API interfaces and obtain transaction data. The acquired data includes transaction hash, timestamp, sender and receiver addresses, transaction amount, etc. Then, use data analysis tools, such as Python's pandas library, to process this data and extract transaction features from it, such as transaction amount, transaction frequency, account type involved, etc. These features are organized into a historical transaction feature dataset.

[0052] Step S172: Identify key factors of the historical transaction feature data set to obtain a transaction verification key factor set; wherein the key factor identification includes transaction complexity factor identification, computing resource consumption factor identification, verification delay factor identification, historical verification success rate factor identification and transaction priority factor identification;

[0053] Specifically, five key factors can be defined first: transaction complexity factor, computing resource consumption factor, verification delay factor, historical verification success rate factor, and transaction priority factor. The decision tree or random forest algorithm in Python's scikit-learn library is used to evaluate the transaction complexity factor. This algorithm can evaluate the complexity of the transaction based on factors such as the number of accounts involved in the transaction, the amount of the transaction, and the frequency of the transaction. For the computing resource consumption factor, it is necessary to analyze the number of computational steps required for transaction execution, which can be achieved by analyzing the smart contract code (if applicable) or using the blockchain's virtual machine (such as Ethereum's EVM). The verification delay factor can be determined by analyzing the time difference from the transaction being submitted to being verified. The historical verification success rate factor can be obtained by counting the success rate of past transaction verifications, which can be achieved by querying the historical data of the blockchain network. Finally, the transaction priority factor can be determined based on factors such as the size of the transaction amount and the reputation of the transaction initiator. Use multivariate analysis methods, such as principal component analysis (PCA), to synthesize these factors and finally obtain a set of key factors for transaction verification.

[0054] Step S173: Quantitative feature modeling is performed on the transaction verification key factor set to obtain a historical transaction verification feature vector set;

[0055] Specifically, Python's pandas library can be used to manage and preprocess data. For each factor in the transaction verification key factor set, the following steps are performed: 1. Transaction complexity factor: This involves the number of inputs and outputs involved in the transaction, the transaction byte size, etc. Calculate the average number of inputs and outputs for each transaction and use it as a feature. 2. Computational resource consumption factor: This is based on the number of computational steps required for transaction execution. For example, for transactions involving smart contracts, the resource consumption is estimated based on the complexity of the contract code. 3. Verification delay factor: This involves the time from the submission of a transaction to its verification. Calculate the average verification time of the transaction and use it as a feature. 4. Historical verification success rate factor: This is based on the success or failure of past transaction verifications. Count the success rate of each transaction type and use it as a feature. 5. Transaction priority factor: This is based on the size of the transaction amount, the reputation of the transaction initiator, etc. Assign higher priority values ​​to large transactions or initiators with high reputation. Next, use the PolynomialFeatures class in the scikit-learn library to generate polynomial combination features of these factors. For example, for the transaction complexity factor, generate its square and cubic terms to capture more complex relationships. Use the SelectKBest class and apply statistical tests such as chi-squared test, mutual information, or ANOVA F-value. Keep the most influential features while removing redundant or unimportant features. For example, suppose you have the following data: Transaction complexity factor: Transaction A has 3 inputs and Transaction B has 5 inputs.

[0056] Computational resource consumption factor: Transaction A consumes 100 computing units, and Transaction B consumes 200 computing units.

[0057] Verification delay factor: The verification time for transaction A is 10 seconds, and for transaction B it is 20 seconds.

[0058] Historical verification success rate factor: The success rate of transaction type A is 95%, and that of transaction type B is 90%.

[0059] Transaction priority factor: Transaction A has a high priority, and Transaction B has a medium priority.

[0060] This generates the following feature vector:

[0061] The feature vector of transaction A is [3, 9, 10, 0.95, 1]

[0062] The feature vector of transaction B is [5, 25, 20, 0.90, 0.5]

[0063] Among them, the elements of each vector correspond to transaction complexity, square of complexity, verification delay, historical success rate and priority factor respectively.

[0064] Step S174: using the historical transaction verification feature vector set to perform neural network feature mapping on the transaction verification key factor set to obtain a historical verification feature weight mapping matrix;

[0065] Specifically, a deep learning framework, such as TensorFlow or PyTorch, can be used to build a neural network model. First, define the structure of the neural network, including the input layer (input historical transaction verification feature vector set), hidden layer (enough neurons to capture the complex relationship between features), and output layer (output weights of each key factor). Use the back propagation algorithm to train the neural network and adjust the network weights by minimizing the loss function of the prediction error (such as mean square error). After training, the neural network is able to map the input feature vector to a weight vector that represents the importance of each key factor in the transaction verification process, that is, the historical verification feature weight mapping matrix.

[0066] Step S175: determining the weight range of the transaction verification key factor set according to the historical verification feature weight mapping matrix to obtain the transaction verification feature weight range set;

[0067] Specifically, data analysis tools (such as Python's numpy library) can be used to process the historical verification feature weight mapping matrix and calculate the minimum and maximum values ​​of each key factor, which will define the range of weights. Then, statistical methods, such as calculating the percentiles of each factor weight (for example, the 25th percentile and the 75th percentile), are used to further refine these ranges to ensure that they reflect the distribution characteristics of the data. In addition, the knowledge of domain experts can be introduced to adjust these ranges to ensure that they make sense in actual operations. Finally, a set of transaction verification feature weight ranges is obtained, which defines a reasonable interval for the weight of each key factor during the verification process.

[0068] Step S176: Use the historical verification feature weight mapping matrix and the transaction verification feature weight range set to perform verification weight training on the preset weighted neural network architecture to obtain a verification weight prediction model, and use the verification weight prediction model to assign verification weight coefficients to the sharded transaction data set to obtain a weighted sharded transaction data set.

[0069] Specifically, please refer to the sub-steps of step S176 for the detailed implementation process of this embodiment.

[0070] The present invention can optimize the verification process based on actual transaction patterns and historical performance by collecting verified transaction data and extracting historical transaction features, thereby improving the accuracy and reliability of verification. By using neural networks to perform feature mapping and weight training on key factors of transaction verification, verification weights can be intelligently assigned to different transaction data to ensure that resources are preferentially allocated to key and complex transactions. By considering factors such as transaction complexity, resource consumption, and verification delay, computing resources can be more reasonably allocated to avoid wasting resources on low-priority transactions. By assigning verification weight coefficients to transaction data sets through a predictive model, transactions that have a greater impact on system performance can be quickly identified and prioritized, thereby improving the efficiency of transaction processing. By using a weighted neural network architecture for verification weight training, not only can historical data be learned, but also verification requirements for future transactions can be predicted. By considering factors such as historical verification success rate and transaction priority, stable performance can be maintained when facing different types of transactions, enhancing the robustness of the system when facing abnormal transactions or attacks.

[0071] Preferably, step S176 includes the following steps:

[0072] Step S1761: Use the historical verification feature weight mapping matrix and the transaction verification feature weight range set to perform verification weight training on the preset weighted neural network architecture to obtain a verification weight prediction model;

[0073] Specifically, deep learning frameworks such as TensorFlow or PyTorch can be used to define the structure of the neural network. The network includes an input layer, several hidden layers, and an output layer. The number of nodes in the input layer matches the dimension of the historical verification feature weight mapping matrix, and the number of nodes in the output layer matches the size of the transaction verification key factor set. The ReLU activation function is used to increase the nonlinear expression ability of the network, and batch normalization is used to accelerate the training process. The mean square error (MSE) is selected as the loss function, and Adam is selected as the optimizer. The network is trained by taking the historical verification feature weight mapping matrix as input and the transaction verification feature weight range set as constraints. During the training process, the loss on the validation set is monitored to avoid overfitting, and the Early Stopping method is used to determine the optimal number of training rounds. After the training is completed, the validation weight prediction model is finally obtained.

[0074] Step S1762: extract key factor feature tensors from the shard transaction data set according to the transaction verification key factor set to obtain a shard transaction feature factor vector set;

[0075] Specifically, the set of key factors for transaction verification includes transaction complexity, computing resource consumption, verification latency, historical verification success rate, and transaction priority. Use feature extraction techniques, such as principal component analysis (PCA) or autoencoders, to extract feature tensors of these key factors from the sharded transaction dataset. For example, use the PCA class in Python's scikit-learn library to reduce the dimensionality of the data while retaining the most important features. For more complex features, such as transaction complexity, customize the feature extraction logic, which involves analyzing the structure of the transaction, the smart contract code involved, etc. Combine these extracted features into a feature tensor, each of which corresponds to a key factor for transaction verification. These feature tensors form a set of sharded transaction feature factor vectors.

[0076] Step S1763: Use the verification weight prediction model to perform weight prediction mapping on the shard transaction feature factor vector set and the shard transaction data set to obtain an initial weight allocation matrix;

[0077] Specifically, the vector set of shard transaction feature factors can be passed as input to the verification weight prediction model. The model will output a weight vector that represents the relative importance of each transaction feature factor. These outputs are collected and the weight vectors are matched with the corresponding transaction data in the shard transaction dataset to form an initial weight assignment matrix, where each row corresponds to a transaction and each column corresponds to the weight of a feature factor.

[0078] Step S1764: Perform Gaussian kernel smoothing on the initial weight distribution matrix to obtain a smoothed weight distribution matrix;

[0079] Specifically, Gaussian kernel smoothing can be implemented using the gaussian_filter function in Python's scipy library. First, the initial weight assignment matrix is ​​treated as a two-dimensional array, and then Gaussian kernel smoothing is applied. Before applying the Gaussian kernel, select an appropriate kernel size (i.e., the standard deviation of the Gaussian filter) and kernel width. The choice of kernel size depends on the degree of smoothing desired. A larger kernel size will result in smoother results, but will blur important features. After applying Gaussian kernel smoothing, a smoothed weight assignment matrix is ​​obtained. Each element in this matrix is ​​obtained by weighted averaging of adjacent elements in the initial matrix, and the weight is determined by the Gaussian function.

[0080] Step S1765: Perform hierarchical weight balancing calibration on the smoothed weight distribution matrix based on the sharded transaction data set to obtain a balanced weight distribution matrix;

[0081] Specifically, different levels of weight calibration strategies can be defined, for example, based on the transaction amount, transaction frequency, or reputation level of transaction participants. Use Python's pandas library to process the smoothed weight assignment matrix and adjust the weights according to the defined hierarchical strategy. For example, for large transactions, increase their weights, while for transactions initiated by participants with lower reputation levels, reduce their weights. This calibration process involves weighted averaging, analytic hierarchy process (AHP), or other multi-criteria decision-making methods. In this way, a balanced weight assignment matrix can be obtained.

[0082] Step S1766: weight embedding is performed on the balanced weight distribution matrix and the shard transaction data set to obtain a weighted shard transaction data set.

[0083] Specifically, Python's pandas library can be used to process the balanced weight distribution matrix and the sharded transaction dataset. First, make sure that the primary keys of the two datasets (for example, transaction ID) are consistent, so that the weight matrix can be aligned with the transaction dataset through the merge function. Then, each row of the weight matrix is ​​merged with the corresponding transaction data record to form a new data frame that contains the original transaction data and the weight of each transaction feature. This new data frame is the weighted sharded transaction dataset. Finally, a dataset containing transaction data and corresponding weights (weighted sharded transaction dataset) is obtained.

[0084] The present invention can accurately predict the verification weight of transaction data by training a weighted neural network model, which helps to allocate system resources more accurately and improve verification efficiency. The extraction of key factor feature tensors deepens the understanding of transaction data, making the weight distribution more in line with the actual characteristics and needs of transaction data. The initial weight distribution matrix obtained by using the verification weight prediction model provides a reasonable starting point based on historical data and feature analysis for the transaction data set. The initial weights are smoothed by Gaussian kernels, reducing the impact of outliers and making the weight distribution more stable and continuous. The hierarchical weight balance calibration ensures that the weight distribution can meet the characteristics of transaction data at different levels, enhancing the fairness and effectiveness of weight distribution. Weight embedding enables the sharded transaction data set to be processed according to its importance and complexity, improving the pertinence and efficiency of data processing.

[0085] Preferably, step S2 comprises the following steps:

[0086] Step S21: deploying a field verification engine on the verification node to obtain basic verification configuration data, and configuring a signature verification cache on the verification node to obtain signature verification configuration data;

[0087] Specifically, you can use the software development kit (SDK) provided by the blockchain platform to develop a field verification engine. For example, with blockchain, use the Web3.py library to interact with smart contracts. Write a script for each verification node that defines the fields that need to be verified, such as transaction amount, sender and receiver addresses, etc. Then, use this script to deploy the verification engine on each verification node, which involves running a background service that listens to transactions on the node and ensuring that it can access the blockchain network. Next, configure the signature verification cache, which involves setting up a data storage system, such as Redis or Memcached, to temporarily store and quickly retrieve transaction signature verification results. Expiration policies and memory management rules are defined for this cache system to ensure that it does not grow indefinitely. After completing these configurations, you will eventually get the basic verification configuration data and signature verification configuration data.

[0088] Step S22: configure the timeout retry mechanism for the verification node to obtain timeout retry configuration data, and record the basic verification configuration data, signature verification configuration data and timeout retry configuration data as edge verification layer configuration data;

[0089] Specifically, you can define a timeout retry strategy, which includes setting a timeout threshold (for example, if a transaction is not verified within 60 seconds, the retry mechanism is triggered) and the number of retries (for example, a maximum of 3 retries). Use a programming language (such as Python) to implement this mechanism by writing a function to encapsulate the verification request and automatically retry when the request times out. Use exception handling to capture timeout errors, and use loops or recursive logic to implement retries. After completing the configuration of the timeout retry mechanism, combine these configuration data with the basic verification configuration data and signature verification configuration data. Use a configuration management database or distributed configuration system (such as etcd or Apache ZooKeeper) to store and manage these configuration data. In this way, each verification node can access and apply these configurations, forming the edge verification layer configuration data.

[0090] Step S23: elastically expand and contract the capacity of the verification node cluster to obtain node cluster capacity configuration data, and deploy a parallel verification framework on the verification node cluster to obtain business verification configuration data;

[0091] Specifically, you can use the automatic expansion function of the cloud service provider, such as Amazon Web Services' AutoScaling or Kubernetes' Horizontal Pod Autoscaler, to configure the elastic expansion and contraction of the verification node cluster. Set thresholds based on performance indicators such as CPU utilization, memory utilization, or queue length to automatically increase or decrease the number of nodes. Next, deploy a parallel verification framework, which involves using message queues (such as RabbitMQ or Kafka) to distribute verification tasks, and using parallel processing libraries (such as Python's concurrent.futures module) to process these tasks in parallel. Write a configuration script to set the message queue and parallel processing parameters, and store this configuration data in the configuration management database so that all nodes in the cluster can access it. After completing these steps, you will finally get the node cluster capacity configuration data and business verification configuration data.

[0092] Step S24: constructing a verification result cache pool for the verification node to obtain verification result cache configuration data;

[0093] Specifically, you can use a high-performance cache system, such as Redis, to build a verification result cache pool for the verification node to store the verification results. First, install and configure the Redis server, set the appropriate memory size, persistence strategy, and backup strategy. Then, write the client code and use Redis's Python client library redis-py to implement the storage and retrieval of verification results. Generate a unique key for each transaction and store its verification result as a value in Redis. Set the expiration time of the key to ensure that the cache does not grow indefinitely. Use Redis's hash table data structure to store the verification results of each transaction, and use pipelining technology to batch process requests. After completing these configurations, you will finally get the verification result cache configuration data.

[0094] Step S25: Determine the cross-region verification task scheduling strategy for the verification node, obtain the verification task scheduling configuration data, and record the node cluster capacity configuration data, business verification configuration data, verification result cache configuration data and verification task scheduling configuration data as regional verification layer configuration data;

[0095] Specifically, you can use distributed monitoring systems, such as Prometheus and Grafana, to collect performance data of validation nodes in each region, including response time and load. Based on this data, use scheduling algorithms, such as minimum response time priority or load balancing algorithms, to determine which region's nodes each validation task should be assigned to. Use a task scheduling framework, such as Apache Kafka or Apache Mesos, to manage the assignment of tasks. Configure a scheduler instance for each region, which is responsible for listening to the task queue and assigning tasks to the best nodes in the region according to the preset strategy. Use JSON or YAML format to define scheduling configuration data, including task assignment rules, node selection criteria, and failover mechanisms. Next, integrate the node cluster capacity configuration data, business validation configuration data, validation result cache configuration data, and the newly determined validation task scheduling configuration data. Use configuration management tools, such as Ansible, Chef, or Puppet, to automate the distribution and update process of these configuration data. These tools can ensure that all relevant components and nodes receive the latest configurations and execute tasks according to these configurations. Finally, all these configuration data are recorded in a centralized configuration repository, such as a Git repository or a distributed configuration service (such as Spring Cloud Config or Consul), which obtains the regional validation layer configuration data.

[0096] Step S26: Deploy an atomic verification engine for cross-shard transactions of the verification node to obtain atomic verification configuration data, and construct a special transaction dedicated verification pipeline for the verification node to obtain dedicated verification pipeline configuration data, and record the atomic verification configuration data and the dedicated verification pipeline configuration data as core verification layer configuration data;

[0097] Specifically, you can use a smart contract programming language (such as Solidity for Ethereum) to develop an atomic verification engine that ensures that cross-shard transactions are either fully executed or not executed at all in all relevant shards to maintain transaction consistency. Deploy this engine on the verification node, use the blockchain platform's SDK (such as Web3.py) to interact with the blockchain, and ensure that each node is able to execute the verification logic in the smart contract. Next, build a dedicated verification pipeline for special transaction types (for example, transactions involving large asset transfers or requiring special permissions). This involves developing specific verification logic and setting up special processing flows such as multi-signature verification. Use workflow management tools (such as Apache Airflow) to design and monitor these dedicated verification pipelines to ensure that they can be executed according to the predetermined steps. After deploying the atomic verification engine and dedicated verification pipeline, you can get atomic verification configuration data and dedicated verification pipeline configuration data. Integrate these data together to form the core verification layer configuration data. Use configuration management tools (such as Ansible) to automate the deployment of these configuration data to ensure that they are correctly set on all relevant nodes.

[0098] Step S27: configuring the verification nodes as a whole according to the edge verification layer configuration data, the regional verification layer configuration data and the core verification layer configuration data to obtain a hierarchical verification node network;

[0099] Specifically, you can use a configuration management database (such as etcd) to centrally store edge validation layer configuration data, regional validation layer configuration data, and core validation layer configuration data, and ensure that they are accessible to all nodes. Read these configuration data and set up each validation node according to the instructions in the data. Set the node's network parameters, verification logic, task scheduling strategy, and any special transaction processing rules. Use automation tools such as Terraform to manage the node's infrastructure to ensure that they can be properly deployed in a cloud environment or data center. Use monitoring tools such as Prometheus and Grafana to monitor the health and performance indicators of the nodes. Set up alert rules to notify the operation and maintenance team in a timely manner when configuration problems cause performance degradation or failures. After completing these steps, you will end up with a hierarchical validation node network, where each node is appropriately configured according to its role in the edge, regional, or core validation layer.

[0100] Step S28: Perform an asynchronous message queue mechanism configuration on the hierarchical verification node network to obtain a parallel verification network cluster.

[0101] Specifically, please refer to the sub-steps of step S28 for the detailed implementation process of this embodiment.

[0102] The present invention can execute special verification strategies for different data fields by deploying field verification engines on verification nodes, thereby improving the accuracy of verification. By introducing signature verification cache configuration and timeout retry mechanism, the system can respond more flexibly when facing network delays or temporary failures. By elastically expanding and contracting capacity configuration, the verification node cluster can dynamically adjust resources according to actual load, adapt to different business needs, and improve the scalability of the system. The deployment of a parallel verification framework allows the system to process multiple verification tasks at the same time, significantly improving the efficiency of the verification process. The construction of a verification result cache pool helps to quickly store and retrieve verification results, speeding up the verification process. By determining the cross-regional verification task scheduling strategy, verification tasks in different regions can be effectively managed and scheduled, improving the processing capacity of cross-regional transactions. By deploying an atomic verification engine and a dedicated verification pipeline, cross-shard transactions and special transactions can be better handled, and the system's support for complex transaction scenarios is enhanced. By building a hierarchical verification node network, multi-level verification from the foundation to the core can be achieved, improving the depth and breadth of verification. Through hierarchical configuration and asynchronous message queue mechanism, the system can continue to run when some nodes fail, improving the fault tolerance of the system.

[0103] Preferably, step S28 comprises the following steps:

[0104] Step S281: Deploy a message middleware architecture on the hierarchical verification node network to obtain an asynchronous communication verification network;

[0105] Specifically, RabbitMQ can be chosen as the message middleware because it supports high-concurrency message delivery and has an easy-to-use management interface. First, install the RabbitMQ service on each verification node and configure it to ensure the persistence and security of messages. Use the Erlang programming language, which is the native language of RabbitMQ, to configure exchanges, queues, and bindings, which define the routing strategy of messages. Create different queues for different types of verification tasks and set priorities to ensure that high-priority tasks can be processed faster. Use RabbitMQ's management interface to monitor the length of the queue and the delivery of messages, and use the alarm mechanism it provides to promptly discover and handle potential problems. Write client code and use the Python client library pika provided by RabbitMQ to implement message sending and receiving. In this way, each verification node can publish verification tasks to the corresponding queue, and other nodes can asynchronously pull tasks from the queue for processing, and finally obtain an asynchronous communication verification network.

[0106] Step S282: performing time window aggregation on the asynchronous communication verification network to obtain a batch verification network;

[0107] Specifically, the strategy of time window aggregation can be used to reduce the frequency of message delivery and improve the processing efficiency of verification tasks. Specifically, configure the RabbitMQ queue so that it can collect messages arriving within a certain time window, and then send these messages to the verification node for batch processing at one time. Use RabbitMQ's delay queue function to implement time window aggregation. Delay queues allow messages to wait for a specified period of time before being consumed. Set a reasonable delay time for each verification task so that at the end of the time window, all messages arriving during this period will be sent to the verification node together. Use RabbitMQ's management interface to adjust the delay time to find the best balance. Write workflow management scripts and use Apache Airflow to schedule batch tasks. These scripts define the execution order and dependencies of tasks and ensure that batch operations are triggered at the end of the time window. Use monitoring tools such as Grafana to monitor the execution of batch tasks. In this way, a batch verification network can be obtained.

[0108] Step S283: performing exponential backoff retransmission setting on the batch verification network to obtain a fault-tolerant transaction verification network;

[0109] Specifically, the retransmission strategy can be configured at the messaging middleware level, such as RabbitMQ or Kafka. For RabbitMQ, the exponential backoff logic is implemented by using existing client libraries such as pika. When message delivery fails, a retry mechanism is written in Python, which gradually increases the retry interval according to the exponential backoff algorithm. For example, the initial retry interval is 1 second, and after each failure, the interval doubles until the maximum number of retries or the maximum waiting time is reached. The exponential backoff algorithm is implemented using the backoff library, which provides a variety of backoff strategies, including exponential backoff. Set a unique identifier for each message and record its status at each retry. If a message fails to be delivered successfully within a certain number of times, mark it as failed and route it to a dead letter queue (DLQ). In this way, a fault-tolerant transaction verification network can be obtained.

[0110] Step S284: setting a two-way ACK confirmation mechanism for the fault-tolerant transaction verification network to obtain a reliable transmission verification network;

[0111] Specifically, you can use RabbitMQ's message confirmation function to implement a two-way ACK confirmation mechanism setting. When a verification node successfully processes a message, it sends an ACK receipt to the sender to confirm that the message has been processed. If the sender does not receive the ACK within the timeout, it triggers the retransmission mechanism. Use the pika library to implement the ACK confirmation logic in the Python client. When the message is successfully processed, the client sends an ACK receipt to the RabbitMQ server. Configure RabbitMQ's transaction and confirmation mode. In addition, use logging and monitoring systems (such as ELK Stack: Elasticsearch, Logstash, Kibana) to track the delivery status and ACK confirmation of messages. In this way, you end up with a reliable transmission verification network.

[0112] Step S285: The reliable transmission verification network and the hierarchical verification node network are integrated with each other to obtain a parallel verification network cluster.

[0113] Specifically, containerization technologies, such as Docker, can be used to encapsulate the services of each validation node to ensure that they can run in a consistent manner in different environments. Each container is configured with the required environment variables and configuration files, which contain parameters such as the message middleware settings, exponential backoff strategy, and two-way ACK confirmation mechanism determined in steps S281 to S284. Use container orchestration tools, such as Kubernetes, to manage these containerized validation nodes. Kubernetes allows the definition of deployment strategies for services, including replica sets (ReplicaSet) to ensure high availability, and horizontal expansion strategies to cope with different load conditions. Define Ingress rules to manage the traffic entering the validation node, and use Service and LoadBalancer to distribute network requests to different nodes. In order to achieve feature synergy, a service mesh, such as Istio, is integrated, which provides fine-grained traffic control and policy enforcement. Istio allows the setting of timeout retries, fault injection, and traffic mirroring strategies, which work in conjunction with the exponential backoff and two-way ACK confirmation mechanisms set previously. Finally, the entire deployment process is automated through a continuous integration / continuous deployment (CI / CD) process, such as Jenkins or GitLab CI. This includes steps for automated testing, building, containerization, and deployment to a Kubernetes cluster. Through these integrated steps, a parallel validation network cluster is obtained.

[0114] The present invention can realize asynchronous communication through the deployment of the message middleware architecture, reduce the waiting time between verification nodes, and thus improve communication efficiency. Through time window aggregation, multiple verification tasks can be packaged and processed, which optimizes the use of resources and improves the efficiency of batch processing. The exponential backoff retransmission setting allows the system to perform intelligent retries when encountering transmission errors, enhances the fault tolerance of the system, and ensures the reliability of the verification task. The two-way ACK confirmation mechanism provides double protection for data transmission, ensures the accurate transmission of data, and reduces the risk of data loss or error. Through the coordinated integration of the hierarchical verification node network and the reliable transmission verification network, the system can be flexibly expanded to adapt to the ever-changing network scale and business needs.

[0115] Preferably, step S3 comprises the following steps:

[0116] Step S31: deploying indicator collection probes for the parallel verification network cluster to obtain a network cluster monitoring network, and collecting performance indicators of the parallel verification network cluster in real time through the network cluster monitoring network to obtain a network cluster performance indicator matrix;

[0117] Specifically, Prometheus, an open source monitoring and alerting tool, can be used to deploy indicator collection probes. The Prometheus server can regularly pull performance metrics from each node in the cluster, such as CPU usage, memory usage, network traffic, and request latency. Configure a Prometheus exporter for each verification node, such as NodeExporter, which can expose the hardware and operating system level metrics of the node. In addition, a custom metricsexporter is used to collect application-specific metrics, such as the number of transactions processed and the verification failure rate. These exporters push the metrics to the Prometheus server or are periodically captured by the Prometheus server. Using Grafana, create a dashboard that displays time series graphs of key performance indicators and thresholds for triggering alerts. Set alert rules so that the system automatically notifies the operation and maintenance team when certain indicators exceed the normal range. Through these methods, a network cluster monitoring network is built that can collect and analyze the performance indicators of parallel verification network clusters in real time, forming a comprehensive network cluster performance indicator matrix.

[0118] Step S32: performing a transaction complexity evaluation on the weighted sharded transaction data set to obtain a transaction computation complexity matrix, and performing a resource consumption evaluation on the weighted sharded transaction data set to obtain a transaction resource requirement matrix;

[0119] Specifically, Python's scientific computing libraries NumPy and Pandas can be used to process weighted sharded transaction data sets and calculate the complexity score of each transaction. For example, a weight is assigned to each factor (the number of accounts involved in the transaction, the amount of the transaction, the frequency of the transaction, and the smart contract involved in the transaction), and then the weighted average is calculated to obtain the complexity score of each transaction. For the evaluation of resource consumption, the computing resources required for each transaction type are analyzed, such as CPU cycles, memory usage, and storage requirements. Use the analysis tools provided by the blockchain platform, such as Ethereum's Gas tracking tool, to estimate the resource consumption of each transaction. Use these evaluation results to construct the transaction computational complexity matrix and the transaction resource requirement matrix.

[0120] Step S33: scoring the performance of the parallel verification network cluster according to the network cluster performance indicator matrix to obtain a cluster performance scoring vector;

[0121] Specifically, the network cluster performance indicator matrix can be extracted from the Prometheus database, which contains key performance indicators such as CPU usage, memory usage, network throughput, and task processing latency. Use Python's data analysis library Pandas to process this data and calculate the performance score of each node. Define a scoring formula based on the weighted average of the indicators, where the weight reflects the degree of impact of each indicator on the overall performance. For example, give higher weights to CPU usage and memory usage because these indicators are often directly related to processing power. Use optimization and linear algebra tools in the SciPy library to minimize the difference between performance scores and actual performance. In this way, a cluster performance score vector can be obtained, which assigns a performance score to each node.

[0122] Step S34: Generate a task scheduling strategy for the weighted sharded transaction data set according to the transaction computation complexity matrix, the transaction resource requirement matrix, and the cluster performance score vector to obtain a verification task scheduling strategy;

[0123] Specifically, Python's Pandas library can be used to merge the transaction computational complexity matrix, transaction resource requirement matrix, and cluster performance score vector. Create a DataFrame where each row represents a transaction and each column represents an attribute such as transaction complexity, resource requirement, and node performance score. Next, define a task scheduling algorithm. This algorithm uses linear programming to model the problem, where the objective function is to minimize weighted latency. Weighted latency is a function of transaction processing time, including processing time and waiting time. Use Python's PuLP library to set up this linear programming problem and define decision variables such as the start time and duration of each transaction assigned to each node. Add constraints to ensure that each transaction is assigned to the node with sufficient resources and the highest performance score. For example, if a node's CPU utilization has reached 90%, it does not have enough resources to process a computationally intensive transaction. Consider the performance score threshold and prioritize assigning transactions to nodes with scores above a certain threshold. Use the PuLP solver to solve this optimization problem. The solver will return an optimal solution that gives the allocation and scheduling of each transaction, minimizes the overall latency, and maximizes resource utilization. This solution will be converted into a verification task scheduling policy, which specifies the optimal processing node and execution order for each transaction.

[0124] Step S35: performing target optimization on the verification task scheduling strategy to obtain a transaction data verification scheduling plan; wherein the target optimization solution includes at least one or more of minimizing verification delay, maximizing resource utilization, minimizing network communication overhead, maximizing parallel processing efficiency and minimizing energy consumption;

[0125] Specifically, mixed integer linear programming (MILP) can be used to solve the target optimization problem, where the objective function is to minimize the verification delay and network communication overhead while maximizing resource utilization and parallel processing efficiency. Use Python's PuLP library to define this optimization problem, where the decision variables represent the start time and duration of the task assigned to the node. A set of constraints are defined, including: 1. Each task must be assigned to a node under the constraints of available resources. 2. The execution of tasks must meet their dependencies and priority requirements. 3. The start time of the task must take into account the current load and processing capacity of the node. Use CPLEX or Gurobi commercial solvers to solve this optimization problem, which can efficiently handle large-scale MILP problems. The optimal solution returned by the solver gives the allocation and scheduling of each task, and finally obtains the transaction data verification scheduling plan.

[0126] Step S36: Decompose and arrange the transaction data verification scheduling plan into tasks to obtain a transaction verification task sequence;

[0127] Specifically, the Pandas library can be used to process the transaction data validation schedule and convert it into a task sequence, where each task has a unique identifier, assigned node, start time, and end time. Use project management tools such as Microsoft Project or Asana to visualize the task sequence. Dependencies are defined for each task, and the transaction validation task sequence is finally obtained.

[0128] Step S37: Perform verification node mapping on the parallel verification network cluster and the transaction verification task sequence to obtain a transaction verification routing allocation table.

[0129] Specifically, a transaction verification task sequence can be used, which contains detailed information about each task, such as task identification, required resources, expected start and end time, etc. Use scheduling algorithms, such as polling, random selection, or load-based scheduling, to decide which node will handle which task. Ensure that tasks are evenly distributed to all nodes, taking into account the current load and performance score of each node, and finally obtain a transaction verification routing allocation table. For example, compute-intensive tasks are preferentially assigned to nodes with high-performance CPUs, while I / O-intensive tasks are assigned to nodes with high-throughput storage systems. Use a configuration management database, such as etcd or Consul, to store and synchronize routing allocation tables. This database will be accessed by all nodes in the cluster to obtain their respective task assignments.

[0130] The present invention can monitor the performance of the parallel verification network cluster in real time and discover and solve potential problems in time by deploying indicator collection probes. Through the evaluation of transaction complexity and resource consumption, resources can be reasonably allocated according to actual needs to improve resource utilization efficiency. The introduction of performance scoring vectors provides a quantitative evaluation of the performance of the network cluster, which helps to make more accurate scheduling decisions. Through the verification task scheduling strategy generated based on multiple factors, tasks can be scheduled more intelligently and the load can be balanced. Through target optimization solution, multiple goals such as verification delay, resource utilization, network communication overhead, etc. can be considered, so that the system can be optimized in many aspects. Through task decomposition and time sequence arrangement, verification tasks can be executed more efficiently and the verification cycle can be shortened. Through the generation of transaction verification routing allocation table, verification nodes can be flexibly mapped according to task characteristics and network conditions, thereby improving the adaptability of the system.

[0131] Preferably, step S4 comprises the following steps:

[0132] Step S41: constructing a scoring index system for the verification node to obtain a node scoring index system;

[0133] Specifically, key indicators for evaluating node performance can be determined, including transaction processing speed, online time, error rate, resource utilization (such as CPU and memory usage), and network latency. Use expert consultation and historical data analysis to determine the weight of each indicator to reflect its impact on overall node performance. Use Python's Pandas library to process and analyze historical data to determine the normal range and threshold of these indicators. Define scoring rules, for example, a node gets full marks when the online time exceeds 99%, and deducts a certain number of points for each 1% drop. Similarly, define scoring rules for error rate, resource utilization, and network latency indicators. Build a scoring model that combines these indicators and weights to calculate the comprehensive score of each node. Use a web framework, such as Flask or Django, to create a scoring system interface that allows administrators to view and update the scoring indicator system. Through this system, a node scoring indicator system can be obtained.

[0134] Step S42: collecting real-time scoring index data of the verification node according to the node scoring index system to obtain a real-time node scoring index data set;

[0135] Specifically, Prometheus and Grafana can be used to monitor and collect real-time performance data of nodes. The Prometheus server is configured with a scraping job to regularly scrape performance indicator data from the Exporter of each node. Data collection rules are configured for each indicator, for example, CPU usage and memory usage are scraped every 5 minutes, and transaction processing speed and error rate are scraped every minute. In this way, a real-time node scoring indicator dataset can be obtained, which contains the performance indicator data of each node at different time points.

[0136] Step S43: Calculate the reputation score of the verification node according to the node scoring index system and the real-time node scoring index data set to obtain a node reputation scoring matrix;

[0137] Specifically, each indicator of each node can be scored according to the rules and weights defined in the scoring indicator system. For example, if a node's transaction processing speed is higher than the average, it will receive a higher score; if the error rate is higher than the threshold, it will receive a lower score. Use the weighted average method to combine these indicators and calculate the overall reputation score of each node. Specifically, the reputation score of node i is calculated using the following formula : ... ;in, Is an indicator The weight of Yes Yes Node in Index The NumPy library is used to perform these calculations, and the result is a node reputation score matrix, where each row represents a node, each column represents a scoring indicator, and each cell in the matrix contains the score of the corresponding node on the corresponding indicator.

[0138] Step S44: performing propagation frequency control on the node reputation score matrix to obtain a time series propagation control matrix;

[0139] Specifically, the interaction patterns between verification nodes and the changes in reputation scores can be analyzed to determine the optimal frequency of reputation information propagation. For example, it is found that the reputation scores of some nodes change rapidly and need to be updated more frequently; while the scores of other nodes are relatively stable, the update frequency can be reduced. Use time series analysis methods, such as the autoregressive moving average (ARMA) model, to predict the changing trend of reputation scores and set the update frequency accordingly. Use Python's Statsmodels library to implement these models, and adjust the reputation information propagation frequency of each node based on the output of the model. Construct a time series propagation control matrix based on the reputation information propagation frequency, in which each row represents a time window, each column represents a node, and each cell in the matrix contains a mark of whether the node needs to update its reputation information within the time window. For example, if a node has a stable reputation score in the current time window, it can be set not to update in the next time window; conversely, if the score fluctuates greatly, it is set to need to be updated.

[0140] Step S45: Identify the consensus path of the verification node to obtain a consensus propagation path set, and based on the consensus propagation path set, perform reputation propagation and diffusion on the verification node according to the node reputation scoring matrix and the timing propagation control matrix to obtain a global node reputation set;

[0141] Specifically, algorithms in graph theory, such as Dijkstra or Floyd-Warshall, can be used to identify the shortest paths between nodes, which constitute the consensus propagation path set. Use Python's NetworkX library to create a graph where nodes represent validation nodes and edges represent connections between nodes. Analyze the interaction data between nodes to determine which nodes have frequent transaction verification interactions, and define these interactions as edges. Adjust the weights of these edges based on the node reputation score matrix and the timing propagation control matrix to reflect the reputation and update frequency between nodes. For example, connections between nodes with higher reputation scores have higher weights, while connections between nodes with lower update frequencies have lower weights. Use these paths and weights to simulate the propagation process of reputation. Use a simple voting mechanism where each node passes its reputation score to its neighbor nodes, or use a more complex mechanism, such as the PageRank algorithm, to take into account the mutual influence between nodes. Use the PageRank function in the NetworkX library to calculate the global node reputation set, which contains the final reputation score of each node.

[0142] Step S46: Perform weighted consensus voting verification on the global node reputation set to obtain a consensus verification node reputation set.

[0143] Specifically, we can first define a weighted voting mechanism, in which the voting weight of each node is proportional to its reputation score. Use Python's Pandas library to process the global node reputation set and assign a voting weight to each node. Use a consensus algorithm, such as PBFT (Practical Byzantine Fault Tolerance) or RAFT, to implement the weighted voting process. In this process, each node votes on the reputation of other nodes according to its weight. Use the Go language's RAFT library to implement the RAFT consensus algorithm, which ensures that the system can reach a consistent decision even when some nodes fail or act maliciously. Set a threshold, and only when a node receives enough votes (that is, its reputation score exceeds this threshold) will it be considered a consensus verification node. Use machine learning methods such as logistic regression or decision trees to determine this threshold to maximize the security and efficiency of the system. Finally, we get the consensus verification node reputation set, which contains the node reputation scores verified by weighted consensus voting.

[0144] The present invention can more accurately manage and evaluate the performance of verification nodes by constructing a scoring index system. By collecting node scoring index data in real time, it is possible to respond to changes in node status in a timely manner, thereby improving the timeliness and accuracy of scoring. By combining real-time data and a scoring index system to calculate node reputation scores, the scoring process is made more objective and fair. Through the timing propagation control matrix, the propagation frequency of reputation information can be reasonably controlled to avoid information overload, while ensuring the timely updating of information. Consensus path identification and reputation propagation diffusion help to form a more accurate global node reputation set, thereby enhancing the effectiveness of the consensus mechanism. Weighted consensus voting verification ensures that only nodes with high reputation can have a decisive impact on transaction verification, thereby improving the security of the system. Through the construction of a global node reputation set, the system can resist attacks from malicious nodes, and the system can still operate normally even if some nodes fail or are attacked.

[0145] Preferably, step S5 comprises the following steps:

[0146] Step S51: extracting shard verification rules from the transaction verification routing allocation table to obtain a verification rule mapping matrix, and performing verification task decomposition on the weighted shard transaction data set according to the verification rule mapping matrix to obtain an atomic transaction verification task set;

[0147] Specifically, a database query language (such as SQL) can be used to access and retrieve the transaction verification routing assignment table, which contains the rules for assigning transaction data to different verification nodes. Use Python's Pandas library to process this data and extract verification rules, for example, which types of transactions should be processed by which nodes. Define a rule mapping matrix in which rows represent transaction types, columns represent verification nodes, and the values ​​in cells indicate whether a specific type of transaction should be processed by a specific node. Use this matrix to guide the decomposition process of transaction data. For each transaction, assign it to the corresponding verification node according to its type and verification rule mapping matrix, and form an atomic transaction verification task.

[0148] Step S52: performing concurrency evaluation on the atomic transaction verification task set to obtain a parallel verification scheduling matrix, and performing dependency identification on the atomic transaction verification task set to obtain a verification task dependency topology graph;

[0149] Specifically, the task execution history data and the current system load can be used to evaluate the concurrency of each task in the atomic transaction verification task set. Use Python's Pandas library to analyze this data, and use statistical methods (such as mean, median, or percentile) to determine the concurrent execution capability of each task. Define a parallel verification scheduling matrix, where rows represent tasks, columns represent time slots, and the values ​​in cells indicate whether the tasks can be executed concurrently in the corresponding time slots. Identify the dependencies between tasks. Use a directed acyclic graph (DAG) to represent these dependencies, where nodes represent tasks and edges represent the dependency directions between tasks. Use Python's NetworkX library to create this DAG, and use graph theory algorithms (such as topological sorting) to determine the execution order of tasks. Finally, the verification task dependency topology graph is obtained, which describes in detail the dependencies and concurrent execution capabilities between tasks.

[0150] Step S53: Perform pipeline parallel scheduling on the atomic transaction verification task set according to the parallel verification scheduling matrix and the verification task dependency topology diagram to obtain a verification task execution sequence;

[0151] Specifically, Python's networkx library can be used to process the dependency topology graph and determine the execution order of tasks. Then, use ThreadPoolExecutor or ProcessPoolExecutor in the concurrent.futures library to create a parallel execution environment, which allows tasks to be scheduled and executed in parallel. According to the information in the parallel verification scheduling matrix, execution resources and time slots are allocated to each task. For example, if a task needs to be executed within a specific time window, it is scheduled within the window and appropriate computing resources are allocated to it. Use task queues to manage the execution of tasks to ensure that tasks are executed sequentially according to dependencies and resource availability. In this way, the verification task execution sequence is finally obtained.

[0152] Step S54: Perform digital signature verification on the verification task execution sequence to obtain a signature verification result set, and perform smart contract verification on the verification task execution sequence to obtain a contract verification result set;

[0153] Specifically, you can use cryptographic libraries, such as Python's cryptography, to verify the digital signature of each transaction. For each transaction, extract the signature and public key, and then use the corresponding hash algorithm (such as SHA-256) and encryption algorithm (such as ECDSA) to verify the validity of the signature. Use the smart contract execution environment provided by the blockchain platform, such as Ethereum's EVM (Ethereum Virtual Machine), to execute the smart contract code. Use the web3.py library to interact with the EVM, send transactions and obtain execution results. Check the logic of the smart contract to ensure that the transaction meets the conditions and rules defined in the contract. Record the results of each verification operation, including digital signature verification results and smart contract verification results. Use a database (such as PostgreSQL or MongoDB) to store these results. Finally, you will get a signature verification result set and a contract verification result set.

[0154] Step S55: Perform state consistency verification on the verification task execution sequence to obtain a state verification result set, and perform double-spending attack detection on the verification task execution sequence to obtain a security verification result set;

[0155] Specifically, you can use the API provided by the blockchain platform, such as Ethereum's Web3.py library, to access the state information of the blockchain. Check the state changes before and after each transaction to ensure the consistency of the state transition. For example, if a transaction involves the transfer of tokens, verify whether the change in the token balance before and after the transaction is consistent with the transaction amount. Analyze the input and output of the transaction to ensure that no tokens are reused. Use a graph database, such as Neo4j, to store and query transaction graphs, which helps to quickly identify and detect circular dependencies and double-spending attempts. Set thresholds and rules, such as checking whether the input of a transaction already exists in other confirmed transactions to identify potential double-spending behavior. Record the results of state consistency verification and double-spending attack detection to form a state verification result set and a security verification result set.

[0156] Step S56: Integrate the verification results of the verification task execution sequence according to the signature verification result set, the contract verification result set, the status verification result set and the security verification result set to obtain a preliminary verification transaction data set;

[0157] Specifically, Python's Pandas library can be used to process the signature verification result set, contract verification result set, state verification result set, and security verification result set, and merge them into a comprehensive data frame. Define a data model to integrate the signature verification results, contract verification results, state verification results, and security verification results of each transaction. For example, create a DataFrame in which each row represents a transaction and each column represents a verification result category, such as signature validity, contract execution result, state consistency, and security. Use logical rules to integrate these results. For example, only when a transaction passes all these verifications is it considered to have passed preliminary verification. Set a threshold or weight system to assign different weights to each verification result category, and then calculate the comprehensive verification score of the transaction. Finally, a preliminary verification transaction data set is obtained.

[0158] Step S57: Calculate the credibility threshold of the consensus verification node reputation set to obtain a node credibility threshold vector, perform Byzantine fault tolerance verification on the preliminary verification transaction data set according to the node credibility threshold vector, and obtain a consensus transaction verification result set;

[0159] Specifically, data analysis tools (such as Python's Pandas library) can be used to process the consensus verification node reputation set and calculate the credibility score of each node. Machine learning methods, such as support vector machines (SVM) or random forests, are used to determine the credibility threshold of each node. These models can predict the credibility of a node based on its historical performance and real-time data. Define a node credibility threshold vector, which contains the credibility threshold of each node. Then, use this vector to perform BFT verification on the transactions in the preliminary verification transaction data set. Use a BFT algorithm, such as the Practical Byzantine Fault Tolerance (PBFT) algorithm, to ensure that the system can reach a consistent verification result even when some nodes are malicious or make mistakes. Use the Go language PBFT library to implement this algorithm, which requires more than 2 / 3 of the nodes to reach a consensus before the transaction verification is considered to be passed. In this process, the verification results of each transaction are recorded to form a consensus transaction verification result set. This result set contains the verification status of each transaction, such as whether it has passed the verification, and the node information involved in the verification.

[0160] Step S58: Generate zero-knowledge proof for the consensus transaction verification result set to obtain a transaction verification proof set, and perform proof verification on the consensus transaction verification result set based on the transaction verification proof set to obtain a final verification transaction data set.

[0161] Specifically, you can use a zero-knowledge proof library such as Zokrates or libsnark to generate a zero-knowledge proof for each transaction that passes consensus verification. Define a proof generation process, which includes selecting an appropriate proof system (such as zk-SNARKs or Bulletproofs) and generating proofs for each transaction. Next, use these zero-knowledge proofs to verify the transactions in the consensus transaction verification result set. Write a verification script to check whether the proof of each transaction is valid. If the proof is valid, the transaction is considered to have been verified and included in the final verification transaction data set. Finally, the final verification transaction data set is obtained, which contains all transactions verified by zero-knowledge proofs.

[0162] The present invention can accurately verify transaction data through detailed verification rule mapping and task decomposition, ensuring that each verification task complies with the predetermined rules. Through the introduction of concurrency evaluation and scheduling matrix, multiple verification tasks can be processed in parallel more effectively, thereby improving the verification efficiency. Dependency identification and the construction of topological graphs help to understand the dependencies between tasks, thereby performing more reasonable task scheduling. Through pipeline parallel scheduling and the generation of task execution sequences, verification tasks can be executed quickly and orderly. Through the joint action of digital signature verification, smart contract verification, state consistency verification and double-spending attack detection, the security of transaction verification is enhanced. By integrating various verification results, a comprehensive preliminary verification transaction data set can be obtained, thereby improving the reliability of the verification results. Through the Byzantine fault-tolerant verification mechanism, a certain number of erroneous or malicious nodes can be tolerated, ensuring that the system can still operate normally when some nodes fail or do evil. Through the consideration of node reputation and the calculation of credibility threshold, nodes with high reputation have a greater impact on the verification results, thereby improving the credibility of the entire system. Through the introduction of zero-knowledge proof, the legitimacy of the transaction can be verified without leaking transaction details, thereby enhancing privacy protection. The generation of a transaction data set through final verification represents transaction data that has been verified and proven at multiple levels, ensuring the finality and immutability of the results.

[0163] Preferably, the present invention further provides a transaction data verification system for executing the transaction data verification method as described above, the transaction data verification system comprising:

[0164] The data sharding module is used to collect transaction data from blockchain network nodes to obtain the original transaction data set; perform adaptive heterogeneous sharding on the original transaction data set to obtain the sharded transaction data set; perform verification weight coefficient allocation on the sharded transaction data set to obtain the weighted sharded transaction data set;

[0165] The verification engine deployment module is used to deploy multi-level verification engines on verification nodes to obtain a hierarchical verification node network; configure an asynchronous message queue mechanism on the hierarchical verification node network to obtain a parallel verification network cluster;

[0166] A routing allocation module is used to perform load balancing scheduling on the weighted sharded transaction data set based on a parallel verification network cluster to obtain a transaction verification task sequence; perform verification routing allocation on the weighted sharded transaction data set according to the transaction verification task sequence to obtain a transaction verification routing allocation table;

[0167] The consensus verification module is used to calculate the reputation score of the verification node to obtain the node reputation score matrix; to spread the reputation of the verification node according to the node reputation score matrix to obtain the global node reputation set; to perform weighted consensus voting verification on the global node reputation set to obtain the consensus verification node reputation set;

[0168] The parallel verification module is used to perform distributed parallel verification on the weighted sharded transaction data set according to the transaction verification routing allocation table to obtain a preliminary verification transaction data set; and to perform consistency proof on the preliminary verification transaction data set according to the consensus verification node reputation set to obtain a final verification transaction data set.

[0169] Therefore, the embodiments should be regarded as illustrative and non-restrictive from all points, and the scope of the present invention is limited by the appended claims rather than the above description, and it is therefore intended that all changes falling within the meaning and range of equivalent elements of the application documents are included in the present invention.

[0170] The above description is only a specific embodiment of the present invention, so that those skilled in the art can understand or implement the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but should conform to the widest scope consistent with the principles and novel features invented herein.

Claims

1. A transaction data verification method, characterized in that: The following steps are involved: Step S1: collect transaction data from blockchain network nodes to obtain an original transaction data set; perform adaptive heterogeneous sharding on the original transaction data set to obtain a sharded transaction data set; perform verification weight coefficient allocation on the sharded transaction data set to obtain a weighted sharded transaction data set; Step S2: deploy a multi-level verification engine on the verification node to obtain a hierarchical verification node network; An asynchronous message queue mechanism is configured for the hierarchical verification node network to obtain a parallel verification network cluster; wherein step S2 includes the following steps: Step S21: deploying a field verification engine on the verification node to obtain basic verification configuration data, and configuring a signature verification cache on the verification node to obtain signature verification configuration data; Step S22: configure the timeout retry mechanism for the verification node to obtain timeout retry configuration data, and record the basic verification configuration data, signature verification configuration data and timeout retry configuration data as edge verification layer configuration data; Step S23: elastically expand and contract the capacity of the verification node cluster to obtain node cluster capacity configuration data, and deploy a parallel verification framework on the verification node cluster to obtain business verification configuration data; Step S24: constructing a verification result cache pool for the verification node to obtain verification result cache configuration data; Step S25: Determine the cross-region verification task scheduling strategy for the verification node, obtain the verification task scheduling configuration data, and record the node cluster capacity configuration data, business verification configuration data, verification result cache configuration data and verification task scheduling configuration data as regional verification layer configuration data; Step S26: Deploy an atomic verification engine for cross-shard transactions of the verification node to obtain atomic verification configuration data, and construct a special transaction dedicated verification pipeline for the verification node to obtain dedicated verification pipeline configuration data, and record the atomic verification configuration data and the dedicated verification pipeline configuration data as core verification layer configuration data; Step S27: configuring the verification nodes as a whole according to the edge verification layer configuration data, the regional verification layer configuration data and the core verification layer configuration data to obtain a hierarchical verification node network; Step S28: configuring an asynchronous message queue mechanism for the hierarchical verification node network to obtain a parallel verification network cluster; wherein step S28 includes the following steps: Step S281: Deploy a message middleware architecture on the hierarchical verification node network to obtain an asynchronous communication verification network; Step S282: performing time window aggregation on the asynchronous communication verification network to obtain a batch verification network; Step S283: performing exponential backoff retransmission setting on the batch verification network to obtain a fault-tolerant transaction verification network; Step S284: setting a two-way ACK confirmation mechanism for the fault-tolerant transaction verification network to obtain a reliable transmission verification network; Step S285: integrating the reliable transmission verification network and the hierarchical verification node network to obtain a parallel verification network cluster; Step S3: Based on the parallel verification network cluster, load balancing scheduling is performed on the weighted sharded transaction data set to obtain a transaction verification task sequence; verification routing allocation is performed on the weighted sharded transaction data set according to the transaction verification task sequence to obtain a transaction verification routing allocation table; Step S4: Calculate the reputation score of the verification node to obtain a node reputation score matrix; perform reputation propagation and diffusion on the verification node according to the node reputation score matrix to obtain a global node reputation set; perform weighted consensus voting verification on the global node reputation set to obtain a consensus verification node reputation set; Step S5: Perform distributed parallel verification on the weighted sharded transaction data set according to the transaction verification routing allocation table to obtain a preliminary verification transaction data set; perform consistency proof on the preliminary verification transaction data set according to the consensus verification node reputation set to obtain a final verification transaction data set; wherein, step S5 includes the following steps: Step S51: extracting shard verification rules from the transaction verification routing allocation table to obtain a verification rule mapping matrix, and performing verification task decomposition on the weighted shard transaction data set according to the verification rule mapping matrix to obtain an atomic transaction verification task set; Step S52: performing concurrency evaluation on the atomic transaction verification task set to obtain a parallel verification scheduling matrix, and performing dependency identification on the atomic transaction verification task set to obtain a verification task dependency topology graph; Step S53: Perform pipeline parallel scheduling on the atomic transaction verification task set according to the parallel verification scheduling matrix and the verification task dependency topology diagram to obtain a verification task execution sequence; Step S54: Perform digital signature verification on the verification task execution sequence to obtain a signature verification result set, and perform smart contract verification on the verification task execution sequence to obtain a contract verification result set; Step S55: Perform state consistency verification on the verification task execution sequence to obtain a state verification result set, and perform double-spending attack detection on the verification task execution sequence to obtain a security verification result set; Step S56: Integrate the verification results of the verification task execution sequence according to the signature verification result set, the contract verification result set, the status verification result set and the security verification result set to obtain a preliminary verification transaction data set; Step S57: Calculate the credibility threshold of the consensus verification node reputation set to obtain a node credibility threshold vector, perform Byzantine fault tolerance verification on the preliminary verification transaction data set according to the node credibility threshold vector, and obtain a consensus transaction verification result set; Step S58: Generate zero-knowledge proof for the consensus transaction verification result set to obtain a transaction verification proof set, and perform proof verification on the consensus transaction verification result set based on the transaction verification proof set to obtain a final verification transaction data set.

2. The transaction data verification method according to claim 1, characterized in that: Step S1 includes the following steps: Step S11: collect transaction data from blockchain network nodes to obtain original transaction data sets; Step S12: extracting multidimensional feature vectors from the original transaction data set to obtain a transaction feature vector set; wherein the multidimensional feature vector extraction includes transaction type identification vector extraction, geographic space coordinate vector extraction, timestamp vector extraction, transaction amount vector extraction and transaction account attribute vector extraction; Step S13: quantifying the feature similarity of the original transaction data set according to the transaction feature vector set to obtain the number of transaction data shards; Step S14: Initially sharding the original transaction data set according to the number of transaction data shards to obtain an initial sharded transaction data set; Step S15: performing internal similarity calculation on the initial shard transaction data set to obtain intra-shard similarity data, and performing inter-shard difference calculation on the initial shard transaction data set to obtain inter-shard difference data; Step S16: adjusting the shard boundary of the initial shard transaction data set according to the intra-shard similarity data and the inter-shard difference data to obtain transaction shard boundary data, and reconstructing the boundary of the initial shard transaction data set according to the transaction shard boundary data to obtain the shard transaction data set; Step S17: Verify the weight coefficient allocation of the shard transaction data set to obtain a weighted shard transaction data set.

3. The transaction data verification method according to claim 2, characterized in that: Step S17 includes the following steps: Step S171: collect verified transaction data from blockchain network nodes to obtain a verified transaction data set, and collect transaction features from the verified transaction data set to obtain a historical transaction feature data set; Step S172: Identify key factors of the historical transaction feature data set to obtain a transaction verification key factor set; wherein the key factor identification includes transaction complexity factor identification, computing resource consumption factor identification, verification delay factor identification, historical verification success rate factor identification and transaction priority factor identification; Step S173: Quantitative feature modeling is performed on the transaction verification key factor set to obtain a historical transaction verification feature vector set; Step S174: using the historical transaction verification feature vector set to perform neural network feature mapping on the transaction verification key factor set to obtain a historical verification feature weight mapping matrix; Step S175: determining the weight range of the transaction verification key factor set according to the historical verification feature weight mapping matrix to obtain the transaction verification feature weight range set; Step S176: Use the historical verification feature weight mapping matrix and the transaction verification feature weight range set to perform verification weight training on the preset weighted neural network architecture to obtain a verification weight prediction model, and use the verification weight prediction model to assign verification weight coefficients to the sharded transaction data set to obtain a weighted sharded transaction data set.

4. The transaction data verification method according to claim 3, characterized in that: Step S176 includes the following steps: Step S1761: Use the historical verification feature weight mapping matrix and the transaction verification feature weight range set to perform verification weight training on the preset weighted neural network architecture to obtain a verification weight prediction model; Step S1762: extract key factor feature tensors from the shard transaction data set according to the transaction verification key factor set to obtain a shard transaction feature factor vector set; Step S1763: Use the verification weight prediction model to perform weight prediction mapping on the shard transaction feature factor vector set and the shard transaction data set to obtain an initial weight allocation matrix; Step S1764: Perform Gaussian kernel smoothing on the initial weight distribution matrix to obtain a smoothed weight distribution matrix; Step S1765: Perform hierarchical weight balancing calibration on the smoothed weight distribution matrix based on the sharded transaction data set to obtain a balanced weight distribution matrix; Step S1766: weight embedding is performed on the balanced weight distribution matrix and the shard transaction data set to obtain a weighted shard transaction data set.

5. The transaction data verification method according to claim 1, characterized in that: Step S3 includes the following steps: Step S31: deploying indicator collection probes for the parallel verification network cluster to obtain a network cluster monitoring network, and collecting performance indicators of the parallel verification network cluster in real time through the network cluster monitoring network to obtain a network cluster performance indicator matrix; Step S32: performing a transaction complexity evaluation on the weighted sharded transaction data set to obtain a transaction computation complexity matrix, and performing a resource consumption evaluation on the weighted sharded transaction data set to obtain a transaction resource requirement matrix; Step S33: scoring the performance of the parallel verification network cluster according to the network cluster performance indicator matrix to obtain a cluster performance scoring vector; Step S34: Generate a task scheduling strategy for the weighted sharded transaction data set according to the transaction computation complexity matrix, the transaction resource requirement matrix, and the cluster performance score vector to obtain a verification task scheduling strategy; Step S35: performing target optimization on the verification task scheduling strategy to obtain a transaction data verification scheduling plan; wherein the target optimization solution includes at least one or more of minimizing verification delay, maximizing resource utilization, minimizing network communication overhead, maximizing parallel processing efficiency and minimizing energy consumption; Step S36: Decompose and arrange the transaction data verification scheduling plan into tasks to obtain a transaction verification task sequence; Step S37: Perform verification node mapping on the parallel verification network cluster and the transaction verification task sequence to obtain a transaction verification routing allocation table.

6. The transaction data verification method according to claim 1, characterized in that: Step S4 includes the following steps: Step S41: constructing a scoring index system for the verification node to obtain a node scoring index system; Step S42: collecting real-time scoring index data of the verification node according to the node scoring index system to obtain a real-time node scoring index data set; Step S43: Calculate the reputation score of the verification node according to the node scoring index system and the real-time node scoring index data set to obtain a node reputation scoring matrix; Step S44: performing propagation frequency control on the node reputation score matrix to obtain a time series propagation control matrix; Step S45: Identify the consensus path of the verification node to obtain a consensus propagation path set, and based on the consensus propagation path set, perform reputation propagation and diffusion on the verification node according to the node reputation scoring matrix and the timing propagation control matrix to obtain a global node reputation set; Step S46: Perform weighted consensus voting verification on the global node reputation set to obtain a consensus verification node reputation set.

7. A transaction data verification system, characterized in that: Used to perform the transaction data verification method according to claim 1, the transaction data verification system comprises: The data sharding module is used to collect transaction data from blockchain network nodes to obtain the original transaction data set; perform adaptive heterogeneous sharding on the original transaction data set to obtain the sharded transaction data set; perform verification weight coefficient allocation on the sharded transaction data set to obtain the weighted sharded transaction data set; The verification engine deployment module is used to deploy multi-level verification engines on verification nodes to obtain a hierarchical verification node network; configure an asynchronous message queue mechanism on the hierarchical verification node network to obtain a parallel verification network cluster; A routing allocation module is used to perform load balancing scheduling on the weighted sharded transaction data set based on a parallel verification network cluster to obtain a transaction verification task sequence; perform verification routing allocation on the weighted sharded transaction data set according to the transaction verification task sequence to obtain a transaction verification routing allocation table; The consensus verification module is used to calculate the reputation score of the verification node to obtain the node reputation score matrix; to spread the reputation of the verification node according to the node reputation score matrix to obtain the global node reputation set; to perform weighted consensus voting verification on the global node reputation set to obtain the consensus verification node reputation set; The parallel verification module is used to perform distributed parallel verification on the weighted sharded transaction data set according to the transaction verification routing allocation table to obtain a preliminary verification transaction data set; and to perform consistency proof on the preliminary verification transaction data set according to the consensus verification node reputation set to obtain a final verification transaction data set.

Images