Unify and improve rate limiting for TRX and BLOCK INVENTORY Messages

[zeusoo001]

Summary

When processing INVENTORY messages, TRON nodes have already implemented a rate limiting mechanism for TRX-type inventories. However, the current logic only counts the number of inventory elements within a historical time window and does not take into account the number of hashes contained in the current message. In addition, BLOCK-type INVENTORY messages currently lack a similar rate limiting mechanism.

The proposed optimizations are:

• Enhance TRX INVENTORY rate limiting by including the number of items in the current message
• Introduce a unified and configurable rate limiting mechanism for BLOCK INVENTORY

These improvements aim to provide more accurate control over inventory intake rate, improve node resource management, and enhance P2P network stability.

Root Cause

In the InventoryHandler or related processing logic:

1. Incomplete Rate Limiting for TRX INVENTORY

The current TRX rate limiting logic is:

int count = peer.getPeerStatistics().messageStatistics.tronInTrxInventoryElement.getCount(10);
if (count > maxCountIn10s) {
  logger.warn("Drop inventory from Peer {}, cur:{}, max:{}",
          peer.getInetAddress(), count, maxCountIn10s);
  return;
}

This logic only relies on the historical count (count) and does not include the size of the current message (message.getHashList().size()).

2. Missing Rate Limiting for BLOCK INVENTORY

BLOCK-type INVENTORY messages have no rate limiting control:

for (Hash hash : message.getHashList()) {
  invToFetch.put(hash, peer);
}

As a result, BLOCK INVENTORY intake is unbounded and lacks unified configuration control.

Reproduction

Start a node and connect it to the P2P network.

TRX scenario:

• Construct TRX INVENTORY messages containing multiple transaction hashes
• Observe that rate limiting depends only on historical counts

BLOCK scenario:

• Construct BLOCK INVENTORY messages containing multiple block hashes
• Observe that the node continuously accepts and inserts them into invToFetch without rate limiting

Impact

• Inaccurate rate limiting: TRX logic does not account for the current message size
• Incomplete coverage: BLOCK INVENTORY lacks rate limiting entirely
• Resource management risk: Large messages with multiple hashes may increase queue pressure and memory usage
• Inconsistent P2P behavior: Different handling strategies for TRX and BLOCK inventories

Suggested Fix

Apply a unified rate limiting optimization for INVENTORY messages:

1. TRX INVENTORY Enhancement

Include the current message size in the rate limiting check:

if (inventoryType.equals(Protocol.Inventory.InventoryType.TRX)) {
  int count = peer.getPeerStatistics().messageStatistics
          .tronInTrxInventoryElement.getCount(10);
  if (count + message.getHashList().size() > maxCountIn10s) {
      logger.warn("Drop inventory from Peer {}, cur:{}, size:{}, max:{}",
              peer.getInetAddress(),
              count,
              message.getHashList().size(),
              maxCountIn10s);
      return;
  }
}

2. BLOCK INVENTORY Rate Limiting (New)

Introduce a configurable parameter:

public int maxBlockInvPerSecond = 10;

Calculate based on a 10-second sliding window:

private int maxBlockInvIn10s = maxBlockInvPerSecond * 10;

Add rate limiting logic:

if (inventoryType.equals(Protocol.Inventory.InventoryType.BLOCK)) {
  int count = peer.getPeerStatistics().messageStatistics
          .tronInBlockInventoryElement.getCount(10);
  if (count + message.getHashList().size() > maxBlockInvIn10s) {
      logger.warn("Drop block inventory from Peer {}, cur:{}, size:{}, max:{}",
              peer.getInetAddress(),
              count,
              message.getHashList().size(),
              maxBlockInvIn10s);
      return;
  }
}

Core Logic

count + message.getHashList().size() > maxLimit
Meaning:
Historical count + current message size > threshold → drop the message

Benefits

• More accurate rate limiting: Combines historical window and current message size
• Unified mechanism: Consistent handling for both TRX and BLOCK inventories
• Configurable control: BLOCK INVENTORY rate limit adjustable (default: 10/s)
• Smoother resource management: Prevents bursts caused by large messages
• Improved P2P stability: More predictable and controlled inventory intake behavior

[lxcmyf]

I checked the current implementation in P2pEventHandlerImpl and the report looks valid on the latest local codebase.

For INVENTORY messages, the TRX-side guard is currently using tronInTrxInventoryElement.getCount(10) before messageStatistics.addTcpInMessage(msg), so the decision is based only on the historical 10-second window and does not include message.getHashList().size() from the current batch. That means a large current TRX inventory can still pass the pre-check even when it should push the peer over the threshold.

For BLOCK inventories, I can confirm there is no equivalent pre-check in the same path today. The block inventory element counters already exist in MessageStatistics, so adding a symmetric limit there should be straightforward.

A reasonable implementation is:

• keep the pre-dispatch guard in P2pEventHandlerImpl
• change the TRX condition to count + currentSize > limit
• add a dedicated BLOCK limit using tronInBlockInventoryElement.getCount(10) + currentSize

One detail to keep in mind: because the rate-limit check happens before addTcpInMessage(msg), the comparison should intentionally include the current message size, otherwise the check will continue to undercount the batch that is currently being processed.

[zeusoo001]

@lxcmyf Thanks for the thorough analysis — the description matches what I see in the code as well.

A few additional observations worth noting:

On the timing of the check

The rate-limit guard runs before addTcpInMessage(msg) is called, which means tronInTrxInventoryElement.getCount(10) only reflects hashes accepted in previous messages, not the one currently being evaluated. So the effective window is always one batch behind. Including currentSize in the comparison (count + currentSize > limit) is the correct fix — it closes this gap by treating the current batch as already committed before making the drop decision.

On BLOCK INVENTORY threshold design

tronInBlockInventoryElement already exists in MessageStatistics alongside the TRX counterpart, so no new counter infrastructure is needed. The reason BLOCK INV warrants its own configurable threshold rather than reusing maxTps is that block announcement frequency operates on a different scale than transaction throughput. Under normal conditions a node receives only a handful of block hashes per slot, so a dedicated and lower limit is more appropriate than inheriting the transaction rate cap.

[abn2357]

Hello, I have a suggestion, could we change the transaction abbreviation 'TRX' in the code? It's easily mistaken for TRON's native token.

[zeusoo001]

@abn2357 Thanks for the suggestion. The abbreviation TRX here stands for Transaction, not TRON's native token. It has been used consistently throughout the codebase for a long time — for example, TrxMessage, TrxInventoryMessage, and related statistics counters all follow this convention. Renaming it would require touching a large number of files and classes, with a high risk of introducing unintended side effects. Given that this is an established internal naming convention rather than a user-facing identifier, we'd prefer to keep it as-is for now.