Proposal: Adapting to Ethereum Cancun Instructions and Enhancing Consensus Layer Verification

[xxo1shine]

Simple Summary

To enhance compatibility with the Ethereum Cancun upgrade, TRON network has already implemented the instructions from EIP-1153: Transient storage opcodes, EIP-5656: MCOPY - Memory copying instruction, EIP-4844: Shard Blob Transactions and EIP-7516: BLOBBASEFEE instruction in GreatVoyage-v4.8.0(Kant).

Meanwhile, to optimize the consensus logic to improve the robustness and scalability of the TRON network, GreatVoyage-v4.8.0(Kant) has also enhanced verification of transaction limitation at consensus layer, replace java.math with cross-platform consistent `java.strictMath, enhanced validation of block production during maintenance periods, refine SR ranking algorithm and enhanced block header validation.

This proposal aims to formally activate these instructions to align TVM with these EVM advancements, and enable the enhancements of consensus layer on chain.

Motivation

Ethereum Cancun Upgrade Support

The Ethereum Cancun upgrade, which went live on March 13, 2024, brought significant improvements. TRON aims to maintain compatibility with Ethereum's EVM for a seamless developer experience across ecosystems, implementing the instructions introduced in this upgrade is essential for operational parity, while benefiting from important improvements that enhance smart contract efficiency and reduce energy costs.

This proposal seeks to activate the Cancun upgrade opcodes in TRON, aligning with our commitment to EVM compatibility and enhancing the developer experience across blockchain ecosystems.

Op	Name
0x49	BLOBHASH
0x4a	BLOBBASEFEE
0x5c	TLOAD
0x5d	TSTORE
0x5e	MCOPY

Activating these opcodes as placeholders would:

• Maintain TVM compatibility with EVM
• Support cross-chain development efforts
• Simplify the migration path for EVM smart contracts to TRON
• Provide TRON developers the same energy optimization benefits

Enhanced Consensus Layer Verification

Enabling the enhanced consensus layer verification would:

• Improve consensus layer verification to prevent malicious blocks from being produced in maintenance periods.
• Improve consensus layer verification to prevent malicious blocks with header times not integer multiples of 3s from being produced.
• Refine the SR ranking algorithm to ensure consistency in rare cases.
• Looking ahead to potential cross-platform support and broader JDK version compatibility, Java-Tron needs to transition from java.lang.Math to a mathematical library that ensures consistent calculation results across platforms and newer JDK versions.
• As the TRON network evolves, its security and efficiency continue to improve. Recently, we have identified that although restrictions are already in place for scenarios such as account activation transactions, excessively large transactions, multi-result transactions, and near-expiry transactions, these restrictions have yet to be elevated to the consensus layer, posing potential security risks. While these scenarios do not compromise the chain's asset security and data consistency, they may impact network efficiency.

This proposal aims to support Ethereum Cancun upgrade and optimize scenarios at the consensus layer to further enhance the efficiency and stability of TRON.

How to Initialize the Voting Request

This is the command of initiating the voting request:

• createProposal 83 1 88 1 89 1

The proposal numbers refer to:

• Proposal 83: Activating TLOAD (0x5c), TSTORE (0x5d) and MCOPY (0x5e) opcodes
• Proposal 88: Enabling the enhanced consensus layer verification
• Proposal 89: Activating BLOBHASH (0x49) and BLOBBASEFEE (0x4a) opcodes

Timeline

The estimated timeline:

Creation time of the voting request: 23rd June 2025
The effective time of voting request: 26th June 2025

Technical Specs

Transient Storage Opcodes

Two new opcodes to be activated:

• TLOAD (0x5c) - Load from transient storage
• TSTORE (0x5d) - Store to transient storage

Transient storage provides significant energy savings for temporary data storage within a transaction, offering an alternative to memory for data that must persist across internal calls but doesn't need to survive beyond the transaction.

For more details, please refer to TIP-650.

MCOPY - Memory copying instruction

One new opcode to be activated:

• MCOPY (0x5e) - Copy memory from one location to another efficiently

MCOPY provides significant energy savings for contracts that need to manipulate memory regions.

For more details, please refer to TIP-651.

Enhanced consensus layer verification

• By limiting the size of account creation transactions, bandwidth consumption is more reasonably managed.
• Strengthening the verification of near-critical transaction sizes avoids situations where transactions within a block may exceed the maximum transaction limit.
• Strictly validating the length of the transaction result list to ensure it aligns with the number of contracts, although inconsistency does not pose a consensus issue.
• Implementing a stricter filtering mechanism for expired transactions to prevent near-expiry transactions from potentially occupying network bandwidth.

For more details, please refer to TIP-694.

BLOBHASH and BLOBBASEFEE instructions

Two new opcodes to be activated:

• BLOBHASH (0x49)
• BLOBBASEFEE (0x4a)

These two opcodes will be activated as placeholders with default return values of 0, maintaining bytecode compatibility with EVM while not implementing the full functionality at this time.

For more details, please refer to TIP-745.

Backwards Compatibility

Since consensus-affecting changes will only be activated post-proposal approval, this migration maintains backward compatibility and preserves consensus from the genesis block onward.

[lxcmyf]

@xxo1shine
Are there strict requirements for the order in which these proposals are opened? Is there a dependency between each other?

[xxo1shine]

@xxo1shine Are there strict requirements for the order in which these proposals are opened? Is there a dependency between each other?

@lxcmyf There is no strict requirement for the order in which these proposals are opened, and there is no dependency between them.

[317787106]

@xxo1shine When is the proposal expected to be launched?

[Murphytron]

@xxo1shine When is the proposal expected to be launched?

Depending on the progress of discussions, and we will review the progress during the core devs meeting in late May.

[KrisdiaPaul]

This proposal mainly aims to improve technology, make it compatible with EVM, and strengthen consensus verification. We can move forward with no doubt.

[CooperDepp]

Activating TLOAD and TSTORE (EIP-1153) and MCOPY (EIP-5656) as placeholders guarantees bytecode parity with Ethereum, enabling a drop-in migration path for existing Solidity contracts with zero opcode mismatches.
This preserves the precise gas-cost model and execution semantics that developers expect, eliminating the need for extensive refactoring or custom wrappers when moving to TRON, thereby reducing migration risk and effort.

[BlockAnalysis]

I think with placeholder BLOB opcodes in place now, TRON gains the flexibility to later implement full proto-danksharding support (EIP-4844) or even future EVM enhancements (e.g., Danksharding, Verkle tries) without disrupting existing contract code.
This modular activation strategy decouples immediate EVM parity from future feature rollouts, so TRON can safely test and stage advanced rollup integrations in parallel with network consensus drills.

[tronfansbyte]

@xxo1shine I noticed that all calculation migrating from java.lang.Math to java.lang.StrictMath was also included in v4.8.0, however I don't see it to be enabled in this proposal, why is that? Are we going to have another proposal to open that?

[halibobo1205]

@tronfansbyte, all calculations are migrating from java.lang.Math to java.lang.StrictMath will be enabled by Proposal 88: Enabling the enhanced consensus layer verification.

[tronfansbyte]

@tronfansbyte, all calculations are migrating from java.lang.Math to java.lang.StrictMath will be enabled by Proposal 88: Enabling the enhanced consensus layer verification.

Thank you, got it!