Introduction of Cancun Compatible Features in TRON

6 min readApr 29, 2025

Summary

The TRON network continues to evolve with significant upgrades to enhance its performance, security, and compatibility since its inception. One of the most notable recent advancements of the TRON Virtual Machine (TVM) is the compatibility upgrade with Ethereum’s Cancun, which introduces several new features while maintaining TRON’s core value proposition of high throughput and low transaction costs.

In March 2024, Ethereum officially launched its Dencun (Cancun-Deneb) upgrade, with the Cancun portion specifically bringing several critical virtual machine enhancements. To maintain compatibility with these new Ethereum features and to further expand TRON’s blockchain efficiency, interoperability, and ecosystem growth, we have introduced the Cancun upgrade functionality to the TRON network.

The TRON Virtual Machine (TVM) serves as the execution environment for smart contracts on the TRON blockchain, interpreting bytecode compiled from high-level languages like Solidity. With the Cancun upgrade, the TVM now supports the latest EVM opcodes and features, ensuring that developers can seamlessly port their Ethereum applications to TRON while benefiting from TRON’s unique advantages in terms of cost and speed.

In this article, we’ll delve into the technical aspects of the Cancun features in TRON, exploring its implementation details and the improvements it brings to the Java-Tron codebase, with a particular emphasis on the TVM enhancements.

Technical Foundations

1. TIP-745: Introduce EIP-4844 and EIP-7516 instructions

At the heart of the Cancun upgrade is EIP-4844, a protocol originally pioneered by Ethereum to optimize Layer 2 scalability.

EIP-4844 introduces a new transaction format for “blob-carrying transactions”, which contain a large amount of data and a new instruction BLOBHASH to get versioned hashes of blob transactions.

EIP-7516 introduces a new instruction that returns the value of the blob base-fee of the current block it is executing in.

Due to the different demands for L2 and data processing capabilities between TRON and Ethereum, we have not introduced blob-type transactions for the time being. And in view of this situation, the implementations of BLOBHASH and BLOBBASEFEE instructions differ from Ethereum.

It’s also important to note that this implementation currently focuses only on introducing the new instructions. Full blob transaction support and the point evaluation precompiled contract will be implemented in future versions. When we implement the point evaluation precompile, we will use an address different from Ethereum’s implementation (0x0a), as this address is already allocated to the ValidateMultiSign precompile on TRON. This phased approach allows us to carefully adapt Ethereum’s data availability solutions to TRON’s unique architecture while maintaining backward compatibility.

2. TIP-650: Implement EIP-1153 Transient storage opcodes

EIP-1153 introduces transient storage opcodes for manipulating state that behaves almost identically to storage but is discarded after every transaction.

3. TIP-651: Implement EIP-5656 MCOPY — Memory copying instruction

EIP-5656 introduces an efficient EVM instruction for copying memory areas.

4. TIP-652: Announce EIP-6049 Deprecate SELFDESTRUCT

EIP-7516 announces to deprecate SELFDESTRUCT by discouraging its use in Ethereum Shanghai upgrade and its behavior has been modified after the Ethereum Cancun upgrade. In accordance with the development plan of TRON, we declare the deprecation of the SELFDESTRUCT in this upgrade.

Overview of New TVM Instructions

Technical Interpretation

1. BLOBHASH instruction

Introduces a new instruction BLOBHASH (with opcode 0x49) and has an Energy cost of 3.
This opcode reads the index from the top of the stack and places a single item with the value 0 onto the stack.

2. BLOBBASEFEE instruction

Introduces a new instruction BLOBBASEFEE (with opcode 0x4a) and has an Energy cost of 2.
This opcode returns a single value 0.

3. Transient storage instructions

Introduces two new instructions TLOAD (with opcode 0x5c) and TSTORE (with opcode 0x5d), and has an Energy cost of 100 separately.
TLOAD opcode pops a 32-byte word from the top of the stack, uses this value as the address in transient storage, retrieves the corresponding 32-byte word from that address, and then pushes this value back onto the stack.
TSTORE opcode pops two 32-byte words from the top of the stack, using the first as the address in transient storage and the second as the value to be stored. It then saves this value at the corresponding location in transient storage.

4. Memory copy instruction

Introduces a new instruction MCOPY (with opcode 0x5e) and the Energy consumption for this operation is calculated as follows:

words_copied = (length + 31) // 32
g_verylow    = 3
g_copy       = 3 * words_copied + memory_expansion_cost
gas_cost     = g_verylow + g_copy

This opcode pops three 32-byte words from the top of the stack, which are the destination position, the source position, and the length of the memory copy. It returns no item on stack.

Contract Example

This is an example contract that includes all the new instructions mentioned above：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract CancunTest {

    constructor() payable {}

    receive() payable external {}

    // BLOBHASH example
    function testBlobHash(uint256 blobIndex) public view returns (bytes32) {
        bytes32 res = blobhash(blobIndex);
        require(res == bytes32(0), "BLOBHASH failed");
        return res;
    }

    // BLOBBASEFEE example
    function testBlobBaseFee() public view returns (uint256) {
        uint256 res = block.blobbasefee;
        require(res == 0, "BLOBBASEFEE failed");
        return res;
    }

    // transient storage (TSTORE/TLOAD) example
    function testTransientStorage(bytes32 value) public returns (bytes32) {
        bytes32 res = 0;
        assembly {
            res := tload(1)
        }
        require(res == bytes32(0), "TLOAD failed");

        assembly {
        // Store the value in transient storage slot 1
            tstore(1, value)
            res := tload(1)
        }
        require(res == value, "TSTORE failed");
        // Clear the transient storage at the end of the function
        assembly {
            tstore(1, 0)
        }
        return res;
    }

    // memory copy (MCOPY) example
    function testMemoryCopy(bytes32 data) public pure returns (bytes32) {
        bytes32 value;
        assembly {
            let memPtr := mload(0x40)
            mstore(memPtr, data)
            let memPtr2 := mload(0x40)
            mcopy(memPtr2, memPtr, 32)
            value := mload(memPtr2)
        }

        require(data == value, "Memory copy failed");
        return value;
    }

    function validateInputLengths(
        bytes calldata version,
        bytes calldata commitment,
        bytes calldata z,
        bytes calldata y,
        bytes calldata proof
    ) internal pure {
        require(version.length == 32, "Invalid versionhash length");
        require(commitment.length == 48, "Invalid commitment length");
        require(z.length == 32, "Invalid evaluation point length");
        require(y.length == 32, "Invalid claimed value length");
        require(proof.length == 48, "Invalid proof length");
    }
}

Impact

The TRON implementation of Ethereum Cancun upgrade delivers substantial benefits by creating a powerful synergy between technical advancement and practical utility for its ecosystem participants.

For developers, these new features bring numerous advantages. For example, the introduction of transient storage opcodes significantly reduces gas costs for complex operations that previously required expensive storage manipulations, enabling the development of more sophisticated and cost-effective smart contracts. Additionally, the MCOPY instruction dramatically improves the efficiency of memory operations, allowing for optimized contract execution.

With the implementation of these EVM-compatible features, developers can now seamlessly port their Ethereum applications to TRON with minimal modifications. This cross-chain compatibility effectively expands the potential user base for dApps while leveraging TRON’s inherent advantages in throughput and cost-effectiveness.

Conclusion

This article has provided a comprehensive technical and practical examination of TRON’s Ethereum Cancun compatibility upgrade. We’ve explored the key technical implementations including enhanced VM compatibility and functional changes based on TRON’s characteristics. The Cancun upgrade marks a crucial milestone in TRON’s development, aligning it more closely with Ethereum’s capabilities while preserving TRON’s distinctive advantages in efficiency and cost.

For more information

GitHub: https://github.com/tronprotocol
Telegram: https://t.me/troncoredevscommunity

TRON