Elastic service optimization method for block chain data storage
Optimize ledger data storage through batch coding and high-level coding, and efficiently manage state data with the dual Trie state management system, the challenge of delicensing blockchain storage is solved, and efficient and fair atomic cross-chain operation and dynamic network maintenance solutions are achieved.
Patent Information
- Application Number
- CN202510286212.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-12
- Publication Date
- 2025-06-10
AI Technical Summary
The existing technology is difficult to effectively solve the challenge of delicensing blockchain storage, especially under decentralized asynchronous networks, which cannot support efficient and fair atomic cross-chain operations.
The ledger data storage is optimized by batch coding and a high-level encoding method, combined with the dual Trie state management system to efficiently manage the state data, and efficient data storage and retrieval is achieved through the partitioning and erasure coding technology of hot and cold Trie.
It realizes efficient storage and retrieval of booklet data and state data, reduces storage costs, supports efficient and fair atomic cross-chain operations, and adapts to the dynamics of the delicensing network.
Smart Images
Figure CN120128599A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of blockchain technology, and particularly relates to a method for optimizing the elastic service of blockchain data storage. Background Art
[0002] With the large emergence of distributed applications (Decentralized Apps, DApps) on permissionless blockchains, such as blockchain games, decentralized exchanges (Decentralized EXchange, DEX), and decentralized finance (Decentralized Finance, DeFi), the amount of blockchain data has shown an explosive growth. Especially in the Ethereum network, the daily data growth of each node is about 0.2GB, which brings huge pressure to blockchain storage nodes. The blockchain storage overhead mainly comes from ledger data and state data. Ledger data is the immutable blockchain, and each block contains a set of transactions; state data is the current system state derived from past transactions, usually organized in a tree structure for quick verification. Existing storage optimization methods such as pruning, compression, stateless blockchains, and erasure codes all have limitations and cannot effectively solve the storage challenges of permissionless blockchains, and it is difficult to adapt to the dynamics of permissionless networks.
[0003] The emergence of state channels has broadened the application of payment channels, enabling off-chain channels to provide more services. Virtual channels can effectively reduce the cost of channel network construction and improve transaction processing efficiency. Therefore, it is of great significance to extend the existing off-chain channel solutions to cross-chain operations. However, they were initially proposed for single-chain operations and cannot be directly extended to support cross-chain operations considering the challenges brought by the congestion of unsettled amounts and unfair exchange problems. In addition, the current design of cross-chain solutions that do not rely on a third party (such as HTLC) targets synchronous networks, and the infinite latency in asynchronous networks may render them ineffective. Summary of the Invention
[0004] Based on the above problems, this application provides a method for optimizing the elastic service of blockchain data storage, which supports an off-chain channel for fair and atomic cross-chain operations and can effectively support efficient and fair atomic cross-chain operations in a decentralized asynchronous network. The technical solution is as follows:
[0005] A method for optimizing the elastic service of blockchain data storage. For ledger data, batch encoding and height-based encoding methods are used to optimize storage; for state data, a dual Trie state management method is adopted: the original state Trie is divided into a hot Trie and a cold Trie. The hot Trie is used to maintain frequently accessed states, and the cold Trie uses erasure codes to fragment and distribute infrequently accessed states.
[0006] Preferably, the batch encoding selects a leader through a verifiable random function, specifies the block height to be encoded, encodes consecutive k blocks as a batch, and encodes from the genesis block to the specified height.
[0007] Preferably, height-based encoding: applies an erasure code to historical blocks that are far from the current blockchain tip. That is, in height-based encoding, the erasure code is only applied to blocks whose height difference from the tip is greater than or equal to M, while blocks with a height difference from the tip less than M are stored in full replication; the set of blocks stored using the erasure code is B EC = {b|b.height < Tip.height - M}, and the set of blocks stored in full replication is B full = {c|c.height ≥ Tip.height - M}.
[0008] Preferably, the hot Trie and cold Trie are managed through three processes: state creation, state mining, and state expiration; the state creation and state mining processes are called during the block execution process, while the state expiration process is called after each block is executed.
[0009] Preferably, state creation: when executing a block, the execution of each transaction involves accessing the state; when accessing the address of a state, it is first necessary to determine whether the state corresponding to this address already exists;
[0010] First, retrieve this address in the hot Trie. If it does not exist, then retrieve this address in the cold Trie; if it cannot be retrieved in both the hot Trie and the cold Trie, it means that this address corresponds to a new state. At this time, the state creation process is called; the creation of a new state requires the blockchain consensus process. First, Merkle proofs from both tries are needed to verify that the state did not exist before. Once the verification passes, the new state will be inserted into the hot Trie, and its frequency and recency will be tracked starting from the block height at which it was created.
[0011] Preferably, state mining: if the accessed state already exists in the hot Trie, it can be directly accessed; when the state currently exists in the cold Trie, the state mining process is called, and the state will be transferred to the hot Trie for faster retrieval in the future.
[0012] Preferably, state expiration: after a block is executed, start checking the states in the hot Trie that have not been accessed within time ΔT and whose access frequency in the past fixed number M of blocks is lower than a specific threshold F, and move them to the cold Trie. This process is called state expiration; state expiration comprehensively considers two key factors: the access frequency and recency of the state;
[0013] Access frequency threshold F: The access frequency refers to the threshold of the frequency of access in a specific time period, that is, in the past M blocks. One of the conditions for state expiration is that:
[0014]
[0015] Considering that newly created states may have a low access frequency but still have a high probability of being accessed in the short term, a recency threshold ΔT is set; the recency of a state refers to the time elapsed (measured by the block height difference) since the block height at which the state was last accessed to the current tip height. Another condition for the corresponding state expiration is that:
[0016] Tip.height - s.lastVisitHeight > ΔT.
[0017] Preferably, the cold Trie is encoded using the SplitTrie function, and the steps are as follows:
[0018] In the first step, the cold Trie is split into k balanced sub-Tries;
[0019] In the second step, the Merkle paths from the roots of these sub-Tries to the root of the original cold Trie are retained;
[0020] In the third step, the k sub-Tries together with the corresponding Merkle paths are encapsulated into data blocks as the input of the encoding function;
[0021] In the fourth step, m redundant blocks are generated through (k, m)-RS encoding.
[0022] Preferably, for blockchain network nodes, they are managed in "groups", including group upgrade and group downgrade; among them: Group upgrade: When two groups of the same size are identified, they can be merged into a larger single group, and the number of groups is proportional to the number of "1"s in the binary representation of N;
[0023] Group downgrade: When the node departure rate of a group exceeds 1 / 4 of its total members, the downgrade process will be initiated to maintain the group's resilience to at most 1 / 3 of the nodes that may exhibit Byzantine behavior;
[0024] After the downgrade results in two smaller groups, the check for group upgrade will be immediately triggered. If there are groups of the same size as these two groups at this time, the group upgrade will be immediately carried out.
[0025] Preferably, during group upgrade or group downgrade, the blockchain data in these groups must be modified according to the new configuration, and the specific method is as follows:
[0026] Converting from the (k,m)-RS scheme to the (2k,2m)-RS scheme requires converting the stored blocks, which involves merging adjacent batches of k blocks into batches of 2k blocks; assume two groups g 1 and g 2 using the (k,m)-RS scheme, which are merged to form a new group g 3 , using the (2k,2m)-RS scheme; nodes and hold the original data blocks, while nodes and store the corresponding parity blocks. In the EC-Chain, the data blocks are organized into batches (B1,B2,...), each batch containing 2k blocks; for data block updates, only the odd batches are retained, while only the even batches are retained; after merging into g 3 , and collectively own the encoded batch of 2k blocks without reallocating the data blocks; afterwards, nodes and can request the necessary data blocks from and and generate parity blocks using the (2k,2m)-RS; converting from the (k,m)-RS scheme to the (2k,2m)-RS scheme for state data updates requires a split operation on the sub-Trie; since and share the same encoded cold Trie, node pairs (p 1 ,p 2 ) can be considered, where p 1 belongs to and p 2 belongs to and process the same sub-Trie; for each such pair of nodes (p 1 ,p 2 ), p 1 and p 2 independently split their sub-Tries into two balanced sub-Tries, denoted as p 1 and T 2 ;
[0027] Then, p 1 retains T 1 , and p 2 retains T 2 ;
[0028] Finally, and obtain the encoded state data according to the new (2k,2m)-RS scheme and generate parity blocks from these data blocks;
[0029] During the downgrade period, the process of updating the ledger and status data is the opposite of the upgrade process.
[0030] Compared with the prior art, the beneficial effects of this application are as follows:
[0031] 1. Apply the Erasure Coding (EC) technology to both the ledger data and the status data to reduce the storage cost. For the ledger data, improve the existing EC-based blockchain storage optimization technology by using batch coding and height-based coding methods; for the status data, introduce an innovative dual Trie state management system, divide the original state Trie into a hot Trie and a cold Trie, and achieve efficient status data management through technologies such as state expiration, mining, and creation.
[0032] 2. Use the Trie splitting method to enhance the efficiency of extracting information from the coded segments, enabling efficient retrieval of specific data without restoring the entire cold Trie, while maintaining data integrity and verifiability.
[0033] 3. Design a network maintenance solution that adapts to the dynamics of the permissionless network, providing a flexible mechanism for group upgrades and downgrades as well as block updates to cope with frequent node joins and departures and improve data availability. Description of the Drawings
[0034] Figure 1 It is a schematic diagram of the coded storage for the ledger;
[0035] Figure 2 It is a schematic diagram of the coded storage for the status;
[0036] Figure 3 It is a schematic diagram of the group combination;
[0037] Figure 4 It is a schematic diagram of the system implementation framework;
[0038] Figure 5 It is a schematic diagram of the test results of the storage overhead of a single node; where (a) shows the variation of the storage overhead of a single node with the increase of the block height under different group sizes (N), with ΔT = 10 fixed at this time 4 , F = 10 -2 ; (b) shows the variation of the storage overhead of a single node with the increase of the block height under different values of ΔT and F, with the group size N = 8 fixed at this time;
[0039] Figure 6Graph of group upgrade and downgrade latency test results; where (a) shows the change in latency during the group upgrade process with the increase in block height under different group sizes (N), ΔT, and F values, and (b) shows the change in latency during the group downgrade process with the increase in block height under different group sizes (N), ΔT, and F values;
[0040] Figure 7 Graph of transaction latency test results; where (a) shows the distribution of transaction latency under different group sizes (N), with ΔT fixed at 10 4 , F = 10 -2 ; (b) shows the distribution of transaction latency under different ΔT and F values, with the group size N fixed at 8;
[0041] Figure 8 Graph of transaction throughput test results; where (a) shows the distribution of transaction throughput under different group sizes (N), with ΔT fixed at 10 4 , F = 10 -2 ; (b) shows the distribution of transaction throughput under different ΔT and F values, with the group size N fixed at 8. Detailed implementation manners
[0042] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present invention.
[0043] An elastic service optimization method for blockchain data storage. For ledger data, batch encoding and height-based encoding methods are used to optimize storage; for state data, a dual Trie state management method is adopted: the original state Trie is divided into a hot Trie and a cold Trie. The hot Trie is used to maintain frequently accessed states, and the cold Trie uses erasure codes to fragment and distribute infrequently accessed states.
[0044] Ledger data encoding:
[0045] (1) Batch encoding: Select a leader through a Verifiable Random Function (VRF), specify the block height to be encoded, encode consecutive k blocks as a batch, and start encoding from the genesis block to the specified height. For example Figure 1As shown, for a group of size 4 (k = 2, m = 2), if the leader designates the encoding of blocks (1 - 4), it is divided into two batches: blocks (1 - 2) and blocks (3 - 4). This method facilitates block verification, avoids the additional overhead caused by non - consecutive block encoding, and enables parallel encoding in multiple batches, thus improving the encoding speed.
[0046] (2) Height - based encoding: Considering that blockchain access patterns mainly focus on blocks near the tip of the current blockchain, such as block synchronization, transaction verification, and blockchain exploration, erasure codes are applied to historical blocks that are far from the tip of the current blockchain. In a blockchain, the block height represents the sequence number of the block. The height of the genesis block is 0, and the height of each other block is 1 more than the height of its parent block. In height - based encoding, erasure codes are only applied to blocks whose height difference from the tip (referring to the latest confirmed block) exceeds M = 10000, while blocks whose height difference from the tip does not exceed 10000 are stored in full replication. That is, the set of blocks stored using erasure codes is B EC ={b|b.height < Tip.height - M}, and the set of blocks stored in full replication is B full ={c|c.height ≥ Tip.height - M}. This encoding method ensures that only a very small part of the ledger (about 0.1%) needs to be replicated in full. At the same time, since the vast majority of access requests to ledger data only target a certain number of the latest blocks, this encoding method can still respond quickly to most access requests.
[0047] State data encoding:
[0048] (1) Dual Trie state management system. The state Trie is divided into a hot Trie and a cold Trie. The hot Trie is used to maintain frequently accessed states and is stored in full replication to prioritize retrieval speed; the cold Trie uses erasure codes to fragment and distribute infrequently accessed states to optimize storage utilization. As Figure 2 shown, these two Tries are effectively managed through three processes: state creation, state mining, and state expiration. The state creation and state mining processes are called during the block execution process, while the state expiration process is called after each block is executed.
[0049] a. State Creation: When executing a block, the execution of each transaction involves accessing (reading and writing) the state. When accessing the address of a state, it is first necessary to determine whether the state corresponding to this address already exists. First, search for this address in the hot Trie. If it does not exist, then search for this address in the cold Trie. If it cannot be found in both the hot Trie and the cold Trie, it means that this address corresponds to a new state. At this time, the state creation process is called. The creation of a new state requires the blockchain consensus process. First, Merkle proofs from both Tries are needed to verify that the state did not exist before. Once the verification passes, the new state will be inserted into the hot Trie, and its frequency and recency will be tracked starting from the block height at which it was created.
[0050] b. State Mining: If the accessed state already exists in the hot Trie, it can be directly accessed. When the state currently exists in the cold Trie, the state mining process is called, and the state will be transferred to the hot Trie for faster retrieval in the future. This process is called state mining, which allows nodes to transfer active states from the cold Trie to the hot Trie.
[0051] c. State Expiration: After a block is executed, start checking the states in the hot Trie that have not been accessed for a long time (within ΔT time), and move them to the cold Trie. This process is called state expiration. State expiration comprehensively considers two key factors, the access frequency and recency of the state, to distinguish between cold / hot accounts. Frequency refers to the rate at which a state is accessed within a specific time period (measured by block height). Based on the observation that states with low access frequencies are less likely to be accessed again; however, newly generated states with low access frequencies may still be accessed in the future. Therefore, recency (the distance from the last accessed block to the blockchain tip) is also an important consideration. By combining these two factors, the system can accurately distinguish between cold and hot states, ensuring that most state accesses can be completed by querying the hot Trie and reducing the need to access the cold Trie. There is a trade-off between storage cost and efficiency when determining the thresholds for frequency and recency (F and ΔT): increasing F and decreasing ΔT will cause more accounts to be transferred to the cold Trie for erasure coding, thus reducing storage costs, but will increase transaction execution latency due to more frequent access to the cold Trie.
[0052] (2) Cold Trie Encoding. Usually, when using erasure codes to store data, the data needs to be first split into a certain number (k) of data blocks, and then these data blocks are encoded by an encoding function to obtain a certain number (m) of redundant blocks. Such an encoding scheme is represented by (k,m)-RS. Trie is a data structure convenient for querying. If the cold Trie is directly split, the tree structure of the Trie will be damaged, and the obtained data blocks cannot be directly used for status query. The complete cold Trie needs to be restored to query the data in the cold Trie, which is relatively inefficient. To avoid this situation, the SplitTrie function is designed.
[0053] In the first step, the cold Trie is split into k balanced sub-Tries.
[0054] In the second step, the Merkle paths from the roots of these sub-Tries to the root of the original cold Trie are retained.
[0055] In the third step, the k sub-Tries together with the corresponding Merkle paths are encapsulated into data blocks as the input of the encoding function.
[0056] In the fourth step, m redundant blocks are generated through (k,m)-RS encoding.
[0057] Such data blocks retain the original data structure of the Trie, support status query, and at the same time support status verification through Merkle paths.
[0058] A new network maintenance scheme is proposed for the storage challenges caused by the frequent joining and leaving of nodes in the permissionless network. Since larger EC groups require less storage space on each node, this encourages nodes to join larger groups, thus minimizing their respective storage consumption. However, larger groups increase the risk of storage unreliability. Therefore, a new rule is designed: larger groups must be formed by merging two smaller groups. This rule ensures that a node must stay in the network for a longer time to become part of a larger group, effectively reducing the risk brought by short-lived participants.
[0059] (1) Group Upgrade and Downgrade. As Figure 3As shown, when two groups of the same size are identified, they can be merged into a larger single group to enjoy lower redundancy. Based on the network setup, the number of groups is proportional to the number of '1's in the binary representation of N. For example, a network with 136 nodes will eventually form two stable groups: a larger group g(128) (using (64,64)-RS coding) and a smaller group g(8) (using (4,4)-RS coding). This arrangement reflects the binary representation of 136, which is 10001000. Given that the storage cost of maintaining the blockchain is proportional to the size of the group, the storage cost of the entire network is linearly related to the number of groups. This number can vary from 1 in the optimal case to log(N) in the worst case, with an average of log(N) / 2. If a node leaves the network or fails, two situations can occur: temporarily offline and offline for a long time. A node may be temporarily offline and is expected to return soon. During this period, the group can continue to operate because the redundancy provided by the EC scheme ensures continuous access to the blockchain data. However, if the number of active nodes in a group drops below the critical threshold, the network will be vulnerable to Byzantine attacks. Therefore, when the node departure rate of a group exceeds 1 / 4 of its total members, a downgrading process will be initiated to maintain the group's resilience against up to 1 / 3 of the nodes potentially exhibiting Byzantine behavior. To downgrade a group that has lost 1 / 4 of its nodes, the remaining 3 / 4 members will be reorganized into two smaller groups. One group will consist of the remaining 1 / 4 nodes, and the other will include 1 / 2. This downgrading ensures that both new groups follow the rule of being a power of 2 in size, facilitating future adjustments. It should be noted that after the downgrading results in two smaller groups, a check for group upgrading will be immediately triggered. If there are groups of the same size as these two groups at this time, group upgrading will be carried out immediately.
[0060] (2) Block update. During group upgrading or downgrading, the blockchain data in these groups must be modified according to the new configuration. Specifically, converting from the (k,m)-RS scheme to the (2k,2m)-RS scheme requires converting the stored blocks, which involves merging adjacent batches of k blocks into batches of 2k blocks. Suppose two groups g 1 and g 2 use the (k,m)-RS scheme and they merge to form a new group g 3 , using the (2k,2m)-RS scheme. Nodes and hold the original data blocks, while nodes and store the corresponding parity blocks. In EC-Chain, the data blocks are organized into batches (B1, B2,...), and each batch contains 2k blocks. For data block updates, only the odd batches are retained, while only the even batches are retained. Therefore, when merging into g3 After that, and jointly own the encoded 2k block batches without reallocating data blocks. After that, nodes and can request the necessary data blocks from and and use (2k, 2m)-RS to generate parity blocks. Converting from the (k, m)-RS scheme to the (2k, 2m)-RS scheme requires a split operation on the sub-Trie for updating the state data. Since and share the same encoded cold Trie, node pairs (p 1 , p 2 ) can be considered, where p 1 belongs to p 2 belongs to and process the same sub-Trie. Each node in the pair independently splits its sub-Trie into two balanced sub-Tries, denoted as T 1 and T 2 . Then, p 1 retains T 1 , and p 2 retains T 2 . Finally, and obtain the encoded state data according to the new (2k, 2m)-RS scheme and generate parity blocks from these data blocks. The process of updating the ledger and state data during downgrade is the opposite of the upgrade process, so it will not be elaborated here.
[0061] Example:
[0062] (1) System implementation. As Figure 4 EC-Chain is implemented based on go-ethereum (the most widely used implementation of Ethereum, developed in Golang). The ledger encoding module with 631 lines of code and the state encoding module with 967 lines of code are integrated into the blockchain database of Ethereum. In addition, a network maintenance module with 429 lines of code is written and integrated into the p2p module of Ethereum responsible for network management. The RS encoding library is provided by Klaus Post, and the DHT library is provided by Protocol Labs.
[0063] (2) Experimental environment. Up to 64 blockchain nodes are distributed in 17 regions of 10 countries. Each node is equipped with an 8-core CPU, 32GB of memory, and 512GB of NVMe SSD, running the Ubuntu 22.04 LTS operating system with a bandwidth of 1Gbps. Additionally, a client is run to synchronize transactions from the Ethereum mainnet in full synchronization mode and forward them to the blockchain nodes for transaction replay.
[0064] (3) Storage cost evaluation. As Figure 5 shown, the experimental results indicate that when the network scale N = 64, the storage cost of EC-Chain nodes is 91.8% lower than that of Ethereum nodes. When N increases, the storage cost per node decreases because the data is encoded by (k,m)-RS, where k = m = |g| / 2. Additionally, increasing the frequency threshold F and decreasing the recency threshold ΔT can reduce the storage cost because more states are transferred to the cold Trie for erasure coding.
[0065] (4) Network maintenance latency evaluation. As Figure 6 shown, as the blockchain grows, the latency of group upgrades and downgrades increases because it takes more time to update the blocks. When ΔT increases and F decreases, more states are retained in the hot Trie, thus reducing the latency of group upgrades and downgrades. Larger groups have lower latency than smaller groups because they benefit from more concurrent data transfers, optimizing the use of available bandwidth. Additionally, the latency of group upgrades is slightly lower than that of downgrades because during group upgrades, most data blocks are accessible, while during downgrades caused by node differences, the possibility of losing data blocks is higher and additional decoding work needs to be done from the remaining parity blocks.
[0066] (5) Transaction latency and throughput evaluation. The transaction latency of EC-Chain is similar to that of Ethereum, indicating that the network scale N has little impact on transaction latency. As Figure 7 shown, when ΔT = 10^4 and F = 10^-2, the latency of EC-Chain is almost the same as that of Ethereum. As F decreases or ΔT increases, more states are retained in the hot Trie, allowing for faster verification. As Figure 8 shown, in all the tested scenarios, the throughput of EC-Chain is almost equal to that of Ethereum, indicating that EC-Chain does not reduce throughput.
[0067] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on such an understanding, the essence of the above technical solution, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.
[0068] Those skilled in the art can easily understand that the above are only preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent replacements, and improvements made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims
1. A method for optimizing elastic services for blockchain data storage, characterized in that: For ledger data, batch encoding and height-based encoding methods are used to optimize storage; for state data, a dual Trie state management method is adopted: the original state Trie is divided into hot Trie and cold Trie. The hot Trie is used to maintain frequently accessed states, while the cold Trie uses erasure codes to shard and distribute infrequently accessed states.
2. The elastic service optimization method for blockchain data storage according to claim 1 is characterized in that: The batch encoding is to select a leader through a verifiable random function, specify the block height to be encoded, encode k consecutive blocks as a batch, and encode from the genesis block to the specified height.
3. The elastic service optimization method for blockchain data storage according to claim 1 is characterized in that: Height-based encoding: Apply erasure codes to historical blocks that are far from the current blockchain tip. That is, in height-based encoding, apply erasure codes only to blocks whose height difference from the tip is greater than or equal to M, and keep full replication storage for blocks whose height difference from the tip is less than M. The set of blocks stored using erasure codes is B EC = {b | b.height < Tip.height - M}, and the set of blocks stored using full replication is B full = {c | c.height ≥ Tip.height - M}.
4. The elastic service optimization method for blockchain data storage according to claim 1 is characterized in that: Hot Trie and cold Trie are managed through three processes: state creation, state mining, and state expiration. The state creation and state mining processes are called during the block execution process, while the state expiration process is called after each block is executed.
5. The elastic service optimization method for blockchain data storage according to claim 4 is characterized in that: State creation: When executing a block, the execution of each transaction involves accessing a state. When accessing the address of a state, you first need to determine whether the state corresponding to this address already exists. First, the address is retrieved in the hot trie. If it does not exist, the address is retrieved in the cold trie. If it cannot be retrieved in both the hot trie and the cold trie, it means that the address corresponds to a new state, and the state creation process is called at this time. The creation of a new state requires a blockchain consensus process. First, Merkle proofs from two tries are required to verify that the state did not exist before. Once the verification is passed, the new state will be inserted into the hot trie, and its frequency and recency will be tracked starting from the block height where it was created.
6. The elastic service optimization method for blockchain data storage according to claim 4 is characterized in that: State mining: If the state to be accessed already exists on the hot Trie, it can be accessed directly; when the state currently exists in the cold Trie, the state mining process is called and the state will be transferred to the hot Trie for faster retrieval in the future.
7. The elastic service optimization method for blockchain data storage according to claim 4 is characterized in that: State expiration: When a block is executed, the hot Trie is checked for states that have not been accessed within time ΔT and whose access frequency in the past fixed number of blocks M is lower than a specific threshold F, and moved to the cold Trie. This process is called state expiration. State expiration takes into account two key factors: the access frequency and recency of the state. Access frequency threshold F: Access frequency refers to the threshold of the frequency of access in a specific time period, that is, in the past M blocks, that is, one of the conditions that must be met for the state to expire is: Considering that the newly created state may have a lower access frequency, but still has a high probability of being accessed in the short term, a recency threshold ΔT is set; the recency of a state refers to the time that has passed since the block height of the state was last accessed from the current tip height. Another condition that needs to be met for the corresponding state to expire is: Tip.height-s.lastVisitHeight>ΔT; Tip.height is the height of the block last visited, and Tip.height is the current tip height.
8. The elastic service optimization method for blockchain data storage according to claim 1 is characterized in that: Use the SplitTrie function to encode the cold Trie. The steps are as follows: The first step is to split the cold Trie into k balanced sub-Tries; The second step is to preserve the Merkle paths from the roots of these sub-tries to the original cold trie root; The third step is to encapsulate the k sub-tries and the corresponding Merkle paths into a data block as the input of the encoding function; The fourth step is to generate m redundant blocks through (k,m)-RS coding.
9. The elastic service optimization method for blockchain data storage according to claim 1 is characterized in that: For blockchain network nodes, they are managed by "group", including group upgrade and group downgrade; among them: Group Upscaling: When two groups of equal size are identified, they can be merged into a single larger group, with the number of groups proportional to the number of "1"s in the binary representation of N; Group Demotion: When the node departure rate of a group exceeds 1 / 4 of its total members, a demotion process is initiated to keep the group resilient against up to 1 / 3 of the nodes that may exhibit Byzantine behavior; After downgrading to two smaller groups, the group upgrade check will be triggered immediately. If there is a group with the same size as these two groups, the group will be upgraded immediately.
10. The elastic service optimization method for blockchain data storage according to claim 1 is characterized in that: During a group upgrade or group downgrade, the blockchain data in these groups must be modified according to the new configuration, as follows: Converting from the (k,m)-RS scheme to the (2k,2m)-RS scheme requires converting the stored blocks, which involves merging adjacent batches of k blocks into batches of 2k blocks; suppose two groups g1 and g2 use the (k,m)-RS scheme, and they merge to form a new group g3, which uses the (2k,2m)-RS scheme; nodes and Holds the original data block, while the node and Store the corresponding check blocks. In EC-Chain, data blocks are organized into batches (B1, B2, ...), each batch contains 2k blocks; for data block updates, Only odd batches are kept, and Only even-numbered batches are retained; after merging into g3, and Shared ownership of the encoded 2k block batches without reallocating data blocks; Afterwards, the node and Can be obtained from and Request the necessary data blocks and use (2k, 2m)-RS to generate the check blocks; the update of the state data from the (k, m)-RS scheme to the (2k, 2m)-RS scheme requires the sub-Trie to be split; and Sharing the same encoding cold trie, we can consider a node pair (p1, p2), where p1 belongs to p2 belongs to Process the same sub-Trie; for each pair of nodes (p1, p2), p1 and p2 independently split their sub-Trie into two balanced sub-Tries, denoted as T1 and T2 respectively; Then, p1 retains T1 and p2 retains T2; at last, and Obtain the coded state data according to the new (2k,2m)-RS scheme and generate check blocks from these data blocks; The process of updating the ledger and state data during a downgrade is the reverse of the upgrade process.