feat(vm): implement TIP-7883 ModExp gas cost increase by yanghang8612 · Pull Request #6654 · tronprotocol/java-tron

yanghang8612 · 2026-04-08T07:28:19Z

Summary

Implements TIP-7883 (TRON adoption of EIP-7883) — repricing the ModExp precompile — and removes the now-redundant config-file plumbing for allowTvmOsaka, gating purely through the on-chain proposal.

Pricing formula changes (under `allowTvmOsaka`)

Minimum energy: raised from 200 to 500.
Multiplication complexity: switches from EIP-2565's piecewise formula (x²/4 + 96x − 3072) to a flat 16 for maxLen ≤ 32 and 2 · ceil(maxLen/8)² for maxLen > 32.
Iteration count: long-exponent (expLen > 32) multiplier doubled from 8 to 16; floor enforced at 1.

The net energy change is input-dependent, not a uniform factor. Test vectors confirm: nagydani_1_square goes 204 → 500 (~2.45× via the new floor); nagydani_5_pow0x10001 actually decreases versus the legacy formula. Pre-fork inputs continue to use the EIP-2565 path unchanged — verified by testEIP7883DisabledPreservesOldPricing.

`allowTvmOsaka` config-knob removal

The Osaka gate was previously settable from a config file as well as the proposal. This PR makes it proposal-only, mirroring the ALLOW_TVM_SELFDESTRUCT_RESTRICTION shape:

CommonParameter.allowTvmOsaka field deleted
CommitteeConfig.allowTvmOsaka field deleted
Args.applyCommitteeConfig assignment deleted
framework/src/main/resources/config.conf sample line deleted
common/src/main/resources/reference.conf default deleted
DynamicPropertiesStore.getAllowTvmOsaka no longer falls back to CommonParameter; reads the DB and .orElse(0L)

Operators do not lose any capability — Osaka activates strictly via the on-chain proposal.

Tests

testEIP7883ModExpPricing — covers the new floor, the doubled-formula branch at the 33-byte boundary, and standard nagydani vectors (1 / 2 / 3 / 4 / 5).
testEIP7883DisabledPreservesOldPricing — pins legacy pricing when allowTvmOsaka == 0.

Spec

TIP-7883: TIP-7883: ModExp Gas Cost Increase tips#837
EIP-7883: https://eips.ethereum.org/EIPS/eip-7883

CodeNinjaEvan · 2026-04-09T08:36:02Z

+      BigInteger energy = BigInteger.valueOf(multComplexity)
+          .multiply(BigInteger.valueOf(iterCount));
+
+      BigInteger minEnergy = BigInteger.valueOf(500);
+      if (isLessThan(energy, minEnergy)) {
+        return 500L;
+      }
+
+      return isLessThan(energy, BigInteger.valueOf(Long.MAX_VALUE)) ? energy.longValueExact()
+          : Long.MAX_VALUE;


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 · 2026-04-09T08:38:11Z

+     */
+    private long getMultComplexityTIP7883(int baseLen, int modLen) {
+      long maxLength = max(baseLen, modLen, VMConfig.disableJavaLangMath());
+      long words = (maxLength + 7) / 8; // ceil(maxLength / 8)


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 · 2026-04-15T02:25:39Z

+      if (maxLength <= 32) {
+        return 16;
+      }
+      return 2 * words * words;


[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.

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 · 2026-04-15T03:18:18Z

+     * Minimal complexity of 16; doubled complexity for base/modulus > 32 bytes.
+     */
+    private long getMultComplexityTIP7883(int baseLen, int modLen) {
+      long maxLength = max(baseLen, modLen, VMConfig.disableJavaLangMath());


[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:

Maths is @Deprecated — new code should not add more callers.

2 * words * words relies on manual reasoning about value ranges for overflow safety. Using multiplyExact makes this explicit and fail-fast.

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.

Raise the floor to 500, switch the >32-byte branch to 2*words², and bump the long-exponent multiplier to 16. Drop the OSAKA gate's config-file plumbing — the on-chain proposal is the only switch.

Verify the new floor, the doubled-formula branch at the 33-byte boundary, and that pre-OSAKA pricing is preserved when the gate is off.

yanghang8612 requested review from bladehan1 and xxo1shine as code owners April 8, 2026 07:28

yanghang8612 force-pushed the implement-tip-7883 branch from be82ead to f13e430 Compare April 8, 2026 07:33

halibobo1205 added this to the GreatVoyage-v4.8.2 milestone Apr 8, 2026

yanghang8612 mentioned this pull request Apr 8, 2026

Core Devs Community Call 59 tronprotocol/pm#196

Closed

CodeNinjaEvan reviewed Apr 9, 2026

View reviewed changes

halibobo1205 added the topic:vm VM, smart contract label Apr 9, 2026

CodeNinjaEvan approved these changes Apr 9, 2026

View reviewed changes

bladehan1 reviewed Apr 15, 2026

View reviewed changes

halibobo1205 reviewed Apr 15, 2026

View reviewed changes

halibobo1205 assigned halibobo1205, CodeNinjaEvan and xxo1shine and unassigned halibobo1205, CodeNinjaEvan and xxo1shine Apr 21, 2026

yanghang8612 force-pushed the implement-tip-7883 branch from e512e21 to 287c0b7 Compare April 29, 2026 01:11

Sunny6889 added this to java-tron May 5, 2026

yanghang8612 added 2 commits May 6, 2026 10:27

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

6b653f8

Raise the floor to 500, switch the >32-byte branch to 2*words², and bump the long-exponent multiplier to 16. Drop the OSAKA gate's config-file plumbing — the on-chain proposal is the only switch.

test(vm): cover TIP-7883 ModExp pricing across nagydani vectors

d4bdf30

Verify the new floor, the doubled-formula branch at the 33-byte boundary, and that pre-OSAKA pricing is preserved when the gate is off.

yanghang8612 force-pushed the implement-tip-7883 branch from 287c0b7 to d4bdf30 Compare May 6, 2026 02:27

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

feat(vm): implement TIP-7883 ModExp gas cost increase#6654
yanghang8612 wants to merge 2 commits intotronprotocol:developfrom
yanghang8612:implement-tip-7883

yanghang8612 commented Apr 8, 2026 •

edited

Loading

Uh oh!

CodeNinjaEvan Apr 9, 2026

Uh oh!

CodeNinjaEvan Apr 9, 2026

Uh oh!

CodeNinjaEvan left a comment

Uh oh!

bladehan1 Apr 15, 2026

Uh oh!

yanghang8612 Apr 27, 2026

Uh oh!

halibobo1205 Apr 15, 2026

Uh oh!

yanghang8612 Apr 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Conversation

yanghang8612 commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Pricing formula changes (under allowTvmOsaka)

allowTvmOsaka config-knob removal

Tests

Spec

Uh oh!

CodeNinjaEvan Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

CodeNinjaEvan Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

CodeNinjaEvan left a comment

Choose a reason for hiding this comment

Uh oh!

bladehan1 Apr 15, 2026

Choose a reason for hiding this comment

Uh oh!

yanghang8612 Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

halibobo1205 Apr 15, 2026

Choose a reason for hiding this comment

Uh oh!

yanghang8612 Apr 27, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

yanghang8612 commented Apr 8, 2026 •

edited

Loading

Pricing formula changes (under `allowTvmOsaka`)

`allowTvmOsaka` config-knob removal