Proposal: Raise limit of the 13th network parameter

[fbsobreira]

Proposal: Raise limit of the 13th network parameter

Introduction

Enable #65(ALLOW_HIGHER_LIMIT_FOR_MAX_CPU_TIME_OF_ONE_TX) proposal, so that the limit for the 13th network parameter will be higher than current value.

Motivation

The 13th network parameter now ranges from 10 to 100 ms. This range currently may limit developers from designing more diverse and complex applications such as DeFi, GameFi, etc.

The larger range of the 13th network parameter will allow the community to easily upgrade it to a more suitable value in the future according to the actual needs of the developers.

For more details, please refer to: TIP-397.

Timeline

Any opinions or discussions about this proposal are welcomed in the next two weeks.

The estimated timeline

• Creation time of the voting request: 2th August 2022
• The effective time of voting request: 14:00, 5th August 2022

How to Initialize the Voting Request

This is the command of initiating the voting request

• CreateProposal 65 1

Technical Specs

After the #65(ALLOW_HIGHER_LIMIT_FOR_MAX_CPU_TIME_OF_ONE_TX) takes effect, the limit for the 13th network parameter will change from 100 ms to 400 ms.

Welcome to discuss.

[lsaaccome]

The current 100ms time limit is indeed a bit low, if for some complex business scenarios, especially for those gamefi products, the contract execution time needs to be more. If it can be raised to 400ms, it is undoubtedly a more great help to the development of Gamefi!

[sunflower-sun]

In the future, the 13th network parameter can be set to a larger value, and it is allowed to execute one transaction costing more time, will it affect the node performance? How to ensure all transactions can be processed in time?

[yanghang8612]

In the future, the 13th network parameter can be set to a larger value, and it is allowed to execute one transaction costing more time, will it affect the node performance? How to ensure all transactions can be processed in time?

Thanks for you reply.

Since the ratio of execution time to energy of individual instructions in TVM does not change, the performance of the nodes is not affected.

Longer execution time means more energy consumption and the initiator of time-consuming transactions will pay more transaction fees. This is reasonable.

Currently in TRON network, transactions are processed in order of the time it takes for them to arrive at each SR node. If there are many transactions waiting to be packed in the network, in the case that the processing capacity of the whole network is exceeded, then some transactions will be discarded. While time-consuming transactions may exacerbate the situation, the initiator of the transaction also pays a heavy price in transaction fees. Even if a transaction is discarded, the user can try to resend the transaction at no other cost.

[joker-gdb]

No doubt, this is an good improvement

[ethan1844]

Thanks to everyone's contribution to this proposal. This issue will be closed as it is already going to effect, check detail at: https://tronscan.org/#/proposal/73

[Birdza87]

.