[Feature]Reduce memory usage in blocks sync via delayed serialization and cache limits

[xxo1shine]

Summary

During the block synchronization process, TRON nodes may experience cache bloat because blocks are serialized too early in the caching stage. By delaying serialization until the actual processing phase and limiting the size of the sync cache, memory usage and cache scale can be better controlled, thereby improving system stability.

Problem

Motivation

During block synchronization, nodes may need to temporarily cache a large number of block data. A more efficient memory management mechanism is required to prevent excessive resource consumption and potential impacts on node stability.

Current State

In the current implementation, blocks are serialized when they are added to the sync cache. When the number of cached blocks is large (e.g., close to 4000), the serialized data significantly increases memory usage.

Limitations or Risks

• Early serialization leads to cache size inflation
• High concurrency sync scenarios may cause significant memory pressure
• Inefficient resource utilization in the block synchronization pipeline

Proposed Solution

Proposed Design

Optimize the block synchronization process as follows:

• Delay block serialization to the actual processing stage
• Limit the number of blocks in the sync cache to prevent unbounded growth
• Avoid unnecessary serialization overhead and control cache size effectively

Key Changes

• Block sync module (adjust cache management logic)
• Block processing flow (change serialization timing)
• Sync cache mechanism (introduce or strengthen maximum cache size limits)

Impact

• Memory usage: Reduces memory inflation caused by early serialization
• System stability: Lowers memory pressure in extreme sync scenarios
• Performance: Reduces unnecessary serialization overhead during caching
• Scalability: Improves node adaptability in large-scale synchronization scenarios

Compatibility

• Breaking Change: No
• Default Behavior Change: Yes (serialization is delayed)
• Migration Required: No

This optimization does not affect external APIs or network protocols; it only impacts internal synchronization and caching logic.

Additional Notes

• Implementation ideas: Yes
• Willing to implement: Yes

[lxcmyf]

Interesting idea. I have 3 quick questions though:

• Do you have any heap/profile data showing where the memory spike mainly comes from during sync?
• For the cache limit, are you thinking count-based or byte-size-based? 4000 blocks can mean very different memory usage depending on block size.
• If the cache hits the limit, what should the node do next: pause fetching, drop some blocks, or apply backpressure in some other way?

The direction sounds reasonable to me, I am just trying to understand the exact control strategy here.

[lvs0075]

I'd recommend the PR include the rationale behind the chosen value — whether it's derived from measured memory pressure data, or a conservative fraction of the current empirical ceiling of ~4000 blocks. A value that's too low may cause frequent cache rejections on poor network conditions, hurting sync throughput; too high and the limit loses its effect. This should ideally be an operator-configurable parameter rather than a hardcoded constant.

[317787106]

The current issue description is too vague, and the necessity of this change is questionable.

For example:

• Where exactly does the premature block serialization occur that leads to memory inflation?
• When the number of cached blocks on the mainnet is N, what is the before-and-after comparison of memory usage?
• What proportion does this account for relative to normal memory allocation?

A high-level, generalized description does not contribute much to meaningful discussion.

[xxo1shine]

@lxcmyf, thanks for the questions.

Cache limit strategy: Prefer count-based limiting. It is simpler and more predictable. While block sizes do vary, a count-based limit covers most scenarios, and byte-size-based limiting would add implementation complexity.

Behavior when the limit is reached: Prefer pausing fetching — stop requesting new blocks from peers until the cache is consumed. This is safer than dropping blocks (avoids redundant re-fetching) and simpler to implement and test than a full backpressure mechanism.

[xxo1shine]

@lvs0075, agreed. The limit value needs careful consideration — ~4000 is the known empirical ceiling, but the actual safe threshold should be determined through memory pressure testing or calculated based on typical block sizes and available heap. Making it operator-configurable is also part of the plan, so node operators can tune it based on their own resource constraints without code changes.