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.
+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 No. 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 No.82 proposal takes effect. It calculates the single-vote cumulative reward value of each super representative in each maintenance period before the No.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 No. 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 No. 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/issues/635
+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
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 enabled by default, and the threshold is 1000. Node deployers can also turn off this function or configure the threshold through the configuration file.
+node.unsolidifiedBlockCheck = true
+node.maxUnsolidifiedBlocks = 1000
+Source Code: https://github.com/tronprotocol/java-tron/pull/5643
+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
+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/issues/621
+Source Code: https://github.com/tronprotocol/java-tron/pull/5584
+https://github.com/tronprotocol/java-tron/pull/5667
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
+The Bias version bumps the jetty dependency library to v9.4.53.v20231009.
+Source Code: https://github.com/tronprotocol/java-tron/pull/5571
+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
+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=true
+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 lite
+Source Code: https://github.com/tronprotocol/java-tron/pull/5711
+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
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
+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
+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
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
+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
+Solon is a non-mandatory upgrade version that will introduce two important updates. A more stable HTTP interface and Lite FullNode data pruning tool bring users a more friendly development experience.
Please find the details below.
-In versions prior to Solon, there was a very small probability that an exception might be triggered when calling the /wallet/getnodeinfo interface due to the concurrent execution of block data object serialization. Therefore, the Solon version modified the serialization logic of block data to ensure the correctness of block data acquisition and make the /wallet/getnodeinfo interface more stable.
Source Code: https://github.com/tronprotocol/java-tron/pull/5594
@@ -1408,7 +1540,7 @@Chilon is a non-mandatory upgrade version that will introduce multiple important updates. Richer gRPC interfaces and faster node startup speed, bring users a more friendly development experience. Optimized disconnection strategy and synchronization process improve the stability of the connection among nodes. The optimized transaction processing logic and database query performance elevate the transaction packaging efficiency and network throughput.
Please find the details below.
-Chilon adds three new gRPC interfaces. Users can obtain historical bandwidth unit price through getBandwidthPrices API, obtain historical energy unit price through getEnergyPrices API, and obtain transaction memo fee through getMemoFee API. These new gRPC APIs further improve the developer experience.
TIP: https://github.com/tronprotocol/tips/blob/master/tip-586.md
@@ -1437,7 +1569,7 @@
In previous versions of Chilon, when the service is shut down, abnormal errors may occur
due to the resource release order issue. The Chilon version optimizes the service shutdown logic. When the kill -15 command is used to shut down the service, it can ensure the accuracy of the release sequence of various types of resources so that the node can exit normally.
Source Code: https://github.com/tronprotocol/java-tron/pull/5410 https://github.com/tronprotocol/java-tron/pull/5425 https://github.com/tronprotocol/java-tron/pull/5421 https://github.com/tronprotocol/java-tron/pull/5429 https://github.com/tronprotocol/java-tron/pull/5447
-Chilon optimizes the HTTP interface monitoring, it no longer counts requests for APIs that are not supported by the node, making the statistics of successful or failed HTTP interface requests more accurate.
Source Code: https://github.com/tronprotocol/java-tron/pull/5332
@@ -1456,7 +1588,7 @@The Chilon version optimizes some HTTP interfaces to make it consistent with get and post request processing, including parameters check and return value. The interfaces include /wallet/getavailableunfreezecount, /wallet/getcanwithdrawunfreezeamount, /wallet/getcandelegatedmaxsize, and /wallet/getavailableunfreezecount.
Source Code: https://github.com/tronprotocol/java-tron/pull/5408
-Chilon adds a check for expired transactions in the broadcast list it receives. For transactions timed out in the list, it will no longer make requests to its remote node, avoiding node connections being disconnected due to transaction processing failures, and improving node connection stability.
Source Code: https://github.com/tronprotocol/java-tron/pull/5460
@@ -1493,7 +1625,7 @@The Periander version introduces several important optimizations and updates, adding two governance proposals to optimize Stake 2.0, greatly improving the flexibility of the TRON stake mechanism; adding a governance proposal to implement EIP-3855 PUSH0 Instruction, which not only ensures the compatibility of TRON and Ethereum at the virtual machine level but also reduces the cost of using TRON smart contracts; more friendly smart contracts interfaces to improve the convenience of smart contract development; the P2P network module of TRON has been fully upgraded to support IPV6 protocol, node discovery via DNS, message compression, etc., greatly improving the performance of TRON network infrastructure.
Please see the details below.
-Libp2p is a Java version open-source P2P protocol framework developed by the Java-tron core developers and anyone can develop distributed applications with Libp2p, as the underlying P2P network of Java-tron is implemented based on Libp2p. In order to further improve the underlying network performance of Java-tron, Periander upgrades the Libp2p v0.1.4 with the v1.2.0 version.
Libp2p v1.2.0 has the following new features：
@@ -1636,7 +1768,7 @@Limiting the API access rate can not only effectively allocate node resources, but also ensure the stable running of a node. In previous versions of Periander, a rate limiter only affected a single interface. You can set the maximum number of accesses per second for an interface, the maximum number of accesses per second for an IP to this interface, and the number of concurrent accesses allowed to this interface. But there is no global rate limiter for all interfaces.
In addition to the original rate limit control function for individual interfaces, the Periander version adds a global rate limit for all interfaces. The overall traffic of all HTTP, gRPC and JSON-RPC interfaces can be limited through the configuration item rate.limiter.global.qps, and the access rate of an IP to all interfaces can be limited through rate.limiter.global.ip.qps.
Java-tron supports event subscription. In the previous version of Periander, if the solidified transaction event is subscribed, then when the node receives a new block, it would send the transaction information in the latest solidified block to the subscriber. If the network of most SR nodes is unstable, making them unable to synchronize and produce blocks in time, in this case, according to the calculation logic of the latest solidified block of the node, the height of the latest solidified block will not be guaranteed to increase by one each time. So that the latest obtained solidified block forwarded to the subscriber during event forwarding may not be the block next to the one that was forwarded the last time, resulting in data missing.
Since the conditions for this problem are very strict, it will basically not appear in the main network. However, to avoid this problem occurring in the test network or private chain, the Periander version optimizes the event forwarding logic in the event subscription and records the height of the solidified block forwarded last time, so when the node receives a new block, it will sequentially send the blocks after the last forwarded solidified block to the subscribers, ensuring the integrity of data forwarding.
@@ -1781,7 +1913,7 @@GreatVoyage-v4.7.1.1 (Pittacus) version optimized multiple interfaces and removed APIs involving sensitive information.
Please see the details below.
-Versions prior to GreatVoyage-v4.7.1.1 (Pittacus) provide APIs related to signature and address generation. Since the input or output of these APIs contains private keys, there are security risks in transmission in the network. At present, public API service providers in the TRON ecosystem have closed these APIs, such as TronGrid, Anker, GetBlock, etc. In the developer document, these APIs have already been tagged as obsolete and it is recommended to sign transactions and create addresses offline using SDK.
GreatVoyage-v4.7.1.1(Pittacus) officially removes these APIs:
@@ -1815,7 +1947,7 @@The /wallet/getdelegatedresourcev2 interface can query the resources that an address delegates to another address, and resource delegate can choose whether to be locked. For 2 resource delegation to the same address, one of them may be locked, and the other may be not locked, so /wallet/getdelegatedresourcev2 interface will return two sets of information: locked resource delegation data and unlocked resource delegation data. In versions prior to GreatVoyage-v4.7.1.1 (Pittacus), if all the resource delegation by one address to another address are locked, then the non-locked resource delegation data will be 0. In this case, the interface may also return non-locked resource delegation data (0 value which is meaningless). The GreatVoyage-v4.7.1.1 (Pittacus) version optimizes the /wallet/getdelegatedresourcev2 interface, and only returns resource delegation data with non-zero value, making the returned data more concise and clear.
Source Code: https://github.com/tronprotocol/java-tron/pull/5123
-origin_energy_usage field in the transaction receipt¶The TRON network supports contract deployers to share part of the contract call cost. In order to facilitate users to query the energy consumption of contract transactions, in addition to recording the total energy consumption of the transaction through the energy_usage_total field, the transaction receipt will also record the amount of energy paid by the contract deployer through the origin_energy_usage field. energy_usage_total contains origin_energy_usage.
In versions prior to GreatVoyage-v4.7.1.1 (Pittacus), in rare cases, the energy_usage_total field is 0 while the origin_energy_usage field is not 0 when querying through /wallet/gettransactioninfobyid API. Therefore the GreatVoyage-v4.7.1.1 (Pittacus) version optimizes the update logic of origin_energy_usage in the transaction receipt to ensure the accuracy of querying the consumed energy of the contract deployer.
Source code: https://github.com/tronprotocol/java-tron/pull/5009
The GreatVoyage-v4.7.1 (Sartre) version optimizes the lock mechanism during block synchronization and improves the stability of the node connection under concurrency.
Source code: https://github.com/tronprotocol/java-tron/pull/4996
-GreatVoyage-v4.7.1(Sartre) version deletes the useless solidified block query API to make the code more clearer.
Source code: https://github.com/tronprotocol/java-tron/pull/4997
GreatVoyage-v4.7.1 (Sartre) version optimizes the resource delegation relationship query API, adds the check to the interface parameters, and makes the interface more stable.
-In versions prior to GreatVoyage-v4.7.1 (Sartre), different modules of the node have different logics for detecting whether the current node is a LiteFullNode. GreatVoyage-v4.7.1 (Sartre) version unifies the logic of light node judgment, making the code more concise.
Source code: https://github.com/tronprotocol/java-tron/pull/4986
@@ -2045,7 +2177,7 @@GreatVoyage-v4.7.0.1 (Aristotle) adds 10 APIs to support Stake 2.0: