TIP-1884/2929: TVM Opcode Spec
Summary
This TIP proposes creating a formal, comprehensive specification for the TVM. It will enumerate all TVM opcodes, their semantics, and Energy (gas) costs – including memory usage costs and state-access costs – and introduce “state access cost” reforms inspired by Ethereum’s EIP-1884 and EIP-2929. By standardizing the TVM’s behavior and updating certain opcode costs, we aim to improve the predictability of resource (Energy) consumption, facilitate formal verification, and ease implementation of TVM in clients.
Abstract
The TRON network currently lacks an official low-level specification for its virtual machine that rivals Ethereum’s formal Yellow Paper. This proposal formalizes the TVM opcode set, gas/Energy costs, and execution model in a single specification document. The spec will detail the TVM’s memory model (word-addressed 256-bit memory with quadratic expansion costs) and all operational codes – including TRON-specific opcodes (for TRC-10 tokens, resource management, voting, etc.) – along with their precise effects and Energy costs. Furthermore, it recommends adjusting state access opcodes (such as storage reads and external account access) to better reflect their true computational overhead, similar to Ethereum’s past network upgrades (e.g. Istanbul’s EIP-1884 and Berlin’s EIP-2929). These adjustments include repricing certain opcodes (like SLOAD, BALANCE, EXTCODEHASH, calls, etc.) and introducing the concept of “cold” vs. “warm” accesses to make gas/Energy consumption more predictable. Together, the formal spec and cost reforms will align TVM execution costs with actual resource usage, improving network security and performance while maintaining compatibility with Ethereum’s model for developer convenience.
Motivation
TRON currently lacks a unified standard for wallet-dApp-node communication. Different wallets expose varying APIs—TronLink uses custom methods, other wallets implement different patterns—while node access splits between Ethereum-compatible JSON-RPC and TRON-specific REST endpoints. This fragmentation forces developers to write custom integration code for each wallet and juggle multiple API paradigms depending on which data they need.
DApp developers must maintain separate code paths for each wallet they support, testing against multiple implementations and handling wallet-specific quirks. When new wallets launch, existing dApps cannot support them without updates. Node operators face similar challenges—some implement partial JSON-RPC for basic queries but lack TRON-specific methods, while others provide comprehensive REST APIs without standardized RPC endpoints. Services bridge this gap by offering both interfaces, but the split forces dApps to maintain dual integration logic.
Beyond complexity, the lack of standards creates security gaps. Some TRON dApps historically accessed user accounts automatically without explicit permission, exposing addresses before users could review or reject connections. Transaction confirmation flows vary—some wallets provide detailed signing prompts while others show minimal context. Error handling differs across implementations, with inconsistent codes making it difficult for dApps to provide appropriate user feedback.
By adopting this standard, wallet developers gain clear implementation targets ensuring their wallets work with all dApps. DApp developers gain a single integration path working with all compliant wallets. Node operators gain specification-driven guidance. Users gain consistent security prompts and clearer understanding of what they’re authorizing across all TRON applications.
Specification
The specification has two primary components: (A) A formal TVM definition (covering the execution model, opcodes, and memory/storage behavior), and (B) Revised gas/Energy cost parameters for certain operations (state access cost reforms). This section outlines both in detail.
A. Formal TVM Specification Document: We define the TVM in a manner equivalent to Ethereum’s Yellow Paper for the EVM. This includes:
- Execution Model & State Transition: A mathematical description of how a transaction’s execution changes the TRON state. We denote the state transition function as
Υ(S, T) = S', meaning given an initial state S and a transaction T, the VM produces a new state S’. The spec will describe the components of state (accounts, balances, storage trie, etc.) and how the TVM processes transaction bytecode to yield a new state. This aligns with Ethereum’s formalism but adapted to TRON specifics (e.g., TRON’s block header fields and consensus differences). - Memory Model: The TVM memory is a volatile byte-addressable memory organized in 32-byte words, initially all zero, with a maximum of 1024 words for the stack. The spec will include the cost function for memory expansion identical to Ethereum’s:
C_mem(a) = G_memory × a + floor(a² / 512)
Where:
ais the new memory size measured in 32-byte wordsG_memoryis the linear memory cost per word and is fixed at 3 Energy
The total memory cost consists of:
- A linear component proportional to memory size
- A quadratic component that increases non-linearly as memory usage grows
The spec will detail how memory expansion cost is calculated for each opcode that increases memory (e.g., MSTORE, CALLDATACOPY, CODECOPY, etc.), consistent with EVM rules. This formal definition ensures that all clients calculate memory costs uniformly and prevents discrepancies in gas usage across implementations.
- Opcode List and Semantics: A complete listing of all opcodes supported by TVM, including:
- Standard EVM Opcodes: All instructions inherited from Ethereum (e.g. arithmetic, cryptographic, stack, environmental and system opcodes) will be listed with their bytecode value, mnemonic, stack inputs/outputs, and descriptive semantics. For example, the spec will cover opcodes like
ADD (0x01)throughSELFDESTRUCT (0xff)in detail, matching Ethereum’s definitions where applicable. - TRON-Specific Opcodes: The TVM has additional opcodes beyond the Ethereum set, introduced via various TIPs. These include opcodes for TRC-10 token transfers (
CALLTOKEN,TOKENBALANCE, etc. at 0xd0–0xd3), contract introspection (ISCONTRACTat 0xd4), resource management (FREEZE,UNFREEZE, etc. at 0xd5–0xdc), and governance (VOTEWITNESS, etc. at 0xd8–0xdf). The specification will incorporate all such opcodes, documenting their behavior (effect on state or stack) and their Energy cost. For instance,CALLTOKEN (0xd0)will be specified to perform an internal message call transferring TRC-10 tokens, including how it deducts balances and how much Energy it consumes. By standardizing these, we ensure that any future implementation of TVM (or formal analysis thereof) will handle TRON-specific logic correctly. - System/Environment Operations: Opcodes like
ADDRESS,BALANCE,BLOCKHASH,TIMESTAMP, etc. will be described in a TRON context. Notably, differences from Ethereum will be clarified – e.g.,DIFFICULTY (0x44)always returns 0 in TVM (since TRON doesn’t have PoW difficulty), andGASLIMIT (0x45)returns 0 (TRON blocks use bandwidth/energy limits instead).GASPRICE (0x3A)andBASEFEE (0x48)return the network’s fixedenergyPriceparameter, because TRON doesn’t have a dynamic fee market. All such deviations will be explicitly stated. - Precompiled Contracts: TRON uses some precompiled contracts (e.g., for cryptographic functions or batch signature verification). The spec will list TRON’s precompiles and addresses, noting differences from Ethereum’s set. For example, TRON’s precompile at address 0x09 is
BatchValidateSign(not present in Ethereum). Each precompile’s gas/Energy cost formula (if any) will be given or referenced.
- Standard EVM Opcodes: All instructions inherited from Ethereum (e.g. arithmetic, cryptographic, stack, environmental and system opcodes) will be listed with their bytecode value, mnemonic, stack inputs/outputs, and descriptive semantics. For example, the spec will cover opcodes like
By presenting this exhaustive opcode table and semantics, the spec acts as the authoritative reference for how any given piece of bytecode will execute on TRON. This improves consistency across different TRON node implementations and helps external developers understand TRON at the same level of detail as Ethereum.
- Gas/Energy Accounting Rules: The spec will formalize how Energy is consumed during execution, analogous to gas in Ethereum. This includes delineating the inherent opcode cost (base cost for executing the opcode), additional dynamic costs (e.g., costs proportional to bytes copied, memory expanded, etc.), and refunds if applicable. TRON’s Energy model largely mirrors Ethereum’s gas model, so we will reuse Ethereum’s formulas unless otherwise noted. For instance, we will specify that a
CALLDATACOPYcosts a base of 3 Energy plus 3 Energy per 32-byte word copied, as derived from the Yellow Paper’s Appendix for the EVM. We will also include TRON-specific considerations, such as the lack of a true gas refund mechanism for freeing storage (Ethereum refunds gas on SSTORE clearing or SELFDESTRUCT; TRON may have disabled or capped some refunds differently). If TRON diverges (for example, if TRON’s implementation of SSTORE or SELFDESTRUCT behaves differently in terms of refunds or failure conditions), those will be explicitly described.
B. Opcode Cost Reforms (Gas Repricing): Alongside documenting current costs, this proposal updates several opcode costs to better align with actual resource costs and Ethereum’s post-Istanbul standards:
- Reprice Trie-Dependent Operations: Increase the Energy cost of opcodes whose execution time grows with state/trie size:
SLOAD(0x54 – reading from contract storage): Increase from 200 Energy to 800 Energy per read. This matches the cost introduced by Ethereum’s EIP-1884. In TRON’s case, sinceSLOADwas deliberately kept cheaper than Ethereum, this is a significant change, but it is necessary for security. Each storage read will now consume 4× more Energy than before, disincentivizing overuse in a single transaction and reflecting the true performance impact.BALANCE(0x31 – fetching an account’s balance) andEXTCODEHASH(0x3F – getting another account’s code hash): Increase from 400 to 700 Energy. These opcodes also require a trie lookup of an external account, which has become slower as the account state grows. Ethereum raised these to 700 in EIP-1884 to equalize with similar operations, and we adopt the same logic. After this change,BALANCEandEXTCODEHASHwill cost the same as anEXTCODESIZE(which is already 700 in TVM due to earlier alignment with EIP-150).- (If not already implemented) Introduce
SELFBALANCE(0x47) opcode, costing 5 Energy, which returns the contract’s own balanceeips.ethereum.org.
Note: TRON may already support
SELFBALANCEas part of Istanbul compatibility; if not, this spec includes it for completeness. This opcode offers a cheap way to get the contract’s balance without a full trie lookup (replacing the pattern ofCALLER+BALANCEof self), thus it should be part of the TVM spec.
- State Access List Mechanism (Cold/Warm costs): Implement the concept of “cold” vs “warm” accesses from EIP-2929 to further balance costs. Under this reform, the first time a contract accesses a particular piece of state in a transaction, it pays a one-time “cold” cost, and subsequent accesses pay a much lower “warm” cost:
- For storage slots: On the first
SLOADorSSTOREof a given storage index in a transaction, charge an additional 2100 Energy (cold access cost). Thus, a coldSLOADwould cost 2100 (instead of 800), and a coldSSTOREwould have 2100 added to its base cost as well. If that same slot is accessed again later in the transaction, the operation is “warm” and the 2100 penalty is not applied (subsequentSLOADcosts only 100 Energy in addition to the normal warm cost). We adopt the exact values from Ethereum’s Berlin upgrade: 2100 Energy cold cost, 100 Energy warm cost. This change encourages better locality of storage access in contracts and prevents abuse of looping over large storage areas within one transaction. - For account access (opcodes that touch other accounts/contracts): The first time an external address is accessed (via
BALANCE,EXTCODESIZE,EXTCODEHASH,EXTCODECOPY, or any CALL-related opcode) in a transaction, impose a 2600 Energy cold access cost. This bringsCALLand similar opcodes in line with Ethereum’s EIP-2929 rules. In practice, a contract call (CALL,DELEGATECALL, etc.) to a new address will pay 2600 extra on its first invocation. Likewise, the firstBALANCEof a given address costs 700+2600, whereas subsequent BALANCE checks to the same address (warm) would cost just 700. We set 2600 as the cold cost as per Ethereum. This reform ensures that transactions touching many different contracts pay a higher price (since each new contract access has overhead in traversing the trie), which reduces the worst-case processing time for huge multi-call transactions. - Internally, the VM will maintain an access set (as Ethereum does) of accessed accounts and storage keys during each transaction. The spec will define this mechanism: at the start of execution, the caller’s address and the contract’s own address are considered warmed (as in EIP-2929). As opcodes execute, if an address or
(address, storageKey)pair is accessed, it’s added to the accessed set. If a subsequent operation tries to access something already in the set, it is treated as warm (no extra cost). This detail will be codified so that all client implementations handle warm/cold distinction identically.
- For storage slots: On the first
Note: TRON may decide not to implement the optional access list transaction feature (EIP-2930) immediately. That feature allows a transaction to specify which addresses/keys will be accessed, to avoid cold costs. It is not necessary for the cost scheme itself and can be introduced separately as a new transaction type if desired. The core of this TIP is the pricing changes and internal logic of warm/cold accounting, which can work without explicit access lists.
- Adjust SSTORE Cost Schedule: If not already aligned with Ethereum’s latest, update the storage write costs according to EIP-2200 (Istanbul) and EIP-3529 (London) reforms. That is, use “net gas metering” for storage: writing to an unmodified storage slot: 20,000 Energy (with refund if the slot is cleared), writing to a slot that already contains the value: 5,000, etc., with the refund on clearing reduced to 4,800 (from 15k) as per EIP-3529. These changes, while primarily already in Istanbul/London Ethereum, should be documented in the spec to ensure TRON’s SSTORE behavior is unambiguous. If TRON’s current implementation diverges (for example, if it still uses the older refund amounts), this spec mandates adopting the newer values to prevent gas refund abuse and keep consistency with Ethereum’s security fixes. (Underpriced refunds in Ethereum led to gas token abuses, hence the reduction in refunds; TRON similarly benefits from eliminating any incentivization to spam-storage for refunds.)
Backwards Compatibility
The proposed gas cost changes constitute a hard-forking change to the protocol. All TRON validators/nodes must upgrade to a client version implementing the revised TVM costs, or they will disagree on transaction validity post-fork. We will choose a fork block (or enable via a committee proposal) at which the new costs and rules become active (old blocks use the previous costs, ensuring historical consistency).
Increasing opcode costs can break existing smart contracts or dApps in subtle ways:
- Contracts that were deployed with fixed Energy assumptions for certain operations may start running out of Energy. For example, a contract might have assumed
SLOADcosts 200 and set an internal limit accordingly; withSLOADnow costing up to 2100 in cold cases, the same loop could exceed the available Energy. Likewise, any contract using the 2300 Energy stipend (for instance, in TRX transfer fallback functions) that then calls an opcode likeSLOADorBALANCEcould fail if 2300 is no longer enoughgithub.com. Developers have had to manage this on Ethereum, but TRON contracts might not be prepared for it. - Calls with fixed gas forwarding: If a contract uses
call.value(...).gas(n)to forward a set amount of gas/Energy to a callee, and that callee now needs more Energy to do the same work, it could fail. Especially the common pattern of forwarding 2300 (to mimictransfer) will not suffice if the callee tries to do storage reads or other now-expensive operations. This TIP will encourage users to adjust such patterns (or use utility functions that account for dynamic costs). - However, because TRON’s Energy model differs (users often pre-stake Energy or pay a fixed price), some Ethereum gas patterns (like exact 2300 stipend reliance) might be less common. Regardless, any contract assuming old opcode prices will need review.
To mitigate breakage, we can/will:
- Announce the planned changes well in advance to developers. Much like Ethereum did, provide tooling or simulation so developers can check their contracts against the new cost regime. Because Ethereum has gone through these changes (1884, 2929), many Solidity patterns have already been updated (e.g., using
SELFBALANCEinstead ofaddress(this).balance, avoiding deep SLOAD loops in a single transaction, etc.). TRON developers can benefit from that hindsight. - As an optional mitigation, if a contract is truly impacted by the cold access costs (2929 rules), TRON could introduce an Access List feature (similar to EIP-2930) allowing the sender to declare which addresses/keys will be accessed, thereby avoiding surprise costs. This is a separate TIP (not covered here in detail) but is mentioned as a path for backward compatibility in extreme cases. Access lists could help non-upgradable contracts that are on the verge of Energy limits by slightly reducing the new overhead when properly utilized.
- TRON’s committee-governed
energyPriceand Dynamic Energy Model could be used to offset increases if needed. For instance, if raising opcode costs across the board is making typical transactions too expensive for users, the network could vote to lowerenergyPrice(the TRX cost per Energy) to compensate, maintaining a balance in actual TRX fees. This doesn’t avoid the need for the repricing (which is for performance reasons), but it can cushion the economic impact on dApps.
In the worst case, some contracts might break or become cost-prohibitive under the new rules (as was the case in Ethereum’s similar upgrades). We believe this risk is manageable and outweighed by the security benefits. Many Ethereum contracts and tools are already designed with these gas costs in mind, so aligning TRON with them actually improves compatibility in the long run. During the Last Call and testnet phase, we will gather data on Energy usage changes and identify any critical contracts that need attention, allowing the community to patch or mitigate issues before mainnet activation.
Conclusion
This proposal establishes a formal specification of the TRON Virtual Machine and modernizes its opcode Energy costs. A unified TVM specification improves clarity, reduces ambiguity in execution semantics, and provides a stable foundation for client implementations, audits, and tooling.
Repricing underpriced operations aligns Energy consumption with real computational cost, improving network stability, security, and predictability as TRON’s state and usage continue to grow.
By aligning TVM behavior with proven EVM design principles where appropriate, this TIP improves interoperability and simplifies long-term maintenance without compromising TRON’s unique Energy and Bandwidth model.
The TRON developer community is encouraged to review this proposal, provide feedback, and participate in discussion on implementation details, edge cases, and potential migration considerations before finalization.