Repository navigation
Build a benchmark of data growth impact on TVM opcodes #6292
Description
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.
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:
- 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.
- 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.
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
lxcmyf commentedon Apr 20, 2025
leonway336 commentedon Apr 21, 2025
In the database design of
java-tron, different types of data are dispersed in different databases, and the whole huge full amount of data is not actually accessed during TVM execution.At the same time, the
k-vstorage structure used in the various databases ofjava-tronmeans that when trying to access the value corresponding to a certain key, the actual overhead only consists of accessing the database file to read the data, deserializing the protobuf structure, and so on.Am I right?
kongchi-ken commentedon Apr 21, 2025
kongchi-ken commentedon Apr 21, 2025
Thank you for your time. Yes, you are right. The
java-tronstorage design is some kind of flatten, so it doesn't require multiple visits to the databse to get to the data, regardless of the data scale.However, the data size may affect the performance of the underlying storage engine (LevelDB or RocksDB), and the time taken to access the data once may vary a lot at different data sizes. That's why I think a benchmarking at different data scale is neccesary.
[-]Build a Benchmark of TVM Opcodes Performance[/-][+]Build a benchmark of data growth impact on TVM opcodes [/+]FriendlyCM commentedon May 29, 2025
Hi, will you test all opcodes in this banchmark? Cloud you add more tests for these two situations:
I think these test results will be great helpful for Expand ARM Architecture Compatibility #5954 and Upgrade to JDK 17 for ARM Architecture #5976
kongchi-ken commentedon May 30, 2025
Yes, we will test all opcodes, especially those related to DB data scales.
I think it's a good idea to extend the test situation to JDK17 and ARM platform, as java-tron is working on upgrade to JDK 17. We will take them into consideration.
undertaker86001 commentedon Jun 13, 2025
design: https://uke4ml20ix.feishu.cn/docx/RIk3dnarwozQbYxk7o4cH3bHnjb?from=from_copylink
kongchi-ken commentedon Jun 13, 2025
Thank you for your time.
We will check the design in detail. If you have any other suggestions, please feel free to comment.
3 remaining items
kongchi-ken commentedon Jul 11, 2025
In our performance testing on X86 and ARM platforms, there isn't much performance difference between these two platforms.
The cpu benchmark (sysbench cpu --cpu-max-prime=20000 --threads=1) shows the single core computility is around 1600 on X86 and around 1100 on ARM for our test machines. Our experiments show that the execution on X86 is slightly faster than ARM and the ratio on the two platforms is 1:1.3. Considering the cpu benchmark difference of these machines, we think the performance of java-tron on X86 and ARM platform are basically on the same level.
FriendlyCM commentedon Jul 15, 2025
Very glad to see this — thank you for the work!
If there’s any abnormal situation, please leave a comment here.
undertaker86001 commentedon Oct 29, 2025
Hello, I haven't been using the Tron protocol for a long time. I would like to try some issues to understand the protocol itself. Could you recommend some issues to me?
halibobo1205 commentedon Oct 29, 2025
@undertaker86001 Hi, you can refer to https://developers.tron.network/docs/getting-start.
ferdinand026 commentedon Mar 19, 2026
With the successful release of 4.8.1, I was wondering if there’s been any further movement on this issue. Looking forward to your updates!
kongchi-ken commentedon Mar 20, 2026
Thanks for following up! 🙌
Yes, work on this is actively in progress. With 4.8.1 now out, we'll be basing the benchmark implementation on that release as our stable foundation. Any meaningful findings or incremental progress will be shared directly in this issue, so feel free to subscribe for updates.
Appreciate the interest — stay tuned!
halibobo1205 commentedon May 15, 2026
@kongchi-ken 4.8.2 is currently in its testing phase — just wanted to check whether there's any incremental benchmark data from the past couple of months you could share here?
yanghang8612 commentedon May 15, 2026
@halibobo1205 Thanks for checking in.
Since I am now assigned to this issue, I will keep it open as an ongoing tracker for TVM opcode performance benchmarking and stress testing, especially around data-scale growth, JDK versions, and platform architecture comparisons.
For the 4.8.2 testing cycle, I will continue following the benchmark results and check whether there is any meaningful incremental data from recent runs that can be shared. At the moment, there is no consolidated benchmark report ready to publish yet. If we identify abnormal performance behavior or get shareable incremental results, I will update this issue here.
cc @kongchi-ken in case there are additional recent benchmark results from the previous experiments.
yanghang8612 commentedon May 29, 2026
Progress update on the TVM opcode data-growth benchmark.
Status: the benchmark harness is being set up against the 4.8.2 (Pyrrho) codebase as the stable baseline. Scope being measured:
SLOAD/SSTORE,BALANCE,EXTCODESIZE/EXTCODEHASH/EXTCODECOPY, and the*CALLfamily — plus the MODEXP precompile path given the concurrent TIP-7823/7883 work.No consolidated report to publish yet — I don't want to post partial numbers that could be misread before the methodology is locked and runs are repeated for variance. Once the 4.8.2 testing cycle produces stable, repeatable measurements, I'll post the results and methodology here.
yanghang8612 commentedon Sep 3, 2026
The earlier x86 and ARM testing addressed the platform-comparison part of this issue, but the broader objective remains measuring how increasing state size affects database-sensitive TVM opcodes. We will therefore keep this issue open as a long-term benchmark tracker.
With java-tron 4.8.2 now available, the current benchmark work will use it as the stable baseline. Before publishing a consolidated report, the methodology still needs to be made reproducible across data scales, storage engines, JDK versions, and x86/ARM environments. The initial focus remains on state-access-heavy opcodes such as
SLOAD/SSTORE,BALANCE,EXTCODE*, and the*CALLfamily, together with relevant precompile paths.There is no consolidated dataset ready to publish yet. Once the methodology is stable and the measurements are repeatable, we will share both the test setup and results here.