The GreatVoyage-v4.6.0 (Socrates) introduces several important optimizations and updates, such as an optimized database checkpoint mechanism, which improves the stability of node operation; optimized resource delegate relationship index structure, and an updated voting reward algorithm, which speed up the execution speed of transactions and increase network throughput; a new proposal to add transaction memo fees, increasing the cost of transactions with memo to reduce the number of low-value transactions, so that improves the security and reliability of the TRON network. The integrated toolkit, new network-related Prometheus metrics, and new help command line together bring users a more convenient development experience.
Please check below for details.
-In the TRON network, accounts can delegate resources to other accounts through staking, and can also accept resources that other accounts stake for themselves. Therefore, each account needs to maintain a record of the delegate relationship, including all the recipient addresses that the account delegated resources to and all the addresses that delegated resources for the account.
In versions prior to GreatVoyage-v4.6.0 (Socrates), the delegate relationship is stored in the form of a list. When performing resource delegating, it needs first to check whether the recipient account already exists in the list and then adds the account to the list only if it is not present. If a particular account has delegated resources to multiple accounts or many accounts have delegated the resources to the particular account, then the length of the delegate relationship list for the particular account will be substantial. The lookup operation would be considerably time-consuming, resulting in long transaction execution times.
@@ -2347,7 +2410,7 @@ ArchiveManifest.jar is an independent LevelDB startup optimization tool, which can optimize the file size of LevelDB manifest, thereby reducing memory usage and greatly improving node startup speed. Starting from the GreatVoyage-v4.6.0 (Socrates), the ArchiveManifest.jar tool has been integrated into the Toolkit.jar. In the future, all the tools around Java-tron will be gradually integrated into the Toolkit.jar toolbox to facilitate tool maintenance and developer use.
@@ -2406,7 +2469,7 @@ GreatVoyage-v4.5.2(Aurelius)
The GreatVoyage-v4.5.2 (Aurelius) version introduces several important optimizations. The optimized transaction cache mechanism greatly reduces memory usage and improves node performance; the optimized P2P node connection strategy improves the efficiency of establishing connections between nodes and speeds up the node synchronization process; the optimized block production and processing logic improve node stability; the newly added database storage partition tool reduces the pressure on data storage; the newly added block header query API and historical bandwidth unit price Query API are to bring users a more convenient development experience.
-Core
+Core
1. Optimize block processing
In versions prior to GreatVoyage-v4.5.2 (Aurelius), threads such as block production, block processing, and transaction processing compete for synchronization lock at the same time. In the case of high concurrency and transactions executing much time, the block production thread or the block processing thread will take a long time to get to the synchronization lock, which leads to the occurrence of a small probability of a block loss event. In order to improve node stability, the GreatVoyage-v4.5.2 (Aurelius) version optimizes the synchronization lock in the block processing logic, allowing only one transaction processing thread to compete for the synchronization lock with the block production or processing thread, and when the transaction processing thread finds that block-related threads waiting for the synchronization lock, it will voluntarily give in, which greatly increases the probability of block production and block processing threads acquiring synchronization lock, and ensures high throughput and stable operation of the node.
TIP: https://github.com/tronprotocol/tips/blob/master/tip-428.md
@@ -2440,7 +2503,7 @@
According to the bandwidth consumption rules, if the transaction initiator’s bandwidth obtained by staking TRX or free bandwidth is insufficient, TRX will be burned to pay for the bandwidth fee. At this time, only the bandwidth fee is recorded in the transaction record, but not the bandwidth consumption number. In order to understand bandwidth consumption of historical transactions, starting from GreatVoyage-v4.5.2 (Aurelius), a new historical bandwidth unit price query API /wallet/getbandwidthprices is added. Users can obtain historical records of bandwidth unit price through this API so that they can calculate bandwidth consumption of historical transactions.
Source Code：https://github.com/tronprotocol/java-tron/pull/4556
-Other Changes
+Other Changes
1. Optimize block synchronization logic
The GreatVoyage-v4.5.2 (Aurelius) version optimizes the block synchronization logic, avoids unnecessary node disconnection in the process of synchronizing blocks, and improves node stability.
Source Code：https://github.com/tronprotocol/java-tron/pull/4542
@@ -2458,7 +2521,7 @@
3. Enhance the fault tol
GreatVoyage-v4.5.1(Tertullian)
The GreatVoyage-v4.5.1(Tertullian) version introduces several important optimization updates. The optimized transaction cache loading process shortens the node startup time; the optimized block acquisition logic and light node synchronization logic promote the stability of the node; the optimized account asset structure and TVM cache structure improves the processing speed of transactions, thereby further improving the performance of node; supporting prometheus protocol interface brings users a more convenient development experience and helps to further prosper the TRON ecosystem.
-Core
+Core
1. Optimize transaction cache loading
In versions prior to GreatVoyage-v4.5.1 (Tertullian), it took a long time from node startup to block synchronization, and the loading of the transaction cache took up most of the node startup time. The transaction cache is used by the node to determine whether a transaction is a duplicate transaction, so during the node startup process, the transaction cache needs to be loaded from the database to the memory, and in versions prior to GreatVoyage-v4.5.1 (Tertullian), it adopts transaction as the storage unit to read the database when loading the transaction cache, so the amount of data to be read is large, and the entire reading process is time-consuming.
In order to speed up the startup of the node, the GreatVoyage-v4.5.1 (Tertullian) version optimizes the loading of the transaction cache. By adopting the block as the storage unit to read the database reduces the times of database reading, improves the efficiency of transaction cache loading, and improves the speed of node startup.
@@ -2487,7 +2550,7 @@ 7. Support node stop at spec
In order to facilitate node deployers to do data backup or data statistics, starting from the GreatVoyage-v4.5.1 (Tertullian) version, the node could stop running under specific conditions. Users can set the conditions for node stop through the node configuration file, such as the node stop’s block time, block height, and the number of blocks the node needs to synchronize from start to stop. The node will stop running automatically when the set conditions are met.
TIP: https://github.com/tronprotocol/tips/blob/master/tip-370.md
Source Code: https://github.com/tronprotocol/java-tron/pull/4325
-TVM
+TVM
1. Adjust the upper limit that can be set for the maximum execution time of TVM
"TVM maximum execution time" is a dynamic parameter of the TRON network, indicating the maximum time allowed for a smart contract to be executed. Super representatives can change this parameter through proposal voting. In versions prior to GreatVoyage-v4.5.1 (Tertullian), the maximum value that this parameter can be modified is 100ms. With the stability of the TRON network infrastructure and the vigorous development of the ecology, the 100ms upper limit confines the complexity of smart contracts. Therefore, GreatVoyage-v4.5.1 (Tertullian) version adds a new proposal that allows to raise the configurable upper limit of "TVM maximum execution time" to 400ms.
TIP: https://github.com/tronprotocol/tips/blob/master/tip-397.md
@@ -2501,7 +2564,7 @@
2. Optimize the cache structure o
GreatVoyage-v4.4.6(David)
GreatVoyage-v4.4.6 (David) updated the version of the dependency library fastjson to ensure the security of using fastjson.
-Other Changes
+Other Changes
1. Update the fastjson dependency library to the latest version
Due to security vulnerabilities in fastjson 1.2.80 and earlier versions, GreatVoyage-v4.4.6 (David) updated the version of the fastjson dependency library to 1.2.83, and enabled the safemode mode of fastjson to ensure the safety of using fastjson.
Source Code：https://github.com/tronprotocol/java-tron/pull/4393
@@ -2511,7 +2574,7 @@ 1. Updat
GreatVoyage-4.4.5(Cicero)
The GreatVoyage-v4.4.5 (Cicero) version optimizes the query interface of the node to filter out invalid fields, which ensures the stability of the interface for parsing data.
-Other Changes
+Other Changes
1. Optimize the query interface of the node
The GreatVoyage-v4.5.0 (Cicero) version optimizes the query interface of the node. When parsing the obtained data, the node will filter out invalid fields to ensure to return the correct interface data
Source Code：https://github.com/tronprotocol/java-tron/pull/4349
@@ -2521,7 +2584,7 @@ 1. Optimize the query interf
GreatVoyage-4.4.4(Plotinus)
The GreatVoyage-v4.4.4 (Plotinus) version introduces several important optimization updates, which reduces the node memory usage; speeds up node startup; Optimized network module, block production threads, improve the stability of nodes; Improved java-tron upgrade mechanism achieves more efficient decentralized governance; TVM supports multi-version program executors, which helps make it more compatible with EVM, brings users a more convenient development experience, and helps further flourish the TRON ecosystem.
-Core
+Core
1. Optimize node startup time
Before the GreatVoyage-v4.4.4 (Plotinus), the node will execute about a minute from startup to block synchronization. The block synchronization thread will first delay 30s to wait for the P2P thread to discover remote nodes, then establish TCP connection with the discovered nodes, and finally perform the block synchronization. This delay time occupies most of the startup time. In fact, every newly discovered node will be persisted to the local database, so there is no need to spend extra time waiting for the node to be discovered when node is started for the second time. So in the GreatVoyage-v4.4.4(Plotinus) version, the waiting time for node discovery has been reduced from 30s to 100ms to improve the speed of node startup.
TIP: https://github.com/tronprotocol/tips/blob/master/tip-366.md
@@ -2533,12 +2596,12 @@
2. Optimize memory usage
The GreatVoyage-v4.4.4 (Plotinus) version adds the interrupt exceptions handling in block-producing thread, so that when the block-producing node catches the interrupt instruction, it can exit safely.
Source Code：https://github.com/tronprotocol/java-tron/pull/4219
-TVM
+TVM
1. TVM support multi-version program-executors
In order to enable the TRON network to support various types of smart contract transactions in the future, starting from GreatVoyage-v4.4.4 (Plotinus), TVM code is refactored to support multi-version program executors, it will select different instruction set to interpret and execute the bytecode of smart contract according to the contract version information.
Source Code：https://github.com/tronprotocol/java-tron/pull/4257
https://github.com/tronprotocol/java-tron/pull/4259
-Other Changes
+Other Changes
1. Optimize log storage
The GreatVoyage-v4.4.4 (Plotinus) version modifies the node log retention time from 3 days to 7 days to facilitate users to troubleshoot issues.
Source Code：https://github.com/tronprotocol/java-tron/pull/4245
@@ -2554,7 +2617,7 @@ 3. improve the Java-tron upgr
GreatVoyage-4.4.2(Augustinus)
The GreatVoyage-v4.4.2(Augustinus) has three essential updates: The new execution model of opcode boosts the TVM performance; individualized LevelDB parameters improve the database performance; and the newly added log filter APIs make the JSON-RPC API more comprehensive.
-TVM
+TVM
1. TVM Opcode Execution Model Optimization
The opcode execution model of the interpreter in TVM is optimized in GreatVoyage-v4.4.2(Augustinus). The performance of TVM is proven to have a great boost through testing.
TIP: https://github.com/tronprotocol/tips/blob/master/tip-344.md
@@ -2564,7 +2627,7 @@
1. Newly Add
Log filter related APIs are available from GreatVoyage-v4.4.2 for compatibility with Ethereum JSON-RPC API.
TIP: https://github.com/tronprotocol/tips/issues/343
Source Code：https://github.com/tronprotocol/java-tron/pull/4153
-Other Changes
+Other Changes
Parameters of each LevelDB database have been individualized by the I/O frequencies from GreatVoyage-v4.4.2(Augustinus). This will significantly boost the database performance.
Source Code：https://github.com/tronprotocol/java-tron/pull/4154
@@ -2574,7 +2637,7 @@ The GreatVoyage-v4.4.0 (Rousseau) version introduces several important updates: the optimization of block broadcasting will let the block be broadcast to the entire network faster; the query performance optimization of dynamic store and the optimization of database parameters will be greatly improved Block processing speed, thereby improving the performance of java-tron; API customization in FullNode makes node configuration more flexible for different application scenarios; TVM will also be better compatible with EVM and adapt to the Ethereum London upgrade, the new JSON-RPC API will bring developers a better development experience, help developers to join the TRON ecosystem more easily, and promote the prosperity of the TRON ecosystem.
-Core
+Core
1. Optimize the block broadcasting
In the version before GreatVoyage-v4.4.0 (Rousseau), the logic of block processing is: verify block -> process block -> broadcast block. However, due to the long block processing time, there is a delay in block broadcasting. In order to speed up block broadcasting, In GreatVoyage-v4.4.0 (Rousseau) version, the block processing logic is changed to: verify block -> broadcast block -> process block, so that the block can be quickly broadcast to the entire network.
TIP: https://github.com/tronprotocol/tips/blob/master/tip-289.md
@@ -2590,7 +2653,7 @@
4. Optimize the parameters of
The GreatVoyage-v4.4.0 (Rousseau) version optimizes the parameters of the database, which improves the read and write performance of the database, thereby improving the efficiency of block processing.
Source Code：https://github.com/tronprotocol/java-tron/pull/4018
https://github.com/tronprotocol/java-tron/pull/3992
-TVM
+TVM
1. Provide compatibility with EVM
The GreatVoyage-v4.4.0 (Rousseau) version provides compatibility solution for those instructions that are different from EVM, so that the newly deployed contract supports the following features:
- The GASPRICE instruction returns the unit price of energy.
@@ -2639,7 +2702,7 @@
3. Optimize the quick start s
GreatVoyage-4.3.0(Bacon)
The release of GreatVoyage-v4.3.0 (Bacon) includes several significant optimization enhancements. The configurability of the parameters FREE_NET_LIMIT and TOTAL_NET_LIMIT will aid the TRON community in achieving improved on-chain governance; The addition of new TVM instructions and ABI types facilitates the use of smart contracts; the new cryptography library strengthens the TRON network's security; the optimization of the account data storage and transaction verification procedures increases transaction processing speed and block verification speed, greatly improving the TRON network's performance; node startup speed improvement will benefit customers and help the TRON ecosystem grow even further.
-Core
+Core
1. Add a proposal to adjust the free net limit in an account.
Prior to GreatVoyage-v4.3.0 (Bacon), the account's daily free bandwidth quota was fixed at 5000. The GreatVoyage-v4.3.0 (Bacon) version includes the #61 proposal FREE_NET_LIMIT, which allows for the customization of the free bandwidth quota. Super representatives and super partners may initiate a vote request for Proposal 61, which modifies the FREE_NET_LIMIT variable, which has the value [0, 100000].
@@ -2666,7 +2729,7 @@ 3. Optimize the Account Data Stru
NOTICE
By default, this feature is disabled, and the super representative or super partner will initiate a vote request to enable it in the future.
-TVM
+TVM
1. Add Vote Instructions and Precompile Contracts in TVM
Ordinary accounts can earn block rewards and voting rewards in versions prior to GreatVoyage-v4.3.0 (Bacon) by voting for super representatives or super representative candidates. However, because TVM does not accept voting instructions, TRX assets in smart contract accounts are unable to generate revenue via voting.
The GreatVoyage-v4.3.0 (Bacon) version adds voting instructions to TVM: VOTE / WITHDRAWBALANCE, allowing smart contract accounts to vote for super representatives or super representative candidates.
@@ -2763,7 +2826,7 @@ 3. Smart Contract ABI Storage
- TIP: TIP-268
- Source code: #3836
-
