Proposal: Adjust the maximum execution time limit of TVM

[yanghang8612]

Background

The goal of TRON network when it was first launched is to provide high TPS and high stability. TRON network generates block every 3 seconds.

When TVM was enabled for TRON network, we introduced a maximum execution time limit of TVM in order to maintain the stability and high TPS of the network.

Motivation

The biggest difference between TRON and the current mainstream public chains in handling smart contract transactions is the maximum execution time mechanism in TVM.

Define SC to represent smart contract.

Define MET to represent maximum execution time.

The MET for a SC transaction is currently controlled by the 13th network parameter named MAX_CPU_TIME_OF_ONE_TX, and the community can initiate a proposal to modify this parameter. However its current legal range is from 10 to 100 ms.

With the increasing stability of TRON network infrastructure and the development of various SC-related ecologies, the current MET mechanism in TVM has more or less limited the diversity and complexity of SC transactions in different application domains.

Therefore, in this issue, we explore how to gradually adjust the MET limit of TVM.

Specifications

To ensure a smooth transition to a stage where TVM no longer have a MET limit, we intend to achieve this goal in three steps.

• First, raise the legal upper limit of the 13th network parameter. This will require a hard fork to achieve.

• Second, when the upper limit of the 13th network parameter is raised, the community can initiate a proposal to set the 13th network parameter to a larger appropriate value (but less than the current time of 750ms for SR's packaged transactions). After the proposal takes effect, observe the network status for a period of time.

• Finally, as the network runs smoothly after the proposal takes effect, then consideration can be given to removing the TVM maximum execution time limit altogether. This will also require a hard fork to achieve.

Implementation

TODO.

Backwards Compatibility

There are no known backward compatibility issues.

Security Considerations

Removing the TVM's MET limit could lead to a potential extra-long smart contract transaction attack against SRs, meaning that the SR misses a block due to exceeding its packaged transaction time when executing this special transaction. However, benefiting from the current good energy model design of TVM and the design of the TRON network, this attack vector is currently difficult and very expensive to reach.

--- Updated at 04.06:

We have launched a new TIP-397 to achieve the first of these steps.

[vita-coffee]

I have two questions about this proposal.

• First of all, the block time of TRON is 3 seconds per block, but the maximum value mentioned in the proposal is 750ms. why? Can it be set longer?

• Second, can you show us what is the meaning of this maximum execution time with more specific data? For example, for a 16C 32M machine, how many times the for loop can be executed within 80ms, and how many times it will become after raising it to 750ms. Or with a specific example, calling USDT transfer in the contract, how many times can be executed in 80ms, and how many times can be executed in 750, thanks.

This would help all the developers to understand it more easily. thanks.

[yanghang8612]

@lakfly This is one of our concerns and will be actively discussed by the community.

[yanghang8612]

I have two questions about this proposal.

• First of all, the block time of TRON is 3 seconds per block, but the maximum value mentioned in the proposal is 750ms. why? Can it be set longer?
• Second, can you show us what is the meaning of this maximum execution time with more specific data? For example, for a 16C 32M machine, how many times the for loop can be executed within 80ms, and how many times it will become after raising it to 750ms. Or with a specific example, calling USDT transfer in the contract, how many times can be executed in 80ms, and how many times can be executed in 750, thanks.

This would help all the developers to understand it more easily. thanks.

For the first question, the upper limit cannot be set larger. This is because in a 3-second period, the super node needs to generate a block and broadcast it to the network in half the time. During the block production time, the super node not only needs to pack the pending transactions to generate a new block, but also needs to persist the newly generated block. So the super node has only 750ms(3000ms / 2 / 2) to pack the pending transactions. Therefore the upper limit of MET cannot be higher than 750ms.
For the second question, we will be conducting a series of performance tests in the near future.

[vita-coffee]

thanks for your clarification, it really helps.

One more question, if the max execution time changed to 750ms via proposal. as I know, SR will execute the transaction during packaging. In extreme cases, such as my contract is very complex, the execution time is just around 750ms. so if the position of my transaction is at the bottom of the pending list, it will have very low chance to be fully executed, right?

Have you considered what I said? please correct me if I am wrong. thanks.

[yanghang8612]

thanks for your clarification, it really helps.

One more question, if the max execution time changed to 750ms via proposal. as I know, SR will execute the transaction during packaging. In extreme cases, such as my contract is very complex, the execution time is just around 750ms. so if the position of my transaction is at the bottom of the pending list, it will have very low chance to be fully executed, right?

Have you considered what I said? please correct me if I am wrong. thanks.

First, proposal to raise the value of the 13th network parameter must be done very carefully, and the community needs to evaluate in detail the various impacts it will have.

Second, even if a transaction is at the back of the queue and cannot be packaged in time, after a few blocks, your transaction will be at the front of the queue and it will then be ready to be packaged.

[vita-coffee]

Thanks for your clarification, i donot mean the attack, just from normal use case point of view.

[diwu1989]

The timing seem very arbitrary, what CPU are you using on the main validator nodes?
The TVM is basically a single threaded opcode interpreter, so you really should be using extremely high frequency CPU cores to maximize the amount of smart contract bytecode executed.

Are the validators running on Aliyun G7 AMD Epyc Milan instances or the Intel IceLake instances? Or earlier G6 instances?

[yanghang8612]

The timing seem very arbitrary, what CPU are you using on the main validator nodes? The TVM is basically a single threaded opcode interpreter, so you really should be using extremely high frequency CPU cores to maximize the amount of smart contract bytecode executed.

Are the validators running on Aliyun G7 AMD Epyc Milan instances or the Intel IceLake instances? Or earlier G6 instances?

We do not know the machine configuration of the node on which the validators is running, which is not publicly available.
Of course if the validators use machine with higher CPU frequency, the opcodes that can be executed in a single smart contract transaction will be boosted somewhat.
The community is currently discussing raising the legal upper limit of the 13th network parameter, not raising its own value.

[yuekun0707]

Hi, for this proposal, is it possible that we limit the resources that one transaction can consume to archive the goal to limiting the time of one transaction? Thus we don't need the limit of the 13th network parameter in the future.
But to do this, firstly we need to confirm whether every OP has a certain execution time, if yes, we can limit the number of OPs one transaction can do, then get the maximum resources according to OPs.

[CarlChaoCarl]

Hello，we can discuss whether it's feasible to increase the execution timeout for individual operations (ops) while still limiting the overall execution timeout for smart contract transactions.