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.
2 participants
This PR aims to implement TIP-7823, and for this purpose, the
allowTvmOsakaproposal has been added.