[Feature] Discuss DoS Protection Strategy for Constant Call APIs

[warku123]

Summary

Nodes with vm.supportConstant = true expose triggerConstantContract and estimateEnergy APIs that are free for callers but consume node CPU. We ran pressure tests on a private network and found that a single machine with zero TRX can degrade a 16-vCPU node to 1.5% success rate within seconds using concurrent requests.

This issue presents test data and aims to discuss: should java-tron provide built-in concurrency protection for these APIs, and if so, should it be enabled by default or configured by operators?

Problem

Motivation

triggerConstantContract is widely used for reading smart contract state without broadcasting transactions. Because it is free, attackers can send high volumes of complex calls to exhaust node CPU. We investigated whether the existing configuration parameters effectively mitigate this.

Current State

Background: Real-world Energy Consumption

We measured the Top 100 most-called contracts on TRON mainnet (456 view/pure functions):

Statistic	Energy
Min	261
Average	648
P50	471
P90	1,024
P95	1,458
Max	4,818

The current default maxEnergyLimitForConstant = 100M provides a ~20,000x safety margin over the observed maximum. However, as shown in Test 3 below, this parameter is not the real execution boundary — CPU time is.

---

We ran a controlled DoS test suite on an AWS EC2 c6a.4xlarge instance running java-tron 4.8.1.

Test environment

Item	Value
Instance	AWS EC2 c6a.4xlarge (16 vCPU, 32GB RAM)
java-tron version	4.8.1
Test contract	EnergyLevelFlexible.consumeWithCount(uint256) (see Appendix)
Test duration	10 seconds per concurrency level

Test 1: Baseline Concurrent Attack

Default configuration with supportConstant=true and no concurrent-request limiting. The test contract executes a configurable number of hash operations:

• Light payload (count=1000): ~0.7M Energy, ~25ms per call
• Heavy payload (count=1500): ~1.0M Energy, ~36ms per call — closer to the CPU time limit

Light payload (count=1000)

Concurrency	Success Rate	Throughput (req/s)	Avg Latency (ms)	P99 Latency (ms)
1	100.0%	40.7	25	34
10	100.0%	303.4	33	45
20	99.7%	300.3	66	85
30	100.0%	300.4	100	118

Heavy payload (count=1500)

Concurrency	Success Rate	Throughput (req/s)	Avg Latency (ms)	P99 Latency (ms)
1	99.9%	28.0	36	43
10	56.9%	123.6	46	52
20	49.9%	106.3	94	112
30	49.5%	105.4	140	155

With a heavy payload, success rate drops to ~50% at concurrency 10+. An attacker only needs to increase the count parameter to maximize per-request CPU cost.

---

Test 2: GlobalPreemptibleAdapter Protection

GlobalPreemptibleAdapter uses a semaphore (tryAcquire(2, TimeUnit.SECONDS)) to limit concurrent execution. Excess requests queue for up to 2 seconds rather than being rejected immediately.

Config	Concurrency	Success Rate	Throughput (req/s)	Avg Latency (ms)	P99 Latency (ms)
Baseline (no protection)	300	1.5%	10.4	348	4212
GlobalPreemptibleAdapter permit=10	300	100.0%	285.1	546	3933

Without protection, 300 concurrent connections collapse the node to 1.5% success. With permit=10, the node stays stable at ~285 req/s with 100% success. The 0 rejections are because each call completes in ~35ms, releasing permit slots fast enough for queued requests to acquire within the 2-second window.

---

Test 3: maxEnergyLimitForConstant Is Not the Real Limit

We swept the count parameter under different maxEnergyLimitForConstant configurations:

Energy Limit	Count	Success Rate	Avg Energy	Avg Latency (ms)	Error
100M	100	100%	67636	37	-
100M	500	100%	340287	30	-
100M	1000	100%	689012	47	-
100M	1500	100%	1046525	43	-
10M	100	100%	67636	34	-
10M	500	100%	340287	26	-
10M	1000	100%	689012	48	-
10M	1500	100%	1046525	46	-
5M	100	100%	67636	15	-
5M	500	100%	340287	39	-
5M	1000	100%	689012	27	-
5M	1500	100%	1046525	37	-
3M	100	100%	67636	34	-
3M	500	100%	340287	29	-
3M	1000	100%	689012	54	-
3M	1500	100%	1046525	41	-

Regardless of maxEnergyLimitForConstant (100M, 10M, 5M, or 3M), the Energy limit is never the binding constraint. CPU timeout (OutOfTimeException) is always what stops execution first. Lowering the Energy limit is a semantic cleanup, not a security fix.

---

Test 4: QPS Blocking Mode Does Not Help

The default QpsRateLimiterAdapter uses Guava RateLimiter.acquire() which blocks but never rejects:

Config	Concurrency	Success Rate	Throughput (req/s)	Rejected
Default (global.qps=50000, blocking)	300	1.5%	10.4	0
Low QPS (global.qps=100, blocking)	30	10.7%	58.8	0
GlobalPreemptibleAdapter permit=10	300	100.0%	285.1	0

Even with global.qps=100, the blocking limiter still only achieves 10.7% success. The fundamental issue: RateLimiter.acquire() queues all requests and exhausts the thread pool, regardless of the QPS setting. Only GlobalPreemptibleAdapter effectively limits concurrent execution.

---

Test 5: estimateEnergy CPU Amplification

Comparing triggerConstantContract vs estimateEnergy with identical contract calls (count=1000, 10 concurrent):

Endpoint	Success Rate	Throughput (req/s)	Avg Latency (ms)
triggerConstantContract	99.0%	292.4	34
estimateEnergy	100.0%	33.3	299

estimateEnergy is ~9x slower due to binary search retries (estimateEnergyMaxRetry=3), each executing the full EVM contract. Any concurrency protection should cover both endpoints.

---

Test 6: maxConnectionAge and maxConcurrentCallsPerConnection (Code Analysis)

These gRPC-only parameters were investigated via code analysis (empirical testing planned as follow-up):

Parameter	Default	Risk
maxConcurrentCallsPerConnection	Integer.MAX_VALUE	Unlimited concurrent calls per connection via HTTP/2 multiplexing
maxConnectionAgeInMillis	Long.MAX_VALUE	Connections never expire

A single gRPC connection can bypass maxConnectionsWithSameIp=2 and exhaust all rpcThread workers.

Limitations or Risks

If left unaddressed, publicly accessible API nodes remain vulnerable to trivial DoS attacks that require no TRX and no on-chain transactions.

Proposed Solution

Reference: Comparison with Ethereum Geth

Ethereum's Geth faces the same problem with eth_call and eth_estimateGas. Geth provides per-call protections (RPCGasCap = 50M, RPCEVMTimeout = 5s, BatchRequestLimit = 1000) but no native concurrent execution limit. This is likely because Go's goroutine model (~few KB each) is more resilient to concurrent load than Java's thread pool model (~1MB per thread). In practice, Geth operators rely on external infrastructure (Nginx, cloud load balancers) for concurrency control.

java-tron already has a built-in mechanism — GlobalPreemptibleAdapter — that can provide this protection natively.

Proposed Design

Based on our test results, GlobalPreemptibleAdapter is the most effective built-in defense. We'd like community input on the deployment strategy.

Key Changes

#	Item	Current	Suggestion
1	GlobalPreemptibleAdapter for TriggerConstantContract	Not configured	Enable with configurable permit value
2	GlobalPreemptibleAdapter for EstimateEnergyServlet	Not configured	Enable with a lower permit (higher CPU cost per request)
3	maxEnergyLimitForConstant	100M	Consider lowering for semantic alignment (not a security fix)

Impact

• Security: Limits the CPU that free constant calls can consume concurrently.
• Stability: Prevents node collapse under concurrent load.
• Performance: Normal queries are unaffected — permit=10 still delivers ~285 req/s.

Compatibility

• Breaking Change: No.
• Default Behavior Change: Depends on discussion outcome.
• Migration Required: No.

References (Optional)

• Related source code:
  • GlobalPreemptibleStrategy.java
  • RateLimiterServlet.java
• Related issue: [Feature] Add a node-level configuration to control the TVM execution time limit for constant calls #6681 (proposal to extend constant call timeout — makes concurrency control even more important)

Additional Notes

We'd like to discuss the following questions with the community:

1. Default-on vs operator-configured? Should GlobalPreemptibleAdapter be enabled by default, or should operators enable it when needed? Enabling by default protects out-of-the-box but may affect high-concurrency use cases; leaving it off means most operators remain unprotected unless they discover the option.

2. Node-level vs external protection? Some operators may prefer to handle rate limiting externally (Nginx, cloud LB). Should java-tron focus on providing the capability and documenting it, rather than enabling it by default?

3. What is a reasonable permit value? Our test used permit=10 on 16 vCPU, achieving ~285 req/s with 100% success. Should the default be tied to CPU cores (e.g., cores / 2), or a fixed conservative value?

4. Should maxEnergyLimitForConstant be lowered? The Top 100 contracts peak at only 4,818 Energy vs the 100M default (~20,000x gap). Lowering doesn't improve DoS resilience but better reflects real-world usage.

• Do you have ideas regarding implementation? Yes
• Are you willing to implement this feature? Yes

Appendix: Test Contract

The consumeWithCount(uint) function performs count iterations of keccak256 hashing and arithmetic, allowing precise control over Energy consumption and CPU time per call.

// Solidity 0.4.23 (compatible with TRON TVM)
contract EnergyLevelFlexible {
    function consumeWithCount(uint count) public pure returns (uint) {
        uint result = 1;
        for (uint i = 0; i < count && i < 500000; i++) {
            result = uint(keccak256(abi.encodePacked(result, i)));
            result = result * 3 + i;
            if (result > 1000000000000) {
                result = result / 2;
            }
        }
        return result;
    }
}

[lxcmyf]

Two questions seem most important here:

• Is the intended protection scope only the HTTP servlets (TriggerConstantContractServlet / EstimateEnergyServlet), or also every equivalent entry like JSON-RPC eth_call / eth_estimateGas and gRPC paths? Otherwise the limit may be easy to bypass by switching protocol.
• Is tryAcquire(..., 2s) really the right overload behavior for this case? It stabilizes success rate, but it still turns overload into queueing and very high tail latency. Would a fail-fast path be safer for public nodes once the concurrent budget is exhausted?

[yanghang8612]

Thanks @warku123 for putting together the data. I'd like to push back on the framing, because after reading through the tests carefully I don't think they support the conclusion the title asserts.

1. What the tests actually measure — and what they don't.

Every metric in the six tests is scoped to the constant-call endpoint: success rate, throughput, latency of triggerConstantContract / estimateEnergy. Nothing in the measurement set touches what a node is fundamentally supposed to do:

• block production / validation latency during the attack
• peer sync status
• mempool and broadcast-TX handling
• JVM heap / GC / total CPU utilization
• responsiveness of unrelated RPC paths (wallet, gRPC, non-constant eth_*)

The headline "1.5% success rate at 300 concurrency" answers exactly one question: can one free, high-compute API satisfy arbitrary concurrent demand on 16 vCPU? The answer is trivially no, for any HTTP service on any stack. That is a capacity fact, not a security finding. "Node collapse" is used as framing but never demonstrated — throughout all the tests, the node stays up, keeps responding, and the only observable degradation is that the specific endpoint under attack stops serving requests. That is the behavior of a cap doing its job, not the behavior of a node under successful DoS.

For this issue to support its thesis, the missing measurements are the ones that matter: does the attack measurably slow block processing? Cause sync to lag? Starve other RPC handlers? Consume memory without releasing? Without any of that, the claim "these APIs need built-in concurrency protection to defend node integrity" is unsupported by the presented evidence.

2. Look at what the failures actually are.

In Test 1 heavy payload, concurrency 10 → success rate 56.9%. The single-call execution time is reported as ~36 ms, well under the 80 ms cap. So the failing requests are not hitting some external limit added by the proposed protection — they are being killed by the existing TVM CPU cap because normal scheduling jitter (thread contention, GC, servlet overhead) pushes 36 ms of execution past an 80 ms wall-clock budget.

Said differently: at only 10 concurrent requests — a level any real dapp backend, analytics service, or indexer routinely exceeds — roughly half of legitimate, non-malicious calls are being rejected as OUT_OF_TIME. The "protection" the issue argues for adding sits on top of a limit that is already causing wholesale false positives for ordinary workloads. Stacking another concurrency gate on top of a threshold that legitimate traffic can't reliably clear is not hardening the node — it's compounding an existing source of user-visible failure.

3. No DoS analysis beyond the word "DoS".

A real DoS discussion would require the pieces that aren't in this issue:

• a threat model (what is the attacker trying to achieve — node death, peer isolation, denying other users, free compute extraction?)
• an economic/cost analysis (what does the attack cost vs. what does the operator lose?)
• blast-radius assessment (what else on the node degrades — or, crucially, does not degrade — while the attack runs?)
• an evaluation of operational defenses already standard in this space (rate limiting at the edge, per-IP caps, WAF, reverse-proxy throttling, separating public vs internal RPC endpoints)
• a comparison against how comparable systems handle this

On the last point: the issue itself cites Geth as a reference and notes Geth has no built-in concurrent-execution limit — operators rely on external infrastructure. That is evidence against the need for a node-level mechanism, not for it. The Go-goroutine-vs-Java-thread distinction doesn't override the operational conclusion: a public RPC endpoint's DoS posture is an operator concern, handled at the operator's boundary, not a semantic property the node runtime is expected to enforce.

4. On the methodology, even for the capacity-saturation question it does measure.

• Single machine class (c6a.4xlarge, 16 vCPU). No 4 / 16 / 64 vCPU scaling curve, so permit=10 has no general justification — it's a guess tuned to one host.
• Single contract, two payload sizes. Real attack shapes (SLOAD-heavy, precompile-heavy, cross-contract) don't resemble a hash loop and will have different CPU/IO profiles.
• 10-second windows. Too short to observe sustained behavior — queue growth under tryAcquire(2s), GC pauses, socket exhaustion. The 100% success rate under protection only holds because the queue hasn't had time to saturate.
• No sweep on permit. The chosen value is asserted, not derived from a curve.
• No comparison to simpler, already-available controls: tightening maxConnectionsWithSameIp, bounding gRPC maxConcurrentCallsPerConnection (Test 6 correctly identifies this as Integer.MAX_VALUE — that is arguably the real problem hiding here, and fixable without a new mechanism).
• As @lxcmyf already noted, any servlet-level limit is bypassed by switching to JSON-RPC eth_call or gRPC, so the placement is incomplete even for its own stated goal.

5. On default-on — for a configuration option, defaulting on is by construction redundant.

The whole value of making this configurable is giving operators the choice. Public nodes already sit behind Nginx / cloud LB / WAF with their own rate limiting and concurrency policies; internal nodes either don't need this or need very different settings. There is no defensible default that fits a 4-vCPU VM and a 64-vCPU bare-metal host simultaneously, which is why the proposal itself can't commit to one. "Default off, clearly documented, configurable on" is the correct shape. Defaulting on just trades one problem (operators unaware of the knob) for another (operators surprised by throttling they didn't opt into).

---

That said, three observations in this issue are genuinely useful and should be pursued on their own, decoupled from the concurrency-protection framing:

• Test 4: QpsRateLimiterAdapter using blocking RateLimiter.acquire() queues indefinitely and never rejects. That is a latent bug worth fixing on its own merits.
• Test 6: gRPC maxConcurrentCallsPerConnection = Integer.MAX_VALUE and maxConnectionAgeInMillis = Long.MAX_VALUE allow a single connection to bypass maxConnectionsWithSameIp. This is a concrete configuration issue and arguably the highest-impact item in the whole writeup.
• Test 3: maxEnergyLimitForConstant is confirmed not to be the CPU-binding constraint. Useful to document; as you note, adjusting it is semantic cleanup, not security.

Recommend splitting those three into focused issues so they can move independently. For the main thesis, I think the discussion needs a fundamentally different test set — one that measures node-level primary-duty impact rather than endpoint-level success rate — before it can support any concrete design choice.

[warku123]

Thanks @lxcmyf and @yanghang8612 for the thorough review.

@lxcmyf Good points — the protocol bypass gap (JSON-RPC / gRPC) and the tryAcquire(2s) vs fail-fast question are valid concerns that further weaken the servlet-only approach.

@yanghang8612 I ran a reproduction test today and also went back to review the logs from the original test session. The findings confirm your criticism: the tests demonstrate endpoint-level capacity saturation for triggerConstantContract, not a node-wide DoS or "node collapse." The missing node-level measurements (block production, sync health, JVM/GC, unrelated RPC paths) are exactly the gap you identified. The data is valid as an endpoint-capacity measurement, but I overstated the implication by framing it as a node-integrity issue without the supporting evidence.

I'll step back from the main thesis and instead split the three concrete, decoupled observations into focused issues so they can move independently:

1. QpsRateLimiterAdapter behavioral issue — it uses RateLimiter.acquire(), which queues indefinitely and never rejects requests. Under concurrent load this can exhaust the servlet thread pool — a design limitation worth addressing independently.
2. gRPC maxConcurrentCallsPerConnection = Integer.MAX_VALUE — a single HTTP/2 connection can bypass maxConnectionsWithSameIp=2 and exhaust all rpcThread workers. This is a concrete configuration issue.
3. maxEnergyLimitForConstant semantic cleanup — confirmed not to be the CPU-binding constraint; useful to document or realign the default with actual usage patterns.

For the broader question of built-in concurrency protection for constant calls, I'll wait until there is proper node-level impact data before reopening that discussion.

Appreciate the rigorous feedback.