Blockchain Contract Cache Segmentation for Hot-Data Retention
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The read/write efficiency of data in blockchain nodes is hindered by the lower performance of drives compared to internal memory, and the least recently used eviction mechanism can lead to inefficient access of long-term hot contracts when cache is insufficient, necessitating retrieval from slower databases.
Innovation Solution
Implementing a blockchain-based data processing method that allocates a total cache region into separate cache regions with distinct eviction mechanisms, allowing for dedicated cache management of custom contracts, evicting data based on specific criteria to ensure sufficient capacity for frequently accessed data.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If a single unified cache is used for all contracts, then the cache utilization is simplified and management is easier, but long-term hot contracts may be evicted to make space for short-term hot contracts, reducing data access efficiency
Solution Approach 1:
The patent divides the unified cache into multiple isolated cache regions, each dedicated to storing data for specific contracts. This segmentation prevents interference between different contracts' cache data, ensuring that long-term hot contracts retain their cache space even when short-term hot contracts are accessed frequently. Each cache region operates independently with its own eviction mechanism, resolving the contradiction by maintaining both manageable structure and high access efficiency.
2Speed
If the cache capacity is increased to accommodate more data, then data access efficiency improves, but the system resource consumption increases and the cost rises
Solution Approach 1:
The patent implements different eviction mechanisms in different cache regions based on local characteristics. For example, cache regions for contracts with stable access patterns may use LRU (Least Recently Used) eviction, while regions for contracts with periodic access patterns may use different strategies. This local optimization allows each cache region to efficiently manage its limited space according to its specific access patterns, maximizing data access efficiency without requiring excessive overall cache capacity.
3Device complexity
If the least recently used eviction mechanism is used to manage cache, then the implementation is simple, but short-term hot contracts may occupy cache space needed by long-term hot contracts, reducing overall system performance
Solution Approach 1:
By segmenting the cache into isolated regions per contract, the patent allows each region to use simple LRU eviction independently without causing interference. The segmentation ensures that evictions in one contract's cache region do not affect other contracts' cache data, thereby maintaining simple implementation while improving overall system productivity through prevented cache thrashing and ensured retention of long-term hot contracts.
Data Source
Figure 1
Figure 2a
Figure 2b
AI summary
A blockchain-based data processing method, comprising: acquiring an application cache instruction for a target customized contract, and, according to customized cache creation parameters in the application cache instruction, creating in the total cache area a cache area associated with the target customized contract, the total cache area comprising at least two cache areas, and cache eviction mechanisms of the cache areas in the total cache area being independent of one another (S101); when contract data to be cached that corresponds to the target customization contract is received, searching for the cache area associated with the target customization contract and using same as a target cache area (S102); if the available cache capacity of the target cache area is less than the capacity to be cached of the contract data to be cached, then, according to the cache eviction mechanism of the target cache area, performing eviction on cache contract data in the target cache area to obtain a new available cache capacity, the new available cache capacity being greater than the capacity to be cached (S103); and, according to the new available cache capacity, storing the contract data to be cached into the target cache area (S104).