feat(vm): implement TIP-7883 ModExp gas cost increase

[yanghang8612]

Summary

Implement TIP-7883 ModExp precompile repricing, gated behind the existing allowTvmOsaka flag.

Changes from the current pricing formula:

• Minimum energy: raised to 500
• Divisor removed: no longer divides by GQUAD_DIVISOR, tripling general cost
• Exponent >32 bytes multiplier: doubled from 8 to 16
• Multiplication complexity: floor of 16 for ≤32 bytes, 2 * ceil(maxLen/8)² for >32 bytes

Related: tronprotocol/tips#837

[CodeNinjaEvan]

Good defensive coding — using BigInteger for the intermediate multiplication avoids any potential overflow with large baseLen/modLen values (up to 1024 bytes), and the Long.MAX_VALUE cap ensures the result is always safe to return as a long. Well handled.

[CodeNinjaEvan]

The inline comment // ceil(maxLength / 8) is a nice touch — it makes the intent of (maxLength + 7) / 8 immediately clear without needing to mentally decode the arithmetic. The structure also maps 1:1 to the spec's pseudocode, which makes auditing straightforward.

[CodeNinjaEvan]

LGTM

[bladehan1]

[P1] Suggestion: use overflow-safe arithmetic for long-term review burden reduction

2 * words * words uses plain long multiplication. Proving it won't overflow requires tracing the full input chain: parseLen() → intValueSafe() returns int → max words = 268,435,456 → 2 * words² = 1.44×10¹⁷ < Long.MAX_VALUE. This reasoning is correct today, but not self-evident — if parseLen() return type or UPPER_BOUND ever changes, the safety assumption silently breaks.

Using overflow-safe arithmetic makes the code self-evidently safe with zero external reasoning required, reducing the review burden for future readers:

return Math.multiplyExact(2, Math.multiplyExact(words, words));

This is a long-term maintainability suggestion, not a current correctness issue.

[yanghang8612]

Thanks for flagging this. Applied in e512e21 — used StrictMathWrapper.multiplyExact instead of Math.multiplyExact to stay consistent with the cross-platform-determinism convention this repo follows (the Maths javadoc explicitly redirects new code to StrictMathWrapper). Same fail-fast guarantee, and reviewers no longer need to trace parseLen() → int → UPPER_BOUND to convince themselves the multiplication is safe.

[halibobo1205]

[SHOULD]getMultComplexityTIP7883 and getIterationCountTIP7883 are new methods with no legacy constraints. They should use StrictMathWrapper directly instead of the deprecated Maths.max(a, b, boolean) pattern.

Suggested changes:

// getMultComplexityTIP7883
- long maxLength = max(baseLen, modLen, VMConfig.disableJavaLangMath());
+ long maxLength = StrictMathWrapper.max(baseLen, modLen);

// avoid silent overflow on 2 * words * words
 - return 2 * words * words;
 + return StrictMathWrapper.multiplyExact(2L, StrictMathWrapper.multiplyExact(words, words));
 
 // getIterationCountTIP7883
 - return max(iterCount, 1, VMConfig.disableJavaLangMath());
 + return StrictMathWrapper.max(iterCount, 1L);

Reasons:

1. Maths is @Deprecated — new code should not add more callers.
2. 2 * words * words relies on manual reasoning about value ranges for overflow safety. Using multiplyExact makes this explicit and fail-fast.

[yanghang8612]

Thanks, all three suggestions applied in e512e21 — getMultComplexityTIP7883 / getIterationCountTIP7883 now call StrictMathWrapper.max directly, and the 2 * words * words product is wrapped in StrictMathWrapper.multiplyExact so the overflow argument no longer depends on parseLen() returning int. Agreed that new code shouldn't keep adding callers to the deprecated Maths helper.