Proposal: Enable the Prague and Osaka Upgrades to Enhance Compatibility with Ethereum

[yanghang8612]

Simple Summary

This proposal aims to activate network parameters #95 and #96 on the TRON mainnet, enabling the Prague and Osaka upgrade features included in GreatVoyage-v4.8.2 (Pyrrho) to enhance TRON's compatibility with Ethereum.

Motivation

GreatVoyage-v4.8.2 introduces support for Ethereum Prague/Pectra and Osaka-related protocol features. These changes improve TVM compatibility, security, execution consistency, and support for newer Ethereum opcodes and precompiled contracts.

Specifically, these upgrades will significantly reduce the on-chain cost of complex cryptographic operations and enable native verification of secp256r1 signatures used by passkeys and hardware-backed key stores, including Apple Secure Enclave and Android Keystore.

The corresponding features have already been implemented but remain gated by on-chain governance parameters. This proposal completes the governance process required to formally activate them on the TRON mainnet.

How to Initialize the Voting Request

This is the command for initiating the voting request:

• createProposal 95 1 96 1

The network parameters refer to:

• Parameter 95: Enable ALLOW_TVM_PRAGUE
• Parameter 96: Enable ALLOW_TVM_OSAKA

Technical Specifications

Parameter 95: ALLOW_TVM_PRAGUE

Activating parameter 95 enables the Prague-related functionality introduced by TIP-2935, which serves historical block hashes from state and provides improved compatibility for applications that require access to a longer block-hash history.

TIP-2935 Activation and Bootstrap Behavior

Let A be the maintenance block in which proposal processing enables parameter 95. Because proposal processing occurs after the transaction loop of block A, transactions in block A do not observe the new functionality. The history contract is deployed during maintenance processing, and the first history write occurs at the start of block A + 1, storing the hash of block A.

Historical hashes from before activation are not backfilled. The 8191-slot ring buffer becomes fully populated at block A + 8191, approximately 6.8 hours after activation at TRON's three-second block interval.

During this bootstrap period, for current block N:

• Queries where K >= N or K < N - 8191 revert.
• Queries for already-written post-activation blocks (A <= K <= N - 1) return the stored block hash.
• Queries for unwritten pre-activation slots still within the valid range (N - 8191 <= K < A) return bytes32(0) rather than reverting.

Applications must treat bytes32(0) as "unavailable", continue using the BLOCKHASH opcode for the most recent 256 blocks, and either wait until N >= A + 8191 or use an off-chain fallback when complete historical coverage is required.

The actual activation block A will be added to the timeline once the proposal takes effect.

Parameter 96: ALLOW_TVM_OSAKA

Activating parameter 96 enables the Osaka-related TVM features, including:

• TIP-7939: Add the Count Leading Zeros (CLZ) opcode.
• TIP-7823: Set upper bounds on MODEXP inputs.
• TIP-7883: Adjust the energy cost of the MODEXP precompile.
• TIP-7951: Add precompile support for the secp256r1/P-256 curve.
• TIP-854: Standardize calldata encoding for signature-verification precompiles.
• TIP-871: Standardize the MODEXP output length when the modulus is zero.

These changes align TVM behavior more closely with the corresponding Ethereum upgrades and reduce compatibility differences for smart contracts, development tools, and cross-chain applications.

Backwards Compatibility

The corresponding protocol changes will only be activated after this proposal is approved and takes effect. Before activation, existing network behavior remains unchanged.

Nodes participating in the TRON network, especially block-producing Super Representatives, must upgrade to GreatVoyage-v4.8.2 before the proposal takes effect. Failure to do so will result in the inability to sync blocks or produce new blocks once the TVM semantics switch.

The TIP-2935 bootstrap period does not change the existing BLOCKHASH opcode semantics, but applications querying the history contract must handle unwritten slots as described above.

Timeline

The estimated timeline:

• Creation time of the voting request: TBD
• Effective time of the voting request: TBD
• Activation block A: TBD

[sunflower-sun]

Strongly in favor of this proposal, especially TIP-7951. TIP-7951 is definitely the highlight here. Right now, verifying secp256r1 in EVM/TVM costs a fortune in energy—this precompile cuts that down by over 70x, which actually makes hardware keys and Passkeys (Apple/Android Keystore) usable on TRON.

[yanghang8612]

Thanks for the support. Agreed—TIP-7951 is one of the most immediately useful developer-facing improvements in this upgrade.

Native secp256r1 verification substantially reduces the Energy cost compared with contract-level implementations, making Passkeys and hardware-backed signing workflows much more practical on TRON. This should enable better wallet and smart-account experiences while improving compatibility with the broader Ethereum ecosystem.

If you have benchmark data or real-world Passkey integration cases, we would also welcome you to share them here.

[lily309]

Definitely in favor of this. Prague and Osaka bring a solid set of compatibility and security improvements, and activating them together makes sense. Looking forward to seeing these features live on mainnet.

[TonyStank911]

Support this proposal. Keeping TVM aligned with the latest Ethereum behavior is important for developers building across multiple chains. The fewer chain-specific differences we have to handle, the better.

[ouy95917]

Overall, I think this is a good package of upgrades. TIP-7951 is probably the most immediately useful for developers, while the MODEXP and block-hash changes improve compatibility and protocol robustness behind the scenes. Happy to support it.

[yanghang8612]

@lily309 Thanks for the support! Activating Prague and Osaka together gives the network a clear and consistent upgrade boundary, rather than introducing these related changes one by one. Hopefully we can move smoothly into the voting and activation stage.

[yanghang8612]

@TonyStank911 Exactly. Reducing behavioral differences between TVM and EVM is one of the main goals here. It should make contract migration, cross-chain development, and tooling integration much more straightforward.

[yanghang8612]

@ouy95917 Overall, I think this is a good package of upgrades. TIP-7951 is probably the most immediately useful for developers, while the MODEXP and block-hash changes improve compatibility and protocol robustness behind the scenes. Happy to support it.

[Benson0224]

TRON already has a native permission system with weighted permissions and multisig, which is a very different account model from Ethereum. On Ethereum, passkeys are primarily enabled through smart accounts because there's no protocol-level permission model. With TIP-7951 adding efficient P-256 verification to the TVM, passkey-based smart wallets become possible on TRON as well. This raises an interesting question about the long-term direction of passkey support on TRON:

• Do you see passkeys remaining primarily a contract-layer capability, or could P-256 eventually become a first-class signature type in TRON's native permission system? If native support is ever considered, what would be the biggest challenges from a consensus or permission-validation perspective?
• As TRON is also exploring post-quantum signature schemes, would it make sense to evolve the native permission system into a more algorithm-agnostic framework that can support multiple signature algorithms—such as secp256k1, P-256, and future post-quantum schemes—instead of introducing support for each algorithm independently?
• If passkeys are expected to remain primarily at the contract layer, should TRON eventually define any common standards or TIPs around passkey-based wallets—for example, interoperability, account portability, or recovery patterns—or is that something you'd prefer to leave entirely to wallet implementations?

[alan-eth]

Strongly support this proposal. Bundling Prague + Osaka into a single governance action with an explicit parameter mapping (createProposal 95 1 96 1) gives the network a clean and consistent upgrade boundary, and the backwards-compatibility notes for SRs are clear and actionable.

Having read through the v4.8.2 implementation, I especially like the attention to detail on TIP-2935: the history contract is kept byte-identical to Ethereum's (same canonical address, same runtime code, same deployer-of-record), so cross-chain tooling sees exactly the same thing on both sides. And the P-256 precompile should make passkeys and hardware-backed signing much more practical on TRON. Looking forward to seeing this activated on mainnet.

[yanghang8612]

@Benson0224 Thanks—these are important questions. My current view is:

1. In the near term, passkeys should remain primarily a contract-layer capability. TIP-7951 deliberately provides an efficient P-256 verification primitive inside TVM without changing TRON’s native transaction-authentication model. Making P-256 a first-class native signature type would be a much larger protocol change: native permissions currently identify keys by address, while P-256 verification uses an explicit public key and does not recover an address. It would require changes to key representation, transaction encoding, permission-weight calculation, node validation, wallets/SDKs, migration rules, and consensus test vectors. WebAuthn also involves more than raw P-256 verification, including authenticatorData, clientDataJSON, origin/RP binding, and related validation rules.

2. An algorithm-agnostic native permission framework is conceptually cleaner than adding algorithms one at a time, especially if post-quantum schemes are considered later. Such a design would need versioned algorithm identifiers, canonical public-key and signature encodings, deterministic verification rules, resource limits, and explicit activation mechanisms. Post-quantum signatures also introduce much larger keys/signatures and different verification costs, so the resource and DoS implications would need careful analysis. I think this deserves a separate TIP and should be informed by contract-layer experimentation first.

3. Contract-layer passkeys should not be left entirely to individual wallet implementations. Common standards would be valuable for signer representation and verification, TIP-712 domain binding, TRC-1271/TRC-7913 interoperability, WebAuthn input handling, key rotation, recovery, and account portability. At the same time, we should avoid standardizing one wallet architecture too early. A practical path is to start with reusable interfaces, reference implementations, and test vectors, then standardize the patterns that prove interoperable in real deployments.

So TIP-7951 should be viewed as an enabling primitive rather than a decision on TRON’s long-term account model. Contract-layer adoption is the practical first step; native P-256 or a broader algorithm-agnostic permission system can be evaluated separately based on deployment experience and security analysis.

[yanghang8612]

@alan-eth Thanks for the support and for taking the time to review the v4.8.2 implementation details. Agreed—activating Prague and Osaka together provides a clear upgrade boundary, while keeping TIP-2935 aligned with Ethereum should make cross-chain tooling and integration more predictable. Really appreciate the careful review.

[freddie-lele]

TIP-2935 bootstrap window: a heads-up for contract/tooling developers

For roughly 7 hours after activation (the bootstrap period), the TIP-2935 historical block-hash ring buffer is not yet full. Within the valid query range, reads from unwritten slots return bytes32(0) rather than reverting — unlike normal out-of-range queries, which do revert — so callers can easily mistake an all-zero return for a real block hash. It depends only on when the query happens, and the issue disappears once the buffer is fully populated.

Suggestions:

• Correctness-sensitive applications should gate on block.number >= activationBlock + 8191 and fall back to an off-chain oracle during the bootstrap window;
• Treat a bytes32(0) return as "unavailable" rather than a valid hash in query logic;
• Use the BLOCKHASH opcode for the most recent 256 blocks (its semantics are unchanged);
• Make these rules explicit in the release notes and developer docs.