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 the current TIP-7883 draft (TRON adoption of EIP-7883) by switching the ModExp precompile to the EIP-7883 pricing formula under allowTvmOsaka, and removes the now-redundant config-file plumbing for allowTvmOsaka so activation is proposal-only.

Baseline note: TRON legacy pricing is not EIP-2565

EIP-7883 is specified as a change from EIP-2565, but java-tron's pre-Osaka ModExp pricing still follows the existing EIP-198-style path: the piecewise multiplication complexity with GQUAD_DIVISOR = 20. This PR intentionally implements the TIP/EIP-7883 formula at activation time; it is not a monotonic multiplier over java-tron's current legacy pricing for every possible input.

Examples versus java-tron legacy pricing:

nagydani_1_square: 204 -> 500
nagydani_2_square: 665 -> 512 (lower than legacy because TIP-7883 follows the newer EIP-2565-family complexity shape)
nagydani_5_pow0x10001: 285900 -> 524288

The net energy change is therefore input-dependent. The intended compatibility target is the TIP-7883/EIP-7883 schedule, not preserving a strict increase over every legacy java-tron input.

Pricing formula changes under `allowTvmOsaka`

Minimum energy is raised to 500.
Multiplication complexity becomes 16 for maxLen <= 32, and 2 * ceil(maxLen / 8)^2 for maxLen > 32.
Iteration count keeps a floor of 1; for expLen > 32, the multiplier changes from the EIP-2565-family 8 to 16.
The old pre-Osaka path remains unchanged when allowTvmOsaka == 0.

`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 the governance activation path: Osaka activates strictly through the on-chain proposal.

Gate granularity

allowTvmOsaka intentionally gates Osaka-aligned TVM changes as a coherent upgrade flag rather than one flag per TIP. That keeps TRON's activation model aligned with upstream fork semantics and avoids a partial-Osaka state for cross-chain tooling and gas estimators. If a testnet-only issue is found before activation, the proposal can simply remain off. If a post-activation issue requires separating one behavior, the cleaner follow-up is a subsequent fork-level override flag rather than splitting this activation gate now.

Tests

testEIP7883ModExpPricing covers the new floor, the doubled-formula branch at the 33-byte boundary, and standard nagydani vectors.
testEIP7883DisabledPreservesOldPricing pins the legacy EIP-198-style pricing when allowTvmOsaka == 0.
testEIP7883CanBeLowerThanLegacyPricing documents the non-monotonic comparison against java-tron's current legacy formula.

Spec

TIP-7883 draft: TIP-7883: ModExp Gas Cost Increase tips#837
EIP-7883: https://eips.ethereum.org/EIPS/eip-7883
Legacy baseline reference: EIP-198 / EIP-2565 pricing tables: https://eips.ethereum.org/EIPS/eip-198 and https://eips.ethereum.org/EIPS/eip-2565

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.

Make overflow safety explicit instead of relying on int range, and keep all arithmetic in the new energy helpers consistent with the existing StrictMathWrapper-based ops.

…-test-fixes # Conflicts: # framework/src/test/java/org/tron/common/runtime/vm/AllowTvmOsakaTest.java

CodeNinjaEvan

LGTM

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

yanghang8612 added 2 commits May 7, 2026 10:39

refactor(vm): wrap TIP-7883 energy arithmetic with StrictMathWrapper

cf144f3

Make overflow safety explicit instead of relying on int range, and keep all arithmetic in the new energy helpers consistent with the existing StrictMathWrapper-based ops.

refactor(vm): extract TIP-7883 ModExp minimum energy constants

881ef98

yanghang8612 requested a review from aiden3885 May 8, 2026 07:54

aiden3885 approved these changes May 8, 2026

View reviewed changes

test(vm): document TIP-7883 legacy pricing delta

7d9201f

yanghang8612 force-pushed the implement-tip-7883 branch from 2bd536e to 7d9201f Compare May 8, 2026 09:42

Merge remote-tracking branch 'origin/develop' into review/pr-6654-doc…

7c7ff21

…-test-fixes # Conflicts: # framework/src/test/java/org/tron/common/runtime/vm/AllowTvmOsakaTest.java

CodeNinjaEvan approved these changes May 8, 2026

View reviewed changes

CodeNinjaEvan merged commit 02158fc into tronprotocol:develop May 8, 2026
12 checks passed

github-project-automation Bot moved this to Done in java-tron May 8, 2026

This was referenced May 13, 2026

Add TIP-854, TIP-2935, TIP-7823, TIP-7883, TIP-7939, TIP-7951 (Last Call) tronprotocol/tips#870

Merged

TIP-7883: ModExp Gas Cost Increase tronprotocol/tips#837

Open

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
CodeNinjaEvan merged 6 commits into
tronprotocol: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!

CodeNinjaEvan left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Conversation

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

Uh oh!

Summary

Baseline note: TRON legacy pricing is not EIP-2565

Pricing formula changes under allowTvmOsaka

allowTvmOsaka config-knob removal

Gate granularity

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!

CodeNinjaEvan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

yanghang8612 commented Apr 8, 2026 •

edited

Loading

Pricing formula changes under `allowTvmOsaka`

`allowTvmOsaka` config-knob removal