Background

High performance has always been one of the core competencies of the TRON network. TVM, as the core smart contract execution environment for TRON, directly impacts transaction throughput, resource efficiency, and developer experience.

As the data scale in TRON continues to grow, currently reaching 2.7TB, it is crucial to understand how the increase in data volume affects the performance of TVM opcodes. Recent discussions have highlighted an execution time limit of 80ms for TVM. A systematic benchmark of TVM opcodes is necessary to determine whether this limit remains justified.

Furthermore, the Gas pricing design for TVM opcodes partially references the Gas pricing of EVM opcodes. However, the EVM has made adjustments to opcode gas pricing in several EIPs that have not yet been implemented in TVM. Conducting a benchmark of TVM opcodes may assist in correcting the gas prices for certain opcodes.

Related issues: #6266, #6288

Rationale

A benchmark of TVM opcode performance can provide the following benefits:

• Performance Optimization: A clear understanding of the performance of TVM opcodes will help developers optimize smart contracts, thereby improving overall network efficiency.
• Impact of Data Scale: As data scale increases, the performance of certain opcodes may be affected. A benchmark can reveal these potential issues.
• Reasonable Gas Pricing: Evaluating the reasonableness of Gas pricing for TVM opcodes can help mitigate the risk of DDoS attacks.

Specification

Several considerations for the benchmark include:

• Execution Count for Each Opcode: Each opcode should be executed a sufficient number of times to ensure the reliability and stability of the results.
• Data Scale Expansion: The benchmark should account for the expansion of data scale in the TRON network, recording performance changes for each opcode under varying data scales.

Implementation:

Here are some ideas for the benchmarking:

1. Sync Mainnet Transactions: Track event data for opcode execution time, aggregating performance data for every 10,000 blocks.
   • Pros: This method is easy to implement and can reveal the influence of data scale on opcode performance. It is based on real mainnet transactions, providing accurate insights.
   • Cons: Some opcodes may not be executed frequently enough in mainnet transactions. This method does not account for read-only request traffic and lacks flexibility.
2. Build Test Cases: Create various test cases covering different logical branch conditions and data scale for each opcode, executing each test case multiple times to collect performance data.
   • Pros: This method ensures that all opcodes are executed enough times to provide accurate performance data.
   • Cons: This approach is challenging to implement, as it requires substantial effort to build comprehensive test cases for each opcode and prepare different data scales.

Considering the input-output ratio, I currently prefer the first method, as it can effectively reveal the actual performance of TVM opcodes on the mainnet. For opcodes with poor execution times, we may consider switching to the second method for further analysis.

Additionally, to simulate future data scales, we should develop the capability to expand the database without interfering with normal block synchronization and transaction executions.

If you have any questions, ideas, or suggestions, please feel free to share and discuss them.