Sharding-oriented blockchain storage optimization method, system and computer device

Abstract

The embodiment of the application is suitable for the field of blockchain technology, and provides a storage optimization method and system for a sharded blockchain and computer equipment. The method comprises the following steps: determining the calling frequency of each virtual contract cached in an execution shard; determining the cache state of each virtual contract based on the calling frequency, wherein the cache state is used to represent the calling frequency of the virtual contract within a time window; and performing storage optimization on the execution shard based on the cache state if the storage capacity of the execution shard is greater than a capacity threshold. Through the above method, the storage pressure and the computing performance of the execution shard can be balanced.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, and in particular relates to a storage optimization method, system and computer equipment for sharded blockchains. Background Technology

[0002] In sharded blockchain systems, to support the execution of cross-shard transactions, executing a shard typically requires caching the smart contract states of other shards locally or constructing virtual contracts.

[0003] However, as the system continuously processes cross-shard calls, the locally cached external contract state data accumulates, leading to severe state bloat. State bloat dramatically increases the storage overhead of the underlying database and triggers a severe read / write amplification effect, causing disk I / O bottlenecks and ultimately resulting in a significant decrease in system throughput during long-term operation. Therefore, it is necessary to implement storage management for the locally cached external contract state data.

[0004] Existing sharded blockchain systems mainly employ three conventional storage management strategies when handling cross-shard state caching: the first is a full retention strategy, which permanently stores all fetched external states in local storage; the second is a cache eviction mechanism based on the traditional Least Recently Used (LRU) algorithm; and the third is a periodic garbage collection mechanism, which performs full data cleanup according to a fixed block height or time period.

[0005] A full retention strategy directly leads to storage exhaustion and degraded read / write performance. Furthermore, the traditional Least Recently Used (LRU) algorithm fails to consider the inherent burstiness and periodicity of smart contract calls over time, easily causing contract states with periodic call characteristics to be frequently swapped out and re-fetched, generating significant unnecessary network transmission overhead between shards. Periodic garbage collection mechanisms, when triggered, instantly consume substantial computing resources and disk read / write bandwidth. This prevents the system from processing normal transactions promptly during the cleanup period, causing periodic drops in overall system throughput and performance fluctuations. Summary of the Invention

[0006] In view of this, embodiments of this application provide a storage optimization method, system, computer device, and program product for sharded blockchains, used to balance the storage of sharded execution.

[0007] The first aspect of this application provides a storage optimization method for sharded blockchains, including: Determine the call frequency of each virtual contract cached in the execution shard; Based on the call frequency, the cache state of each virtual contract is determined, and the cache state is used to characterize the call frequency of the virtual contract within the time window; Storage optimization is performed on the execution shards based on cache status and storage capacity.

[0008] In one possible implementation, the frequency of calls to each virtual contract cached in the execution shard is determined, including: Within each transaction processing cycle, the total number of times each virtual contract is called across shard transactions is counted. The total number of times is the call frequency of the virtual contract within the transaction processing cycle.

[0009] In one possible implementation, each time window includes at least one transaction processing cycle, and the cache state of each virtual contract is determined based on the call frequency, including: Based on the frequency of virtual contract calls within each transaction processing cycle within a time window, calculate the popularity score of each virtual contract. The cache status is determined based on the popularity score.

[0010] In one possible implementation, a popularity score for each virtual contract is calculated based on the frequency of its invocation within each transaction cycle of a time window, including:

[0011] in, The popularity score is represented by W, where W is the number of transaction processing cycles within the time window. The time decay factor, The frequency of calls is represented by epoch, which is the identifier corresponding to the current transaction processing cycle. Used to identify each transaction processing cycle within a time window.

[0012] In one possible implementation, the cache state is determined based on the popularity score, including: If the popularity score is greater than or equal to the popularity judgment threshold, the cache status is determined to be hot. If the popularity score is less than the popularity threshold, the cache status is determined to be cold.

[0013] In one possible implementation, the cache state is determined based on the popularity score, including: Based on the popularity score calculated for each transaction processing cycle, determine the comprehensive popularity value corresponding to each virtual contract; If the overall popularity value is greater than or equal to the popularity judgment threshold, the cache status is determined to be hot. If the overall popularity value is less than the popularity judgment threshold, the cache status is determined to be cold.

[0014] In one possible implementation, storage optimization of the execution shards is performed based on the cache state and the storage capacity of the execution shards, including: If the storage capacity exceeds the capacity threshold, virtual contracts in a cold state are cleaned up to free up storage space for execution shards.

[0015] In one possible implementation, virtual contracts in a cold state are cleaned up to free up storage space for execution shards, including: The target virtual contract is defined as any virtual contract, or the virtual contract with the lowest overall popularity value among virtual contracts in a "cold" state. Delete the state data of the target virtual contract that is in a cold state; After the state data of each target virtual contract is deleted, check whether the storage capacity is greater than the capacity threshold. If the storage capacity is greater than the capacity threshold, a new target virtual contract is determined, and the target step and the steps following the target step are executed. The target step is to delete the state data of the target virtual contract that is in a cold state. If the storage capacity is less than the capacity threshold, then storage optimization for execution sharding is completed.

[0016] A second aspect of this application provides a storage optimization system for sharded blockchains, comprising: The statistics module is used to determine the call frequency of each virtual contract cached in the execution shard; The determination module is used to determine the cache state of each virtual contract based on the call frequency. The cache state is used to characterize the call frequency of the virtual contract within a time window. The optimization module is used to optimize the storage of execution shards based on cache status and storage capacity.

[0017] A third aspect of this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method of the first aspect described above.

[0018] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0019] A fifth aspect of this application provides a computer program product that, when run on a computer device, causes the computer device to perform the method described in the first aspect.

[0020] Compared with the prior art, the embodiments of this application have the following advantages: The method described in this application can be used to optimize storage in sharded blockchains. For sharded blockchains, the execution shard can determine the call frequency of each virtual contract cached in the execution shard; based on the call frequency, the cache state of each virtual contract is determined, and the cache state is used to characterize the call frequency of the virtual contract within a time window; based on the cache state and the storage capacity of the execution shard, storage optimization is performed on the execution shard. When releasing the virtual contract state data in the sharded blockchain, this application embodiment can determine the cache state of the virtual contract based on the call frequency of each virtual contract, and the cache state can characterize the probability of the virtual contract being called. When the storage capacity of the execution shard exceeds the capacity threshold, storage optimization of the execution shard can be triggered. During storage optimization, storage space can be released based on the cache state of the virtual contracts. Releasing storage space based on the cache state of the virtual contracts can prioritize the deletion of state data of virtual contracts with low probability of recent calls, thereby expanding the storage space of the execution shard while ensuring the execution efficiency of the execution shard. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0022] Figure 1 This is a flowchart illustrating the steps of a storage optimization method for sharded blockchains provided in an embodiment of this application. Figure 2 This is a schematic diagram of a storage optimization system for sharded blockchain provided in an embodiment of this application; Figure 3 This is a schematic diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0023] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0024] Existing sharded blockchain systems mainly employ three conventional storage management strategies when handling cross-shard state caching: the first is a full retention strategy, which permanently stores all fetched external states in local storage; the second is a cache eviction mechanism based on the traditional Least Recently Used algorithm; and the third is a periodic garbage collection mechanism, which performs full data cleanup according to a fixed block height or time period.

[0025] A full retention strategy directly leads to storage exhaustion and degraded read / write performance. Furthermore, the traditional Least Recently Used (LRU) algorithm fails to consider the inherent burstiness and periodicity of smart contract calls over time, easily causing contract states with periodic call characteristics to be frequently swapped out and re-fetched, generating significant unnecessary network transmission overhead between shards. Periodic garbage collection mechanisms, when triggered, instantly consume substantial computing resources and disk read / write bandwidth. This prevents the system from processing normal transactions promptly during the cleanup period, causing periodic drops in overall system throughput and performance fluctuations.

[0026] Virtual contracts in sharded blockchains are smart contract models in which the contract logic (code, ABI, interface) is visible and shared across all shards of the network, but the contract state (account, balance, stored variables) is distributed to different state shards according to sharding rules (such as address hash, object ID).

[0027] The core of execution shards (also known as execution channels / computation shards) in sharded blockchains is to completely decouple the computational execution of transactions / contracts from state storage and global consensus. Dedicated shard clusters handle contract execution, virtual machine computation, and state read / write in parallel, without being responsible for storing the complete state or global sorting. This overcomes the computational bottleneck of a single shard and achieves linear throughput scaling. The methods in this application embodiment can be applied to sharded blockchains. Each shard in a sharded blockchain can include multiple blockchain nodes. The sharded blockchain can be deployed on computer devices, utilizing the computing resources of the computer devices to execute the methods in this application. This application embodiment does not limit the computer devices used.

[0028] The storage optimization method for sharded blockchains in this embodiment can delete the contract state data of virtual contracts in the sharded blockchain, thereby freeing up storage space in the sharded blockchain. Based on storage optimization, the storage pressure and execution efficiency of the sharded blockchain can be balanced.

[0029] The technical solution of this application will be described below through specific embodiments.

[0030] Reference Figure 1 This illustration shows a flowchart of a storage optimization method for sharded blockchains provided in an embodiment of this application, which may specifically include the following steps: S101, determine the call frequency of each virtual contract cached in the execution shard.

[0031] Blockchain has a transaction cycle (Epoch). A transaction cycle can be divided into blocks; for example, a transaction cycle may include a preset number of blocks, and each block may package multiple transactions. During transaction processing, the blockchain can invoke contracts to execute different tasks. These invoked contracts can be virtual contracts.

[0032] Within each transaction processing cycle, the execution sharding can count the total number of times each virtual contract is called across shard transactions. This total number is the call frequency of the virtual contract within that transaction processing cycle.

[0033] In one possible implementation, within the execution shard, a thread-safe key-value pair counter can be maintained in the contract caching module. Each virtual contract's unique identifier is used as the key, and the number of calls is used as the value. When a virtual contract is loaded from the cache and executed, the corresponding counter is atomically incremented. Simultaneously, the counter is initialized when a virtual contract is added to the cache and is synchronously cleaned up when it is removed, avoiding invalid data from occupying memory. Finally, by traversing this counter set, the call frequency of each virtual contract in the current cache can be obtained in real time.

[0034] In one possible implementation, the aforementioned call frequency can be obtained from the pre-execution phase data built into the shard nodes. During the pre-execution phase of transaction processing, the execution shard naturally parses the transaction's call target. The background statistics module maintains a lightweight counter in memory. For any locally cached virtual contract i, it records in real-time the total number of times it is called across shard transactions within the current period, denoted as ci. This data collection process is completed synchronously during pre-execution, without blocking the main execution thread. By directly reusing the pre-execution phase data built into the shard nodes for call frequency statistics, the execution shard avoids modifying the underlying virtual machine code or introducing additional instruction instrumentation overhead, thus preventing any impact on the normal execution of the sharded blockchain.

[0035] S102, based on the call frequency, determine the cache state of each virtual contract. The cache state is used to characterize the call frequency of the virtual contract within the time window.

[0036] In this embodiment, the time window can be divided according to the transaction processing cycle. The time window may include multiple transaction processing cycles.

[0037] Based on the frequency of virtual contract calls within each transaction processing cycle within a time window, a heat score is calculated for each virtual contract; the cache status is then determined according to the heat score. The heat score characterizes the frequency of virtual contract calls within the time window. The cache status characterizes the demand for virtual contracts within the time window. A hot cache status indicates high demand for the virtual contract during transaction execution within the time window; a cold cache status indicates low demand for the virtual contract during transaction execution within the time window.

[0038] In one possible implementation, a corresponding weight value can be assigned to each transaction processing cycle within a time window, where the weight value can be lower the closer to the current time window. The product of the assigned weight for each transaction processing cycle and the corresponding call frequency is calculated, and this product is used as the corresponding popularity score.

[0039] In one possible implementation, the popularity score of each virtual contract is calculated based on the frequency of its invocation within each transaction cycle of a time window, using the following formula:

[0040] Where i is the identifier of the virtual contract. Let W be the popularity score of virtual contract i, and W be the number of transaction processing cycles within the time window. The time decay factor, The frequency of calls is represented by epoch, which is the identifier corresponding to the current transaction processing cycle. Used to identify each transaction processing cycle within a time window. It should be noted that... This is for identification purposes and is not an exponential calculation.

[0041] As an example, a time window can include 3 transaction processing cycles. If the current transaction processing cycle is an epoch, then after the block execution of a transaction processing cycle is completed, the popularity score for virtual contract i is:

[0042] That is, the popularity score can be the sum of the product of the time decay factor and the call frequency for each transaction processing cycle within the time window.

[0043] The aforementioned cache states can include cold states and hot states. A cold state indicates that the virtual contract is unlikely to be called in the near future, while a hot state indicates that the virtual contract is likely to be called in the near future.

[0044] In one possible implementation, the cache status can be determined directly based on the popularity score corresponding to the current time window. For example, if the popularity score is greater than or equal to the popularity threshold, the cache status is determined to be "hot"; if the popularity score is less than the popularity threshold, the cache status is determined to be "cold".

[0045] In one possible implementation, the cache status is determined based on popularity scores corresponding to multiple time windows. For example, a comprehensive popularity value for each virtual contract can be determined based on the popularity score calculated for each transaction processing cycle; if the comprehensive popularity value is greater than or equal to a popularity threshold, the cache status is determined to be "hot"; if the comprehensive popularity value is less than the popularity threshold, the cache status is determined to be "cold". The comprehensive popularity value can be the sum of popularity scores corresponding to multiple time windows, or the average of popularity scores corresponding to multiple time windows.

[0046] As an example, for a virtual contract, a popularity score can be calculated in each transaction processing cycle. In the current transaction processing cycle, the cache state of the virtual contract can be calculated based on the popularity scores calculated from multiple past transaction processing cycles. For instance, if the current virtual contract has already calculated 5 popularity scores, x1 to x5, a comprehensive popularity value can be calculated based on x1 to x5. This comprehensive popularity value can be the cumulative value of x1 to x5, or a weighted cumulative value of x1 to x5. The weight of the popularity score can decrease over time; that is, the further back in time the calculation is from the current transaction processing cycle, the lower the weight of the popularity score.

[0047] S103, if the storage capacity of the shard being executed is greater than the capacity threshold, then storage optimization is performed on the shard being executed based on the cache status.

[0048] The sharding process monitors the disk space utilization of the underlying local database (such as LevelDB) in real time in the background. The system sets a safe capacity threshold, such as a specific percentage of the maximum available disk capacity. For example, the safe capacity threshold could be set to 80% of the maximum available disk capacity.

[0049] The aforementioned capacity threshold can be considered the security capacity threshold for sharded blockchains. If the storage capacity for sharding exceeds the capacity threshold, it indicates excessive storage pressure, requiring the release of storage space and storage optimization.

[0050] If the storage capacity is greater than the capacity threshold, virtual contracts in a cold state can be cleaned up to free up storage space for execution shards.

[0051] During the cleanup of virtual contracts, virtual contracts in a cold state can be cleaned up one by one until the storage capacity is less than the capacity threshold.

[0052] In one possible implementation, sharding can determine the target virtual contract. The target virtual contract can be any virtual contract, or it can be the virtual contract with the lowest overall popularity value among the virtual contracts in a cold state. The state data of the target virtual contract in a cold state is deleted. After deleting the state data of each target virtual contract, the storage capacity can be checked to see if it exceeds a capacity threshold. If the storage capacity exceeds the capacity threshold, a new target virtual contract is determined, and the target step and subsequent steps are executed. The target step is to delete the state data of the target virtual contract in a cold state. If the storage capacity is less than the capacity threshold, the storage optimization for sharding is complete.

[0053] In this embodiment, different threads can be used to determine the cache state of the virtual contract and perform storage optimization. The determination of the cache state of the virtual contract and the release of the virtual contract state data can be independent of each other.

[0054] During the pre-execution phase of each transaction processing cycle, the execution shard can calculate the popularity score corresponding to the current time window, and determine the hot / cold status of the virtual contract based on the popularity score calculated for each time window.

[0055] The sharding process can include a process for evicting virtual contract data for storage optimization. This process can monitor storage capacity in real time. When the detected storage capacity exceeds a capacity threshold, the process is triggered to release the storage capacity; when the storage capacity falls below the capacity threshold, the release of virtual contract data is stopped.

[0056] This application introduces a delayed eviction mechanism based on underlying storage capacity awareness, completely decoupling the cleanup action from the time period. In this application, the shard will only wake up the background eviction thread when the local storage utilization rate of the shard exceeds the safe capacity threshold. Before the storage utilization rate reaches the threshold, even if there are a large number of cold-state contracts, the system will not perform any cleanup action. After the eviction thread is woken up, it directly traverses the set of contracts currently marked as cold. The system physically removes the state data, code cache, and associated state tree nodes corresponding to these cold-state contracts from the local persistent storage. The cleanup process continues until the storage utilization rate falls below the safe capacity threshold, at which point the eviction thread re-enters a dormant state. If the evicted contract is called again in the future, the shard will re-initiate a state retrieval request from the source shard according to the normal process.

[0057] In this application, a capacity-triggered delayed eviction mechanism can be used to strictly control the storage overhead of shard nodes within a healthy range. This avoids the read / write amplification effect caused by the unlimited accumulation of data in the underlying database, ensuring the stability of the system's throughput during long-term operation.

[0058] This application can eliminate the performance jitter of garbage collection. It abandons the traditional periodic forced cleaning design and only starts on-demand cleaning when the capacity reaches the red line, avoiding the intense competition for computing resources and disk bandwidth, and fundamentally eliminating the periodic jitter of system performance.

[0059] The method in this application can reduce cache miss rate and unnecessary network overhead. By using a time-decaying sliding window to accurately assess contract activity, it effectively captures the bursty and periodic call characteristics of smart contracts. Compared to traditional algorithms, this mechanism prevents frequent swapping of virtual contract states between shards, significantly reducing cross-shard network communication overhead.

[0060] It should be noted that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0061] To more clearly illustrate the solutions in this application, specific embodiments are described below.

[0062] Assume that each shard node locally caches virtual contracts X and Y from other shards. The system sets the sliding window to include the past 3 periods (W=3), the time decay factor α=0.5, the heat threshold to 40 minutes, and the storage capacity trigger threshold to 70%.

[0063] Scenario 1 (Popularity Calculation and Classification): In three consecutive periods, Contract X was called 100 times, 20 times, and 0 times, respectively. At the end of the third period, Contract X's score was calculated as follows: the current period (0 times) multiplied by 1, plus the previous period (20 times) multiplied by 0.5, plus the period before that (100 times) multiplied by 0.25. Contract X's overall score was 35 points. Since 35 points is below the threshold of 40 points, Contract X was marked as a cold state.

[0064] Scenario 2 (Capacity Trigger and Delayed Eviction): During subsequent operation, the storage utilization rate of this shard node reached 75%, exceeding the preset capacity threshold. At this point, the system's underlying delayed eviction mechanism was triggered. A background thread started and scanned the cold state queue, finding contract X in the cold state list. The system safely removed contract X's data from the local database. After cleanup, the storage utilization rate dropped to 65%, below the trigger threshold, and the cleanup thread went to sleep. The entire on-demand cleanup process was executed silently in the background, without hindering the normal processing of cross-shard transactions in the foreground, completely eliminating the performance fluctuations caused by periodic cleanup.

[0065] As another example, in a sharded blockchain network, an execution shard is responsible for processing transactions and caching multiple virtual contracts, such as virtual contract VC1, virtual contract VC2, and virtual contract VC3.

[0066] First, based on the method in this application, the call frequency of each virtual contract cached in the shard can be determined. The sharded blockchain system continuously counts the number of times virtual contracts VC1, VC2, and VC3 are called across shard transactions within each transaction processing cycle. For example, in the most recent six transaction processing cycles, the system recorded that the call frequency of virtual contract VC1 remained consistently high, the call frequency of virtual contract VC2 was initially high but then gradually decreased, while the call frequency of virtual contract VC3 remained at an extremely low level.

[0067] Based on these call frequencies, the system determines the cache state of each virtual contract. The system sets a time window (e.g., encompassing the most recent six transaction cycles) and defines a heat threshold. The system calculates the overall call activity of each virtual contract within this time window (e.g., through a weighted average call frequency) and compares it to the heat threshold. For example, virtual contract VC1's overall activity is significantly higher than the threshold, therefore its cache state is determined to be "hot." Virtual contract VC2's overall activity falls below the threshold later in the time window, therefore its cache state is determined to be "cold." Virtual contract VC3's overall activity consistently falls far below the threshold, therefore its cache state is also determined to be "cold." This cache state accurately characterizes the call frequency of the virtual contract within the time window.

[0068] Finally, when the storage capacity of the execution shard is detected to exceed a preset capacity threshold, the method optimizes the storage of the execution shard based on the cache state. For example, when the storage capacity reaches 95%, the system initiates the storage optimization process. The system identifies virtual contracts in a "cold state," namely virtual contracts VC2 and VC3. The system prioritizes cleaning up these cold-state virtual contracts. Specifically, the system can first delete the state data of virtual contract VC3 because it has the lowest call frequency and has been inactive for a long time, thereby freeing up some storage space. Subsequently, the system checks the storage capacity again. If it is still greater than the capacity threshold, it continues to delete the state data of virtual contract VC2, further freeing up storage space. By cleaning up the state data of these inactive virtual contracts, the storage capacity of the execution shard is effectively controlled, falling back below the capacity threshold, thereby alleviating the state bloat problem and avoiding performance degradation caused by storage resource exhaustion.

[0069] Based on the above examples, the method provided in this embodiment demonstrates a significant technical contribution to solving the storage optimization problem of sharded blockchains.

[0070] Compared to the full retention strategy in existing technologies, this method dynamically analyzes the call frequency of virtual contracts and determines their cache status accordingly. This allows for the accurate identification and cleanup of virtual contract data in a "cold state." For example, in the example above, virtual contracts VC2 and VC3 are identified as cold and cleaned up. This effectively avoids the storage exhaustion and performance degradation problems caused by the indiscriminate accumulation of all data under the full retention strategy.

[0071] Compared to the traditional Least Recently Used (LRU) algorithm, this embodiment determines the cache state by comprehensively evaluating the call frequency of the virtual contract within a time window, rather than relying solely on the most recent usage time. This time window and call frequency-based approach better captures the potential burstiness and periodicity of smart contract calls over time. For example, a virtual contract may be active during some time periods but inactive during others. The method in this application can determine the cache state based on its actual activity within the time window, avoiding the frequent swapping and re-fetching of contract states with periodic call characteristics that might occur with the traditional LRU algorithm, thus reducing unnecessary network transmission overhead between shards.

[0072] Furthermore, the method in this application triggers storage optimization only when the storage capacity of the sharding exceeds a capacity threshold, which is fundamentally different from the fixed-time triggering method of periodic garbage collection mechanisms. This on-demand triggering mechanism avoids the problem of periodic garbage collection consuming a large amount of computing resources and disk read / write bandwidth at fixed points in time, thus effectively solving the problem of the system being unable to process normal transactions in a timely manner during the cleanup period, causing a periodic decrease in the overall system throughput and performance fluctuations. Through precise cleanup of inactive virtual contracts, this method can smoothly manage storage space, ensuring that the system maintains stable throughput and performance during long-term operation.

[0073] Reference Figure 2 The diagram illustrates a storage optimization system for sharded blockchains provided in an embodiment of this application. Specifically, it may include an acquisition module 21, a first determination module 22, a second determination module 23, and a positioning module 24, wherein: The statistics module is used to determine the call frequency of each virtual contract cached in the execution shard; The determination module is used to determine the cache state of each virtual contract based on the call frequency. The cache state is used to characterize the call frequency of the virtual contract within a time window. The optimization module is used to optimize the storage of execution shards based on cache status and storage capacity.

[0074] In one possible implementation, the frequency of calls to each virtual contract cached in the execution shard is determined, including: Within each transaction processing cycle, the total number of times each virtual contract is called across shard transactions is counted. The total number of times is the call frequency of the virtual contract within the transaction processing cycle.

[0075] In one possible implementation, each time window includes at least one transaction processing cycle, and the cache state of each virtual contract is determined based on the call frequency, including: Based on the frequency of virtual contract calls within each transaction processing cycle within a time window, calculate the popularity score of each virtual contract. The cache status is determined based on the popularity score.

[0076] In one possible implementation, a popularity score for each virtual contract is calculated based on the frequency of its invocation within each transaction cycle of a time window, including:

[0077] in, The popularity score is represented by W, where W is the number of transaction processing cycles within the time window. The time decay factor, The frequency of calls is represented by epoch, which is the identifier corresponding to the current transaction processing cycle. Used to identify each transaction processing cycle within a time window.

[0078] In one possible implementation, the cache state is determined based on the popularity score, including: If the popularity score is greater than or equal to the popularity judgment threshold, the cache status is determined to be hot. If the popularity score is less than the popularity threshold, the cache status is determined to be cold.

[0079] In one possible implementation, the cache state is determined based on the popularity score, including: Based on the popularity score calculated for each transaction processing cycle, determine the comprehensive popularity value corresponding to each virtual contract; If the overall popularity value is greater than or equal to the popularity judgment threshold, the cache status is determined to be hot. If the overall popularity value is less than the popularity judgment threshold, the cache status is determined to be cold.

[0080] In one possible implementation, storage optimization of the execution shards is performed based on the cache state and the storage capacity of the execution shards, including: If the storage capacity exceeds the capacity threshold, virtual contracts in a cold state are cleaned up to free up storage space for execution shards.

[0081] In one possible implementation, virtual contracts in a cold state are cleaned up to free up storage space for execution shards, including: The target virtual contract is defined as any virtual contract, or the virtual contract with the lowest overall popularity value among virtual contracts in a "cold" state. Delete the state data of the target virtual contract that is in a cold state; After the state data of each target virtual contract is deleted, check whether the storage capacity is greater than the capacity threshold. If the storage capacity is greater than the capacity threshold, a new target virtual contract is determined, and the target step and the steps following the target step are executed. The target step is to delete the state data of the target virtual contract that is in a cold state. If the storage capacity is less than the capacity threshold, then storage optimization for execution sharding is completed.

[0082] As the apparatus embodiments are basically similar to the method embodiments, they are described in a relatively simple manner. For relevant details, please refer to the description in the method embodiment section.

[0083] Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 3 As shown, the computer device 300 of this embodiment includes: at least one processor 30 ( Figure 3 (Only one is shown in the diagram), memory 31, and computer program 32 stored in memory 31 and executable on at least one processor 30, which, when executed by processor 30, performs the steps in any of the above-described method embodiments.

[0084] Computer equipment 300 can be used for cleaning, moving, etc. This computer equipment may include, but is not limited to, a processor 30 and a memory 31. Those skilled in the art will understand that... Figure 3 The computer device 300 is merely an example and does not constitute a limitation on the computer device 300. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0085] The processor 30 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0086] In some embodiments, memory 31 may be an internal storage unit of computer device 300, such as a hard disk or memory of computer device 300. In other embodiments, memory 31 may be an external storage device of computer device 300, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on computer device 300. Furthermore, memory 31 may include both internal and external storage units of computer device 300. Memory 31 is used to store operating system, application programs, bootloader, data, and other programs, such as program code of computer programs. Memory 31 may also be used to temporarily store data that has been output or will be output.

[0087] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps described in the various method embodiments above.

[0088] This application provides a computer program product that, when run on a computer device, enables the computer device to perform the steps described in the above-described method embodiments.

[0089] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A storage optimization method for sharded blockchains, characterized in that, include: Determine the call frequency of each virtual contract cached in the execution shard; Based on the call frequency, the cache state of each virtual contract is determined, and the cache state is used to characterize the call frequency of the virtual contract within the time window; If the storage capacity of the shard being executed is greater than the capacity threshold, then storage optimization is performed on the shard being executed based on the cache status.

2. The method as described in claim 1, characterized in that, Determine the call frequency of each cached virtual contract in the execution shard, including: Within each transaction processing cycle, the total number of times each virtual contract is called across shard transactions is counted. The total number of times is the call frequency of the virtual contract within the transaction processing cycle.

3. The method as described in claim 1, characterized in that, Each time window includes at least one transaction processing cycle. Based on the call frequency, the cache state of each virtual contract is determined, including: Based on the frequency of virtual contract calls within each transaction processing cycle within a time window, calculate the popularity score of each virtual contract. The cache status is determined based on the popularity score.

4. The method as described in claim 3, characterized in that, Based on the frequency of virtual contract calls within each transaction processing cycle within a time window, a popularity score is calculated for each virtual contract, including: in, The popularity score is represented by W, where W is the number of transaction processing cycles within the time window. The time decay factor, The frequency of calls is represented by epoch, which is the identifier corresponding to the current transaction processing cycle. Used to identify each transaction processing cycle within a time window.

5. The method as described in claim 3, characterized in that, Based on the popularity score, determine the cache status, including: If the popularity score is greater than or equal to the popularity judgment threshold, the cache status is determined to be hot. If the popularity score is less than the popularity threshold, the cache status is determined to be cold.

6. The method as described in claim 3, characterized in that, Based on the popularity score, determine the cache status, including: Based on the popularity scores calculated from multiple time windows, the overall popularity value corresponding to each virtual contract is determined. If the overall popularity value is greater than or equal to the popularity judgment threshold, the cache status is determined to be hot. If the overall popularity value is less than the popularity judgment threshold, the cache status is determined to be cold.

7. The method as described in claim 1, characterized in that, If the storage capacity of the executed shard is greater than the capacity threshold, then storage optimization is performed on the executed shard based on the cache state, including: If the storage capacity exceeds the capacity threshold, virtual contracts in a cold state are cleaned up to free up storage space for execution shards.

8. The method as described in claim 7, characterized in that, The cleanup of virtual contracts in a cold state to free up storage space for execution shards includes: The target virtual contract is defined as any virtual contract, or the virtual contract with the lowest overall popularity value among virtual contracts in a "cold" state. Delete the state data of the target virtual contract that is in a cold state; After the state data of each target virtual contract is deleted, check whether the storage capacity is greater than the capacity threshold. If the storage capacity is greater than the capacity threshold, a new target virtual contract is determined, and the target step and the steps following the target step are executed. The target step is to delete the state data of the target virtual contract that is in a cold state. If the storage capacity is less than the capacity threshold, then storage optimization for execution sharding is completed.

9. A storage optimization system for sharded blockchains, characterized in that, include: The statistics module is used to determine the call frequency of each virtual contract cached in the execution shard; The determination module is used to determine the cache state of each virtual contract based on the call frequency. The cache state is used to characterize the call frequency of the virtual contract within a time window. The optimization module is used to optimize the storage of the executed shards based on the cache status if the storage capacity of the executed shards is greater than the capacity threshold.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes a computer program to implement the method as claimed in any one of claims 1-8.

Images