TRON Virtual Machine (TVM)
TVM is the runtime environment for TRON smart contracts, and each node in the network maintains a TVM entity.The TRON protocol keeps the continuous, uninterrupted, and immutable operation of this state machine. At any given block in the chain, TRON has one and only one 'canonical' state, and the TVM is what defines the rules for computing a new valid state from block to block.
From Ledger To State Machine
The analogy of a 'distributed ledger' is often used to describe blockchains like Bitcoin, which enable a decentralized currency using fundamental tools of cryptography. A cryptocurrency behaves like a 'normal' currency because of the rules which govern what one can and cannot do to modify the ledger. For example, a Bitcoin address cannot spend more Bitcoin than it has previously received. These rules underpin all transactions on Bitcoin.
While TRON has its own native cryptocurrency TRX that follows almost exactly the same intuitive rules, it also enables a much more powerful function: smart contracts. For this more complex feature, instead of a simple distributed ledger, TRON is a distributed state machine. TRON's state is a large data structure which holds not only all accounts information, but a machine state, which can change from block to block according to a pre-defined set of rules, and which can execute arbitrary machine code.
The State Transition Function
The TVM behaves as a mathematical function would: Given an input, it produces a deterministic output. It therefore is quite helpful to more formally describe TRON as having a state transition function:
Y(S, T) = S'
Given an old valid state (S) and a new set of valid transactions (T), the TRON state transition function Y(S, T) produces a new valid output state S'.
State
In the TRON network, the state is an enormous data structure called Merkle Trie, which keeps all accounts linked by hashes and reducible to a single root hash stored on the blockchain.
Transaction
Transactions are cryptographically signed instructions from accounts. They are divided into two categories, system contract transactions and smart contract transactions, in which smart contract transactions include those which result in contract message calls and those which result in contract creation.
Contract creation results in the creation of a new contract account containing compiled smart contract bytecode. Whenever another account makes a message call to that contract, it executes its bytecode in TVM.
TVM Instructions
The EVM executes as a stack machine with a depth of 1024 items. Each item is a 256-bit word, which was chosen for the ease of use with 256-bit cryptography (such as Keccak-256 hashes or secp256k1 signatures).
Compiled smart contract bytecode executes as a number of EVM opcodes, which perform standard stack operations like XOR, AND, ADD, SUB, etc. The EVM also implements a number of blockchain-specific stack operations, such as ADDRESS, BALANCE, BLOCKHASH, etc. More opcodes please refer to TRON opcodes
The below flowchart shows how TVM works:
The flow is as follows:
- The compiler compiles the smart contract into bytecode readable and executable on TVM.
- TVM processes data through opcode.
- TVM accesses blockchain data and invokes external data interfaces through the Interoperation layer.
- When TVM finishes execution , the status is written into the block, and the user can query the execution result and status through the API.
TVM vs EVM
The TRON Virtual Machine (TVM) exhibits fundamental compatibility with the Ethereum Virtual Machine (EVM), with notable distinctions in the following aspects:
- The TVM employs an Energy model instead of the Gas model.
energyPrice
is a network parameter (it can be changed by committee proposals), currently set at 210 SUN on Mainnet. Unlike the fluctuating Gas prices and the presence of abasefee
in the EVM, the TVM'sGASPRICE
andBASEFEE
opcodes both return theenergyPrice
. - The Energy consumption of the majority of TVM opcodes aligns with their EVM counterparts, with certain opcodes exhibiting lower Energy costs, such as
SLOAD
andCALL
. - The prefix for contract addresses generated via
CREATE2
in the TVM is different from the EVM. The TVM utilizes the0x41
prefix, determined by the formula (where ++ represents string concatenation):keccak256(0x41++ address ++ salt ++ keccak256(init_code))[12:]
- TRX can be transmitted to contracts through two mechanisms: standard transfers and
TriggerSmartContract
invocations carrying acallValue
. Standard transfers bypass the execution of the contract'sfallback
function.
Differences in Instructions
Instruction | TVM | EVM |
---|---|---|
DIFFICULTY (0x44) | Returns 0 | Returns the current block difficulty |
GASLIMIT (0x45) | Returns 0 | Returns the current block’s gaslimit |
GASPRICE (0x3A) | Returns energyPrice | Returns the current gasPrice |
BASEFEE (0x48) | Returns energyPrice | Returns the current block’s baseFee |
CREATE2 (0xf5) | Contract address prefix: 0x41 | Contract address prefix: 0xff |
Differences in Precompiled Contracts
Precompiled Contract Address | TVM | EVM |
---|---|---|
Ripemd160 (0x03) | Computes SHA-256 twice | Computes SHA-256 once |
0x09 | BatchValidateSign (used for batch signature verification) | Blake2F |
New Features of the TVM
Instructions
Instruction | Function |
---|---|
TRC-10 | |
CALLTOKEN (0xd0) |
Invokes contract with TRC-10 token |
TOKENBALANCE (0xd1) |
Queries the balance of TRC-10 token for an address |
CALLTOKENVALUE (0xd2) |
Retrieves the TRC-10 token value associated with the current call |
CALLTOKENID (0xd3) |
Retrieves the ID of the TRC-10 token involved in the current call |
TIP-44 | |
ISCONTRACT (0xd4) |
Checks if a given address is a contract address |
TIP-157 freeze/Unfreeze Functions | |
FREEZE (0xd5) |
Stake TRX to acquire resources |
UNFREEZE (0xd6) |
Unstake TRX, releasing acquired resources |
FREEZEEXPIRETIME (0xd7) |
Queries the expiration time of a FREEZE operation |
TIP-467 freezeV2/UnfreezeV2 Functions | |
FREEZEBALANCEV2 (0xda) |
Stake TRX to acquire resources (V2) |
UNFREEZEBALANCEV2 (0xdb) |
Unstake TRX, releasing acquired resources (V2) |
CANCELALLUNFREEZEV2 (0xdc) |
Cancels all pending UNFREEZE operations (V2) |
WITHDRAWEXPIREUNFREEZE (0xdd) |
Withdraws expired unstaked TRX |
DELEGATERESOURCE (0xde) |
Delegates resources to another address |
UNDELEGATERESOURCE (0xdf) |
Cancels resource delegation |
TIP-721 Contract Voting Related Functions | |
VOTEWITNESS (0xd8) |
Votes for a Super Representative |
WITHDRAWREWARD (0xd9) |
Withdraws accumulated voting rewards |
Precompiled Contracts
Precompiled Contract | Function |
---|---|
TIP-60 | |
ValidateMultiSign (0x0a) |
Multi-signature verification |
TIP-43 | |
BatchValidateSign (0x09) |
Batch signature verification |
Shielded Contract-Related Functions TIP-135: Shielded TRC-20 Contract TIP-137: Zero-knowledge Proof (ZKP) Verification Functions TIP-138: Pedersen Hash Function |
|
verifyMintProof (0x1000001) |
Verifies the validity of ZKP when transforming the public TRC-20 token into shielded tokens. |
verifyTransferProof (0x1000002) |
Verifies the validity of ZKP for shielded tokens transactions |
verifyBurnProof (0x1000003) |
Verifies the validity of ZKP when transforming the shielded tokens back to public TRC-20 tokens. |
TIP-271 Contract Voting-Related Functions | |
RewardBalance (0x1000005) |
Retrieves voting reward balance |
IsSrCandidate (0x1000006) |
Queries whether an address is an srCandidate |
VoteCount (0x1000007) |
Queries the number of votes a certain address has given to a certain Witness |
TIP-467 freezeV2/UnfreezeV2 Functions | |
GetChainParameter (0x100000b) |
Queries the specified chain parameters |
AvailableUnfreezeV2Size (0x100000c) |
Queries the available length of the unfreeze queue for the target address (V2) |
UnfreezableBalanceV2 (0x100000d) |
Queries the unfreezable balance of the specified resource type for the target address (V2) |
ExpireUnfreezeBalanceV2 (0x100000e) |
Queries the withdrawable amount at a specified timestamp for a target address (V2) |
DelegatableResource (0x100000f) |
Queries the delegatable amount of the specified resource type for the target address |
ResourceV2 (0x1000010) |
Queries the amount of the specified resource type delegated from the specified address to the target address (V2) |
CheckUnDelegateResource (0x1000011) |
Checks whether the contract can reclaim the specified amount of resources of a specific resource type that have been delegated to the target address |
ResourceUsage (0x1000012) |
Queries the usage and recovery time of the specified resource type for the target address. |
TotalResource (0x1000013) |
Queries the total amount of available resources of the specified resource type for the target address |
TotalDelegatedResource (0x1000014) |
Queries the amount of delegated resources of a specified resource type for the target address |
TotalAcquiredResource (0x1000015) |
Queries the total amount of the specified resource type acquired by the target address through delegation |
Discussions regarding compatible solutions are ongoing. Participate in the current discussions on GitHub Issues.
Updated 11 days ago