A method and system for generating an online shopping contract based on blockchain

Abstract

The present invention relates to the field of blockchain contract applications, and specifically to an online shopping contract generation method and system based on blockchain. When the number of contracts to be processed in each business shard is monitored to exceed the preset business shard expansion threshold, the business shard is split into multiple sub-business shards and independent nodes are assigned; the block parameters of the business shard are dynamically adjusted according to the predicted number of contracts to be processed, and the real-time block generation interval is dynamically adjusted. When the real-time block generation interval is greater than the upper limit of the dynamic block generation interval, the minimum allowable block generation interval is adopted and a node expansion instruction is triggered; the contracts to be processed are redistributed through the consistent hashing algorithm until the generation delay of the contracts to be processed is less than the preset maximum tolerance delay threshold; the problems of online shopping contract backlog, inefficient resource allocation, and contract confirmation delay are solved, the resource utilization rate is optimized, and the contract generation efficiency in high-concurrency scenarios is significantly improved.

Description

Technical Field

[0001] The present invention relates to the field of blockchain contract applications, and specifically to an online shopping contract generation method and system based on blockchain. Background Art

[0002] The real-time generation and security of online shopping contracts have become the core requirements of platform operation. Traditional contract generation methods mostly rely on centralized servers, which have the risk of data tampering and rely on third-party trust institutions, making it difficult to meet the efficiency and transparency requirements in high-concurrency scenarios. Therefore, blockchain technology has been introduced into the contract generation field due to its decentralized and immutable characteristics to effectively ensure the security of contracts.

[0003] Although blockchain technology eliminates the centralized dependence through consensus mechanisms (such as PoW, PoS), in high-concurrency scenarios, existing blockchain systems are still difficult to meet the efficiency requirements of real-time contract generation due to throughput limitations and rigid resource allocation. When the number of online shopping contracts to be processed surges, transaction backlogs are likely to occur, resulting in too long contract confirmation time and affecting the contract generation efficiency. Traditional sharding technologies do not fully consider the business types of shopping contracts, which easily leads to the accumulation of similar contracts and inefficient resource allocation. Once high concurrency occurs, the shards will be overloaded, and the contract confirmation delay will increase significantly.

[0004] Therefore, there is an urgent need for a dynamic and adaptive blockchain-based online shopping contract generation method to meet the timeliness requirements of contract generation in high-concurrency scenarios. Summary of the Invention

[0005] (1) Technical Problems to be Solved

[0006] The purpose of the present invention is to provide an online shopping contract generation method and system based on blockchain to solve the problem that in the current blockchain contract generation, the business types of shopping contracts are not fully considered, which easily leads to the accumulation of similar contracts, inefficient resource allocation, and once high concurrency occurs, the shards will be overloaded and the contract confirmation delay will increase significantly.

[0007] (2) Technical Solutions

[0008] To achieve the above purpose, on the one hand, the present invention provides an online shopping contract generation method based on blockchain, and the method includes:

[0009] S1. Divide the online shopping contracts into business shards according to business types, and monitor the number of contracts to be processed in each business shard in real time. When the number of contracts to be processed in a business shard exceeds the preset business shard expansion threshold, the business shard is split into multiple sub-business shards, and an independent node is assigned to each sub-business shard.

[0010] S2. Obtain the current number of contracts to be processed in the business shard and predict the predicted number of contracts to be processed through a pre-trained LSTM model. Dynamically adjust the block parameters of the business shard according to the predicted number of contracts to be processed, monitor the communication latency and block packaging success rate of the nodes within the business shard, and dynamically adjust the real-time block generation interval. When the real-time block generation interval is greater than the upper limit of the dynamic block generation interval, then adopt the minimum allowable block generation interval and trigger a node expansion instruction.

[0011] S3. Dynamically add verification nodes to the business shard according to the node expansion instruction, and reallocate the contracts to be processed through the consistent hashing algorithm until the generation latency of the contracts to be processed is less than the preset maximum tolerance latency threshold; when the number of contracts to be processed in the business shard exceeds the preset business shard expansion threshold and the real-time block generation interval is greater than the upper limit of the dynamic block generation interval, then give priority to performing business shard splitting and then trigger a node expansion instruction.

[0012] Further, the method for reallocating the contracts to be processed through the consistent hashing algorithm includes:

[0013] Real-time monitor the real-time load status and historical contract processing efficiency of the nodes within the business shard, calculate the real-time load weight of the real-time load status through a weighted algorithm, and construct a dynamic allocation priority in combination with the communication latency and historical contract processing efficiency; the real-time load status includes CPU utilization rate, memory usage rate, and network bandwidth occupancy rate, and the historical contract processing efficiency includes average contract processing latency and block packaging success rate.

[0014] Obtain the task complexity of the contracts to be processed and the node resource capacity and perform matching, and preferentially allocate high-task-complexity contracts to nodes whose real-time load weight is greater than the preset load weight threshold and whose resource capacity is greater than the preset resource capacity threshold.

[0015] Obtain the block packaging success rate and contract processing latency of the nodes within the business shard according to the preset statistical period. If the contract processing latency of a node exceeds the preset ratio threshold of the average processing latency within the business shard for multiple consecutive statistical periods, then trigger a load rebalancing operation of the nodes within the business shard, migrate some contracts to be processed to low-latency nodes according to the contract type label, and update the consistent hashing mapping table.

[0016] Further, the method for triggering the load rebalancing operation of the nodes within the business shard includes:

[0017] Construct a dynamic performance scoring model for nodes by obtaining the historical contract processing latency, real-time CPU utilization, memory usage, block packing success rate, and network jitter rate of nodes within a business shard as performance metrics; screen out a set of high-performance nodes within the business shard according to the dynamic performance scoring model, and calculate the target node matching degree of the contract to be migrated, where the matching degree is obtained through data analysis of the remaining resource capacity of the target node, the associated processing efficiency with the contract type label, and the real-time communication latency.

[0018] Prioritize migrating contracts with high task complexity to high-performance nodes whose matching degree exceeds a preset matching degree threshold, and at the same time add dynamic priority labels to the migrated contracts to ensure their priority processing in the block packing queue of the target node; after the migration is completed, dynamically update the weight allocation relationship between nodes and contract types in the consistent hashing mapping table according to the migration results.

[0019] Furthermore, the method further includes:

[0020] Generate an initial performance score for the node by weighted fusion of the performance metrics; according to the change trend of the node performance metrics within a preset time window, use a moving average algorithm to dynamically correct the scoring weights, where the weights of the historical contract processing latency and the network jitter rate are adaptively adjusted according to the fluctuation range of the real-time load.

[0021] When a node processes a new contract type, according to the similarity between the contract type label and the node's historical processing records, introduce an incremental learning mechanism to update the dynamic performance scoring model to ensure that the scoring prediction error of the dynamic performance scoring model for the new contract type is lower than a preset scoring prediction error threshold.

[0022] Compare the performance score of the node with the average performance score of the nodes within the business shard. If the performance score of the node is continuously lower than the average performance score of the nodes within the business shard and the resource utilization rate is continuously higher than the business shard average, mark it as an inefficient node and trigger a resource expansion warning, and at the same time reduce the contract allocation weight of the node in the load rebalancing operation.

[0023] Furthermore, the method of introducing an incremental learning mechanism to update the dynamic performance scoring model to ensure that the scoring prediction error of the dynamic performance scoring model for the new contract type is lower than a preset scoring prediction error threshold includes:

[0024] When a node processes a new contract type for the first time, record the contract type label and the actual processing latency and resource consumption characteristics as incremental training samples, and judge whether to trigger the update of the dynamic performance scoring model according to a preset confidence threshold.

[0025] Construct an implicit association between the contract type features and the node performance metrics through a lightweight neural network, and fine-tune the lightweight neural network using the incremental training samples.

[0026] After the fine-tuning is completed, use the shadow model to compare the scoring prediction errors of the dynamic performance scoring model for the new contract type before and after the update. If the scoring prediction error is lower than the preset scoring prediction error threshold, roll back to the state before the update and mark that the contract type requires manual intervention.

[0027] If the reduction amplitude of the error is greater than or equal to the preset error reduction amplitude threshold, dynamically adjust the association weight between the contract type label and the node in the dynamic performance scoring model, and feedback the association processing efficiency of the new contract type to the matching degree calculation of the load rebalancing operation.

[0028] Furthermore, the method of using the shadow model to compare the scoring prediction errors of the dynamic performance scoring model for the new contract type before and after the update includes:

[0029] Construct a shadow model with the same structure as the current dynamic performance scoring model. The shadow model loads the parameters before and after the update respectively and accesses the same historical contract processing data set.

[0030] Input the incremental training samples of the new contract type into each shadow model, record the absolute error between its predicted processing delay and the actual processing delay, and calculate the error volatility of each shadow model.

[0031] If the error volatility of the dynamic performance scoring model after the update is lower than the preset error volatility threshold, set the dynamic performance scoring model after the update as the main scoring model; otherwise, retain the dynamic performance scoring model before the update and generate an exception type report, which includes the contract type label, resource consumption characteristics, and error distribution data.

[0032] Furthermore, the method of dividing the online shopping contract into business shards according to the business type includes:

[0033] Parse the keyword fields in the contract text through a predefined contract type label rule library to determine the business type; among them, the keyword fields include the contract subject, service terms, payment method, logistics identifier, and after-sales terms, and classify the contract into the payment contract shard, logistics contract shard, and after-sales contract shard according to the semantic similarity matching algorithm.

[0034] For a hybrid contract containing cross-business type clauses, calculate the association degree score of each business type according to the clause weight distribution model, allocate the contract to the business shard with the highest score, and record the cross-shard index of the hybrid contract in the blockchain at the same time.

[0035] The contract type label rule library is dynamically updated through an offline-trained classification model, and the classification model is iteratively optimized according to the historical contract data and the manually labeled contract type labels.

[0036] Further, the method for predicting the number of contracts to be processed through a pre-trained LSTM model includes:

[0037] Obtain the historical contract generation data of the business shard, and extract the contract quantity sequence, contract type distribution, and node resource occupancy rate within the time window as input features to construct the training dataset of the LSTM model.

[0038] Pre-train the LSTM model. The network structure of the LSTM model includes two hidden layers, and the number of neurons in each layer is twice the dimension of the input features. The hyperparameters are optimized using sliding time window cross-validation.

[0039] Take the contract quantity within the current time window, the average communication delay of nodes within the business shard, and the block packaging success rate as real-time inputs, and output the predicted number of contracts to be processed within a preset future time period through the LSTM model.

[0040] On the other hand, based on the same inventive concept, the present invention embodiment also provides an online shopping contract generation system based on a blockchain. The system includes: a business shard management module, a block generation interval analysis module, and a contract generation management module, and the modules are communicatively connected in sequence;

[0041] The business shard management module is used to divide the online shopping contracts by business type to obtain business shards, and real-time monitor the number of contracts to be processed in each business shard. When the number of contracts to be processed in a business shard exceeds the preset business shard expansion threshold, the business shard is split into multiple sub-business shards, and independent nodes are assigned to each sub-business shard.

[0042] The block generation interval analysis module is used to obtain the current number of contracts to be processed in the business shard and predict the number of contracts to be processed through a pre-trained LSTM model, dynamically adjust the block parameters of the business shard according to the predicted number of contracts to be processed, monitor the communication delay and block packaging success rate of nodes within the business shard, and dynamically adjust the real-time block generation interval. When the real-time block generation interval is greater than the dynamic block generation interval upper limit, the minimum allowable block generation interval is adopted and a node expansion instruction is triggered.

[0043] The contract generation management module is used to dynamically add verification nodes to the business shard according to the node expansion instruction, and reallocate the contracts to be processed through the consistent hashing algorithm until the generation delay of the contracts to be processed is less than the preset maximum tolerance delay threshold; when the number of contracts to be processed in the business shard exceeds the preset business shard expansion threshold and the real-time block generation interval is greater than the dynamic block generation interval upper limit, the business shard split is preferentially executed, and then the node expansion instruction is triggered.

[0044] (3) Beneficial effects

[0045] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0046] 1. Through the mechanism of dynamic splitting of business shards and node expansion, combined with the LSTM prediction model to accurately predict the number of contracts to be processed, horizontal resource expansion and vertical parameter tuning are realized, the contract generation delay is reduced to within the preset maximum tolerance delay threshold, effectively coping with traffic peaks; and according to the dynamic load balancing of the consistent hashing algorithm and the intelligent matching of high-performance nodes, the contract generation efficiency in high-concurrency scenarios is significantly improved.

[0047] 2. By fusing multi-dimensional performance indicators to construct a dynamic performance scoring model, and combining the incremental learning mechanism and shadow model verification to accurately quantify the node processing ability, ensuring the scoring reliability under new contract types and node performance fluctuations, effectively reducing the resource mismatch rate and optimizing the resource utilization rate. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 It is a flowchart of a method for generating an online shopping contract based on blockchain according to Embodiment 1 of the present invention.

[0049] Figure 2 It is a schematic diagram of the module composition of a system for generating an online shopping contract based on blockchain according to Embodiment 2 of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0050] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0051] Before giving examples, it is necessary to elaborate on the application scenario of the inventive concept. The present invention is a method and system for generating online shopping contracts based on blockchain. During a major promotion period on an online shopping platform, the number of daily orders exceeded 100,000. The platform adopted a smart contract system based on blockchain to automatically generate shopping contracts, covering payment, logistics, and after-sales links. However, during peak hours, users frequently encountered the "contract generation timeout" prompt, and some orders became invalid due to the failure of the contract to be timely uploaded to the blockchain, resulting in a large number of customer complaints. Among them, for payment contracts, due to the fixed sharding rules, all were concentrated in the same shard for processing, resulting in the accumulation of more than 10,000 contracts to be processed in this shard. The block production interval of the node extended from an average of 2 seconds to 15 seconds, and users had to wait for more than 3 minutes to obtain the confirmation of the contract being uploaded to the blockchain, far exceeding the 30-second standard promised by the platform. In the shard of logistics contracts, some nodes had insufficient hardware performance (such as the CPU of old servers being fully loaded), and the processing delay for complex logistics contracts was as high as 8 seconds per pen. However, high-performance nodes were restricted by the static hash allocation strategy and only processed simple contracts, with a resource utilization rate of less than 40%. And a large number of orders included mixed terms of "payment + logistics + limited-time return and exchange", and all of them were classified into the payment shard, resulting in a soaring load of the payment shard, while the idle rate of the logistics and after-sales shards exceeded 60%, and the overall throughput decreased to 35% of the peak period. The original plan of the online shopping platform was to temporarily expand the capacity by adding server nodes, but due to uneven load distribution after the nodes were added, some new nodes did not adapt to high-complexity contracts, which instead caused more transaction rollbacks. Eventually, a large number of orders were lost due to contract processing delays.

[0052] Embodiment 1: As Figure 1 shown, this embodiment provides a method for generating an online shopping contract based on blockchain, and the method includes:

[0053] S1. Divide the online shopping contracts by business type to obtain business shards, and monitor the number of contracts to be processed in each business shard in real time. When the number of contracts to be processed in a business shard exceeds the preset business shard expansion threshold, split the business shard into multiple sub-business shards, and allocate independent nodes to each sub-business shard; each business shard consists of a group of blockchain nodes, which are responsible for processing the generation, verification, and storage of the same type of contracts. When the number of contracts to be processed in a certain business shard exceeds the preset expansion threshold, it indicates that the current processing capacity of this business shard is approaching saturation, and an expansion operation is required. Allocate independent nodes to each sub-business shard to increase the parallel processing ability. For example, the system of the online shopping platform will continuously count the number of contracts to be processed in each business shard (such as the payment shard currently has 10,000 backlogged contracts). Preset the business shard expansion threshold (for example, the threshold for the payment shard is 8,000 contracts). When it is detected that the number of contracts to be processed exceeds the threshold (such as 10,000 > 8,000), trigger the shard split. Split the original business shard into multiple sub-business shards (such as splitting the payment shard into payment sub-shards A and B). Node allocation is to allocate independent node groups to each sub-business shard (such as allocating nodes 1 - 3 to sub-shard A and nodes 4 - 6 to sub-shard B), and the sub-business shards process contract tasks in parallel.

[0054] S2. Obtain the current number of contracts to be processed in the business shard and predict the predicted number of contracts to be processed through a pre-trained LSTM model. Dynamically adjust the block parameters of the business shard according to the predicted number of contracts to be processed, monitor the communication delay and block packaging success rate of the nodes within the business shard, and dynamically adjust the real-time block production interval. When the real-time block production interval is greater than the dynamic block production interval upper limit, then adopt the minimum allowable block production interval and trigger the node expansion instruction; the communication delay and block packaging success rate of the nodes within the business shard directly reflect the health status of the network and the processing ability of the nodes. The real-time block production interval is the time interval between the creation of a block and its addition to the blockchain. If the real-time block production interval exceeds the preset dynamic block production interval upper limit, it indicates that the network may be congested or the processing ability of the nodes is insufficient. Then adjust the block production interval to the minimum allowable block production interval to speed up the generation of blocks, and trigger the node expansion instruction, that is, add more nodes to the business shard to improve the overall processing ability. The minimum allowable block production interval is determined by the system hardware performance and network bandwidth of the online shopping platform. For example, the system hardware performance limit is the minimum time-consuming for the node CPU / memory to process transactions (such as single block verification takes 0.3 seconds). The network limit is the minimum time required for block broadcasting (such as the whole network node synchronization takes 0.2 seconds). The comprehensive minimum allowable block production interval is 0.5 seconds.

[0055] S3. Dynamically add verification nodes to the business shard according to the node expansion instruction, and re - distribute the contracts to be processed through the consistent hashing algorithm until the generation delay of the contracts to be processed is less than the preset maximum tolerance delay threshold; when the number of contracts to be processed in the business shard exceeds the preset business shard expansion threshold and the real - time block generation interval is greater than the upper limit of the dynamic block generation interval, the business shard splitting is preferentially executed, and then the node expansion instruction is triggered. The consistent hashing algorithm is an implementation method of a distributed hash table (DHT). When nodes are dynamically added or removed, it tries to maintain the stability and balance of data distribution. Through the consistent hashing algorithm, the contracts to be processed can be evenly distributed to each node, avoiding the situation where some nodes are overloaded while others are idle. The re - distribution process will continue until the generation delay of the contracts to be processed is reduced below the preset maximum tolerance delay threshold. The maximum tolerance delay threshold is set according to business requirements and user experience, ensuring that the speed and efficiency of contract processing can meet user requirements. When the number of contracts to be processed in the business shard exceeds the preset business shard expansion threshold and the real - time block generation interval is greater than the upper limit of the dynamic block generation interval, the business shard splitting is preferentially executed, and then the node expansion instruction is triggered because in this case, simply adding nodes may not effectively solve the problem as the processing capacity of the business shard itself has reached its limit. Therefore, it is necessary to first reduce the load of each shard by splitting the shards and then further improve the processing capacity by adding nodes.

[0056] The method of re - distributing the contracts to be processed through the consistent hashing algorithm includes:

[0057] Real-time monitor the real-time load status and historical contract processing efficiency of nodes within a business shard. Calculate the real-time load weight through a weighted algorithm for the real-time load status, and construct a dynamic allocation priority by combining communication latency and historical contract processing efficiency. The real-time load status includes CPU utilization, memory usage, and network bandwidth occupancy. The historical contract processing efficiency includes average contract processing latency and block packaging success rate. CPU utilization, memory usage, and network bandwidth occupancy are important indicators to measure the current processing capacity of nodes. CPU utilization reflects the usage of computing resources of nodes, memory usage indicates whether the storage resources of nodes are tight, and network bandwidth occupancy is related to the communication efficiency between nodes. Average contract processing latency reflects the speed at which nodes process contracts, and the block packaging success rate directly reflects the activity and reliability of nodes in the blockchain network. The real-time load weight comprehensively considers the real-time load status and historical contract processing efficiency of nodes, and is an indicator that comprehensively measures the current processing capacity and historical performance of nodes. Combine communication latency (i.e., the time delay of information transmission between nodes) and the real-time load weight to construct a dynamic allocation priority for each node, which is used to determine which nodes to prioritize when performing resource allocation or task scheduling in the future. Specifically, nodes with low load, high processing efficiency, and small communication latency will be given higher priorities because they are more likely to provide stable and efficient services in the future. On the contrary, nodes with high load, low processing efficiency, or large communication latency will be given lower priorities, and their workload will be reduced or operations such as capacity expansion will be carried out. For example, there are two business shard nodes A and B. The CPU utilization of node A is 50%, the memory usage is 60%, the network bandwidth occupancy is 40%, the average contract processing latency is 2 seconds, and the block packaging success rate is 95%. For node B, the CPU utilization is 80%, the memory usage is 90%, the network bandwidth occupancy is 70%, the average contract processing latency is 5 seconds, and the block packaging success rate is 80%. First, standardize or normalize the data and then calculate the real-time load weights of nodes A and B through a weighted algorithm. Since the indicators of node A are all better than those of node B, node A is given a higher real-time load weight. Then, considering the communication latency factor, assume that the average communication latency between node A and other nodes in the network is 10 milliseconds, while the average communication latency of node B is 20 milliseconds. Since the communication latency of node A is also smaller, the dynamic allocation priority of node A is higher.

[0058] Obtain the task complexity of the contract to be processed and the node resource capacity and match them. First, allocate contracts with high task complexity to nodes whose real-time load weight is greater than the preset load weight threshold and whose resource capacity is greater than the preset resource capacity threshold; the task complexity is a comprehensive indicator, including the size of the contract, the amount of computing resources required, and the estimated processing time, which reflects the resource and time costs required to process this contract. The resource capacity of a node refers to the total amount of resources such as CPU, memory, storage, and network bandwidth currently available on the node, which measures the node's ability to process tasks. First, a preset load weight threshold and a preset resource capacity threshold are set, which are set according to the overall load and resource conditions of the online shopping platform, aiming to ensure the rationality of allocation and the balanced utilization of resources. For contracts with high task complexity, they will be preferentially allocated to nodes whose load weight is lower than the preset load weight threshold and whose resource capacity is greater than the preset resource capacity threshold. This ensures that high-complexity contracts can be processed in a timely manner and improves the overall processing efficiency of the system. Second, by preferentially allocating tasks to low-load nodes, the load of each node can be balanced, avoiding the situation where some nodes are overloaded while others are idle. For example, there are two contracts C1 and C2 to be processed, and two business sharding nodes A1 and A2. The task complexity of contract C1 is relatively high, requiring more computing resources and processing time; while the task complexity of contract C2 is relatively low and is relatively easy to process. The load weight of node A1 is 0.635 (higher than the preset load weight threshold of 0.5), and the resource capacity is 80% (greater than the preset resource capacity threshold of 70%). The load weight of node A2 is 0.47 (lower than the preset load weight threshold of 0.5), and the resource capacity is 60% (lower than the preset resource capacity threshold of 70%). Then, the high-task-complexity contract C1 is preferentially allocated to node A1. Because node A1 has sufficient processing power and idle resources to efficiently process contract C1, while node A2 is not suitable for processing high-complexity contracts due to high load and insufficient resources.

[0059] Obtain the block packaging success rate and contract processing latency of the nodes within the business shard according to a preset statistical period. If the contract processing latency of a node exceeds the preset proportional threshold of the average processing latency within the business shard for multiple consecutive statistical periods, trigger the load rebalancing operation of the nodes within the business shard. Migrate some of the pending contracts to low-latency nodes according to the contract type label, and update the consistent hashing mapping table. Collect the block packaging success rate and contract processing latency data of each node according to a preset statistical period (such as every hour, every day, etc.). These data reflect the processing capabilities and efficiencies of the nodes over a period of time. Calculate the average processing latency of all nodes within the business shard and use it as a benchmark value. For each node, check whether the contract processing latency for multiple consecutive statistical periods exceeds the preset proportional threshold of the average processing latency (such as 1.5 times, 2 times, etc.). The preset proportional threshold is set according to business requirements and the system performance of the online shopping platform, aiming to ensure that measures can be taken in a timely manner when the node processing latency increases significantly. Contract migration is to select some of the pending contracts according to the contract type label (such as classification by contract urgency, size, etc.), migrate them from high-latency nodes to low-latency nodes, ensure that the load on high-latency nodes is reduced, and at the same time, low-latency nodes can use their remaining processing capabilities to efficiently process these contracts. Updating the consistent hashing mapping table ensures that new contracts can be correctly assigned to the corresponding nodes. The consistent hashing algorithm can ensure that when nodes join or leave, the distribution of data remains as stable as possible, reducing the risk of data migration and data loss. The load rebalancing operation ensures that the contract processing latency within the entire shard remains within a reasonable range, thereby improving the overall performance and stability of the system. For example, there is a business shard containing three nodes N1, N2, and N3. The preset statistical period is every day, and the preset proportional threshold is 1.5 times. In the recent three statistical periods, the contract processing latency of node N1 has continuously exceeded 1.5 times the average latency within the shard, then the load rebalancing operation is triggered. First, a part of the pending contracts will be selected for migration from node N1 according to the contract type label. For example, select those contracts with lower urgency and fewer required resources for migration. Then, these contracts will be assigned to node N2 or N3 (assuming their processing latencies are lower).

[0060] The method for triggering the load rebalancing operation of the nodes within the business shard includes:

[0061] A dynamic performance scoring model for nodes is constructed by obtaining the historical contract processing latency, real-time CPU utilization, memory usage, block packing success rate, and network jitter rate of nodes within a business shard as performance metrics; high-performance node sets within the business shard are selected according to the dynamic performance scoring model, and the target node matching degree of the contract to be migrated is calculated. The matching degree is obtained through data analysis of the remaining resource capacity of the target node, the associated processing efficiency with the contract type label, and the real-time communication latency. The network jitter rate evaluates the stability of node network communication. The matching degree is analyzed based on the following factors: The remaining resource capacity of the target node ensures that the target node has sufficient resources to process the migrated contract. The associated processing efficiency with the contract type label selects nodes with high efficiency in processing similar contracts historically as target nodes according to the contract type label. The real-time communication latency considers the communication latency between the target node and the current node to ensure that the migrated contract can perform data transmission and synchronization efficiently. A matching degree score is calculated comprehensively based on these factors to guide the contract migration decision. For example, there is a business shard containing four nodes A, B, C, and D. Through the dynamic performance scoring model, it is calculated that nodes A and B have higher performance scores, while the performance scores of nodes C and D are lower. Now there is a contract F to be migrated, and its type label indicates that a node with a large amount of computing resources and stable network communication is required to process it. The system starts to calculate the matching degree of contract F with the target nodes (A, B, C, D): For node A, it has a high remaining resource capacity, high efficiency in processing similar contracts historically, and low real-time communication latency, so the matching degree with contract F is very high. For node B, although its performance is also good, due to the fact that it is currently processing a large number of high-priority contracts and the remaining resource capacity is relatively small, the matching degree with contract F is slightly lower than that of node A. For nodes C and D, due to their low performance scores, limited remaining resource capacity, and low efficiency in processing similar contracts historically, the matching degree with contract F is very low. Then it is decided to migrate contract F to node A for processing. This can not only ensure the efficient processing of the contract, but also make full use of the remaining resources of node A, while avoiding bringing an additional burden to nodes with lower performance.

[0062] Prioritize the migration of high-task-complexity contracts to high-performance nodes whose matching degree exceeds a preset matching degree threshold. At the same time, add dynamic priority tags to the migrated contracts to ensure their priority processing in the block packaging queue of the target node. After the migration is completed, dynamically update the weight distribution relationship between nodes and contract types in the consistent hashing mapping table. The consistent hashing mapping table records the weight distribution relationship between nodes and contract types. Updating the consistent hashing mapping table can ensure that subsequent contracts can take into account the results of previous migrations when being allocated, so as to more accurately select the target node. For example, a certain business shard contains three high-performance nodes E, F, and G, and a high-task-complexity contract H to be migrated. The matching degrees of nodes E, F, and G with contract H have been calculated as 0.85, 0.70, and 0.60 respectively, and the preset matching degree threshold is 0.75. Then only the matching degree of node E exceeds the preset threshold, so contract H will be migrated to node E. After the migration, a dynamic priority tag will be added to contract H, indicating that it has a high priority in the block packaging queue of node E. Subsequently, the consistent hashing mapping table will be updated to increase the weight of node E for processing contracts of type H similar to contract H. In this way, when subsequent similar contracts need to be allocated, the system will be more inclined to select node E as the target node.

[0063] The method further includes:

[0064] Generate the initial performance score of a node by weighted fusion of performance metrics; according to the change trend of the node's performance metrics within a preset time window, use the moving average algorithm to dynamically correct the scoring weights, where the weights of historical contract processing latency and network jitter rate are adaptively adjusted according to the fluctuation amplitude of the real-time load; assign a weight to each performance metric, and the weight reflects the importance of each metric to the overall performance of the node. The preset time window is used to observe the change trend of the node's performance metrics, and the moving average algorithm is used to calculate the average value of each performance metric to smooth out short-term fluctuations, and the weights of each performance metric are dynamically adjusted according to the change trend of the average value. When the fluctuation amplitude of the real-time load is large, the weights of historical contract processing latency and network jitter rate can be adaptively increased because these metrics can better reflect the stability and reliability of the node during load fluctuations. By dynamically correcting the scoring weights, it can be ensured that the performance score of the node more accurately reflects the current real-time performance. For example, the initial weights of the CPU utilization rate, memory usage rate, block packaging success rate, historical contract processing latency, and network jitter rate of a node I are 0.3, 0.2, 0.1, 0.25, and 0.15 respectively. At a certain moment, the fluctuation amplitude of the real-time load of node I is large, resulting in a significant increase in the values of these two metrics, historical contract processing latency and network jitter rate. In this case, the average values of these two metrics within the preset time window are calculated according to the moving average algorithm, and it is observed that these average values are also increasing. According to the observation results, the weights of historical contract processing latency and network jitter rate are adaptively increased, for example, their weights are adjusted to 0.35 and 0.2 respectively, and at the same time, the weights of other metrics are correspondingly reduced to keep the total weight at 1. Through this dynamic adjustment, it can be ensured that in the case of large load fluctuations, the performance score of node I focuses more on reflecting its stability and reliability, thus more accurately evaluating its current performance.

[0065] When the node processes a new contract type, according to the similarity between the contract type label and the node's historical processing records, introduce an incremental learning mechanism to update the dynamic performance scoring model to ensure that the scoring prediction error of the dynamic performance scoring model for the new contract type is lower than the preset scoring prediction error threshold; the similarity is calculated by comparing the feature vectors of the contract type labels with the feature vectors of the contract type labels in the node's historical processing records. Incremental learning allows the model to be gradually updated when new data is received without having to retrain the entire model, thus improving the learning efficiency and adaptability.

[0066] Compare the performance score of a node with the average performance score of nodes within a business shard. If the performance score of the node is continuously lower than the average performance score of nodes within the business shard and its resource utilization rate is continuously higher than the average of the business shard, mark it as an inefficient node and trigger a resource expansion warning. At the same time, reduce the contract allocation weight of the node during the load rebalancing operation. The resource expansion warning indicates that the system of the online shopping platform needs to increase the resources (such as CPU, memory, storage, etc.) of the node to improve its processing ability. For example, there is a business shard containing nodes J, K, and L, all processing different types of contracts. A new contract type M is introduced, and the ability of node J to handle this new contract type needs to be evaluated. First, evaluate its potential ability based on the similarity between the label of contract type M and the historical processing records of node J. Assume the similarity is high, indicating that node J may have the ability to handle the new contract type M. Then, use the incremental learning mechanism to update the dynamic performance scoring model to include the scoring prediction for the new contract type M. Through incremental learning, it can be ensured that the scoring prediction error for the new contract type M is lower than the preset scoring prediction error threshold. During continuous monitoring, it is found that the performance score of node K is continuously lower than the average performance score of nodes within the business shard, and its resource utilization rate is continuously higher than the average of the business shard. Therefore, node K is marked as an inefficient node. Triggering the resource expansion warning indicates that the system needs to increase the resources of node K. At the same time, in subsequent load rebalancing operations, the contract allocation weight of node K is reduced to reduce its contract processing burden and allocate more contracts to other high-performance nodes (such as node J or L) for processing.

[0067] The method for updating the dynamic performance scoring model by introducing the incremental learning mechanism to ensure that the scoring prediction error of the dynamic performance scoring model for the new contract type is lower than the preset scoring prediction error threshold includes:

[0068] When a node first processes a new contract type, record the contract type label, actual processing delay, and resource consumption characteristics as incremental training samples, and determine whether to trigger the update of the dynamic performance scoring model according to a preset confidence threshold; the confidence threshold is preset according to the system stability and accuracy requirements of the online shopping platform.

[0069] Construct an implicit association between the contract type features and the node performance metrics through a lightweight neural network, and fine-tune the lightweight neural network using the incremental training samples; the purpose of fine-tuning is to update the evaluation of the processing ability of the dynamic performance scoring model for the new contract type.

[0070] After the fine-tuning is completed, use a shadow model to compare the scoring prediction errors of the dynamic performance scoring model for the new contract type before and after the update. If the scoring prediction error is lower than the preset scoring prediction error threshold, roll back to the state before the update and mark that the contract type requires manual intervention;

[0071] If the reduction amplitude of the error is greater than or equal to the preset error reduction amplitude threshold, the association weight between the contract type label and the node in the dynamic performance scoring model is dynamically adjusted, and the association processing efficiency of the new contract type is fed back to the matching degree calculation of the load rebalancing operation. For example, there is a business shard containing nodes A, B, and C, a new contract type N is introduced, and the ability of node A to process this new contract type needs to be evaluated. When node A processes contract type N for the first time, the label of this contract type, the actual processing delay (such as 5 seconds), and the resource consumption characteristics (such as CPU usage rate of 80% and memory occupancy of 60%) will be recorded. It is judged whether to trigger the update of the dynamic performance scoring model according to the preset confidence threshold (such as 90%). Suppose the confidence reaches 95% at this time, so the model update is triggered. An implicit association between the characteristics of contract type N and the performance metrics of node A is constructed using a lightweight neural network, and the neural network is fine-tuned using the above incremental training samples. After the fine-tuning is completed, a shadow model is used to compare the scoring prediction errors of the dynamic performance scoring model before and after the update for contract type N. Suppose the prediction error before the update is 10%, and the prediction error after the update is reduced to 5%. Since the scoring prediction error of the updated model is lower than the preset scoring prediction error threshold (such as 8%), and the reduction amplitude of the error is greater than or equal to the preset error reduction amplitude threshold (such as 3%), the updated model is retained. The association weight between contract type N and node A in the dynamic performance scoring model is dynamically adjusted, and the association processing efficiency of the new contract type N (such as the average processing delay is 5 seconds) is fed back to the matching degree calculation of the load rebalancing operation. Then, when allocating subsequent contracts, it is more inclined to allocate contracts similar to contract type N to node A for processing.

[0072] The method of using a shadow model to compare the scoring prediction errors of the dynamic performance scoring model for the new contract type before and after the update includes:

[0073] Construct a shadow model with the same structure as the current dynamic performance scoring model. The shadow model loads the parameters before and after the update respectively and accesses the same historical contract processing dataset; so as to compare the performance under the same conditions.

[0074] Input the incremental training samples of the new contract type into each shadow model, record the absolute error between its predicted processing delay and the actual processing delay, and calculate the error volatility of each shadow model; the error volatility measures the fluctuation degree of the model prediction error, that is, an index of prediction stability, and a low volatility indicates that the model prediction is relatively stable.

[0075] If the error volatility of the updated dynamic performance scoring model is lower than the preset error volatility threshold, then set the updated dynamic performance scoring model as the main scoring model; otherwise, retain the pre-updated dynamic performance scoring model and generate an exception type report, which includes contract type labels, resource consumption characteristics, and error distribution data. Two shadow models are created: one loads the pre-updated parameters and the other loads the updated parameters. These two shadow models are verified using the same historical contract dataset. A batch of incremental training samples containing new contract types are collected and input into the two shadow models, and the absolute errors between their predicted processing delays and actual processing delays are recorded. Calculate the error volatility and stability index: It is found that the error volatility of the updated model is 5%, which is 10% lower than the preset error volatility threshold. Since the updated model has better error volatility than the pre-updated model, it is decided to adopt the updated model as the main scoring model.

[0076] The method for dividing an online shopping contract into business shards according to business types includes:

[0077] Parse the keyword fields in the contract text to determine the business type through a predefined contract type label rule library; among them, the keyword fields include contract parties, service terms, payment methods, logistics identifiers, and after-sales terms, and classify the contracts into payment contract shards, logistics contract shards, and after-sales contract shards according to the semantic similarity matching algorithm; the semantic similarity matching algorithm is based on the text content of the keyword fields and uses natural language processing technology to evaluate the similarity with predefined contract types.

[0078] For a hybrid contract containing cross-business type clauses, calculate the correlation score of each business type according to the clause weight distribution model, and assign the contract to the business shard with the highest score. At the same time, record the cross-shard index of the hybrid contract in the blockchain; the cross-shard index is to maintain the integrity and traceability of contract information and helps to quickly locate all relevant information of the contract when needed.

[0079] The contract type tag rule library is dynamically updated through a classification model trained offline. The classification model is iteratively optimized based on historical contract data and manually annotated contract type tags. For example, there is a contract text that contains both detailed information about product delivery and logistics, as well as mentions of payment methods and after-sales service policies. Contract parsing and preliminary classification: First, identify the key fields in the contract, such as "product delivery", "logistics cost", "credit card payment", and "30-day return and exchange policy". Through semantic similarity matching, it is preliminarily determined that this contract may be related to logistics, payment, and after-sales business types at the same time. For hybrid contract processing, a clause weight distribution model is used to calculate that the correlation score of this contract with the logistics business type is 75 points, the correlation score with the payment business type is 65 points, and the correlation score with the after-sales business type is 60 points. Therefore, this contract is assigned to the logistics contract shard, and its cross-shard index is recorded in the blockchain so that relevant terms information related to payment and after-sales can be accessed when needed. Over time, more similar hybrid contract data is collected, and the contract type tags are updated through manual annotation. These new data are used to train and optimize the classification model to improve its classification accuracy for hybrid contracts and other complex contract types.

[0080] The method for predicting the number of contracts to be processed by a pre-trained LSTM model includes:

[0081] Obtain the historical contract generation data of the business shard, and extract the contract quantity sequence, contract type distribution, and node resource occupancy rate within the time window as input features to construct the training dataset of the LSTM model; the historical contract generation data contains information about the contract quantity, contract type, and node resource occupancy rate. Extract the contract quantity sequence, contract type distribution (the proportion or quantity of various contracts), and node resource occupancy rate within the time window from these data as input features. These features jointly describe the historical state and trend of the business shard.

[0082] Pre-train the LSTM model. The network structure of the LSTM model contains two hidden layers, and the number of neurons in each layer is twice the dimension of the input features. The hyperparameters are optimized using sliding time window cross-validation; by sliding the window on the time series data to create the training set and validation set, the performance of the model in different time periods can be evaluated, and the hyperparameters can be adjusted accordingly to improve the generalization ability of the model.

[0083] Take the contract quantity within the current time window, the average communication delay of the nodes within the business shard, and the block packaging success rate as real-time inputs, and output the predicted number of contracts to be processed within a preset future time period through the LSTM model.

[0084] Embodiment 2: Based on the same inventive concept, such as Figure 2As shown in the figure, this embodiment also provides an online shopping contract generation system based on blockchain. The system includes: a business sharding management module, a block generation interval analysis module, and a contract generation management module, and the modules are communicatively connected in sequence;

[0085] The business sharding management module is used to divide the online shopping contract into business shards according to the business type, and monitor the number of contracts to be processed in each business shard in real time. When the number of contracts to be processed in a business shard exceeds the preset business shard expansion threshold, the business shard is split into multiple sub-business shards, and an independent node is assigned to each sub-business shard;

[0086] The block generation interval analysis module is used to obtain the current number of contracts to be processed in the business shard and predict the predicted number of contracts to be processed through a pre-trained LSTM model, dynamically adjust the block parameters of the business shard according to the predicted number of contracts to be processed, monitor the communication delay and block packaging success rate of the nodes in the business shard, and dynamically adjust the real-time block generation interval. When the real-time block generation interval is greater than the dynamic block generation interval upper limit, the minimum allowable block generation interval is adopted and a node expansion instruction is triggered;

[0087] The contract generation management module is used to dynamically add verification nodes to the business shard according to the node expansion instruction, and reallocate the contracts to be processed through the consistent hashing algorithm until the generation delay of the contracts to be processed is less than the preset maximum tolerance delay threshold; when the number of contracts to be processed in the business shard exceeds the preset business shard expansion threshold and the real-time block generation interval is greater than the dynamic block generation interval upper limit, the business shard split is preferentially executed, and then the node expansion instruction is triggered.

[0088] It should be noted that regarding the system in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment related to the method, and will not be elaborated here.

[0089] Finally, it should be noted that although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A method for generating an online shopping contract based on blockchain, characterized in that: The method comprises: Online shopping contracts are divided into business slices according to business types, and the number of pending contracts in each business slice is monitored in real time. When the number of pending contracts in a business slice exceeds the preset business slice expansion threshold, the business slice is split into multiple sub-business slices, and an independent node is allocated to each sub-business slice; Obtain the current number of pending contracts in the business shard and predict the predicted number of pending contracts through the pre-trained LSTM model. Dynamically adjust the block parameters of the business shard based on the predicted number of pending contracts, monitor the communication delay and block packaging success rate of the nodes in the business shard, and dynamically adjust the real-time block interval. When the real-time block interval is greater than the upper limit of the dynamic block interval, the minimum allowed block interval is used and the node expansion instruction is triggered; Dynamically add verification nodes to the business shard according to the node expansion instruction, and redistribute pending contracts through the consistent hashing algorithm until the pending contract generation delay is less than the preset maximum tolerance delay threshold; when the number of pending contracts in the business shard exceeds the preset business shard expansion threshold and the real-time block interval is greater than the upper limit of the dynamic block interval, the business shard splitting is executed first, and then the node expansion instruction is triggered.

2. According to the blockchain-based online shopping contract generation method of claim 1, it is characterized in that: The method for redistributing pending contracts by using a consistent hashing algorithm includes: Monitor the real-time load status and historical contract processing efficiency of nodes in the business shard in real time, calculate the real-time load weight through a weighted algorithm, and build a dynamic allocation priority based on the communication delay and historical contract processing efficiency; the real-time load status includes CPU utilization, memory utilization, and network bandwidth occupancy, and the historical contract processing efficiency includes average contract processing delay and block packaging success rate; Obtain the task complexity of the contract to be processed and the node resource capacity and match them, and preferentially assign high task complexity contracts to nodes whose real-time load weight is greater than the preset load weight threshold and whose resource capacity is greater than the preset resource capacity threshold; The nodes in the business shard are calculated based on the preset statistical period to obtain the block packaging success rate and contract processing delay of the nodes. If the contract processing delay of the node for multiple consecutive statistical periods exceeds the preset proportional threshold of the average processing delay in the business shard, the load rebalancing operation of the nodes in the business shard is triggered, and some pending contracts are migrated to low-latency nodes according to the contract type label, and the consistent hash mapping table is updated.

3. According to claim 2, a method for generating an online shopping contract based on blockchain, characterized in that: The method for triggering a load rebalancing operation of a node within a service slice includes: A dynamic performance scoring model for nodes is constructed by obtaining the historical contract processing delay, real-time CPU utilization and memory usage, block packaging success rate and network jitter rate of nodes in the business shard as performance indicators; a set of high-performance nodes in the business shard is screened out according to the dynamic performance scoring model, and the target node matching degree of the contract to be migrated is calculated, and the matching degree is obtained by data analysis of the remaining resource capacity of the target node, the associated processing efficiency with the contract type label and the real-time communication delay; Prioritize migrating high-task complexity contracts to high-performance nodes whose matching degree exceeds the preset matching degree threshold. At the same time, add dynamic priority tags to the migrated contracts to ensure that they are given priority in the block packaging queue of the target node. After the migration is completed, the weight distribution relationship between nodes and contract types in the consistent hash mapping table is dynamically updated according to the migration results.

4. According to claim 3, a method for generating an online shopping contract based on blockchain, characterized in that: The method further comprises: The performance indicators are weighted and integrated to generate the initial performance score of the node. According to the changing trend of the node performance indicators within the preset time window, the sliding average algorithm is used to dynamically correct the score weight, in which the weights of the historical contract processing delay and the network jitter rate are adaptively adjusted according to the real-time load fluctuation amplitude. When a node processes a new contract type, an incremental learning mechanism is introduced to update the dynamic performance scoring model based on the similarity between the contract type label and the node's historical processing record to ensure that the dynamic performance scoring model's score prediction error for the new contract type is lower than the preset score prediction error threshold; The performance score of the node is compared with the average performance score of the nodes in the business shard. If the performance score of the node is continuously lower than the average performance score of the nodes in the business shard and the resource utilization rate is continuously higher than the business shard average, it is marked as an inefficient node and a resource expansion warning is triggered. At the same time, the contract allocation weight of the node is reduced in the load rebalancing operation.

5. According to the method for generating an online shopping contract based on blockchain in claim 4, it is characterized in that: The method of introducing an incremental learning mechanism to update the dynamic performance scoring model to ensure that the scoring prediction error of the dynamic performance scoring model for a new contract type is lower than a preset scoring prediction error threshold comprises: When a node processes a new contract type for the first time, it records the contract type label and actual processing delay and resource consumption characteristics as incremental training samples, and determines whether to trigger the dynamic performance scoring model update based on the preset confidence threshold; Constructing implicit associations between contract type features and node performance indicators through a lightweight neural network, and fine-tuning the lightweight neural network using incremental training samples; After fine-tuning is completed, the shadow model is used to compare the score prediction error of the dynamic performance scoring model for the new contract type before and after the update. If the score prediction error is lower than the preset score prediction error threshold, it is rolled back to the state before the update and the contract type is marked as requiring manual intervention; If the error reduction is greater than or equal to the preset error reduction threshold, the association weight between the contract type label and the node in the dynamic performance scoring model is dynamically adjusted, and the association processing efficiency of the new contract type is fed back to the matching degree calculation of the load rebalancing operation.

6. According to claim 5, a method for generating an online shopping contract based on blockchain, characterized in that: The method of using the shadow model to compare the score prediction error of the dynamic performance scoring model before and after the update for the new contract type includes: Constructing a shadow model that is consistent with the structure of the current dynamic performance scoring model, wherein the shadow model loads parameters before and after the update and accesses the same historical contract processing data set; Input incremental training samples of new contract types into each shadow model, record the absolute error between the predicted processing delay and the actual processing delay, and calculate the error volatility of each shadow model; If the error volatility of the updated dynamic performance scoring model is lower than the preset error volatility threshold, the updated dynamic performance scoring model is set as the main scoring model; otherwise, the dynamic performance scoring model before the update is retained and an abnormal type report is generated, wherein the abnormal type report includes a contract type label, resource consumption characteristics and error distribution data.

7. According to claim 1, a method for generating an online shopping contract based on blockchain, characterized in that: The method for dividing the online shopping contract into business segments according to the business type includes: Through the predefined contract type label rule library, the key fields in the contract text are parsed to determine the business type; wherein the key fields include the contract subject, service terms, payment method, logistics identification and after-sales terms, and the contract is classified into payment contract segment, logistics contract segment and after-sales contract segment according to the semantic similarity matching algorithm; For hybrid contracts containing cross-business type clauses, the relevance scores of each business type are calculated according to the clause weight allocation model, and the contracts are allocated to the business shard with the highest score. At the same time, the cross-shard index of the hybrid contract is recorded in the blockchain; The contract type label rule library is dynamically updated through an offline trained classification model, and the classification model is iteratively optimized based on historical contract data and manually annotated contract type labels.

8. The method for generating an online shopping contract based on blockchain according to claim 1, characterized in that: The method for predicting the number of contracts to be processed by using the pre-trained LSTM model includes: Obtain the historical contract generation data of the business shards, extract the contract quantity sequence, contract type distribution and node resource occupancy rate within the time window as input features, and build the training data set of the LSTM model; Pre-training the LSTM model, wherein the network structure of the LSTM model includes two hidden layers, the number of neurons in each layer is twice the input feature dimension, and a sliding time window cross-validation is used to optimize hyperparameters; The number of contracts in the current time window, the average communication delay of nodes in the business shard, and the block packaging success rate are used as real-time inputs, and the predicted number of contracts to be processed in a future preset time period is output through the LSTM model.

9. A blockchain-based online shopping contract generation system, characterized in that: The system includes: a business slicing management module, a block interval analysis module, and a contract generation management module, and each module is sequentially connected to each other; The business slicing management module is used to divide online shopping contracts into business slicing according to business types, and monitor the number of pending contracts in each business slicing in real time. When the number of pending contracts in a business slicing exceeds the preset business slicing expansion threshold, the business slicing is split into multiple sub-business slicings, and an independent node is allocated to each sub-business slicing; The block interval analysis module is used to obtain the current number of pending contracts in the business shard and predict the predicted number of pending contracts through the pre-trained LSTM model. The block parameters of the business shard are dynamically adjusted according to the predicted number of pending contracts, and the communication delay and block packaging success rate of the nodes in the business shard are monitored. The real-time block interval is dynamically adjusted. When the real-time block interval is greater than the upper limit of the dynamic block interval, the minimum allowed block interval is used and the node expansion instruction is triggered; The contract generation management module is used to dynamically add verification nodes to the business shards according to the node expansion instruction, and redistribute pending contracts through the consistent hashing algorithm until the pending contract generation delay is less than the preset maximum tolerance delay threshold; when the number of pending contracts in the business shard exceeds the preset business shard expansion threshold and the real-time block interval is greater than the upper limit of the dynamic block interval, the business shard splitting is executed first, and then the node expansion instruction is triggered.

Images