feat(vm): implement TIP-7823#6611
Conversation
# Conflicts: # common/src/main/java/org/tron/core/Constant.java # framework/src/main/java/org/tron/core/config/args/Args.java
1. Change ALLOW_TVM_OSAKA proposal id from 95 to 96 2. DynamicPropertiesStore.getAllowTvmOsaka() defaults to CommonParameter 3. ModExp returns Pair.of(false, EMPTY_BYTE_ARRAY) instead of throwing PrecompiledContractException when inputs exceed 1024 bytes, matching geth/besu behavior where only the CALL fails (not the whole tx) 4. Update test to verify return value instead of catching exception
| import org.tron.core.vm.config.VMConfig; | ||
|
|
||
| @Slf4j | ||
| public class AllowTvmOsakaTest extends VMTestBase { |
There was a problem hiding this comment.
The current test only covers two cases: all-zero lengths (valid) and an oversized baseLen (invalid). Please add the following cases:
baseLen == 1024 → should succeed (boundary value)
baseLen == 1025 → should fail (just over the limit)
Oversized expLen only → should fail
Oversized modLen only → should fail
All limits exceeded while allowTvmOsaka is disabled → should succeed (no restriction applied)
There was a problem hiding this comment.
Thanks for the review! All suggested test cases have been added in the latest commit:
- baseLen == 1024 → passes (boundary value)
- baseLen == 1025 → fails (just over the limit)
- Oversized expLen only → fails
- Oversized modLen only → fails
- All limits exceeded with allowTvmOsaka disabled → passes (no restriction applied)
Also added a helper method toLenBytes(int) for cleaner ABI-encoded length construction. All tests pass locally.
- baseLen == 1024 boundary value should succeed - baseLen == 1025 just over limit should fail - oversized expLen only should fail - oversized modLen only should fail - all limits exceeded with osaka disabled should succeed
| if (VMConfig.allowTvmOsaka() | ||
| && (baseLen > UPPER_BOUND || expLen > UPPER_BOUND || modLen > UPPER_BOUND)) { | ||
| return Pair.of(false, EMPTY_BYTE_ARRAY); | ||
| } |
There was a problem hiding this comment.
Hey @ouy95917, just a quick curiosity question here — is there a specific calculation or reasoning behind why baseLen, expLen, and modLen are each capped at 1024 bytes specifically? I'm wondering whether this was driven by cryptographic practicality (e.g., covering RSA-8192 as the largest real-world key size), or some other consideration from the EIP authors. Any context you can share — or a pointer to the relevant EIP discussion thread — would be greatly appreciated. Thanks!
There was a problem hiding this comment.
The 1024-byte (8192-bit) limit was mainly driven by cryptographic practicality — it covers RSA keys up to 8192 bits, which is the largest size used in practice. Ethereum's on-chain analysis (~7 years of mainnet data) confirmed the max observed input was only 513 bytes, so 1024 gives plenty of headroom.
There's a more detailed discussion on this in the TIP issue: tronprotocol/tips#826 — covers the rationale, error semantics, security background, etc. Worth a read if you're interested.
… security 1. change shielded transaction API default from true to false in config.conf 2. update Args.java and CommonParameter.java to reflect new default 3. add allowShieldedTransactionApi to whitelist config Closes tronprotocol#6611
… security 1. change shielded transaction API default from true to false in config.conf 2. update Args.java and CommonParameter.java to reflect new default 3. add allowShieldedTransactionApi to whitelist config 4. replace arithmetic operators with StrictMathWrapper for overflow protection 5. update test to handle ArithmeticException from StrictMathWrapper.subtractExact Closes tronprotocol#6611
4 participants
This PR aims to implement TIP-7823, and for this purpose, the
allowTvmOsakaproposal has been added.