Online shopping contract generation method and system based on block chain

Abstract

The invention relates to the field of blockchain contract application, in particular to an online shopping contract generation method and system based on a blockchain, and the method comprises the steps: splitting a business fragment into a plurality of sub-business fragments and distributing independent nodes when monitoring that the number of to-be-processed contracts of each business fragment exceeds a preset business fragment capacity expansion threshold; according to the predicted number of contracts to be processed, dynamically adjusting block parameters of the service fragments and dynamically adjusting a real-time block output interval, and when the real-time block output interval is greater than the upper limit of the dynamic block output interval, adopting a minimum allowable block output interval and triggering a node capacity expansion instruction; redistributing the contract to be processed through a consistent Hash algorithm until the generation delay of the contract to be processed is smaller than a preset maximum tolerance delay threshold value; the problems of online shopping contract accumulation, low resource allocation efficiency and contract confirmation delay are solved, the resource utilization rate is optimized, and the contract generation efficiency in a high-concurrency scene is remarkably improved.

Description

Technical Field

[0001] The present invention relates to the application field of blockchain contracts, and specifically to a method and system for generating an online shopping contract based on blockchain. Background Art

[0002] The real-time generation and security of online shopping contracts have become the core requirements of platform operations. 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 field of contract generation due to its decentralized and tamper-proof characteristics to effectively ensure the security of contracts.

[0003] Although blockchain technology eliminates centralized dependence through consensus mechanisms (such as PoW and PoS), in high-concurrency scenarios, the existing blockchain system still cannot 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, transactions are prone to pile up, resulting in a long contract confirmation time, which affects the efficiency of contract generation. Traditional sharding technology does not fully consider the business type 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 online shopping contract generation method to meet the timeliness requirements of contract generation in high-concurrency scenarios. Summary of the invention

[0005] (1) Technical issues to be resolved The purpose of the present invention is to provide a blockchain-based online shopping contract generation method and system to solve the problem that the business type of the shopping contract is not fully considered in the current blockchain contract generation, which easily leads to the accumulation of similar contracts and inefficient resource allocation. Once high concurrency occurs, the sharding will be overloaded and the contract confirmation delay will increase significantly.

[0006] (2) Technical solution To achieve the above objectives, on the one hand, the present invention provides a method for generating an online shopping contract based on blockchain, the method comprising: S1. Divide online shopping contracts into business slices according to business types, and monitor the number of pending contracts in each business slice 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.

[0007] S2. 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 according to 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.

[0008] S3. 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.

[0009] Furthermore, the method for reallocating 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 the average contract processing delay and block packaging success rate.

[0010] The task complexity of the contract to be processed and the node resource capacity are obtained and matched, and contracts with high task complexity are preferentially assigned 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.

[0011] 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.

[0012] Furthermore, 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. 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.

[0013] 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.

[0014] Furthermore, the method further comprises: The performance indicators are weightedly fused 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, among which the weights of the historical contract processing delay and the network jitter rate are adaptively adjusted with the real-time load fluctuation amplitude.

[0015] 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 records 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.

[0016] 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.

[0017] 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 a new contract type is lower than a preset scoring prediction error threshold includes: When a node processes a new contract type for the first time, it records the contract type label and the actual processing delay and resource consumption characteristics as incremental training samples, and determines whether to trigger the update of the dynamic performance scoring model based on the preset confidence threshold.

[0018] An implicit association between contract type features and node performance indicators is constructed through a lightweight neural network, and the lightweight neural network is fine-tuned using incremental training samples.

[0019] 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.

[0020] 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.

[0021] Furthermore, 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: A shadow model that is consistent with the structure of the current dynamic performance scoring model is constructed, and the shadow model loads parameters before and after the update respectively and accesses the same historical contract processing data set.

[0022] The incremental training samples of the new contract type are input into each shadow model, the absolute error between the predicted processing delay and the actual processing delay is recorded, and the error volatility of each shadow model is calculated.

[0023] 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.

[0024] Furthermore, the method of dividing the online shopping contract by business type to obtain business segments 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.

[0025] For hybrid contracts containing cross-business type clauses, the relevance scores of each business type are calculated according to the clause weight distribution model, and the contracts are assigned 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.

[0026] 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.

[0027] Furthermore, the method for predicting the number of contracts to be processed by using the pre-trained LSTM model includes: The historical contract generation data of the business shards is obtained, and the contract quantity sequence, contract type distribution and node resource occupancy rate within the time window are extracted as input features to construct the training data set of the LSTM model.

[0028] The LSTM model is pre-trained. 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 the sliding time window cross-validation is used to optimize the hyperparameters.

[0029] 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.

[0030] On the other hand, based on the same inventive concept, the present invention also provides a blockchain-based online shopping contract generation system, the system comprising: a business sharding management module, a block generation interval analysis module, and a contract generation management module, and each module is sequentially connected in communication; 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.

[0031] 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.

[0032] 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.

[0033] (3) Beneficial effects Compared with the prior art, the present invention has the following beneficial effects: 1. Through the dynamic splitting of business shards and the node expansion mechanism, combined with the LSTM prediction model, the number of pending contracts is accurately predicted, horizontal resource expansion and vertical parameter tuning are achieved, and the contract generation delay is reduced to the preset maximum tolerable delay threshold, effectively coping with traffic peaks; and based on 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.

[0034] 2. Build a dynamic performance scoring model by integrating multi-dimensional performance indicators, and combine incremental learning mechanism and shadow model verification to accurately quantify node processing capabilities, ensure the reliability of scoring under new contract types and node performance fluctuations, effectively reduce resource mismatch rate, and optimize resource utilization. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0036] Figure 2 This is a schematic diagram of the module composition of an online shopping contract generation system based on blockchain in Example 2 of the present invention. DETAILED DESCRIPTION

[0037] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only 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 ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0038] Before giving examples, it is necessary to explain the application scenarios of the present invention. The present invention is a method and system for generating online shopping contracts based on blockchain. During the promotion period of an online shopping platform, the number of orders per day exceeded 100,000. The platform automatically generated shopping contracts based on the blockchain smart contract system, covering payment, logistics, and after-sales links. However, during peak hours, users frequently encountered "contract generation timeout" prompts, and some orders were invalidated because the contracts were not uploaded to the chain in time, causing a large number of customer complaints. Among them, payment contracts were all concentrated in the same shard due to fixed sharding rules, resulting in a pile of more than 10,000 pending contracts in the shard, and the node block interval was extended from an average of 2 seconds to 15 seconds. Users had to wait for more than 3 minutes to obtain the contract on-chain confirmation, which far exceeded the 30-second standard promised by the platform. In the logistics contract sharding, some nodes had insufficient hardware performance (such as old server CPU fully loaded), and the delay was as high as 8 seconds / transaction when processing complex logistics contracts, while high-performance nodes were limited by static hash allocation strategies and only processed simple contracts, with resource utilization less than 40%. A large number of orders contain mixed terms of "payment + logistics + limited-time return and exchange", which are all included in the payment shard, causing the payment shard load to soar, while the idle rate of logistics and after-sales shards exceeds 60%, and the overall throughput drops to 35% of the peak period. The online shopping platform originally planned to temporarily expand capacity by adding server nodes, but due to uneven load distribution after the nodes were added, some new nodes were not adapted to highly complex contracts, which caused more transaction rollbacks. In the end, a large number of orders were lost due to delayed contract processing.

[0039] Example 1: Figure 1 As shown, this embodiment provides a method for generating an online shopping contract based on blockchain, the method comprising: S1. Divide online shopping contracts by business type to obtain business shards, and monitor the number of pending contracts of each business shard in real time. When the number of pending contracts of 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; each business shard consists of a group of blockchain nodes, which are responsible for processing the generation, verification and storage of contracts of the same type. When the number of pending contracts of a business shard exceeds the preset expansion threshold, it indicates that the current processing capacity of the business shard is close to saturation and expansion operations are required. Allocate independent nodes to each sub-business shard to increase parallel processing capabilities. For example, the system of an online shopping platform will continuously count the number of pending contracts of each business shard (such as the payment shard currently has a backlog of 10,000 contracts). Preset the business shard expansion threshold (for example, the payment shard threshold is 8,000 contracts). When the number of pending contracts exceeds the threshold (such as 10,000>8,000), the shard splitting is triggered. The original business shard is split into multiple sub-business shards (such as the payment shard is split into payment sub-shards A and B). Node allocation is to assign an independent node group to each sub-business shard (such as sub-shard A is assigned nodes 1-3, and sub-shard B is assigned nodes 4-6), and the sub-business shards process contract tasks in parallel.

[0040] S2. 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 according to the predicted number of pending contracts and monitor the communication delay and block packaging success rate of the nodes in the business shard. 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 adopted and the node expansion instruction is triggered. The communication delay and block packaging success rate of the nodes in the business shard directly reflect the health of the network and the processing capacity of the nodes. The real-time block interval is the time interval between the creation and addition of blocks to the blockchain. If the real-time block interval exceeds the preset upper limit of the dynamic block interval, it indicates that the network may be congested or the processing capacity of the node is insufficient. The block interval is adjusted to the minimum allowed block 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 capacity. The minimum allowed block 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 required for node CPU / memory to process transactions (such as 0.3 seconds for single block verification). The network limit is the minimum time required for block broadcasting (such as 0.2 seconds for full network node synchronization). The minimum allowed block interval is 0.5 seconds.

[0041] S3. 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 generation delay of pending contracts is less than the preset maximum tolerable 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 split is executed first, and then the node expansion instruction is triggered. The consistent hashing algorithm is an implementation method of a distributed hash table (DHT). When nodes dynamically join or leave, the stability and balance of data distribution are maintained as much as possible. The consistent hashing algorithm can evenly distribute pending contracts to each node to avoid overloading some nodes while other nodes are idle. The redistribution process will continue until the generation delay of pending contracts is reduced to below the preset maximum tolerable delay threshold. The maximum tolerable delay threshold is set according to business needs and user experience, ensuring that the speed and efficiency of contract processing can meet user requirements. When the number of pending contracts of a 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 performed first, and then the node expansion instruction is triggered. This is because in this case, simply adding nodes may not be able to effectively solve the problem, because the processing capacity of the business shard itself has reached its limit. Therefore, it is necessary to first split the shard to reduce the load of each shard, and then add nodes to further improve the processing capacity.

[0042] The method for redistributing pending contracts by using a consistent hashing algorithm includes: Real-time monitoring of the real-time load status and historical contract processing efficiency of the nodes in the business shard, calculating the real-time load weight through a weighted algorithm, and building a dynamic allocation priority in combination with 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; CPU utilization, memory utilization and network bandwidth occupancy are important indicators for measuring the current processing capacity of the node. CPU utilization reflects the computing resource usage of the node, memory utilization indicates whether the storage resources of the node are tight, and network bandwidth occupancy is related to the communication efficiency between the node and other nodes. The average contract processing delay reflects the speed at which the node processes the contract, and the block packaging success rate directly reflects the activity and reliability of the node in the blockchain network. The real-time load weight comprehensively considers the real-time load status and historical contract processing efficiency of the node, and is an indicator that comprehensively measures the current processing capacity and historical performance of the node. Combining communication delay (i.e., the time delay of information transmission between nodes) and real-time load weight, a dynamic allocation priority is built for each node, which is used to prioritize which nodes when allocating resources or scheduling tasks in the future. Specifically, nodes with low load, high processing efficiency and low communication delay will be given higher priority 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 delay will be given lower priority, and their workload will be reduced or expanded. For example, there are two business shard nodes A and B. The CPU utilization of node A is 50%, the memory utilization is 60%, the network bandwidth occupancy is 40%, the average contract processing delay is 2 seconds, and the block packaging success rate is 95%. The CPU utilization of node B is 80%, the memory utilization is 90%, the network bandwidth occupancy is 70%, the average contract processing delay is 5 seconds, and the block packaging success rate is 80%. The real-time load weights of nodes A and B are calculated by standardizing or normalizing the data first, and then the weighted algorithm is used to calculate the real-time load weights of nodes A and B. Since all indicators of node A are better than those of node B, node A is given a higher real-time load weight. Next, considering the communication delay factor, it is assumed that the average communication delay between node A and other nodes in the network is 10 milliseconds, while the average communication delay of node B is 20 milliseconds. Since the communication delay of node A is also smaller, the dynamic allocation priority of node A is higher.

[0043] The task complexity of the contract to be processed is obtained and matched with the node resource capacity. The high task complexity contract is preferentially assigned to the node 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 cost required to process the contract. The resource capacity of the node refers to the total amount of resources such as CPU, memory, storage and network bandwidth currently available to 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 situation of the online shopping platform, aiming to ensure the rationality of the allocation and the balanced use of resources. For contracts with high task complexity, they will be preferentially assigned to those nodes whose load weight is lower than the preset load weight threshold and whose resource capacity is greater than the preset resource capacity threshold. It ensures that high-complexity contracts can be processed in a timely manner and improves the overall processing efficiency of the system. Secondly, by preferentially assigning tasks to low-load nodes, the load of each node can be balanced to avoid the situation where some nodes are overloaded while other nodes are idle. For example, there are two pending contracts C1 and C2, and two business shard nodes A1 and A2. The task complexity of contract C1 is high, requiring more computing resources and processing time; while the task complexity of contract C2 is low and relatively simple 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%). The contract C1 with high task complexity is preferentially assigned 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 its high load and insufficient resources.

[0044] The nodes in the business shard are obtained according to the preset statistical period. The block packaging success rate and contract processing delay of the nodes are obtained. If the contract processing delay of the node for multiple consecutive statistical periods exceeds the preset ratio 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. The block packaging success rate and contract processing delay data of each node are collected according to the preset statistical period (such as every hour, every day, etc.). These data reflect the processing capacity and efficiency of the node over a period of time. The average processing delay of all nodes in the business shard is calculated and used as a benchmark value. For each node, check whether the contract processing delay for multiple consecutive statistical periods exceeds the preset ratio threshold of the average processing delay (such as 1.5 times, 2 times, etc.). The preset ratio threshold is set according to business needs and the system performance of the online shopping platform, aiming to ensure that timely measures can be taken when the node processing delay increases significantly. Contract migration is to select some pending contracts based on contract type labels (for example, the urgency, size, etc. of the contract) and migrate them from high-latency nodes to low-latency nodes, ensuring that the load on high-latency nodes is reduced, while low-latency nodes can use their remaining processing power to efficiently process these contracts. Update the consistent hash mapping table to ensure that new contracts can be correctly assigned to the corresponding nodes. The consistent hashing algorithm can ensure that the distribution of data remains as stable as possible when nodes join or leave, reducing the risk of data migration and data loss. The load rebalancing operation ensures that the contract processing delay 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 daily, and the preset ratio threshold is 1.5 times. In the last three statistical periods, the contract processing delay of node N1 has continued to exceed 1.5 times the average delay in the shard, triggering the load rebalancing operation. First, a part of the pending contracts will be selected to migrate from node N1 based on the contract type label. For example, contracts with lower urgency and fewer resources are selected for migration. These contracts are then dispatched to nodes N2 or N3 (assuming they have lower processing latency).

[0045] The method for triggering a load rebalancing operation of a node within a service slice includes: The dynamic performance scoring model of the node 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 the nodes in the business shard as performance indicators; the high-performance node set 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. 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; the network jitter rate evaluates the stability of the node network communication. The matching degree is analyzed according to 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, according to the contract type label, selects the node with high efficiency in processing similar contracts in history as the target node. The real-time communication delay takes into account the communication delay between the target node and the current node to ensure that the migrated contract can efficiently transmit and synchronize data. A matching score is calculated based on these factors to guide the migration decision of the contract. For example, there is a business shard containing four nodes A, B, C, and D. The dynamic performance scoring model calculates that nodes A and B have higher performance scores, while nodes C and D have lower performance scores. Now there is a contract F to be migrated, whose 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): Node A has a high remaining resource capacity, a high efficiency in processing similar contracts in history, and a low real-time communication delay, so it has a high matching degree with contract F. For node B, although its performance is also very good, it is currently processing a large number of high-priority contracts and has relatively less remaining resource capacity, so its 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 in history, they have a low matching degree with contract F. It is decided to migrate contract F to node A for processing. Not only can it ensure that the contract is processed efficiently, but it can also make full use of the remaining resources of node A while avoiding adding additional burden to nodes with lower performance.

[0046] Prioritize the migration of high-task complexity contracts to high-performance nodes whose matching degree exceeds the preset matching degree threshold, and add a dynamic priority tag to the migrated contract to ensure that it is processed first in the block packaging queue of the target node; after the migration is completed, the weight distribution relationship between the node and the contract type in the consistent hash map is dynamically updated according to the migration result. The consistent hash map records the weight distribution relationship between the node and the contract type. Updating the consistent hash map can ensure that the subsequent contract can take into account the results of the previous migration when allocating, so as to select the target node more accurately. For example, a business shard contains three high-performance nodes E, F and G, and a high-task complexity contract H to be migrated. It has been calculated that the matching degrees of nodes E, F and G with contract H are 0.85, 0.70 and 0.60 respectively, and the preset matching degree threshold is 0.75. Only the matching degree of node E exceeds the preset threshold, so contract H will be migrated to node E. After migration, a dynamic priority tag will be added to contract H, indicating that it has a higher priority in the block packaging queue of node E. Subsequently, the consistent hash map will be updated to increase the weight of node E in processing contracts similar to contract H. In this way, when similar contracts need to be assigned later, the system will be more inclined to choose node E as the target node.

[0047] The method further comprises: The performance indicators are weighted and fused 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 scoring weight, in which the weights of the historical contract processing delay and the network jitter rate are adaptively adjusted with the real-time load fluctuation amplitude; a weight is assigned to each performance indicator, and the weight reflects the importance of each indicator to the overall performance of the node. The preset time window is used to observe the changing trend of the node performance indicators, and the sliding average algorithm is used to calculate the average value of each performance indicator to smooth out the fluctuations in the short term, and the weight of each performance indicator is dynamically adjusted according to the changing trend of the average value. When the real-time load fluctuation amplitude is large, the weights of the historical contract processing delay and the network jitter rate can be adaptively increased, because these indicators can better reflect the stability and reliability of the node when the load fluctuates. By dynamically correcting the scoring weight, it can be ensured that the node's performance score more accurately reflects the current real-time performance. For example, the initial weights of the CPU utilization, memory usage, block packaging success rate, historical contract processing delay, 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 real-time load of node I fluctuates greatly, causing the values ​​of the two indicators, historical contract processing delay and network jitter rate, to rise significantly. In this case, the average values ​​of these two indicators within the preset time window are calculated according to the sliding average algorithm, and it is observed that these average values ​​are also rising. According to the observation results, the weights of historical contract processing delay and network jitter rate are adaptively increased, for example, their weights are adjusted to 0.35 and 0.2 respectively, while the weights of other indicators are reduced accordingly 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 is more focused on reflecting its stability and reliability, thereby more accurately evaluating its current performance.

[0048] 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 similarity is calculated by comparing the feature vector of the contract type label with the feature vector of the contract type label in the node's historical processing record. Incremental learning allows the model to be updated gradually when new data is received without retraining the entire model, thereby improving learning efficiency and adaptability.

[0049] 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 mean, 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. The resource expansion warning prompts the system of the online shopping platform to increase the resources of the node (such as CPU, memory, storage, etc.) to improve its processing capacity. For example, there is a business shard containing nodes J, K, and L, all of which are processing different types of contracts. A new contract type M is introduced, and the ability of node J to process this new contract type needs to be evaluated. First, the potential capacity of contract type M is evaluated based on the similarity between the label of contract type M and the historical processing record of node J. Assuming that the similarity is high, it indicates that node J may have the ability to process the new contract type M. Then, the dynamic performance scoring model is updated using the incremental learning mechanism to include the score prediction for the new contract type M. Incremental learning can ensure that the score prediction error for the new contract type M is lower than the preset score prediction error threshold. During the continuous monitoring process, it was found that the performance score of node K was continuously lower than the average performance score of the nodes in the business shard, and its resource utilization rate was continuously higher than the business shard average. Therefore, node K was marked as an inefficient node. The triggering of the resource expansion warning prompted the system to increase the resources of node K. At the same time, in the subsequent load rebalancing operation, the contract allocation weight of node K was reduced to reduce its burden of processing contracts, and more contracts were allocated to other high-performance nodes (such as nodes J or L) for processing.

[0050] 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 an update of the dynamic performance scoring model based on a preset confidence threshold; the confidence threshold is pre-set based on the system stability and accuracy requirements of the online shopping platform.

[0051] An implicit association between contract type features and node performance indicators is constructed through a lightweight neural network, and the lightweight neural network is fine-tuned using incremental training samples; the purpose of fine-tuning is to update the dynamic performance scoring model to evaluate the processing capabilities of new contract types.

[0052] 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 weights between the contract type label and the node in the dynamic performance scoring model are dynamically adjusted, and the associated processing efficiency of the new contract type is fed back into the matching calculation of the load rebalancing operation. For example, a business shard includes nodes A, B, and C, and a new contract type N is introduced, and the ability of node A to handle this new contract type needs to be evaluated. When node A processes contract type N for the first time, it records the label, actual processing delay (such as 5 seconds), and resource consumption characteristics (such as CPU usage of 80% and memory usage of 60%) of the contract type. According to the preset confidence threshold (such as 90%), it is determined whether it is necessary to trigger the update of the dynamic performance scoring model. Assume that the confidence reaches 95% at this time, so the model update is triggered. A lightweight neural network is used to construct an implicit association between the characteristics of contract type N and the performance indicators of node A, and the neural network is fine-tuned using the above incremental training samples. After the fine-tuning is completed, the shadow model is used to compare the score prediction error of the dynamic performance scoring model for contract type N before and after the update. Assume that the prediction error before the update is 10%, and the prediction error after the update is reduced to 5%. Since the updated model score prediction error is lower than the preset score prediction error threshold (such as 8%), and the error reduction is greater than or equal to the preset error reduction threshold (such as 3%), the updated model is retained. The association weights of contract type N and node A in the dynamic performance scoring model are dynamically adjusted, and the associated processing efficiency of the new contract type N (such as an average processing delay of 5 seconds) is fed back to the matching calculation of the load rebalancing operation. In subsequent contract allocation, contracts similar to contract type N are more likely to be allocated to node A for processing.

[0053] 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: A shadow model consistent with the structure of the current dynamic performance scoring model is constructed, and the shadow model loads the parameters before and after the update and accesses the same historical contract processing data set; so as to compare the performance under the same conditions.

[0054] The incremental training samples of the new contract type are input into each shadow model, the absolute error between the predicted processing delay and the actual processing delay is recorded, and the error volatility of each shadow model is calculated; the error volatility measures the volatility of the model prediction error, which is an indicator of prediction stability. Low volatility indicates that the model prediction is relatively stable.

[0055] 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, which contains the contract type label, resource consumption characteristics and error distribution data. Two shadow models are created: one loads the parameters before the update and the other loads the parameters after the update. The two shadow models are verified using the same historical contract data set. 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. The error volatility and stability index are calculated: it is found that the error volatility of the updated model is 5% lower than the preset error volatility threshold of 10%. Since the updated model is better than the model before the update in error volatility, it is decided to use the updated model as the main scoring model.

[0056] 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 fragments, logistics contract fragments and after-sales contract fragments according to the semantic similarity matching algorithm; the semantic similarity matching algorithm is based on the text content of the key fields and uses natural language processing technology to evaluate the similarity with the predefined contract types.

[0057] For hybrid contracts containing cross-business type clauses, the relevance scores of each business type are calculated according to the clause weight distribution model, and the contracts are assigned 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 cross-shard index is to maintain the integrity and traceability of the contract information, which helps to quickly locate all relevant information of the contract when needed.

[0058] The contract type label rule base is dynamically updated by the offline trained classification model, which is iteratively optimized based on historical contract data and manually annotated contract type labels. For example, there is a contract text that contains detailed information about product delivery and logistics, as well as payment methods and after-sales service policies. Contract parsing and preliminary classification: First, key fields in the contract are identified, such as "product delivery", "logistics costs", "credit card payment" and "30-day return and exchange policy". Through semantic similarity matching, it is preliminarily determined that this contract may involve logistics, payment and after-sales business types at the same time. The mixed contract processing uses the clause weight distribution model to calculate that the relevance score of this contract with the logistics business type is 75 points, the relevance score with the payment business type is 65 points, and the relevance 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 the clause information related to payment and after-sales can be accessed when needed. Over time, more similar mixed contract data is collected and the contract type label is updated through manual annotation. This new data is used to train and optimize the classification model to improve its classification accuracy for hybrid contracts and other complex contract types.

[0059] The method for predicting the number of contracts to be processed by using the pre-trained LSTM model includes: The historical contract generation data of the business shards is obtained, and the contract quantity sequence, contract type distribution and node resource occupancy rate within the time window are extracted as input features to build the training data set of the LSTM model; the historical contract generation data contains information about the contract quantity, contract type and node resource occupancy rate. From these data, the contract quantity sequence, contract type distribution (the proportion or quantity of each type of contract) and node resource occupancy rate within the time window are extracted as input features, which together describe the historical status and trend of the business shards.

[0060] The LSTM model is pre-trained. The network structure of the LSTM model includes two hidden layers. The number of neurons in each layer is twice the dimension of the input features. The sliding time window cross-validation is used to optimize the hyperparameters. The training set and the validation set are created by sliding the window on the time series data to evaluate the performance of the model in different time periods, and the hyperparameters are adjusted accordingly to improve the generalization ability of the model.

[0061] 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.

[0062] Embodiment 2: Based on the same inventive concept, Figure 2As shown, this embodiment also provides an online shopping contract generation system based on blockchain, the system includes: a business sharding management module, a block interval analysis module, and a contract generation management module, and each module is sequentially connected in communication; 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.

[0063] 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 of the method, and will not be elaborated here.

[0064] Finally, it should be noted that: Although the present invention has been described in detail with reference to the aforementioned embodiments, it is still possible for those skilled in the art to modify the technical solutions described in the aforementioned embodiments, or to make equivalent substitutions for some of the technical features therein. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in 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 and match the task complexity and node resource capacity of the contract to be processed, and prioritize assigning high-task-complexity contracts to nodes whose real-time load weight is greater than a preset load weight threshold and whose resource capacity is greater than a 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 current dynamic performance scoring model structure, 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