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.

Differences from EVM

TVM is basically compatible with EVM with some differences in details

• TVM uses energy instead of gas. The energy price is currently 280 sun

• GASPRICE, DIFFICULTY and GASLIMIT return zero in TVM; BASEFEE is currently not supported

• Most opcodes in TVM have the equivalent energy consumption as in the EVM, some of them are lower(e.g., SLOAD, CALL)

• Contract address prefix created by CREATE2 is different from EVM: TVM chooses 0x41 as the prefix, the formula is keccak256( 0x41 ++ address ++ salt ++ keccak256(init_code))[12:]

• Pre-compiled contract Ripemd160(0x03): TVM calculates SHA-256 twice on the input. There will be a new pre-compiled contract to implement the standard Ripemd160

• Pre-compiled contract 0x09: EVM has Blake2F on this address; on TVM it is BatchValidateSign. See TIP-43

• There are two ways to send TRX to contracts: Transfer and TriggerSmartContract with a callValue. Transfer will not call fallback functions in the contracts

TVM has new features bases on TRON's characteristics

• TRC-10 related opcodes: CALLTOKEN(0xd0), TOKENBALANCE(0xd1), CALLTOKENVALUE(0xd2) and CALLTOKENID(0xd3)

• Judging whether an address belongs to a contract: ISCONTRACT(0xd4) TIP-44

• Batch validations for normal and multiple signatures: BatchValidateSign(0x09)TIP-43, ValidateMultiSign(0x0a)TIP-60

• Anonymous contract and Librustzcash related pre-compile contracts: verifyMintProof(0x1000001), verifyMintProof(0x1000002), verifyMintProof(0x1000003) and merkleHash(0x1000004). See TIP-135, TIP-137 and TIP-138.

• Freeze / Unfreeze functions: FREEZE(0xd5), UNFREEZE(0xd6) and FREEZEEXPIRETIME(0xd7). See TIP-157.

• Contract voting related opcodes and pre-compiled contracts: VOTEWITNESS(0xd8), WITHDRAWREWARD(0xd9), RewardBalance(0x1000006), IsSrCandidate(0x1000006), VoteCount(0x1000007), UsedVoteCount(0x1000008), ReceivedVoteCount(0x1000009) and TotalVoteCount(0x100000a). See TIP-271.

Compatible solutions are currently under discussion, if you are interested, please move to the GitHub ISSUE to participate in the discussion.

ISSUE-272

TIP-272