Blockchain state management method and system based on delayed write and sliding window state tree

Abstract

This invention discloses a blockchain state management method and system based on delayed writes and a sliding window state tree. The method includes, in response to the execution of the current block, applying the generated state update to the sliding window state tree in memory and generating a local state commitment stored in the current block header; and, in response to the fulfillment of preset conditions, asynchronously calculating the global state root based on the accumulated state updates in the sliding window state tree and disclosing it in the header of subsequent blocks. This invention introduces a TCP-inspired congestion control strategy, adaptively adjusting the window span vector according to the number of active leaf nodes. By decoupling state root calculation from block verification, reducing disk I / O operations, and dynamically adjusting memory load, it significantly improves the transaction processing throughput, node verification efficiency, and attack resistance of the blockchain system, making it suitable for public blockchains, consortium blockchains, and permissioned blockchain environments.

Description

Technical Field

[0001] This invention relates to the field of blockchain state verification technology, and in particular to a blockchain state management method and system based on delayed writing and a sliding window state tree. Background Technology

[0002] Currently, blockchain systems (such as Ethereum) rely on Authentication Data Structures (ADS) to manage and store massive global states. Traditional systems often use Merkle Patricia Trees (MPTs) or Verkle trees as state storage structures. MPTs construct a tree structure through hash calculations of key-value path paths, enabling the generation of existence proofs for arbitrary state data; Verkle trees, on the other hand, compress the proof volume through vector commitments, reducing the verification overhead of lightweight nodes.

[0003] However, as blockchain-supported smart contracts become increasingly complex and transaction density increases, state tree maintenance has become a core performance bottleneck limiting system throughput. Specifically: 1. Strong coupling between state root calculation and block execution: When generating or verifying each block, the system must synchronously modify the underlying state tree and calculate the state root in real time. In systems like Ethereum, this process requires nodes to immediately load the modified node from disk and recalculate the root hash after executing all transactions, causing the block generation path to be blocked.

[0004] 2. Huge I / O and computational overhead: For MPT trees, each state change requires O(logN) disk accesses, and each new block may involve thousands of state modifications, resulting in a serious disk I / O amplification problem; while for Verkle trees, which aim to reduce proof size, the elliptic curve vector commitments (such as IPA and KZG10) introduced bring extremely high CPU computational burden, with a single commitment calculation taking up to milliseconds, making it difficult to meet the sub-second block generation requirements.

[0005] 3. Poor ability to handle sudden load surges: The existing state tree lacks caching and congestion management mechanisms. When faced with drastic fluctuations in on-chain transaction volume (such as the NFT minting craze) or malicious state bloat attacks, it is highly susceptible to network-wide synchronization delays or even network paralysis due to instantaneous I / O saturation or memory exhaustion. For example, attackers can rapidly expand the state tree size by creating a batch of "dust accounts," causing node memory overflow.

[0006] To address the aforementioned issues, there is an urgent need for a blockchain state management mechanism that can decouple state root calculation, significantly reduce I / O frequency, and adapt to network load fluctuations. Summary of the Invention

[0007] The purpose of this invention is to overcome the shortcomings of the existing technology. To achieve the above objectives, a blockchain state management method and system based on delayed writing and sliding window state tree is adopted to solve the problems mentioned in the background technology.

[0008] A blockchain state management method based on delayed write and sliding window state tree, applied to blockchain nodes, includes the following steps: In response to the execution of the current block, the resulting state update is applied to the sliding window state tree maintained in memory, and a local state commitment corresponding to the current block is generated based on the updated sliding window state tree. The local state commitment is stored in the block header of the current block for other nodes to verify state consistency. In response to the satisfaction of the preset global state root generation conditions, the global state root is asynchronously calculated and generated based on the accumulated state updates in the sliding window state tree, and the global state root is stored in the block header of the subsequent block.

[0009] As a further aspect of the present invention: the nodes in the sliding window state tree include a time indicator field and a capacity indicator field. The time indicator field is used to record the block range corresponding to the state data represented by the node, and the capacity indicator field is used to record the number of leaf nodes under the node.

[0010] As a further aspect of the present invention: applying the state update to the sliding window state tree further includes: According to the preset window mapping rules, the window index bit corresponding to the current block's state update in the sliding window state tree is determined, so as to map the state update to the sliding window state tree.

[0011] As a further aspect of the present invention: the window mapping rule is a static fixed mapping rule, and the static fixed mapping rule is as follows: Based on the preset number S of consecutive blocks that each window can accommodate, and using the current block height... and the starting height of the sliding window Determine the window index bit corresponding to the current block.

[0012] As a further aspect of the present invention: the window mapping rule is a dynamic adaptive mapping rule, which includes: Through a variable span vector To dynamically allocate the number of consecutive blocks covered by each window bit, where For window width, This represents the number of consecutive blocks dynamically accommodated by the i-th window position.

[0013] As a further aspect of the present invention: determining the window index bit corresponding to the current block further includes: Based on the starting height of the current window and the span vector C, calculate the block height range corresponding to each window position; determine the corresponding window index position by judging which window position's block height range the current block height falls into.

[0014] As a further aspect of the present invention, it also includes: The values ​​of each element in the span vector C are dynamically adjusted based on the current number of active leaf nodes in the sliding window state tree.

[0015] As a further aspect of the present invention: dynamically adjusting the span vector C, including during the slow start phase, causing the block span allocated to the window bit to grow exponentially until a preset congestion threshold based on the physical capacity of the state tree is reached.

[0016] As a further aspect of the present invention: dynamically adjusting the span vector C further includes, during the congestion avoidance phase, changing the growth mode of the block span from exponential growth to linear growth after the block span exceeds the congestion threshold; This also includes, during the fast recovery phase, when the number of active leaf nodes is detected to exceed the preset memory capacity limit of the sliding window state tree, halving the current congestion threshold and deterministically recalculating the span vector allocation of the remaining window bits based on the height of the on-chain blocks and the bitmap information of the History field in the sliding window state tree.

[0017] The second aspect provides a technical solution: a system comprising a blockchain state management method based on delayed write and sliding window state tree as described in any of the above claims, including: The transaction execution module is configured to send the resulting state updates to the state cache module in response to the execution of the current block. The state caching module is configured to maintain a sliding window state tree residing in memory, apply the received state update to the sliding window state tree, and generate a local state commitment corresponding to the current block based on the updated sliding window state tree. The block generation module is configured to store the local state commitment in the block header of the current block; The global state management module is configured to, in response to the satisfaction of preset global state root generation conditions, obtain the accumulated state updates from the sliding window state tree from the state cache module, asynchronously calculate and generate a global state root, and send the global state root to the block generation module so that the block generation module can store the global state root in the block header of subsequent blocks.

[0018] Compared with the prior art, the present invention has the following technical advantages: 1. Improved Block Verification Efficiency: The delayed state root mechanism proposed in this invention effectively decouples state consistency verification from state root calculation during the block verification process. It utilizes a lightweight sliding window state tree to quickly verify state changes, while the calculation of the state root is performed asynchronously. By introducing this pipelined state processing mechanism, the block verification path is significantly shortened.

[0019] 2. Enhanced node processing performance: The sliding window state mechanism allows the global state tree to be generated once every few blocks, reducing the number of state tree updates required for each new block generation, reducing disk I / O and computing resource consumption caused by state root calculation, and effectively alleviating I / O bottlenecks.

[0020] 3. Adaptive load balancing and attack-resistant security: By introducing a TCP-like dynamic congestion control strategy, the system can automatically scale the window span to distribute data pressure when facing extreme fluctuations in network transaction volume or malicious state bloat attacks. In simulated attack tests, memory usage was consistently kept below safe limits, and no synchronization delay occurred, ensuring the stability and robustness of network-wide state synchronization.

[0021] 4. Significantly reduces the proof size and network overhead of stateless clients. Because the capacity of the sliding window state tree is strictly limited (constrained by the window width W and capacity limit), stateless nodes can directly synchronize and maintain this lightweight tree structure in their local memory. When verifying state transitions, stateless nodes can directly perform local self-verification for recently active state updates, only needing to obtain proofs for a small number of missed cached states and proofs for the transition from the memory tree to the global state tree via the network. This mechanism significantly reduces the frequency of requests for the complete global state tree proof path by stateless nodes, effectively solving the problem of excessive proof size and bandwidth bottlenecks caused by the expansion of the state tree in stateless client solutions. This technical effect, combining "lightweight caching" and "strict cryptographic verifiability," is something that a simple "caching + batch writing" solution cannot achieve. Attached Figure Description

[0022] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings: Figure 1 This is a schematic diagram illustrating the steps of a blockchain state management method according to an embodiment of this application; Figure 2 This is a schematic diagram of the delayed state root generation mechanism according to an embodiment of this application; Figure 3 This is a schematic diagram of a sliding window state tree according to an embodiment of this application; Figure 4This is a schematic diagram of the state of a block in an embodiment of this application.

[0023] Specialized Glossary: State root: The root hash or cryptographic commitment of the global state tree, which reflects a snapshot of all states on the chain at a certain moment and is used to generate proof of state existence. It is the key technical foundation of the verification mechanism.

[0024] ADS (Authenticated Data Structure): A data structure (such as MPT, Verkle tree) that can generate concise cryptographic commitments for a dataset, allowing any entity to verify the authenticity of a specific data element through a compact proof.

[0025] Sliding window state tree: a temporary authentication cache tree residing in memory that tracks the freshness of state updates by introducing a time window field, supporting fast pruning of expired data. Detailed Implementation

[0026] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] Example 1: Please refer to Figure 1 In this embodiment of the invention, a blockchain state management method based on delayed write and sliding window state tree is applied to a blockchain node, comprising the following steps: Step S1: In response to the execution of the current block, apply the generated state update to the sliding window state tree maintained in memory, and generate the local state commitment corresponding to the current block based on the updated sliding window state tree. In this embodiment, the nodes in the sliding window state tree include a time indicator field and a capacity indicator field. The time indicator field is used to record the block range corresponding to the state data represented by the node, and the capacity indicator field is used to record the number of leaf nodes under the node.

[0028] In this embodiment, applying the state update to the sliding window state tree further includes: According to the preset window mapping rules, the window index bit corresponding to the current block's state update in the sliding window state tree is determined, so as to map the state update to the sliding window state tree.

[0029] In this embodiment, the window mapping rule is a static fixed mapping rule, which is as follows: Based on the preset number S of consecutive blocks that each window can accommodate, and using the current block height... and the starting height of the sliding window Determine the window index bit corresponding to the current block.

[0030] In this embodiment, the window mapping rule is a dynamic adaptive mapping rule, which includes: Through a variable span vector To dynamically allocate the number of consecutive blocks covered by each window bit, where For window width, This represents the number of consecutive blocks dynamically accommodated by the i-th window position.

[0031] It is important to note that traditional memory caching cannot be directly applied in a blockchain environment. This is because if uncommitted states are only temporarily stored in a regular cache, the pending states in the cache cannot participate in Merkle root computation when a cryptographic state commitment needs to be generated for the current block, causing the consensus mechanism to fail. This invention addresses this by splitting a single global state commitment into a two-layer structure: an immediately valid local commitment and an asynchronously disclosed global commitment. This allows blocks to complete network-wide consensus verification on the immediate critical path by relying only on the root hash of a lightweight sliding window tree, while removing the time-consuming, large-scale persistent tree root computation from the critical path. This two-layer commitment decoupling design, while meeting the strict verifiability constraints of blockchain, achieves asynchronous pipelined state writing and commitment generation for the first time, and its technical implementation exhibits cross-domain non-obviousness.

[0032] Step S2: Store the local state commitment in the block header of the current block for other nodes to perform state consistency verification; Step S3: In response to meeting the preset global state root generation conditions, based on the accumulated state updates in the sliding window state tree, asynchronously calculate and generate the global state root, and store the global state root in the block header of the subsequent block.

[0033] In this embodiment, determining the window index corresponding to the current block further includes: Based on the starting height of the current window and the span vector C, calculate the block height range corresponding to each window position; determine the corresponding window index position by judging which window position's block height range the current block height falls into.

[0034] This embodiment also includes: The values ​​of each element in the span vector C are dynamically adjusted based on the current number of active leaf nodes in the sliding window state tree.

[0035] In this embodiment, the span vector C is dynamically adjusted, including during the slow start phase, causing the block span allocated to the window position to grow exponentially until a preset congestion threshold based on the physical capacity of the state tree is reached.

[0036] In this embodiment, dynamically adjusting the span vector C also includes, during the congestion avoidance phase, changing the growth mode of the block span from exponential growth to linear growth after the block span exceeds the congestion threshold. This also includes, during the fast recovery phase, when the number of active leaf nodes is detected to exceed the preset memory capacity limit of the sliding window state tree, halving the current congestion threshold and deterministically recalculating the span vector allocation of the remaining window bits based on the height of the on-chain blocks and the bitmap information of the History field in the sliding window state tree.

[0037] In this embodiment, the delayed state root mechanism is as follows: This mechanism significantly improves block verification efficiency by decoupling state consistency verification from state root calculation in the block verification process. Specifically, block verifiers can confirm state consistency without relying on a complete state root; instead, they use a sliding window state tree mechanism to quickly verify state changes. The generation of the state root is then processed asynchronously and performed in subsequent blocks.

[0038] In a full node, the generation of a state tree root is no longer mandatory when a block is proposed. Instead, the three stages of transaction execution, state tree construction, and state root disclosure are separated and processed in parallel in a pipeline manner. This avoids blocking the block generation process when calculating the state root, thus mitigating its impact on node performance. This process relies on two key components: a sliding window state tree (a memory structure that temporarily caches recent state updates) and a persistent global state tree (which stores long-term committed states).

[0039] like Figure 2 As shown in the figure, this is a schematic diagram of the delayed state root generation mechanism; Transaction execution phase: Responsible for executing all transactions in the current block and applying the resulting state updates to the temporary sliding window state tree, generating a state commitment based on the sliding window state tree, which will be embedded in the block.

[0040] State Tree Construction Phase: When the capacity of the sliding window state tree exceeds a preset threshold, or when there are insufficient available window slots, a global state commitment event is triggered. The sliding window state tree selects the least recently updated entries and inserts them in batches into the persistent global state tree. Crucially, this phase can proceed in parallel with the transaction execution phase of subsequent blocks, thus achieving efficient pipeline operations.

[0041] State root disclosure phase: Once the global state root is calculated, the result will be disclosed when the next block is packaged (included in the block header), and old entries that have been inserted into the global state tree will be officially pruned from the sliding window state tree.

[0042] In this embodiment, the sliding window state tree mechanism is as follows: Since the state root generation time is much longer than the block generation interval, frequently building new trees and performing merging operations during block generation not only incurs extremely high computational overhead but also severely slows down block confirmation speed. Furthermore, frequently creating new trees, saving intermediate states, and loading subtrees for merging leads to a large number of disk I / O operations, which will become a major bottleneck in system performance.

[0043] Therefore, this invention employs a sliding window tree to eliminate frequent tree construction, reduce computational overhead, optimize memory / storage, and reduce I / O, thereby improving node performance. Specifically, only one tree is maintained in a cache area, and all updates are incremental modifications to a single tree. Each insertion only updates the node hash along the path from the modified leaf node to the root node in the tree.

[0044] like Figure 3 As shown, the diagram illustrates a sliding window state tree. The History field uses an 8-bit format to record data storage status; 1 indicates that data exists at the current bit, and 0 indicates that the bit is empty or the data has been cleared. The History of the parent node is the union of the History of its child nodes. The Size field indicates the number of leaf nodes. The Size of the parent node is the sum of the sizes of its child nodes. The size is used to determine whether the tree needs pruning.

[0045] according to Figure 3 The History field of the parent node in the sliding window tree shows that blocks 3, 4, 5, and 6 contain data. If we need to delete data in block 3, we can determine this by checking if the third position of the History field is 1. A path search reveals that the leaf nodes within the red box have a 1 in the third position of their History field. Therefore, we only need to delete the data in these two nodes, leaving the data in the remaining nodes unchanged. Thus, we can analyze the age of the leaf node data based on the parent node and prioritize pruning older written data.

[0046] Specifically, assuming the sliding window has a bit width of W, this method supports both static and dynamic window mapping modes to adapt to different network load scenarios: In this embodiment, the static fixed mapping mode is: When network transaction volume is stable, each window position can hold a fixed number of S consecutive blocks' status update information. As new blocks are continuously generated, the window will continuously move forward with a sliding step of S blocks, and the oldest bit of data will be cleared or reused to reduce storage overhead. Therefore, to determine which position of the sliding window a certain block's data should be stored in, this invention uses the following calculation method: Let the current block height be The initial height of the window is ; The sliding window index corresponding to the current block state is:

[0047] Similarly, the starting index of the current sliding window is:

[0048] This positioning method maps the current block's state update to a single bit in the sliding window, avoiding full tree scanning or frequent tree reconstruction. Due to the use of a circular bitmap structure, the window can be used cyclically as the block height increases; old state bits that have exceeded the window's range will be cleared or merged into the global state tree. For example... Figure 4 As shown, the diagram illustrates the state of the block; In this embodiment, the dynamic adaptive mapping mode is as follows: When network load fluctuates drastically, the fixed constant S will transform into a dynamic span vector. ,in This represents the number of consecutive blocks dynamically accommodated by the i-th window position.

[0049] At this point, the current block height The corresponding index is no longer determined by simple division, but is calculated by summing intervals.

[0050] Let f be the starting index of the current window loop, and let f be the starting height. Then the block height range corresponding to the i-th window position is ,in:

[0051]

[0052] By judgment To accurately map the window index bit to which the current block belongs.

[0053] 3. TCP-inspired congestion control strategies Because the transaction volume and state update volume contained in different blocks in the actual network fluctuate significantly, using a fixed-size window will result in extremely low cache utilization under low load, while under high load, it will cause congestion and frequent pruning because the cache is filled up instantly.

[0054] In the above dynamic mapping mode, interval vector The allocation is dynamically adjusted by a congestion control algorithm similar to TCP. The specific adjustment mechanism includes the following three key stages: Slow start phase: In the initial phase, the block span allocated to each window bit grows exponentially (e.g., 1, 2, 4...) until the span reaches a system-predefined congestion threshold. This phase is designed to quickly probe the system's write load capacity.

[0055] Congestion avoidance phase: Once the block span exceeds a set threshold, its growth pattern switches to linear growth. This allows the system to gradually adapt to higher system throughput while maintaining control over memory growth. The span allocation logic is as follows: if the exponential span value is less than the preset threshold, it is allocated exponentially; if it exceeds the threshold, it is allocated linearly based on the threshold.

[0056] Fast Recovery Phase: When the number of active leaf nodes exceeds the set maximum capacity limit, congestion is detected, and the system immediately enters fast recovery mode. At this time, the system halves the current congestion threshold and recalculates and reassigns the block span vector of the remaining unused bits in the sliding window using the slow start rule. This update operation ensures that the window bits before the congestion point remain unchanged, the truncated window bits are adjusted to precisely cover the block height that triggered the congestion, and the remaining window bits are allocated using a restart strategy.

[0057] This embodiment is based on delayed write and a sliding window state tree: like Figure 2 As shown, the method flow of this embodiment clearly demonstrates the core idea of ​​the delayed state root mechanism, which decouples the three stages of transaction execution, state tree construction and state root disclosure, and processes them in parallel in a pipeline manner.

[0058] The method in this embodiment runs on a full-node server configured with a high-performance CPU (e.g., a core frequency of at least 2.5 GHz and at least 32 cores), large-capacity memory (e.g., at least 64 GB), and a high-speed solid-state drive (e.g., NVMe SSD with sequential read / write speeds of at least 3000 MB / s). This node runs the improved blockchain protocol software.

[0059] First, during the transaction execution phase, a node responds to the execution of a new block (let's say at height H). This block contains 2000 transactions. The node executes these transactions, resulting in changes to the state of accounts, contract storage, etc. These state changes are not immediately written to the underlying persistent global state tree (e.g., the MPT tree maintained in LevelDB or RocksDB databases), but are first applied to a sliding window state tree (100) maintained in memory. This sliding window state tree (100) is a specially designed lightweight Merkle tree, with all nodes residing in memory. After all transactions are executed, the node quickly calculates a 32-byte hash value based on the root node of the updated sliding window state tree (100), serving as the local state commitment corresponding to the current block H. This local state commitment is filled into the block header of block H and broadcast to the entire network. Thus, when other nodes verify block H, they only need to check whether this local state commitment is consistent with the temporary tree root after the transaction execution, without waiting for the time-consuming calculation of the global state root, greatly shortening the verification path.

[0060] Next, during the state tree construction phase, the nodes continuously monitor the memory usage of the sliding window state tree. In this embodiment, preset triggering conditions include the number of active leaf nodes reaching a preset percentage of the maximum capacity limit (e.g., 80%), or the window's bitmap having been completely cycled through once. The node structure of the sliding window state tree includes an 8-bit time indicator field (History) and a 32-bit capacity indicator field (Size). This embodiment uses an 8-bit bitmap as an example, but the bit width of the time indicator field can be flexibly set according to the system size and hardware configuration, for example, using 32 bits or 64 bits to support longer-term state tracking. The History field is a bitmap, where each bit represents a block range; 1 indicates that the range has been updated, and 0 indicates no update or that the data has been cleared. The parent node's History field is the bitwise OR result of the History fields of all its child nodes. The Size field represents the total number of leaf nodes contained in the subtree rooted at that node.

[0061] Assume the current window width W is 8, and the initial number of blocks S mapped to each window is 64. When block H is completed, the window has cumulatively covered 512 blocks from H-511 to H. At this point, the number of active leaf nodes is detected to be close to a preset threshold. The system then triggers asynchronous global state root calculation. The system scans the sliding window state tree, identifies the oldest data bits based on the History field (e.g., the range from H-511 to H-448), and writes these old, persistent state data in batches into the underlying persistent global state tree. This batch write process involves merging approximately 150,000 leaf nodes and takes about 2 seconds. Most importantly, this global state root calculation and persistence process is completely parallel to the transaction execution phase of the next block (H+1), achieving pipelined operation and eliminating congestion.

[0062] Finally, during the state root disclosure phase, after the global state root calculation is complete, the 32-byte root hash value is not immediately inserted into the currently generated block, but is stored in memory. When a node begins packaging subsequent blocks (e.g., block H+1 or, due to computation time, postponed to block H+x), it fills the block header of that subsequent block with this global state root up to block H for disclosure. Simultaneously, stale entries that have been successfully persisted to the global tree are safely pruned from the sliding window state tree, their corresponding History bits are cleared, and their Size values ​​are reduced accordingly, thus freeing up valuable memory space. This completes a full delayed state root cycle.

[0063] This embodiment, through the aforementioned pipelined asynchronous processing, removes the originally synchronous blocking state root calculation time from the critical path of block verification, significantly reducing random read and write requests to the underlying database and fundamentally alleviating the disk I / O bottleneck.

[0064] Example 2: Alternative Implementation Based on Static Fixed Window Mapping This embodiment is basically the same as Embodiment 1, except for the window mapping rules.

[0065] In this embodiment, the network load is relatively stable, and the system adopts a static fixed mapping mode. The bit width W of the sliding window is fixed at 16. The system presets the number of consecutive blocks S that each window bit can accommodate to be 128. This means that the sliding window state tree (100) always caches the state updates of the most recent 2048 (16×128) blocks.

[0066] like Figure 3 As shown, block height The mapping relationship with the window index bit is calculated using the following formula:

[0067] Where S = 128. For example, for a block with a height of 1,000,000, its corresponding window index is: (1000000 / 128) mod 16 = 7812 mod 16 = 4. For a block with a height of 1,000,128, its index becomes: (1000128 / 128) mod 16 = 7813 mod 16 = 5. As the block height increases, the window smoothly slides forward in steps of 128 blocks. When a new block arrives, its index may be the same as the previous block (if it falls within the same S-window), or it may carry over to the next index. After the window completes one cycle, the data at the oldest index (e.g., the bit mapped 16 blocks ago) is marked as stale and is batched and persisted to the underlying global state tree the next time global state commitment generation is triggered, subsequently being cleared from memory during the state root disclosure phase.

[0068] In tests conducted in a specific private blockchain environment (where transactions exhibit extremely high locality), this mapping pattern demonstrated an extremely high cache hit rate, significantly reducing disk read requests that penetrate to the underlying layer.

[0069] Example 3: Boundary Implementation Based on Dynamic Adaptive Window Mapping and Congestion Control The difference between this embodiment and embodiments 1 and 2 is that it adopts the defined dynamic adaptive window mapping and congestion control strategy to cope with extreme fluctuations in network load.

[0070] In this embodiment, the window's bit width W remains 16, but the previously fixed value S is replaced by a dynamic span vector. Replaced. The initial value of vector C is set to 1, meaning that each window bit initially maps only 1 block.

[0071] The system simulates the TCP congestion control algorithm, dynamically adjusting the values ​​of each element in vector C based on the number of active leaf nodes (i.e., buffer pressure) monitored in real time in the sliding window state tree (100). The specific adjustment mechanism is as follows: Slow start phase: When the system starts up or the load is low, the block span allocated to each new window bit grows exponentially. For example, the system allocates... =1 (maps 1 block), second window bit allocation 2 (mapping 2 blocks), third window bit allocation 4. This continues until the number of blocks mapped by a single window bit reaches a preset congestion threshold based on the physical capacity of the state tree, such as 64.

[0072] Congestion avoidance phase: when the span of a certain window bit Once it reaches 64, its subsequent growth becomes linear. For example, if network load continues to increase, the span of the next window will be set to 65, then 66, and so on. This allows the system to adapt to high throughput in a more robust manner, avoiding a sharp increase in memory usage.

[0073] Fast Recovery Phase: Suppose that during a sudden surge in transactions, multiple large blocks (e.g., a block containing 10,000 transactions) instantly fill the allocated window slots, causing a sharp increase in the number of active leaf nodes in the sliding window state tree (100), exceeding the preset maximum capacity limit for active leaf nodes (e.g., a maximum capacity limit of 1 million nodes, corresponding to approximately 300MB of memory usage), and the system determines that congestion has occurred. At this point, the system immediately triggers a fast recovery mechanism: halving the current congestion threshold (originally 64) to 32. Then, the system retains the window slots that were already filled before the congestion point, precisely truncating the block span of the currently being written window slot to the height of the block that triggered the congestion. For the remaining unallocated window slots, the span is reassigned according to the slow start rule, but the starting value starts from 1 and increases exponentially with the new threshold of 32 as the upper limit.

[0074] This embodiment successfully withstood a simulated "state bloat attack" test through this adaptive mechanism. In the test, an attacker attempted to create a massive number of new accounts within a short period (100 blocks), causing the state data volume to surge 50 times. Traditional solutions crashed due to memory exhaustion, while nodes using this embodiment's solution maintained a larger sliding window span. Upon detecting pressure, the system quickly switches from linear growth mode and dynamically shrinks the window through a fast recovery mechanism, distributing the pressure across more window positions. Memory usage is consistently kept below a preset safety threshold (e.g., 300MB), and no significant synchronization delay occurs. This demonstrates the invention's excellent adaptive load balancing capabilities and attack resistance.

[0075] Example 4: Comparative Example This embodiment is a comparative example designed to demonstrate the necessity of the core feature of the "sliding window state tree" in this invention. The method in this embodiment is basically the same as that in Embodiment 1, except that the sliding window state tree (100) in memory is omitted.

[0076] The node operation process is as follows: 1. In response to the execution of the current block, the resulting state update is directly written to the underlying persistent global state tree (MPT tree).

[0077] 2. Once all transactions have been executed, the state root is calculated synchronously directly from the global state tree on the disk.

[0078] 3. Fill the calculated state root into the current block header.

[0079] 4. As new blocks are generated, repeat the above synchronous read / write and calculation process.

[0080] The results show that, under the same hardware environment (CPU, memory, SSD) and the same transaction load (an average of 1500 transactions per block), the scheme in this comparative embodiment exhibits a severe performance bottleneck. Because each state change requires multiple random disk reads and writes (due to the MPT tree structure), the average block packaging time increases dramatically by several times (e.g., from tens of milliseconds in Embodiment 1 to hundreds of milliseconds or even seconds). Especially when processing transactions involving a large number of contract state updates, state tree operations account for over 80% of the total block execution time. Disk I / O remains saturated for extended periods, causing a sharp decline in node processing capacity, making it unable to keep up with the main chain's block production speed, ultimately leading to consensus failure.

[0081] This comparative example clearly demonstrates that the absence of the "sliding window state tree" memory caching layer will cause the state root calculation and block execution to be recoupled, which will not only prevent the realization of asynchronous pipelined processing, but also cause the system performance to crash due to huge disk I / O overhead. This, in turn, proves the necessity and advancement of the technical solution of the present invention.

[0082] By simulating 100 nodes replaying the same block history under different network latencies, the evolution sequence of the span vector calculated by all nodes is completely consistent with the global state root, verifying the cryptographic determinism of this mechanism in asynchronous networks.

[0083] The second aspect provides a technical solution: a system comprising a blockchain state management method based on delayed write and sliding window state tree as described in any of the above claims, including: The transaction execution module is configured to send the resulting state updates to the state cache module in response to the execution of the current block. The state caching module is configured to maintain a sliding window state tree residing in memory, apply the received state update to the sliding window state tree, and generate a local state commitment corresponding to the current block based on the updated sliding window state tree. The block generation module is configured to store the local state commitment in the block header of the current block; The global state management module is configured to, in response to meeting preset global state root generation conditions, obtain the accumulated state updates from the sliding window state tree from the state cache module, asynchronously calculate and generate a global state root, and send the global state root to the block generation module so that the block generation module can store the global state root in the block header of subsequent blocks. At the same time, it instructs the state cache module to prune and clear the old state updates that have participated in the global state root calculation from the sliding window state tree.

[0084] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention. The scope of the invention is defined by the appended claims and their equivalents, all of which should be included within the scope of protection of the invention.

Claims

1. A blockchain state management method based on delayed write and sliding window state tree, applied to blockchain nodes, characterized in that, Includes the following steps: In response to the execution of the current block, the resulting state update is applied to the sliding window state tree maintained in memory, and a local state commitment corresponding to the current block is generated based on the updated sliding window state tree. The local state commitment is stored in the block header of the current block for other nodes to verify state consistency. In response to the satisfaction of the preset global state root generation conditions, the global state root is asynchronously calculated and generated based on the accumulated state updates in the sliding window state tree, and the global state root is stored in the block header of the subsequent block.

2. The blockchain state management method based on delayed write and sliding window state tree according to claim 1, characterized in that, The nodes in the sliding window state tree include a time indicator field and a capacity indicator field. The time indicator field is used to record the block range corresponding to the state data represented by the node, and the capacity indicator field is used to record the number of leaf nodes under the node.

3. A blockchain state management method based on delayed write and sliding window state tree according to claim 1 or 2, characterized in that, Applying the state update to the sliding window state tree further includes: According to the preset window mapping rules, the window index bit corresponding to the current block's state update in the sliding window state tree is determined, so as to map the state update to the sliding window state tree.

4. The blockchain state management method based on delayed write and sliding window state tree according to claim 3, characterized in that, The window mapping rule is a static fixed mapping rule, and the static fixed mapping rule is as follows: Based on the preset number S of consecutive blocks that each window can accommodate, and using the current block height... and the starting height of the sliding window Determine the window index bit corresponding to the current block.

5. The blockchain state management method based on delayed write and sliding window state tree according to claim 3, characterized in that, The window mapping rule is a dynamic adaptive mapping rule, which includes: Through a variable span vector To dynamically allocate the number of consecutive blocks covered by each window bit, where For window width, This represents the number of consecutive blocks dynamically accommodated by the i-th window position.

6. The blockchain state management method based on delayed write and sliding window state tree according to claim 5, characterized in that, Determining the window index corresponding to the current block further includes: Based on the starting height of the current window and the span vector C, calculate the block height range corresponding to each window position; determine the corresponding window index position by judging which window position's block height range the current block height falls into.

7. The blockchain state management method based on delayed write and sliding window state tree according to claim 5, characterized in that, Also includes: The values ​​of each element in the span vector C are dynamically adjusted based on the current number of active leaf nodes in the sliding window state tree.

8. The blockchain state management method based on delayed write and sliding window state tree according to claim 7, characterized in that, The span vector C is dynamically adjusted, including during the slow start phase, causing the block span allocated to the window bit to grow exponentially until a preset congestion threshold based on the physical capacity of the state tree is reached.

9. The blockchain state management method based on delayed write and sliding window state tree according to claim 8, characterized in that, The dynamic adjustment of the span vector C also includes, during the congestion avoidance phase, changing the growth mode of the block span from exponential growth to linear growth after the block span exceeds the congestion threshold. This also includes, during the fast recovery phase, when the number of active leaf nodes is detected to exceed the preset memory capacity limit of the sliding window state tree, halving the current congestion threshold and deterministically recalculating the span vector allocation of the remaining window bits based on the height of the on-chain blocks and the bitmap information of the History field in the sliding window state tree.

10. A system comprising a blockchain state management method based on delayed write and sliding window state tree as described in any one of claims 1 to 9, characterized in that, include: The transaction execution module is configured to send the resulting state updates to the state cache module in response to the execution of the current block. The state caching module is configured to maintain a sliding window state tree residing in memory, apply the received state update to the sliding window state tree, and generate a local state commitment corresponding to the current block based on the updated sliding window state tree. The block generation module is configured to store the local state commitment in the block header of the current block; The global state management module is configured to, in response to the satisfaction of preset global state root generation conditions, obtain the accumulated state updates from the sliding window state tree from the state cache module, asynchronously calculate and generate a global state root, and send the global state root to the block generation module so that the block generation module can store the global state root in the block header of subsequent blocks.

Images