Mainnet Bias Announcement
The TRON developer community has released the GreatVoyage-v4.7.4(Bias) version. This is a mandatory upgrade. Please finish your upgrade to the new version by 23:59, April 3rd, 2024 (SGT).
The Bias version introduces several important optimizations and updates, including a new proposal to optimize the performance of voting reward withdrawal; the refactored Gradle dependency reduces the complexity of core protocol development; support for gRPC reflection services and optimized logging system brings a more friendly and convenient development experience to users. Please find the details below.
Core
1. Optimize voting reward withdrawal performance
TIP-465 aims to improve the calculation performance of TRON voting rewards. By recording the single-vote cumulative reward value of each super representative in each maintenance period, the time complexity of voting reward calculation can be reduced from linear time to constant time. The TIP-465 has been implemented as early as the Socrates version, and №82 proposal based on TIP-465 has been officially adopted at 2023–01–20 14:00:00. However, this proposal only optimizes the calculation performance of voting rewards generated after the proposal takes effect (constant time complexity), while the calculation performance of voting rewards generated before the proposal takes effect is still low (linear time complexity).
The Bias version optimizes the calculation performance of voting rewards generated before the №82 proposal takes effect. It calculates the single-vote cumulative reward value of each super representative in each maintenance period before the №82 proposal takes effect in advance through background tasks, and saves the calculation results to the database. This will make the calculation performance of voting rewards generated before and after the №82 proposal takes effect consistent, so that any transaction involving reward withdrawal can complete the reward calculation within a constant time, speeding up the execution speed of transactions related to voting rewards withdrawal, improving network throughput.
This optimization is the №79 parameter of the TRON network. After Bias is deployed, it is turned off by default and can be enabled through governance voting.
TIP: https://github.com/tronprotocol/tips/blob/master/tip-635.md
Source Code: https://github.com/tronprotocol/java-tron/pull/5406 https://github.com/tronprotocol/java-tron/pull/5654 https://github.com/tronprotocol/java-tron/pull/5683 https://github.com/tronprotocol/java-tron/pull/5742 https://github.com/tronprotocol/java-tron/pull/5748
2. Add check function for the number of unsolidified blocks
The block solidification mechanism of the TRON network is: a block can be solidified only after it is confirmed by 70% of the super representatives, that is, the block data is written to the disk and the data cannot be changed. Blocks that cannot be solidified are always stored in memory. If the number of unsolidified blocks continues to increase, it may cause memory exhaustion and the node to stop running.
The Bias version adds a check function for the number of unsolidified blocks. When it is detected that the number of unsolidified blocks of a node reaches the threshold, the node will stop broadcasting transactions to avoid too many transactions that cannot be solidified in the network. This can not only reduce the node’s memory usage, but also reduce the number of transactions in the block, improve the block execution speed, and facilitate the rapid recovery of the network in the later period..
This feature is disabled by default. Node deployers can also turn on this function or configure the threshold through the configuration file.
node.unsolidifiedBlockCheck = true
node.maxUnsolidifiedBlocks = 54Source Code: https://github.com/tronprotocol/java-tron/pull/5643
API
1. Supply BLOCK_UNSOLIDIFIED in code for /wallet/broadcasttransaction API
The Bias version adds a check function for the number of unsolidified blocks. When it is detected that the number of unsolidified blocks of a node reaches the threshold, the node will stop broadcasting transactions. In order to provide better feedback on the node status, the Bias version adds a new return code BLOCK_UNSOLIDIFIED for the /wallet/broadcasttransaction API. This code indicates that the node has too many unsolidified blocks and the number has exceeded the threshold, the node cannot broadcast the transaction.
Source Code: https://github.com/tronprotocol/java-tron/pull/5643
Other Changes
1. Add field codeVersion to HelloMessage to declare code version
Bias adds a new field codeVersion representing version information in the HelloMessage message, so that nodes can obtain the version information of the other node during the node discovery phase, which is beneficial to troubleshooting and locating problems later.
TIP: https://github.com/tronprotocol/tips/blob/master/tip-621.md
Source Code: https://github.com/tronprotocol/java-tron/pull/5584 https://github.com/tronprotocol/java-tron/pull/5667
2. Bump libp2p to version 2.2.1
Bias upgrades the network module to libp2p v2.2.1. The main contents of this version include: bump snappy-java dependency library to v1.1.10.5, add LAN IP acquisition logic, optimize handshake logic, and adjust some log levels.
Source Code: https://github.com/tronprotocol/java-tron/pull/5692
3. Bump jetty to 9.4.53.v20231009
The Bias version bumps the jetty dependency library to v9.4.53.v20231009.
Source Code: https://github.com/tronprotocol/java-tron/pull/5571
4. Refactor Gradle dependencies
The Java-tron code is divided into multiple modules, each module has its own dependencies, but currently there are situations where dependencies are declared multiple times in multiple modules. The Bias version reconstructs the Gradle dependencies of each module and deletes duplicate dependency statements, making the code dependencies clearer and enabling unified management of dependencies to reduce maintenance costs.
Source Code: https://github.com/tronprotocol/java-tron/pull/5625
5. Provide gRPC reflection service
Starting from the Bias version, the gRPC reflection service is supported. Users can directly use the gRPCurl command line tool to make the gPRC interface calls, which improves the ease of use of the gRPC interface.
This feature needs to be enabled through the following configuration items:
node.rpc.reflectionService=trueSource Code: https://github.com/tronprotocol/java-tron/pull/5583
6. Delete the LiteFullNodeTool related code under the framework module
In order to facilitate tool maintenance and developer use, TRON has launched the Toolkit.jar toolbox, which includes various TRON development tools. As early as the Aristotle version, the code related to the LiteFullNode data clipping tool has been integrated into the Toolkit toolbox (located under the plugin module), and Tookit can completely replace LiteFullNodeTool (located under the framework module). Therefore, the Bias version deletes the LiteFullNodeTool related code under the framework module, which not only reduces code redundancy, but also makes the division of functional modules clearer. The commands to use the LiteFullNode data pruning function in the Toolkit are as follows:
java -jar Toolkit.jar db liteSource Code: https://github.com/tronprotocol/java-tron/pull/5711
7. Remove configuration item node.discovery.bind.ip
Bias upgrades libp2p to v2.2.1. That makes the node can obtain the node LAN IP directly through libp2p without manual configuration by the deployer. Therefore, the Bias version deletes the no longer used configuration item node.discovery.bind.ip, simplifying the configuration complexity.
Source Code: https://github.com/tronprotocol/java-tron/pull/5597 https://github.com/tronprotocol/java-tron/pull/5750
8. Remove redundant CI scripts
The Bias version removes project build scripts that are no longer used, including checkStyle.sh, codecov.sh, querySonar.sh, sonar.sh.
Source Code: https://github.com/tronprotocol/java-tron/pull/5580
9. Initialize the API service first during the node startup
The Bias version adjusts the start order of each service, starts the node API service first, and then starts the P2P service and consensus service. This prevents the API service port from being occupied by other services.
Source Code: https://github.com/tronprotocol/java-tron/pull/5711
10. Optimize log
The Bias version optimizes node logs, adjusts some log levels according to business logic, simplifies expected exception logs, and elaborates unexpected exception logs to facilitate problem location.
Source Code: https://github.com/tronprotocol/java-tron/pull/5624 https://github.com/tronprotocol/java-tron/pull/5601 https://github.com/tronprotocol/java-tron/pull/5660 https://github.com/tronprotocol/java-tron/pull/5687 https://github.com/tronprotocol/java-tron/pull/5697
11. Add synchronization control when writing to ZeroMQ
Java-tron supports subscribing to events through the built-in ZeroMQ message queue. However, when multiple threads concurrently send events to the ZeroMQ, write exception errors may occur. The Bias version adds synchronization control when writing to ZeroMQ, ensuring the order of concurrent access between threads.
Source Code: https://github.com/tronprotocol/java-tron/pull/5536
12.Optimize unexpected exception capture process of scalingFactor in /wallet/createshieldedcontractparameters API.
The Bias version optimizes the /wallet/createshieldedcontractparameters interface and adds a legality check for the anonymous contract scaling factor parameter scalingFactor, which must be a positive integer.
Source Code: https://github.com/tronprotocol/java-tron/pull/5746
Be slow in considering, but resolute in action. — — Bias
