Repository navigation
TIP-7883: ModExp Gas Cost Increase #837
Description
tip: 7883
title: ModExp Gas Cost Increase
description: Increases cost of ModExp precompile
author: ouy95917@gmail.com
status: Final
type: Standards Track
category: VM
created: 2026-03-19
Summary
EIP-7883 modifies the ModExp precompile pricing algorithm introduced in EIP-2565, addressing scenarios where the current gas cost significantly underestimates actual resource consumption. The key changes include raising the minimum gas cost from 200 to 500, tripling the general cost by removing the division by 3, doubling the multiplier for exponents larger than 32 bytes, and introducing a minimal multiplication complexity of 16 with doubled complexity for base/modulus lengths exceeding 32 bytes.
Bringing EIP-7883 to TRON would correct the underpriced ModExp precompile on TVM, mitigating potential DoS attack vectors where adversaries exploit cheap but computationally heavy MODEXP calls. This repricing also aligns TRON with Ethereum's Osaka upgrade roadmap, reduces cross-chain development friction for dApps relying on cryptographic primitives, and lays the groundwork for potential future increases in TRON's block energy limit. Therefore, EIP-7883 should be implemented on TRON as soon as possible to maintain compatibility with mainstream EVM standards.
Abstract
This TIP is modifying the ModExp precompile pricing algorithm introduced in EIP-2565.
Motivation
Currently the ModExp precompile is underpriced in certain scenarios relative to its resource consumption. By adjusting the pricing formula, this TIP aims to address these discrepancies, making ModExp sufficiently efficient to enable potential increases in the block gas limit.
Specification
Upon activation of this TIP, the gas cost of calling the precompile at address 0x0000000000000000000000000000000000000005 will be calculated as follows:
def calculate_multiplication_complexity(base_length, modulus_length):
max_length = max(base_length, modulus_length)
words = math.ceil(max_length / 8)
multiplication_complexity = 16
if max_length > 32: multiplication_complexity = 2 * words**2
return multiplication_complexity
def calculate_iteration_count(exponent_length, exponent):
iteration_count = 0
if exponent_length <= 32 and exponent == 0: iteration_count = 0
elif exponent_length <= 32: iteration_count = exponent.bit_length() - 1
elif exponent_length > 32: iteration_count = (16 * (exponent_length - 32)) + ((exponent & (2**256 - 1)).bit_length() - 1)
return max(iteration_count, 1)
def calculate_gas_cost(base_length, modulus_length, exponent_length, exponent):
multiplication_complexity = calculate_multiplication_complexity(base_length, modulus_length)
iteration_count = calculate_iteration_count(exponent_length, exponent)
return max(500, math.floor(multiplication_complexity * iteration_count))
The specific changes from the algorithm defined in EIP-2565:
1. Increased minimal and general price
The gas cost calculation is modified from:
return max(200, math.floor(multiplication_complexity * iteration_count / 3))
to:
return max(500, math.floor(multiplication_complexity * iteration_count))
This change increases the minimum gas cost from 200 to 500 and triples the general cost by removing the division by 3.
2. Increase cost for exponents larger than 32 bytes
The gas cost calculation is modified from:
elif exponent_length > 32: iteration_count = (8 * (exponent_length - 32)) + ((exponent & (2**256 - 1)).bit_length() - 1)
to:
elif exponent_length > 32: iteration_count = (16 * (exponent_length - 32)) + ((exponent & (2**256 - 1)).bit_length() - 1)
The multiplier for exponents larger than 32 bytes is increased from 8 to 16, doubling its impact.
3. Assume the minimal base / modulus length to be 32 and increase the cost when it is larger than 32 bytes
The gas cost calculation is modified from:
def calculate_multiplication_complexity(base_length, modulus_length):
max_length = max(base_length, modulus_length)
words = math.ceil(max_length / 8)
return words**2
to:
def calculate_multiplication_complexity(base_length, modulus_length):
max_length = max(base_length, modulus_length)
words = math.ceil(max_length / 8)
multiplication_complexity = 16
if max_length > 32: multiplication_complexity = 2 * words**2
return multiplication_complexity
This change introduces a minimal multiplication complexity of 16 and doubles the complexity if the base or modulus length exceeds 32 bytes.
Rationale
Benchmarking the ModExp precompile revealed several scenarios where its gas cost was significantly underestimated. Pricing adjustments are designed to rectify underpriced edge cases by modifying the existing ModExp pricing formula parameters. Specifically, the minimum cost for ModExp will rise from 200 to 500 (a 150% increase), the general cost will triple (a 200% increase), a minimum base/modulus length of 32 bytes will be assumed and the cost will scale more aggressively when the base, modulus, or exponent exceed 32 bytes. These modifications aim to ensure that the ModExp precompile's performance, even in its most resource-intensive edge cases across all execution layer clients, no longer impedes potential increases to the block gas limit.
Backwards Compatibility
This TIP introduces a backwards-incompatible change. However, similar gas repricings have occurred multiple times in the Ethereum ecosystem, and their effects are well understood.
An empirical analysis of this proposal is available here, with a separate breakdown by affected entities provided here.
Test Cases
The most common usages (approximately 99.69% of historical Modexp calls as of January 4th, 2025) will experience either a 150% increase (from 200 to 500 gas) or a 200% increase (tripling from approximately 1360 gas).
No changes are made to the underlying interface or arithmetic algorithms, allowing existing test vectors to be reused. The table below presents the updated gas costs for these test vectors:
| Test Case | EIP-2565 Pricing | TIP-7883 Pricing | Increase |
|---|---|---|---|
| modexp_nagydani_1_square | 200 | 500 | 150% |
| modexp_nagydani_1_qube | 200 | 500 | 150% |
| modexp_nagydani_1_pow0x10001 | 341 | 2048 | 501% |
| modexp_nagydani_2_square | 200 | 512 | 156% |
| modexp_nagydani_2_qube | 200 | 512 | 156% |
| modexp_nagydani_2_pow0x10001 | 1365 | 8192 | 501% |
| modexp_nagydani_3_square | 341 | 2048 | 501% |
| modexp_nagydani_3_qube | 341 | 2048 | 501% |
| modexp_nagydani_3_pow0x10001 | 5461 | 32768 | 500% |
| modexp_nagydani_4_square | 1365 | 8192 | 501% |
| modexp_nagydani_4_qube | 1365 | 8192 | 501% |
| modexp_nagydani_4_pow0x10001 | 21845 | 131072 | 500% |
| modexp_nagydani_5_square | 5461 | 32768 | 500% |
| modexp_nagydani_5_qube | 5461 | 32768 | 500% |
| modexp_nagydani_5_pow0x10001 | 87381 | 524288 | 500% |
| modexp_marius_1_even | 2057 | 45296 | 2102% |
| modexp_guido_1_even | 2298 | 51136 | 2125% |
| modexp_guido_2_even | 2300 | 51152 | 2124% |
| modexp_guido_3_even | 5400 | 32400 | 500% |
| modexp_guido_4_even | 1026 | 94448 | 9105% |
| modexp_marcin_1_base_heavy | 200 | 1152 | 476% |
| modexp_marcin_1_exp_heavy | 215 | 16624 | 7632% |
| modexp_marcin_1_balanced | 200 | 1200 | 500% |
| modexp_marcin_2_base_heavy | 867 | 5202 | 500% |
| modexp_marcin_2_exp_heavy | 852 | 16368 | 1821% |
| modexp_marcin_2_balanced | 996 | 5978 | 500% |
| modexp_marcin_3_base_heavy | 677 | 2032 | 200% |
| modexp_marcin_3_exp_heavy | 765 | 4080 | 433% |
| modexp_marcin_3_balanced | 1360 | 4080 | 200% |
Security Considerations
This TIP does not introduce any new functionality or make existing operations cheaper, therefore there are no direct security concerns related to new attack vectors or reduced costs. The primary security consideration for this TIP is the potential for ModExp scenarios to be overpriced, though this is deemed a lesser risk compared to the current underpricing issues.
Copyright
Copyright and related rights waived via CC0.
Activity
jwrct commentedon Mar 20, 2026
@ouy95917 While the backward incompatibility is acknowledged and well-understood from Ethereum’s experience, the test case table shows certain operations (e.g., modexp_guido_4_even with 9105% increase) experiencing dramatic cost surges. It would be valuable to supplement this TIP with a brief impact analysis identifying which categories of dApps or cryptographic primitives are most likely affected, and recommended migration strategies for developers currently relying heavily on these operations.
ouy95917 commentedon Mar 21, 2026
@jwrct Thanks for the feedback — this is a good point.
The large increases (e.g., modexp_guido_4_even) mainly come from synthetic edge-case benchmarks, rather than patterns seen in real-world usage. In practice, MODEXP is mostly used with standard sizes (e.g., RSA ≤ 4096 bits), where the impact is limited and predictable.
Overall, the practical impact on existing dApps is expected to be minimal.
lily309 commentedon Apr 3, 2026
How widely is the
ModExpprecompile actually used on TRON? Is this change going to affect many contracts?ouy95917 commentedon Apr 3, 2026
@lily309 Honestly,
ModExpusage on TRON is pretty low — the vast majority of contracts never touch it. But that's not really the point.ModExpis the underlying primitive for RSA signature verification, VDFs, and certain ZK proof schemes. Ethereum analyzed their historical data and found that roughly 99.69% of ModExp calls use standard parameters — those would see about a 1.5x to 3x energy cost increase, which is very manageable. The real concern isn't current usage volume, it's eliminating the DoS risk from underpricing. Right now, someone could craft aModExpcall with large parameters where the energy cost is way below the actual computation time — that's a security gap we should close.alan-eth commentedon Apr 16, 2026
Solid security hardening! The current underpricing is essentially a ticking time bomb — low usage today doesn't mean the attack surface isn't there.
Beyond DoS prevention, properly pricing ModExp also removes a blocker for potential future energy limit increases on TRON. When precompiles are underpriced, raising the energy limit amplifies the worst-case execution time, which limits the network's ability to scale throughput safely. Fixing this now is forward-looking.
Nice alignment with the Osaka timeline 👍
yanghang8612 commentedon May 8, 2026
TIP-7883 (ModExp repricing) and TIP-7939 (CLZ opcode) are both "Osaka-aligned" changes. From the implementation PR (java-tron#6654) it looks like both are gated behind a single
allowTvmOsakaflag.Two questions:
ouy95917 commentedon May 8, 2026
@yanghang8612
Bundling is intentional, and I think it's the right call — but worth saying why explicitly.
The single
allowTvmOsakaflag tracks the Ethereum Osaka upgrade as a coherent set of changes. Ethereum activates them as one fork; TRON activating them piecemeal would mean dApps that rely on Osaka-as-a-whole (cross-chain tooling, audit assumptions, gas estimators) would face a partial-activation window where TRON has some Osaka features but not others. That's a worse interop story than waiting for the whole set.Specifically for TIP-7883 + TIP-7939:
On rollback: the flag-gated structure means we can disable activation pre-fork without code changes. Post-activation, if a problem surfaces in one of the two, the cleanest path is a follow-on flag (
disableTvmOsakaModExpor similar) at a subsequent fork, not unwinding the whole Osaka gate. The forgiving / pre-Osaka behavior remains in the codebase behind the flag, so a strict revert is always possible.If anyone has a strong case for splitting the flag (e.g. risk model concerns specific to one of the two), I'm open to revisiting — but my lean is that flag granularity should track "coherent upstream upgrade," not "individual TIP."
yanghang8612 commentedon May 13, 2026
Quick update on where TIP-7883 stands.
Implementation merged
The reference implementation in java-tron has landed: tronprotocol/java-tron#6654. It gates the new pricing behind the
allowTvmOsakaproposal, ships the full EIP-7883 test vector set, and keeps the pre-Osaka path byte-for-byte unchanged so the cutover is purely flag-driven.Spec promoted to Last Call
The TIP has been merged into the tips repo as tip-7883.md with status Last Call. The Last Call period is the final review window before the spec is locked in for the SR proposal stage. If anyone has remaining concerns — spec wording, pricing edges, activation mechanics, or anything surfaced by the implementation review — please raise them in this thread.
Otherwise, after Last Call closes the spec moves to Final, and the on-chain activation will be proposed alongside the other Osaka-aligned TIPs as a coherent proposal set.
Thanks to everyone who reviewed and pushed back on details along the way.
Redchar1992 commentedon Jun 5, 2026
The repricing direction makes sense, especially together with the MODEXP input bound in TIP-7823.
My main request is to keep the TRON-specific benchmark data linked from the TIP: the community should be able to see why the new energy schedule better tracks CPU cost on java-tron, not just that it matches an Ethereum-side formula. A short migration note for contracts that use MODEXP for RSA or proof verification would also help, even if the expected breakage is low.
yanghang8612 commentedon Jun 9, 2026
Agreed, @Redchar1992. I'll keep the TRON-specific benchmark data linked from the TIP rather than only citing the Ethereum-side formula — the point is to show why the new energy schedule tracks java-tron's actual CPU cost, not just that it matches an upstream number. And a short migration note for MODEXP-using RSA / proof-verification contracts is worth adding even though expected breakage is low.
317787106 commentedon Jul 6, 2026
@ouy95917 One concern is that the proposal cites Ethereum's historical analysis:
However, this conclusion is based on Ethereum's contract ecosystem, which is not necessarily representative of TRON's. TRON has a different contract landscape and usage patterns, so it would be helpful to provide similar statistics based on TRON mainnet data before drawing the same conclusion.
Even if TRON's distribution turns out to be similar, the remaining ~0.3% of contracts could still experience a very significant increase in energy consumption. For those applications, a 1.5x–3x increase may not be manageable at all and could introduce unacceptable compatibility and cost issues.
Since the proposal itself concludes that the new formula results in "about a 1.5x to 3x energy cost increase" for the vast majority of calls, another possible approach would be to scale the calculated energy cost by a factor of 1/2 or 1/3. This would keep the energy consumption of common ModExp calls close to their current levels, preserving backward compatibility for existing contracts, while still adopting the improved pricing model to mitigate potential DoS attacks.
ouy95917 commentedon Jul 6, 2026
@317787106 Thanks for raising this. I agree that TRON-specific impact data is the right thing to include before finalizing the TIP. We have been looking at the TRON-side MODEXP usage distribution, and the concern does not appear to materialize in practice.
One important baseline difference is worth calling out: TRON has not adopted EIP-2565 MODEXP pricing. The current java-tron pre-Osaka path is still EIP-198-style pricing. So the compatibility comparison for TRON should be EIP-198 -> EIP-7883, not EIP-2565 -> EIP-7883. The Ethereum statement that common calls see a 1.5x-3x increase is relative to Ethereum's EIP-2565 baseline, and should not be directly applied to TRON.
From the TRON mainnet samples we have analyzed so far, most MODEXP calls come from secp256k1-related Solidity libraries, especially the point-decompression /
deriveYhelper paths used by VRF libraries or k1-related verification code. In these cases, MODEXP is used for the secp256k1 field square-root step, not for the whole verification algorithm itself.The dominant pattern is:
baseLen = 32expLen = 32modLen = 32modulus = secp256k1 field prime pexponent = (p + 1) / 4For this pattern, both EIP-198 and EIP-7883 pricing depend on lengths and exponent bit length, not on the concrete base value. The energy is therefore stable for these calls:
32/32/32, exponent(p + 1) / 4For reference, here is the full comparison of the EIP-7883 test vectors against TRON's current EIP-198-style baseline:
modexp_nagydani_1_squaremodexp_nagydani_1_qubemodexp_nagydani_1_pow0x10001modexp_nagydani_2_squaremodexp_nagydani_2_qubemodexp_nagydani_2_pow0x10001modexp_nagydani_3_squaremodexp_nagydani_3_qubemodexp_nagydani_3_pow0x10001modexp_nagydani_4_squaremodexp_nagydani_4_qubemodexp_nagydani_4_pow0x10001modexp_nagydani_5_squaremodexp_nagydani_5_qubemodexp_nagydani_5_pow0x10001modexp_marius_1_evenmodexp_guido_1_evenmodexp_guido_2_evenmodexp_guido_3_evenmodexp_guido_4_evenmodexp_marcin_1_base_heavymodexp_marcin_1_exp_heavymodexp_marcin_1_balancedmodexp_marcin_2_base_heavymodexp_marcin_2_exp_heavymodexp_marcin_2_balancedmodexp_marcin_3_base_heavymodexp_marcin_3_exp_heavymodexp_marcin_3_balancedThis shows that, under TRON's actual current baseline, EIP-7883 is not a uniform gas increase. Some pathological/heavy cases become more expensive, which is the intended security hardening. But several common 256-bit patterns become cheaper than the current EIP-198-style pricing.
For that reason, I do not think applying an additional
1/2or1/3scaling factor is necessary. It would weaken the intended worst-case repricing while solving a compatibility problem that we do not see in the TRON data. A better path is to add the TRON-specific MODEXP distribution and the EIP-198-vs-EIP-7883 comparison to the TIP, so the impact is explicit.yanghang8612 commentedon Jul 16, 2026
Thank you for your continued interest and support for this TIP.
All relevant features have now been implemented in the latest release: java-tron GreatVoyage-v4.8.2.
The specification has also been finalized: TIP-7883 is now in Final status.
As the objectives of this issue have been achieved, this thread is now ready to be closed. Thank you all for your valuable contributions to the TRON ecosystem!