Skip to content

History

Code Name Version Released Incl TIPs Release Note Specs
Kant GreatVoyage-v4.8.0 2025-04-29 TIP-650
TIP-651
TIP-694
TIP-697
TIP-745		 Release Note Specs
Epicurus GreatVoyage-v4.7.7 2024-11-29 TIP-697 Release Note Specs
Anaximander GreatVoyage-v4.7.6 2024-10-04 N/A Release Note Specs
Cleobulus GreatVoyage-v4.7.5 2024-5-30 TIP-653 Release Note Specs
Bias GreatVoyage-v4.7.4 2024-3-15 TIP-635
TIP-621		 Release Note Specs
Solon GreatVoyage-v4.7.3.1 2024-1-12 N/A Release Note Specs
Chilon GreatVoyage-v4.7.3 2023-10-25 TIP-586
TIP-592		 Release Note Specs
Periander GreatVoyage-v4.7.2 2023-7-1 TIP-541
TIP-542
TIP-543
TIP-544
TIP-555
TIP-547
TIP-548
TIP-549
TIP-550		 Release Note Specs
Pittacus GreatVoyage-v4.7.1.1 2023-4-17 TIP-534 Release Note Specs
Sartre GreatVoyage-v4.7.1 2023-2-27 N/A Release Note Specs
Aristotle GreatVoyage-v4.7.0.1 2023-1-20 TIP-467
TIP-474
TIP-491		 Release Note Specs
Socrates GreatVoyage-v4.6.0 2022-11-21 TIP-387
TIP-461
TIP-465
TIP-476		 Release Note Specs
Aurelius GreatVoyage-v4.5.2 2022-8-18 TIP-425
TIP-428
TIP-440		 Release Note Specs
Tertullian GreatVoyage-v4.5.1 2022-1-19 TIP-391
TIP-388
TIP-383
TIP-382
TIP-370
TIP-369
TIP-397		 Release Note Specs
David GreatVoyage-v4.4.6 2022-5-25 N/A Release Note Specs
Cicero GreatVoyage-4.4.5 2022-4-27 N/A Release Note Specs
Plotinus GreatVoyage-4.4.4 2022-2-22 TIP-362
TIP-366		 Release Note Specs
Pythagoras GreatVoyage-4.4.3 2021-12-17 N/A Release Note N/A
Augustinus GreatVoyage-4.4.2 2021-12-16 TIP-343
TIP-344		 Release Note Specs
Protagoras GreatVoyage-4.4.1 2021-10-19 N/A Release Note N/A
Rousseau GreatVoyage-4.4.0 2021-10-15 TIP-289
TIP-290
TIP-272
TIP-318		 Release Note Specs
Bacon GreatVoyage-4.3.0 2021-8-3 TIP-292
TIP-293
TIP-295
TIP-271
TIP-306		 Release Note Specs
Epictetus GreatVoyage-4.2.2.1 2021-6-25 N/A Release Note Specs
Lucretius GreatVoyage-4.2.2 2021-6-22 TIP-268
TIP-269
TIP-281		 Release Note Specs
Origen GreatVoyage-4.2.1 2021-5-22 N/A Release Note N/A
Plato GreatVoyage-4.2.0 2021-4-27 TIP-157
TIP-207		 Release Note Specs
Thales GreatVoyage-4.1.3 2021-3-18 TIP-238 Release Note Specs
N/A GreatVoyage-4.1.2 2021-1-20 TIP-196
TIP-204
TIP-209		 Release Note Specs
N/A GreatVoyage-4.1.1 2020-11-9 N/A Release Note Specs
N/A GreatVoyage-v4.1.0 2020-11-2 TIP-127
TIP-128
TIP-174
TIP-175
TIP-176		 Release Note N/A
N/A GreatVoyage-v4.0.2 2020-11-2 N/A Release Note N/A
N/A GreatVoyage-v4.0.1 2020-3-17 N/A Release Note N/A
N/A GreatVoyage-4.0.0 2020-7-7 TIP-135
TIP-137
TIP-138		 Release Note Specs
N/A Odyssey-v3.7 2020-3-17 N/A Release Note Specs
N/A Odyssey-v3.6.5 2019-10-8 TIP-37
TIP-43
TIP-44
TIP-53
TIP-54
TIP-60		 Release Note Specs
N/A Odyssey-v3.6.2 2019-8-8 N/A Release Note N/A
N/A Odyssey-v3.6.1 2019-7-10 TIP-41 Release Note N/A
N/A Odyssey-v3.6.0 2019-6-20 TIP-26
TIP-28
TIP-29
TIP-30
TIP-31
TIP-32		 Release Note N/A
N/A Odyssey-v3.5.1 2019-4-10 N/A Release Note N/A
N/A Odyssey-v3.5.0.1 2019-3-1 N/A Release Note N/A
N/A Odyssey-v3.5 2019-3-1 N/A Release Note N/A
N/A Odyssey-v3.2.5 2019-1-25 N/A Release Note N/A
N/A Odyssey-v3.2.4 2019-1-14 N/A Release Note N/A
N/A Odyssey-v3.2.3 2018-12-24 N/A Release Note N/A
N/A Odyssey-v3.2.2 2018-12-17 N/A Release Note N/A
N/A Odyssey-v3.2.1.2 2018-12-7 N/A Release Note N/A
N/A Odyssey-v3.2.1 2018-11-30 N/A Release Note N/A
N/A Odyssey-v3.2 2018-11-30 N/A Release Note N/A
N/A Odyssey-v3.1.3 2018-10-19 N/A Release Note N/A
N/A Odyssey-v3.1.2 2018-10-12 N/A Release Note N/A
N/A Odyssey-v3.1.1 2018-9-17 N/A Release Note N/A
N/A Odyssey-v3.1.0 2018-9-10 N/A Release Note N/A
N/A Odyssey-v3.0.1 2018-9-6 N/A Release Note N/A
N/A Odyssey-v3.0 2018-8-30 N/A Release Note N/A
N/A Odyssey-v2.0.8.1 2018-8-20 N/A Release Note N/A
N/A Odyssey-v2.0.8 2018-8-14 N/A Release Note N/A
N/A Odyssey-v2.0.7 2018-8-9 N/A Release Note N/A
N/A Odyssey-v2.0.6 2018-7-11 N/A Release Note N/A
N/A Odyssey-v2.0.5 2018-6-24 N/A Release Note N/A
N/A Odyssey-v2.0.4.1 2018-6-24 N/A Release Note N/A
N/A Odyssey-v2.0.4 2018-6-22 N/A Release Note N/A
N/A Odyssey-v2.0.3 2018-6-20 N/A Release Note N/A
N/A Odyssey-v2.0.2 2018-6-19 N/A Release Note N/A
N/A Odyssey-v2.0.1 2018-6-6 N/A Release Note N/A
N/A Odyssey-v2.0 2018-5-31 N/A Release Note N/A
N/A Odyssey-v1.1.2 2018-5-31 N/A Release Note N/A
N/A Odyssey-v1.1.1 2018-5-28 N/A Release Note N/A
N/A Odyssey-v1.1 2018-5-18 N/A Release Note N/A
N/A Odyssey-v1.0.6.3 2018-5-10 N/A Release Note N/A
N/A Odyssey-v1.0.6.1 2018-5-7 N/A Release Note N/A
N/A Odyssey-v1.0.6 2018-5-7 N/A Release Note N/A
N/A Odyssey-v1.0.5 2018-4-20 N/A Release Note N/A
N/A Odyssey-v1.0.4 2018-4-13 N/A Release Note N/A
N/A Odyssey-v1.0.3 2018-4-5 N/A Release Note N/A
N/A Exodus-v1.0 2017-12-28 N/A Release Note N/A

GreatVoyage-4.8.0(Kant)

The Kant release introduces several important optimizations and updates, including support for the Ethereum Cancun upgrade and enhanced validation in the consensus layer. Detailed information is provided below.

Ethereum Cancun Upgrade Support

1. TIP-650: Implement EIP-1153 Transient Storage Instructions

The TRON Virtual Machine (TVM) will support the TLOAD and TSTORE opcodes, aligning with the Ethereum Cancun upgrade.

ID TVM Instruction Description
0x5c TLOAD Read operation for transient storage
0x5d TSTORE Write operation for transient storage

Transient storage is a temporary storage mechanism between persistent storage (storage) and memory. It offers a more gas-efficient storage solution that persists for the duration of a transaction. Data in transient storage is automatically cleared upon transaction completion.

Note: This feature is governed by TRON network parameter #83. It is disabled by default (value: 0) post-Kant deployment and can be enabled through a governance proposal vote. Once enabled, it cannot be disabled.

2. TIP-651: Implement EIP-5656 MCOPY - Memory Copying Instruction

TVM will support the MCOPY instruction, aligning with the Ethereum Cancun upgrade.

ID TVM Instruction Description
0x5e MCOPY Memory copy operation

Memory copying is an operation that copies data from its original location to a target location in memory. It aims to reduce resource costs for memory area copying, thereby improving copying efficiency.

Note: This feature is governed by TRON network parameter #83. It is disabled by default (value: 0) post-Kant deployment and can be enabled through a governance proposal vote. Once enabled, it cannot be disabled.

3. TIP-745: Introduce EIP-4844 Instruction and EIP-7516 Instruction

TVM will support the Ethereum Cancun upgrade's BLOBHASH and BLOBBASEFEE instructions:

ID TVM Instruction Description
0x49 BLBOHASH Retrieves the Blob hash value for a specified index in the current transaction; currently returns 0 by default
0x4a BLOBBASEFEE Retrieves the Blob transaction base fee for the current block; currently returns 0 by default

The BLOBHASH and BLOBBASEFEE instructions are associated with Ethereum Blob transactions. Currently, BLOBHASH and BLOBBASEFEE are implemented as stubs, both returning 0. The precompile contracts verifying KZG proof are not implemented in Kant since blob transaction is not supported.

Note: This feature is governed by TRON network parameter #89. It is disabled by default (value: 0) post-Kant deployment and can be enabled through a governance proposal vote. Once enabled, it cannot be disabled.

Core

1. Enhanced Consensus Layer Verification

1.1 TIP-694: Enhance Verification of Transaction Limitations at Consensus Layer

Prior to Kant, transaction validation was optimized at various points, but only focused on the transaction broadcast phase. The Kant version enhances transaction validation at the consensus layer, further improving transaction processing consistency and validity.

  • Strengthened Account Creation Transaction Size Check: Verifies that the transaction size, excluding its results and signatures, does not exceed the maximum byte limit allowed for account creation transactions (parameter #82).
  • Enhanced Transaction Size Validation: Verifies whether the transaction body content exceeds the size limit.
  • Transaction Result List Constraint: Ensures consistency with the contract count (currently limited to 1).
  • Transaction Expiration Time Check: Verifies that the transaction expiration time is later than the next block's slot time.

Note: This enhancement is governed by TRON network parameter #88. It is disabled by default post-Kant deployment and can be enabled through a governance proposal vote.

1.2 Enhanced Validation of Block Production during Maintenance Periods

Maintenance periods are designated for Super Representative (SR) elections and proposal processing. Therefore, SRs must not produce blocks during these periods. However, in prior versions, blocks produced by SRs during maintenance periods could potentially pass validation. The Kant version modifies block production and validation logic to prevent SRs from producing blocks during maintenance periods. Any block produced during this time will fail validation.

Note: This enhancement is governed by TRON network parameter #88. It is disabled by default post-Kant deployment and can be enabled through a governance proposal vote.

1.3 Enhanced Block Header Validation

Block time, recorded in the block header, represents the time a block is produced. Given that the TRON network's block slot time is 3 seconds, the block time must be a strict multiple of 3 seconds.

Note: This enhancement is governed by TRON network parameter #88. It is disabled by default post-Kant deployment and can be enabled through a governance proposal vote.

1.4 Optimized Super Representative Election Ranking Algorithm

In versions prior to Kant, when multiple SRs had identical vote counts, the system determined the ranking order based on the hash of the SR's address. However, due to the risk of hash collisions and the potential for impacting ranking performance in extreme cases, the Kant version optimizes the SR ranking rules by implementing a more intuitive and stable lexicographical ordering of addresses (i.e., ranking by address alphanumerically). This approach eliminates hash collision-related performance issues and provides a more transparent and predictable ranking mechanism.

TVM

1. TIP-652: Announce EIP-6049 Deprecate SELFDESTRUCT

Note: Although TIP-652 itself does not modify the behavior of the SELFDESTRUCT opcode, it has been officially announced that client developers will change its behavior in a future upgrade. Therefore, any applications that expose the SELFDESTRUCT opcode to users must clearly warn them that a semantic change to SELFDESTRUCT is imminent.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-652.md

Net

1. Optimized Block Synchronization Logic

Kant introduces two key optimizations to the block synchronization logic, significantly improving synchronization efficiency:

1.1 Optimized P2P Protocol: Discarding Solidified Block Lists to Conserve Network Bandwidth

Kant optimizes the synchronization request mechanism by eliminating requests for solidified block data from remote nodes. This prevents redundant requests for existing data, reduces resource waste, and improves synchronization efficiency.

1.2 Faster Block Synchronization Task Scheduling for Enhanced Efficiency

Kant adjusts the scheduling frequency of block synchronization tasks from once per second to once per 100 milliseconds. This accelerates block processing, further improving block synchronization efficiency.

2. Enhanced Transaction Validity Verification by Early Discarding Zero-Contract Transactions

Kant strengthens transaction validity verification. Upon receiving a transaction message, the node will discard transactions with zero contracts and disconnect from the sender.

Other Changes

1. Enhanced Event Service Framework (V2.0) Provision

The previous event service framework (V1.0) lacked support for processing events in historical blocks and intertwined event processing with block processing logic. Consequently, event service exceptions could lead to block processing failures, disrupting block broadcast and synchronization.

Kant introduces a new event service framework (V2.0) that segregates event services from block processing at the thread level. This prevents node disruptions caused by event service exceptions. V2.0 also supports event processing that begins from local historical blocks. Users can specify the starting block height for event synchronization using the event.subscribe.startSyncBlockNum configuration parameter. This feature is disabled if the parameter value is ≤ 0, and enabled otherwise.

Note: Double-check the startSyncBlockNum configuration when restarting the node, since the node will synchronize historical events from the specified block height upon startup. The original event service framework is retained to facilitate a gradual migration to the new framework. Post-Kant deployment, the V1.0 version remains the default. To utilize the V2.0 version, modify the following configuration parameter: 

event.subscribe.version = 1  // 1 means v2.0 , 0 means v1.0
* Source Code: https://github.com/tronprotocol/java-tron/pull/6256 https://github.com/tronprotocol/java-tron/pull/6245 https://github.com/tronprotocol/java-tron/pull/6234 https://github.com/tronprotocol/java-tron/pull/6227 https://github.com/tronprotocol/java-tron/pull/6223 https://github.com/tronprotocol/java-tron/pull/6206 https://github.com/tronprotocol/java-tron/pull/6192

2. Cross-Platform Consistent java.lang.StrictMath Replacement for java.lang.Math

The mathematical operation library is migrated from java.lang.Math to java.lang.StrictMath, to further enhance Java-tron's cross-platform compatibility and establish a robust foundation for future support of diverse hardware architectures (including ARM). This ensures consistent computational results across different platforms.

3. Optimized Node Exit and Startup Logic

3.1 Optimized Node Exit Logic

Kant standardizes the code logic for process termination while preserving original functionalities, enhancing code consistency and system stability.

3.2 Optimized Node Startup Logic

Kant introduces enhanced service integrity checks for the node startup process. To ensure operational stability, the node will immediately terminate if any core service (including API, P2P, Prometheus, and event plugins) fails to initialize. This prevents operation with incomplete critical services.

Additionally, the Kant version extends the API service with the following four configurable options (all enabled by default), providing node deployers the choice to selectively disable or enable these API service features: 

node.rpc.enable = true
node.rpc.solidityEnable = true
node.rpc.PBFTEnable = true
node.http.PBFTEnable = true
* Source Code: https://github.com/tronprotocol/java-tron/pull/5857 https://github.com/tronprotocol/java-tron/pull/6228 https://github.com/tronprotocol/java-tron/pull/6233

4. Dependency Library Security Upgrade

To enhance system security, Kant has updated several underlying dependency libraries and removed obsolete components. This includes updating the jcommander, pf4j, grpc, logback, and libp2p dependency libraries to secure and stable releases, and removing the deprecated library quartz for task scheduling.

5. Gradle 7.6.4 Upgrade with Dependency Integrity Verification

Kant upgrades Gradle to version 7.6.4 and enables security verification of third-party dependency JAR packages. During JAR file packaging and generation, the system automatically validates all referenced external dependencies to ensure they originate from trusted sources and are free from tampering. This prevents the inclusion of potentially vulnerable JAR packages in the final product. This enhancement effectively mitigates supply chain attacks and bolsters the overall build security of the project.

6. Null Pointer Exception Fix During Startup

Kant resolves an intermittent null pointer exception that could occur during node startup. This ensures the consensus service initializes before the network service, preventing startup failures.

7. Internal Transaction Details Logging for CANCELALLUNFREEZEV2 Opcode

Nodes configured to save internal transactions, beginning with the Kant version, will log the unstaking amounts of various resources when processing transactions that include the CANCELALLUNFREEZEV2 opcode. For example: {"BANDWIDTH":100,"ENERGY":100,"TRON_POWER":0}.

API

1. Enhanced Compatibility for Ethereum JSON-RPC Interface

1.1 Support for Querying Solidified Data via finalized Block Parameter in JSON-RPC API

Kant's JSON-RPC interface now supports the "finalized" parameter. This allows certain interfaces that use a block number as a parameter to accept "finalized” for querying the latest solidified block information, further improving compatibility with the Ethereum JSON-RPC interface.

Interfaces supporting "finalized" as a parameter:

  • eth_getBlockTransactionCountByNumber
  • eth_getBlockByNumber
  • eth_getTransactionByBlockNumberAndIndex
  • eth_getLogs

Interfaces not supporting "finalized" as a parameter:

1.2 New Limits on Block Range and “Topics” Quantity for JSON-RPC Log Queries

Kant introduces a query limit mechanism for JSON-RPC event query interfaces, controlled by the following two configuration parameters:

  • maxBlockRange: Specifies the maximum block range allowed for log queries. The default value is 5000. The range between the starting block and the ending block cannot exceed this value when related interfaces are called.
  • maxSubTopics: Limits the maximum number of “sub topics” that can be set. The default value is 1000, meaning that a maximum of 1000 “sub topics” can be set during interface calls.

Note: The values of the above configuration parameters must be positive integers greater than 0. If a configured value is less than or equal to 0, the corresponding limit is considered disabled, and the relevant interfaces will not perform this validation. 

node.jsonrpc.maxBlockRange = 5000
node.jsonrpc.maxSubTopics = 1000

Interfaces supporting maxBlockRange:

  • eth_getLogs

Interfaces supporting maxSubTopics:

1.3 Optimized eth_getLogs to Resolve Data Retrieval Issue in Rare Hash Collisions

Kant optimizes the eth_getLogs processing logic to resolve the issue where the interface failed to retrieve data in rare hash collision scenarios, thus increasing interface stability.

2. Non-Null Payment Address Validation in Shielded Transaction Creation API

Kant adds validation to the shielded transaction creation API to ensure a payment address is not empty. If the validation fails, the API returns the reason for the failure, improving the user experience.

Science is organized knowledge. Wisdom is organized life.

---Immanuel Kant

GreatVoyage-4.7.7(Epicurus)

GreatVoyage-4.7.7(Epicurus) introduces multiple important optimizations and updates, including a new proposal to upgrade the floating-point power calculation library from java.lang.Math to java.lang.StrictMath, to expand TRON hardware compatibility and provide users with more flexible hardware platform selection, and save operating costs; optimizing event subscription processing logic to ensure the integrity of event acquisition, and bring users a more user-friendly development experience; adapting to the GRPC asynchronous call mode, and further improve the node monitoring system. You may find the details below.

Core

1. Migrate pow operation from java.lang.Math to java.lang.StrictMath for cross-platform computational consistency

In order to enable java-tron to support multiple platforms and be compatible with new JDK versions, the Epicurus version switches the floating-point power operation library from java.lang.Math to java.lang.StrictMath to ensure consistency in cross-platform calculations.

Note: This optimization is the No. 87 parameter of the TRON network. After Epicurus is deployed, it is disabled by default and can be enabled through governance voting.

TIP: https://github.com/tronprotocol/tips/issues/697

Source Code: https://github.com/tronprotocol/java-tron/pull/6098

Other Changes

1. Optimize event subscription processing logic

java-tron provides event subscription service, and developers can subscribe to specific events from node through event plugin. For block events, when a node receives a new block, if it successfully verifies and processes the block, it will save the block data in the memory database. At the same time, if there is a new solidified block, the solidified block data will be written to the disk database. If the node deployer subscribes to block events, after the node completing the above block processing steps, the event sending related logic will be performed, that is, the latest block event and the latest solidified block event will be sent to the event plugin. However, in previous versions of Epicurus, block processing and event sending used the same exception capture logic: the newly received block data was removed from the memory database and an exception was thrown. This would result in the new block data being deleted when the block processing was normal but an exception occurred during event sending, which might temporarily affect block synchronization.

The Epicurus version optimizes the event subscription processing logic and performs separate exception capture on the block event sending logic. When an exception occurs during event sending, an error log is output and the node exits, so that the node deployer can understand the node abnormality in time and ensure the integrity of event acquisition.

Source Code: https://github.com/tronprotocol/java-tron/pull/6096

2. Support graceful shutdown with signal -15 (SIGTERM) for nodes enabling backup.

The Epicurus version adjusts the resource release order of the master and backup services, first closing the communication channel between the master and backup nodes, and then closing the thread pool to ensure that the nodes enabling backup can exit gracefully through the kill -15 command.

Source Code: https://github.com/tronprotocol/java-tron/pull/6095

3. Improve duration metrics accuracy of gRPC interfaces

The Epicurus version optimizes the duration statistics method for GRPC interface calls to adapt to the GRPC asynchronous call mode: a new server-side interceptor is added to record the start time of the GRPC call and monitor the end event of the GRPC call to accurately calculate the time consumption of the GRPC interface asynchronous call.

Source Code: https://github.com/tronprotocol/java-tron/pull/6097

Not what we have but what we enjoy, constitutes our abundance.

---Epicurus

GreatVoyage-v4.7.6(Anaximander)

The GreatVoyage-4.7.6(Anaximander) introduces several important optimizations and updates, including optimized unit test tasks to improve the stability of test cases execution; newly added TCP and UDP traffic statistics further enriches node monitoring data; optimized peer node idle judgment logic improves the stability of block synchronization; optimized node connection random disconnection logic improves the robustness of node network. Please find the details below.

Other Changes

1. Optimize the statistical logic of node HTTP request monitoring metric

java-tron supports node monitoring and provides various metrics data. Anaximander optimizes the statistical logic of node HTTP request monitoring metric to ensure data consistency during concurrent access by multiple threads when counting request data from each mapping address.

Source Code: https://github.com/tronprotocol/java-tron/pull/5920

2. Improve stability of Gradle test task

Anaximander optimizes the unit test task. The Gradle test-retry plugin is introduced to allow the failed unit test tasks to be re-executed. The @Ignore annotation is used to skip temporarily unused and unstable test cases. This optimization improves the stability of test task execution.

Source Code: https://github.com/tronprotocol/java-tron/pull/5916 https://github.com/tronprotocol/java-tron/pull/5927

3. Add TCP outflow monitoring metric for Prometheus and add UDP inflow traffic statistic to /monitor/getstatsinfo API

Anaximander adds a new node TCP outflow monitoring metric and adds a UDP inflow statistic to the /monitor/getstatsinfo interface, further enriching the node monitoring data.

Source Code: https://github.com/tronprotocol/java-tron/pull/5942

4. Optimize peer node idle judgment logic

Anaximander optimizes the logic of judging whether the peer node is idle during the block synchronization process, so that block synchronization is not affected by the process of broadcasting blocks/transactions, which improves the efficiency of block synchronization and the stability of the connection between nodes.

Source Code: https://github.com/tronprotocol/java-tron/pull/5921

5. Optimize peer sorting logic

Anaximander optimizes the peers’ sorting logic and adds exception-catching to improve the efficiency of establishing connections between nodes.

Source Code: https://github.com/tronprotocol/java-tron/pull/5923

6. Optimize check logic for fetching block inventory message

Anaximander optimizes the check logic for fetching block inventory messages. The block number requested should be smaller than the largest block number in chain inventory message so that the node can detect illegal messages in time and disconnect from the other node. At the same time, richer node logs are conducive to the troubleshooting and location of connection issues between nodes.

Source Code: https://github.com/tronprotocol/java-tron/pull/5922

7. Optimize block processing logic

Anaximander optimizes the block processing logic. When processing a received broadcasted block, the node will promptly update the ID and number of the block which the node with its peer both have to better understand the status of the peers.

Source Code: https://github.com/tronprotocol/java-tron/pull/5925

8. Optimize random disconnection strategy

When a node’s latest block height is higher than all peers’ that are connected to it, this node will neither be able to synchronize blocks from peers, nor broadcast transactions. We call it an "island node". An island node actually does not have a valid peer. In order to prevent a node from entering the island state, Anaximander optimizes the random disconnection logic of the node, disconnects nodes that have been inactive for a long time, increases the number of valid connections, and improves the robustness of the node network.

Source Code: https://github.com/tronprotocol/java-tron/pull/5924 https://github.com/tronprotocol/java-tron/pull/5944
https://github.com/tronprotocol/java-tron/pull/5956
https://github.com/tronprotocol/java-tron/pull/5984

Nature is eternal and does not age.

---Anaximander

GreatVoyage-v4.7.5(Cleobulus)

The Cleobulus version introduces multiple important optimizations and updates, including a new proposal to adjust the energy cost of some opcodes in TVM to make the energy cost more reasonable. The enhanced transaction and block verification logic improves the system's fault tolerance. The optimized synchronization logic between threads improves data consistency. You may find the details below.

Core

1. Optimize block synchronization and production logic

The Cleobulus version optimizes the block production logic. After obtaining the block production lock, the node will check whether it meets the conditions for producing blocks to avoid inconsistent state before and after obtaining the block production lock, thereby improving the stability of the TRON network.

Additionally, Cleobulus enhances the block verification logic. All nodes add checks on block size and block time.

Source Code: https://github.com/tronprotocol/java-tron/pull/5833 https://github.com/tronprotocol/java-tron/pull/5830

2. Strengthen size check of account creation transactions

The Cleobulus version optimizes the account creation logic, strengthens the size check of account creation transactions, and adds the No.82 TRON network parameter to set the maximum number of bytes allowed for account creation transactions. The parameter ranges from 500 to 10000 and the default value is 1000. The value can be modified by initiating a proposal for a vote.

Source Code: https://github.com/tronprotocol/java-tron/pull/5835

TVM

1. Adjust energy cost for some opcodes in TVM

Cleobulus adjusts the energy cost of the VOTEWITNESS and SUICIDE opcodes to make the energy consumption more reasonable based on the resources and time required for the actual execution of each opcode.

This optimization is the No. 81 parameter of the TRON network. After Cleobulus is deployed, it is disabled by default and can be enabled through governance voting.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-653.md
Source Code: https://github.com/tronprotocol/java-tron/pull/5837

Other Changes

1. Optimize synchronization logic among threads

The Cleobulus version optimizes the block request logic and no longer reads fetchBlockInfo data when printing logs, improving the stability of concurrent access to fetchBlockInfo object by multiple threads.

Additionally, Cleobulus optimizes the synchronization block processing logic. Regardless of whether the syncBlockToFetch queue is empty, the node can process block data normally, improving the efficiency of block synchronization.

Source Code: https://github.com/tronprotocol/java-tron/pull/5831
https://github.com/tronprotocol/java-tron/pull/5832

2. Remove redundant code

The Cleobulus version removes redundant code in the block processing logic, improving the readability and maintainability of the code.

Source Code: https://github.com/tronprotocol/java-tron/pull/5834

Seek virtue and eschew vice.

---Cleobulus

GreatVoyage-v4.7.4(Bias)

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 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

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 turn on it and configure the threshold through the below configuration items.

node.unsolidifiedBlockCheck = true
node.maxUnsolidifiedBlocks = 54

Source 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/issues/621
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=true
Source Code: https://github.com/tronprotocol/java-tron/pull/5583

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 Toolkit 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

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

GreatVoyage-v4.7.3.1(Solon)

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.

Other Changes

1. More stable /wallet/getnodeinfo interface

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

2. Optimize Lite FullNode data pruning tool

In order to solve the problem of node database corruption caused by the abnormal shutdowns, starting from Socrates version, the Checkpoint V2 mechanism was introduced. The V2 mechanism saves multiple checkpoints on the disk, corresponding to multiple solidified block data, which is used to restore the data when the node database is damaged.

The Lite FullNode data pruning tool should also be compatible with the checkpoint v2 version. When a node stops abnormally, the pruning tool can also restore the node data and complete the data pruning.

Therefore, Solon optimized the Lite FullNode data pruning tool in the toolkit. When it is found that checkpoint v2 is used, the data will be queried from the checkpoint v2 database, so that even if the node stops abnormally, the tool can restore and prune the data, which improves the usability of the Lite FullNode data pruning tool.

Source Code: https://github.com/tronprotocol/java-tron/pull/5658

Do not counsel what is most pleasant, but what is best.

---Solon

GreatVoyage-v4.7.3(Chilon)

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.

Core

1. Add gRPC interfaces for resource price and transaction memo fee query

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
Source Code: https://github.com/tronprotocol/java-tron/pull/5412

2. Supplement disconnect reasons

When a node fails to process a message from a peer, it may initiatively disconnect from the peer. However, in previous versions of Chilon, in some cases, the node did not inform the other node of the reason for the disconnection, which was not conducive to the analysis and troubleshooting of the connection issue by the other node.

The Chilon version supplements two reasons for disconnection. Node will send the disconnection reasons to the other node before dropping the connection, so as to facilitate efficient handling of node connection problems.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-592.md
Source Code: https://github.com/tronprotocol/java-tron/pull/5392

3. Discard transactions from bad peers instead of disconnected peers

For a broadcast transaction, the node must determine whether to process it. In previous versions of Chilon, the basis for judgment is whether the transaction comes from a disconnected peer. If so, the transaction will be discarded. However, whether to execute a broadcasted transaction should not be judged based on whether it maintains a connection with the other node, but whether the other node is a malicious node.

Therefore, the Chilon version optimizes the transaction processing logic and no longer discards transactions from disconnected peers. Instead, it only discards transactions broadcasted from the nodes that have sent illegal transactions. This change improves transaction broadcast and packaging efficiency.

Source Code: https://github.com/tronprotocol/java-tron/pull/5440

4. Optimize Stake 2.0 codes and error messages

The Chilon version standardizes Stake 2.0-related code and simplifies complex functions， improving the simplicity and readability of the code.

Source Code: https://github.com/tronprotocol/java-tron/pull/5426

5. Accelerate bloomFilter initialization for transaction cache

When a node starts, it will load the transactions of the latest 65536 blocks from the database to build a transaction cache bloomFilter, which is used to determine duplicate transactions when verifying transactions later. In previous versions of Chilon, the loading time of the transaction cache accounted for more than 70% of the node startup time. In order to accelerate the speed of the transaction cache bloomFilter initialization, the Chilon version persists in the transaction cache bloomFilter. When the node exits normally, the transaction cache bloomFilter-related data will be stored on the disk. When the node restarts, there will be no need to read the transaction information in the recent blocks, but directly load the bloomFilter data into the memory, speeding up the initialization process of the transaction cache bloomFilter and greatly improving the node startup speed. This feature is disabled by default and can be enabled through the node configuration item storage.txCache.initOptimization = true.

Source Code: https://github.com/tronprotocol/java-tron/pull/5394 https://github.com/tronprotocol/java-tron/pull/5491 https://github.com/tronprotocol/java-tron/pull/5505 https://github.com/tronprotocol/java-tron/pull/5523 https://github.com/tronprotocol/java-tron/pull/5543

6. Fix concurrency issues when generating chain inventory

In previous versions of Chilon, when node A requests to synchronize blocks from node B, it first sends its own chain summary to node B. After receiving it, node B generates node A's missing block list according to the local chain and returns the list to node A. The list generation process is: first, find the maximum common block height of the two nodes from the chain summary of node A, and then add the IDs of several blocks starting from the maximum common block height to the missing blocks list of node A. Since the generation of the missing block list and chain switching are executed concurrently, if chain switching occurs when generating the missing block list, it may happen that after the maximum common block height is obtained, the corresponding block id cannot be obtained, causing the generated missing block list does not match the chain summary of node A, resulting in dropping the node connection.

The Chilon version optimizes the generation logic of the missing block list. When the ID of the highest common block previously calculated cannot be obtained, the node will retry to ensure that the returned list contains the highest common block information, which improves the stability of connections between nodes.

Source Code: https://github.com/tronprotocol/java-tron/pull/5393 https://github.com/tronprotocol/java-tron/pull/5532

7. Correct resource disorder closure behavior on kill -15

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

API

1. Optimize HTTP interface monitoring

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

2. Provide uniform rate limitation configuration for all HTTP and gRPC APIs

java-tron supports interface rate limiting. The default qps (queries per second) of each interface is 1000. Node deployers can also limit the traffic of a particular interface. However, in previous versions of Chilon, it was not supported to modify the default qps of each interface, that way, If you want to configure the default qps of each interface to 2000, you need to configure the current limit for each interface respectively. The Chilon version adds a new default interface rate limit configuration rate.limiter.global.api.qps. With this configuration, users can change the rate limit of all interfaces, simplifying the configuration complexity.

rate.limiter.global.api.qps = 1000

Source Code: https://github.com/tronprotocol/java-tron/pull/5502

3. Optimize HTTP interface parameter parsing

In previous versions of Chilon, for interfaces involving reward queries, if the request passes in invalid parameters or non-JSON formatted parameters, the node will throw an exception. The Chilon version optimizes the HTTP interface parameter parsing logic and returns a 0 value or error message for requests with incorrect parameter formats.

Source Code: https://github.com/tronprotocol/java-tron/pull/5367 https://github.com/tronprotocol/java-tron/pull/5483

4. Add solidity query interfaces of resource unit price

Chilon supplements query interfaces of resource unit price for solidity, they are /walletsolidity/getbandwidthprices and /walletsolidity/getenergyprices.

Source Code: https://github.com/tronprotocol/java-tron/pull/5412 https://github.com/tronprotocol/java-tron/pull/5451
https://github.com/tronprotocol/java-tron/pull/5437

5. Optimize the processing logic of some HTTP interfaces

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

Other Changes

1. Add check for expired transactions when fetching transactions

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

2. Fix concurrency issue of getHeadBlockId method

During the block synchronization process, the node must obtain the BlockId of the latest block through the getHeadBlockId method. In previous versions of Chilon, the BlockId was obtained through the block number and hash of the latest block. However, due to the concurrent execution of the latest block data acquisition thread and the update thread, getHeadBlockId may start to obtain the BlockId of the latest block before the block number and hash value of the latest block have been updated, which makes it possible for the getHeadBlockId method to return an abnormal BlockId value.

Chilon optimizes the BlockId acquisition logic of the latest block, and getHeadBlockId only obtains BlockId through the hash value of the latest block, ensuring the correctness of the block ID acquisition.

Source Code: https://github.com/tronprotocol/java-tron/pull/5403

3. Delete unused network configurations

Chilon deleted four unused network parameters, including the three configuration items below, simplifying the complexity of using for developers.

node.discovery.public.home.node
node.discovery.ping.timeout
node.p2p.pingInterval

Source Code: https://github.com/tronprotocol/java-tron/pull/5441

4. Obtain external IP through Libp2p

In previous versions of Chilon, when a node starts, the external IP address would be obtained repeatedly, and java-tron and lib2p2 each perform the IP acquisition once. To improve the node startup speed, Chilon optimizes the external IP acquisition logic. When a node starts, it directly calls the libp2p module to obtain the external IP, and it can directly assign the external IP to libp2p and repeated obtaining is avoided.

Source Code: https://github.com/tronprotocol/java-tron/pull/5407

Chilon optimizes the event subscription service and adds the parsing of addresses in stake-related transactions, so that event subscribers can obtain address information in stake, resource delegation, and other transactions.

Source Code:https://github.com/tronprotocol/java-tron/pull/5419

6. Adjust default number of CPU cores used in signature validation

In previous versions of Chilon, nodes used 1/2 of the system CPU cores for parallel signature verification by default. To improve the performance of node synchronization and block processing, the Chilon version changed the default value of the number of threads used for signature verification to the maximum number of CPU cores to maximize signature verification performance. Node deployers can also adjust the number of signature verification threads through the node.validateSignThreadNum configuration item.

Source Code:https://github.com/tronprotocol/java-tron/pull/5396

In the previous version, the code related to the LiteFullNode tool has been integrated into the toolkit in the plugins module. The Chilon version has further integrated and moved the test cases related to the LiteFullNode tool from the framework module to the plugins module. Not only does It make the code structure clearer but also improves the execution efficiency of test cases.

Source Code: https://github.com/tronprotocol/java-tron/pull/5475 https://github.com/tronprotocol/java-tron/pull/5482

8. Enhance query performance of properties DB

During the block processing process, nodes access the properties database more frequently. Better properties database query performance will improve the processing speed of the block. Since the property data volume is small and updates are infrequent, Chilon optimizes the query performance of the properties database, loading all data into the first-level cache to maximize data query performance and thereby improve transaction processing capabilities.

Source Code: https://github.com/tronprotocol/java-tron/pull/5378

Do not desire impossible.

---Chilon

GreatVoyage-v4.7.2(Periander)

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.

Core

1. Upgrade Libp2p to v1.2.0

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：

  • Support IPv6 protocol

    IPV6 protocol is the next-generation Internet IP protocol that replaces IPV4. While solving the problem of IP4 address exhaustion, the network performance has also been improved. Currently, mainstream server operating systems support both IPv4 and IPv6. Therefore, Libp2p v1.2.0 supporting dual protocol stacks not only improves the network performance of TRON but also enables nodes that either support one of the protocols or support both of them to join the TRON network.

    This function is disabled by default and needs to be enabled through the node configuration item node.enableIpv6 = true.

  • Node Discovery via DNS

    Libp2p v1.2.0 supports node discovery through DNS so that nodes can use not only the Kademlia algorithm but also the DNS servers for node discovery. The nodes supporting the feature can publish nodes to the DNS service and use DNS for node discovery. These functions need to be enabled through node configuration items, see below:

    Publish Nodes to DNS

    The node supports publishing known nodes to the DNS service for other nodes to use. There are two ways to publish nodes: dynamic publishing and static publishing. Dynamic publishing is the node periodically publishing the remote node IP in the K-bucket to DNS. Static publishing is to publish the nodes in the dns.staticNodes configuration item to the DNS service at one time, without updating later. If dns.staticNodes is not empty, it means to adopt the static publishing way, otherwise, the dynamic publishing way.

    node.dns {
    # enable or disable dns publish, default false
    publish = true

    # dns domain to publish nodes, required if publish is enable
    dnsDomain = "..."

    # dns private key used to publish, required if publish is enable, hex string of length 64
    dnsPrivate = "..."

    # dns server to publish, required if publish is enable, only ”aws” or “aliyun” is support
    serverType = "..."

    # access key id of aws or aliyun api, required if publish is enable, string
    accessKeyId = "..."

    # access key secret of aws or aliyun api, required if publish is enable, string
    accessKeySecret = "..."

    # if publish is enable and serverType is aliyun, it's endpoint of aws dns server, string
    aliyunDnsEndpoint = "..."

    # if publish is enable and serverType is aws, it's region of aws api, such as "eu-south-1", string
    awsRegion = "..."
    # if publish is enable and serverType is aws, it's host zone id of aws's domain, string
    awsHostZoneId = "..."

    # static nodes to published on dns
    staticNodes = [
        # Sample entries:
        # "ip:port",
        # "ip:port"
    ]

    # the range is from 1 to 5
    maxMergeSize = 2

    changeThreshold = 0.001
}

    Node discovery via DNS

    To use the function of node discovery via DNS, you need to configure the following configuration items: 

    node.dns {
 # DNS URL to get nodes, URL format tree://{pubkey}@{domain}, default empty
 treeUrls = [......]
}

  • Connection precheck before P2P communication

    Libp2p v0.1.4 chooses whether to establish a connection and synchronize data with a remote node according to the order of the update time of the node. In actual scenarios, the connection may be rejected by the other party for some reason, which will affect data synchronization. In order to improve the efficiency of establishing connections between nodes, Libp2p v1.2.0 supports node connection precheck before the P2P communication, which can check whether the other node can accept the connection in advance.

    The node tries to establish a TCP connection with the other node in advance to know whether it is online. If the TCP connection is established, a pair of interactive messages are used to obtain the relevant information of the other node, including the Libp2p version, the maximum number of connections, the current number of connections, etc., to determine whether the other node can still accept connections. This function avoids invalid connection requests and greatly improves the efficiency of connection establishment.

    This function is disabled by default and needs to be enabled through the node configuration item node.nodeDetectEnable.

  • P2P message Snappy compression

    Libp2p v1.2.0 supports TCP message compression. The node compresses the TCP message before transmission and decompresses it after receiving the compressed message. After testing, the time consumption for message compression and decompression is short, less than 1 ms, and this function can significantly reduce the network bandwidth occupation of message transmission, which can save about 40% of the bandwidth.

2. Support canceling unstaking in Stake 2.0

In the versions previous to Periander, after initiating an unstaking transaction through the HTTP API in Stake 2.0, the user needs to wait for a 14-day waiting period before withdrawing the corresponding funds, and the unstaking cannot be canceled.

The Periander version optimizes the Stake 2.0 mechanism, allowing users to cancel unstakings that have been initiated but not completed yet. When canceling unstakings, all unstaked funds still in the waiting period will be re-staked, and the resource obtained through the re-staking remains the same as before. Unstakings that exceeded the 14-day waiting period cannot be canceled, and this part of the unstaked funds will be automatically withdrawn to the owner’s account. This feature is controlled by the No. 77 parameter of the TRON network, which needs to be enabled through governance voting. After it is enabled, the nodes will support a new transaction type, and users can use the wallet/cancelallunfreezev2 API to create an unstaking canceling transaction: 

curl -X POST http://127.0.0.1:8090/wallet/cancelallunfreezev2 -d \
'{
  "owner_address": "TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",
  "visible": true
}'

3. Resource delegating supports customizable lock period

In the versions previous to Periander, users can choose whether to lock or not when delegating resources. If chosen to lock, the resource delegating to the recipient address could not be canceled within 3 days, which is more conducive for users participating in the resource rental market.

The Periander version further optimizes the lock time when delegating resources, changing it from the current fixed value of 3 days to a configurable length of time for users according to their needs.

This feature is controlled by the No.78 parameter of the TRON network. It needs to be enabled through governance voting. When enabling the proposal, a time parameter needs to be specified, indicating the maximum value of the lock time that can be set. Once enabled, a new parameter, lock_period, will be added to wallet/delegateresource API:

curl -X POST http://127.0.0.1:8090/wallet/delegateresource -d \
'{
  "owner_address": "TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",
  "receiver_address": "TPswDDCAWhJAZGdHPidFg5nEf8TkNToDX1",
  "balance": 1000000,
  "resource": "ENERGY",
  "lock": true,
  "lock_period": 86400,
  "visible": true
}'
  • lock: whether to lock the delegating
  • lock_period: lock time, only when lock is true, this field is valid. The owner cannot cancel the delegating before the lock time is up. The unit of lock_period is block interval(3 seconds). This field indicates the time of how many blocks will be produced from the moment the transaction is executed. So the above 86400 means locking for 259200 seconds (3 days). lock_period cannot exceed the maximum lock period (value of the No.78 network parameter).

The default value of lock_period is 86400, which is 3 days. That is, when lock is true, if lock_period is not specified or set to 0, lock_period will be set to 86400 by default, which will ensure compatibility before and after this feature takes effect.

In addition, the value of lock_period cannot be lower than the remaining lock time of this type of resource that was previously delegated to the same recipient address, and the value will overwrite the remaining lock time of the previous delegating.

For example, user A delegates 100 energy shares to B, and lock_period is set to 57600 (2 days), and so that the remaining lock time after 1 day is 28800. At this time, when A delegates energy to B again, if choose to lock, lock_period should be set to at least 28800 (1 day), otherwise, an exception error will be thrown when creating the delegating transaction: “The lock period for ENERGY this time cannot be less will be thrown when creating a proxy transaction than the remaining time[9600000ms] of the last lock period for ENERGY!.”

4. Optimize effective peer-acquiring strategy

When the latest block heights of all connected remote nodes are lower than a node’s, then the node will not be able to synchronize blocks from the remote nodes, nor broadcast the transactions. We call this kind of node an "island node". In fact, the island node has no valid peer node.

In order to enable nodes to connect to effective peer nodes, the Periander version optimizes the node acquisition strategy and adds island node detection. If a node finds that it is in an island state, it will look for a node with a higher header block than the local one and establish a connection with it. This strategy prevents the node from being in an isolated state for a long time, ensures that the node can quickly replenish effective connections, enables it to obtain new blocks and broadcast transactions, and improves the stability of the node.

This function is disabled by default and needs to be enabled by setting the node configuration item node.effectiveCheckEnable.

TVM

1. Implement EIP-3855 PUSH0 Instruction

EIP-3855 is included in the Shanghai upgrade of Ethereum, which adds a new instruction called PUSH0 to the Ethereum Virtual Machine (EVM) to reduce the gas cost of smart contract transactions, and Periander also adds a new governance proposal to be compatible with EIP-3855. On one hand, it can ensure the compatibility between TRON and Ethereum at the virtual machine level, and on the other hand, it also reduces the energy cost of using smart contracts on TRON as well.

API

1. Add API global rate limiter

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.

# QPS rate limit for all interfaces
rate.limiter.global.qps =10  
# QPS rate limit to all interfaces from the same IP address
rate.limiter.global.ip.qps = 5

2. Add data to HTTP Interfaces for Smart Contract Interaction

The Periander version optimizes the HTTP smart contract calling interfaces triggersmartcontract, triggerconstantcontract and estimateenergy, and adds a data parameter to them. This optimization not only realizes the contract call directly through the data field in the transaction but also enables the triggerconstantcontract and estimateenergy interfaces to estimate the energy consumption of smart contract deployment transactions, which greatly improves the convenience of smart contract development.

  • Calling contract using function_selector and parameter 

    curl --request POST \
 --url https://api.shasta.trongrid.io/wallet/triggersmartcontract \
 --header 'accept: application/json' \
 --header 'content-type: application/json' \
 --data '
{
    "owner_address": "TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",
  "contract_address": "TG3XXyExBkPp9nzdajDZsozEu4BkaSJozs",
  "function_selector": "balanceOf(address)",
  "parameter": "000000000000000000000000a614f803b6fd780986a42c78ec9c7f77e6ded13c",
  "visible": true
}
'

  • Calling contract through data 

    curl --request POST \
 --url https://api.shasta.trongrid.io/wallet/triggersmartcontract \
 --header 'accept: application/json' \
 --header 'content-type: application/json' \
 --data '
{
  "owner_address": "TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",
  "contract_address": "TG3XXyExBkPp9nzdajDZsozEu4BkaSJozs",
  "data": "70a08231000000000000000000000000a614f803b6fd780986a42c78ec9c7f77e6ded13c",
  "visible": true
}'

  • Estimate energy consumption of contract deployment transaction 

    curl --request POST \
 --url https://api.shasta.trongrid.io/wallet/triggerconstantcontract \
 --header 'accept: application/json' \
 --header 'content-type: application/json' \
 --data '
{
  "owner_address": "TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",
  "data": "608060405234801561001057600080fd5b50d3801561001d57600080fd5b50d2801561002a57600080fd5b506101c18061003a6000396000f3fe608060405234801561001057600080fd5b50d3801561001d57600080fd5b50d2801561002a57600080fd5b50600436106100455760003560e01c8063f8b2cb4f1461004a575b600080fd5b610064600480360381019061005f919061012a565b61007a565b6040516100719190610170565b60405180910390f35b60008173ffffffffffffffffffffffffffffffffffffffff16319050919050565b600080fd5b600074ffffffffffffffffffffffffffffffffffffffffff82169050919050565b6100ca816100a0565b81146100d557600080fd5b50565b600073ffffffffffffffffffffffffffffffffffffffff82169050919050565b6000610103826100d8565b9050919050565b600081359050610119816100c1565b610122816100f8565b905092915050565b6000602082840312156101405761013f61009b565b5b600061014e8482850161010a565b91505092915050565b6000819050919050565b61016a81610157565b82525050565b60006020820190506101856000830184610161565b9291505056fea26474726f6e58221220839f9be3efc349a3efd6bb491d0bee7bc34d86313c73f6e6eeddc4719ec69c0064736f6c63430008120033",
  "visible": true
}'

  • TIP: https://github.com/tronprotocol/tips/blob/master/tip-544.md

  • Source Code: https://github.com/tronprotocol/java-tron/pull/5079

3. Optimize getStorageAt interface

In versions previous to Periander, for contracts created by the create2 instruction, the contract data cannot be queried through the getStorageAt interface. This is due to the difference in index construction of contract data in the underlying storage for contracts created using the create instruction and the create2 instruction. The Periander version optimizes the getStorageAt interface, which will select the corresponding method to construct the index according to the way the contract was created to ensure the availability of the getStorageAt interface.

Other Changes

1. Optimize event forwarding logic in event subscription

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.

2. Support dynamic loading according to node.active and node.passive

java-tron supports configuring trusted nodes for the local node with node.active and node.passive. The local node will actively connect to the nodes in node.active and accept the connection request of the nodes in node.passive. By configuring trusted nodes, you can solve the problem that the node has no valid connections or the number of connections is rather small. However, in the previous version of Periander, you need to stop the node first to change the configuration file, and then restart the node after the update is completed. Restarting the node has a certain impact on some applications. Therefore, starting from the Periander version, the dynamic loading of node.active and node.passive configuration items are supported, so that the change of the trusted node can be completed without restarting the local node, which improves the online stability of the node.

This function is disabled by default and needs to be enabled by modifying the following node configuration items. 

node.dynamicConfig.enable=true
node.dynamicConfig.checkInterval = 600

3. Optimize block synchronization logic

The Periander version optimizes the block synchronization logic, ensures the correctness of concurrent execution of the block acquisition thread and block synchronization thread, the block summary obtaining thread and chain switching thread through the lock mechanism, and improves the stability of block synchronization and node connection.

4. Normalize HTTP URLs

The node supports disabling the specified HTTP APIs, and the node deployer can configure the interfaces to which the node will stop providing services through the node.disabledApi. In previous versions of Periander, even if the interface was added to the node.disabledApi list, the node would still respond to non-standard URL requests. The Periander version normalizes the requested URL to ensure the validity of the node.disabledApi list.

node.disabledApi= [
   "getaccount",
    "getnowblock2"
]

5. Optimize block fetching logic

After a node requests a block from another node, if it does not receive the block within a certain period of time, the request will be considered as a timeout, and then it will request the block from another node that meets the conditions. Of which, one of the conditions for selecting a node is that the node's block acquisition delay is lower than the block timeout period. Therefore, a low block timeout setting may make the node unable to find other remote nodes, resulting in slow block synchronization or stopping the synchronization.

In order to improve block synchronization performance under an unstable network, the Periander version increases the default value of the timeout period for nodes to obtain blocks, from 200ms to 500ms, which not only expands the scope of node selection but also increases the probability of successfully obtaining blocks, greatly improving the efficiency of block synchronization. The node deployer can also adjust the timeout period through the node.fetchBlock.timeout configuration item.

6. Add a new node startup mode

In order to facilitate data backup or data statistics for node deployers, the client supports stopping running under specific conditions. Users can set the conditions for node stop through the node configuration file. When the conditions are met, the node will stop syncing and exit. However, in the versions previous to Periander, the node only supports stopping under certain conditions and does not support the interface query service after stopping, so users cannot call the interface to query the status of the system. Therefore, the Periander version adds a new node startup mode to support data query services without starting the P2P network module. When the node successfully stops under certain conditions, the user can add -p2p- disable true parameter to the command to start the node. At this time, the node will not start the network module, and will not perform node discovery and block synchronization, but will provide interface query services, so that users can query the current system status. Below is the start command:

java -jar FullNode.jar -c config.conf --p2p-disable true

7. Upgrade JUnit to 4.13.2

The Periander version upgrades the unit testing framework and upgrades the JUnit dependency library from v4.12 to v4.13.2.

8. Add monitoring metrics for JSON-RPC

The Periander version supports JSON-RPC interface latency monitoring metrics, allowing node deployers to monitor the latency of all types of interfaces.

9. Optimize the database module

In versions previous to Periander, for nodes using LevelDB as the storage engine, if the LevelDB database is detected to be damaged during the startup period, it will try to repair the data. Although this function can repair the data, it cannot guarantee the integrity of the data. Therefore, the Periander version optimizes the database module and removes the LevelDB data automatic repair function, so that when the node detects that the database is damaged, it immediately reports an error and exits, avoiding invalid synchronization.

10. Optimize checkpoint v2 recovery process

In order to solve the problem of node database corruption caused by the abnormal shutdowns, starting from GreatVoyage-v4.6.0 (Socrates), the Checkpoint V2 mechanism is introduced. The V2 mechanism will save multiple checkpoints on the disk, corresponding to multiple solidified block data, which is used to restore the data when the node database is damaged.

This function needs to periodically clean up expired checkpoints. Since the operation of deleting expired checkpoints is not an atomic operation, this will lead to the situation that expired checkpoints may not be completely deleted when the machine is abnormally shut down, that is, there may be damaged checkpoints. Therefore, the Periander version optimizes the automatic repair function of checkpoint v2. When restoring data, all expired checkpoints are skipped, avoiding the situation of using damaged checkpoints to repair data, and improving the stability of nodes.

Forethought in all things.

---Periander

GreatVoyage-v4.7.1.1 (Pittacus)

GreatVoyage-v4.7.1.1 (Pittacus) version optimized multiple interfaces and removed APIs involving sensitive information.

Please see the details below.

API

1. Remove APIs involving sensitive information

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:

  • HTTP
    • createaddress: Create an address based on the specified password
    • generateaddress: Create address randomly
    • easytransfer: Transfer TRX with password
    • easytransferbyprivate: Transfer TRX with private key
    • easytransferasset: Transfer TRC10 token with password
    • easytransferassetbyprivate: Transfer TRC10 token with private key
    • gettransactionsign: Sign transaction with private key
    • addtransactionsign: Sign transaction with private key which is mainly used to sign multi-signature transactions
  • gRPC
    • CreateAddress: Create an address based on the specified password
    • GenerateAddress: Create address randomly
    • EasyTransfer: Transfer TRX with password
    • EasyTransferByPrivate: Transfer TRX with private key
    • EasyTransferAsset: Transfer TRC10 token with password
    • EasyTransferAssetByPrivate: Transfer TRC10 token with private key
    • GetTransactionSign: Sign transaction with private key
    • GetTransactionSign2: Sign transaction with private key
    • AddSign: Sign transaction with private key which is mainly used to sign multi-signature transactions

TIP: https://github.com/tronprotocol/tips/issues/534

Source Code: https://github.com/tronprotocol/java-tron/pull/5096

2. Optimize resource delegate information query interface

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

Other Changes

1. Optimize the update logic of the 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/5120

Whatever you do, do it well.

---Pittacus

GreatVoyage-v4.7.1(Sartre)

GreatVoyage-v4.7.1(Sartre) introduces several important optimizations and updates. The optimized block synchronization logic improves the stability of block synchronization; the optimized node IP setting improves the availability of nodes; the optimized node log improves the maintainability of nodes.

Please see the details below.

Cores

1. Optimize the node IP setting

When the node starts, it will obtain the local IP of the node, and then use this IP to communicate with other nodes in the network. If the node cannot access the external network, it will not be able to obtain the local IP. At this time, the node will set its local IP to the default value of 0.0.0.0, and this IP will make the node even unable to communicate with other nodes successfully in the LAN. So the GreatVoyage- v4.7.1 (Sartre) version changes the default IP of the node. If the node cannot obtain the local IP, it will set its local IP to 127.0.0.1, so that even if the node cannot access the external network, it can still communicate with other nodes in the LAN normally.

Source code: https://github.com/tronprotocol/java-tron/pull/4990

2. Optimize block synchronization logic

During the block synchronization process, the node will maintain a block request list, which contains the IDs of all blocks that have sent requests to other nodes. When the connection between the node and node A is abnormally disconnected with a very small probability, the block ID that is being requested to node A will be deleted from the request list. After that, the node will think that it has not requested the block, and then send the block request to node B and add the block ID to the request list again. Before this node disconnects with node A, the requested block may have already been sent by node A，and it is received by the node after disconnecting. Since the node found that the block is from node A that has already been disconnected, it will discard the block, and delete the block ID from the request list again, this will lead to the node to send a request for the same block to node B again. When Node B receives the repeated block request, it will consider it an illegal message and disconnect from the node.

In order to improve the efficiency of block synchronization in concurrent scenarios, the GreatVoyage-v4.7.1 (Sartre) version optimized the update mechanism of the block request list, and saved the block ID and node information in the request list at the same time. In the above scenario, after receiving a block from node A that has been disconnected, the same block ID requested from node B will not be deleted from the request list to ensure that it will not be disconnected from node B, thereby improving the stability of block synchronization.

Source code: https://github.com/tronprotocol/java-tron/pull/4995

When a node synchronizes blocks from other nodes, it needs to obtain the local block chain summary of the node. The summary includes the IDs of several blocks including the local header block. In versions prior to GreatVoyage-v4.7.1 (Sartre), when obtaining the summary, the node will first query the Dynamic database to obtain the block height, and then query the Block database to obtain the ID of the block according to the block height. However, when the node is processing a block, the writing to each database is not carried out at the same time. The node will first update the Dynamic database, and then update other databases such as Block. As a result, in versions prior to GreatVoyage-v4.7.1 (Sartre), the following scenario will occur with a very small probability: when the latest block information is only written into the Dynamic database, but have not yet been written into the block database, the node starts to obtain the summary. In this situation the corresponding block ID will not be found in the block database according to the head block height obtained from the Dynamic database, leading to the summary reading fail. The GreatVoyage-v4.7.1 (Sartre) version optimizes the block chain summary acquisition logic. The ID of the head block is directly obtained from the Dynamic database instead of the Block database, which improves the stability of summary reading.

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

API

1. Optimize the list of solidified block APIs

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

2. Optimize resource delegation relationship API

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.

Other Changes

1. Optimize LiteFullNode detection logic

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

2. Optimize node log output

The Database Log

Starting from GreatVoyage-v4.7.0.1 (Aristotle), the logs of LevelDB or RocksDB databases are redirected to the node log file, which simplifies the difficulty of database troubleshooting. GreatVoyage-v4.7.1 (Sartre) further optimizes the log module, Output database logs to a separate db.log file to make node logs clearer.

Source code: https://github.com/tronprotocol/java-tron/pull/4985 https://github.com/tronprotocol/java-tron/pull/5001 https://github.com/tronprotocol/java-tron/pull/5010

The Event Service Module Log

Remove invalid logging output for event service module.

Source code: https://github.com/tronprotocol/java-tron/pull/4974

The network module log

Optimized the log output of the network module, outputting Error-level logs for received abnormal blocks, and outputting Warn-level logs for network requests that have already timed out, improving the efficiency of troubleshooting network-related problems.

Source code: https://github.com/tronprotocol/java-tron/pull/4977

The more sand that has escaped from the hourglass of our life, the clearer we should see through it.

---Sartre

GreatVoyage-v4.7.0.1(Aristotle)

GreatVoyage-v4.7.0.1 (Aristotle) introduces several important optimizations and updates. The new stake mechanism, Stake 2.0, improves the flexibility of the resource model and the stability of the stake system; the dynamic energy model helps to promote ecologically balanced development; the secondary cache mechanism optimizes the database reading performance, improves transaction execution performance, and expands the network throughput; uses the libp2p library as the java-tron P2P network module to make the code structure clearer and reduce code coupling; optimizes the log output, redirect the logs of LevelDB and RocksDB to java-tron log files; integrate more tools and functions into the ‘Toolkit.jar’ toolbox to bring users a more convenient development experience.

Please see the details below.

Cores

1. A new stake model - Stake 2.0

GreatVoyage-v4.7.0.1 (Aristotle) version introduces a new stake model, Stake 2.0, aiming to establish a more flexible, efficient and stable stake system. Compared with the current Stake 1.0 model, Stake 2.0 has been improved in the following aspects,

  • Staking and delegating are separated

    In Stake 1.0, staking and resource delegating are combined in one operation. The resource recipient must be specified in the operation. After the staking is completed, the resource will be delegated to the designated resource recipient. The unstaking and undelegating are also combined in one operation. If you want to cancel the delegating, you must unstake the corresponding TRX as well. Stake 2.0 separates staking and resource delegating into two independent operations. The user executes the staking first, the resource selected is allocated to the owner now. And then executes the delegate operation to assign the resource to the designated address. Unstaking and undelegating are also separated into two operations. If the user wants to cancel the delegating, he or she can directly perform the undelegate operation without unstaking and then can delegate the resource to others again as needed. Separation of staking/unstaking and delegating/undelegating simplifies user operations and reduces operational complexity.

  • Resource Fragmentation Management

    In Stake 1.0, one unstake operation will unstake all the staked TRX, and the specified amount of TRX cannot be unstaked. This is optimized in Stake 2.0 now. We can specify an amount of TRX to unstake, as long as the specified amount is less than or equal to the total staked amount. In Stake 1.0, to cancel a certain resource delegate, you can only cancel all delegated resources at once, and you cannot cancel by specifying an amount. Stake 2.0 has also brought partially undelegate, we can now undelegate part of the delegated resources as needed, which improves the flexibility of resource management.

  • Unstake Lock Period and Delayed Arrival of Unstaked TRX

    In Stake 1.0, after staking TRX, we need to wait 3 days before releasing the TRX. After the release, the TRX staked will immediately arrive in the owner’s account. In Stake 2.0, after the staking is completed, the TRX staked can be released at any time, but it needs to wait for ’N’ days. After the ’N’ days delay, the TRX released could be withdrawn to the owner’s account. ’N’ is the TRON network parameter. When the TRX market fluctuates violently, due to the delayed arrival of funds, it will no longer trigger a large number of stake or unstake operations, which improves the stability of the stake model, and at the same time will not cause a large number of funds to flood into the market and aggravate market volatility. It helps to build a more anticipated future of the entire network circulation for the network participants.

  • TVM Supports Staking and Resource Management

    In Stake 2.0, the TRON virtual machine integrates instructions related to stake and resource management. Users can perform TRX stake/unstake operations in smart contracts, as well as perform resource delegate/undelegate operations.

For more details on Stake 2.0, please refer to What is Stake 2.0?

The new stake mechanism is a dynamic parameter in the TRON network. After GreatVoyage-v4.7.0.1 (Aristotle) is deployed, it is disabled by default and can be enabled by initiating a proposal vote.

2.Enhance database query performance

java-tron uses memory and disk databases for data storage. The solidified block data will be stored in multiple disk databases, and the unsolidified data will be stored in memory. When a block is solidified, the corresponding in-memory data is written to the disk databases. When querying data, first query the data in memory, if not found, then query the disk database. The disk database query is time-consuming. Therefore, the GreatVoyage-v4.7.0.1 (Aristotle) version optimizes the database query performance and adds a secondary cache before performing the underlying disk database operation. When data is written to the disk, the data is also written to the second-level cache. When the disk database needs to be queried, if the data to be queried exists in the second-level cache, it will be returned directly without querying the disk database. The second-level cache reduces the number of queries to the disk database, improves transaction execution speed, and improves network throughput.

3. Optimize block production process

When a node produces a block, it will sequentially verify and execute all transactions that can be packaged into the block, and each transaction verification and execution will involve the acquisition of block data, such as block number, block size, block transaction information, etc. In versions prior to GreatVoyage-v4.7.0.1 (Aristotle), when nodes package transactions, block data is recalculated during the process of verifying and executing each transaction, which includes many repeated calculations.

In order to improve the efficiency of packaging transactions, the GreatVoyage-v4.7.0.1 (Aristotle) optimizes the block production process, only calculates the block data once and updates the data only when necessary, thus greatly reducing the number of block data calculations and improving the block packaging efficiency.

4. Add transaction hash cache

When a node processes a block, it will use the transaction hash value multiple times. In versions before GreatVoyage-v4.7.0.1 (Aristotle), the transaction hash value is calculated as it is used, and the calculation of the transaction hash value is time-consuming, which leads to slower block processing. Therefore, GreatVoyage-v4.7.0.1 (Aristotle) adds a transaction hash cache, the transaction hash will be directly obtained from the cache when used. Only when the transaction data changes, the transaction hash is recalculated. The newly added cache reduces unnecessary transaction hash calculations and improves block processing speed.

5. Add libp2p module as java-tron p2p network protocol implementation

Starting from GreatVoyage-v4.7.0.1 (Aristotle), the libp2p library will be directly used as the P2P network module of java-tron, instead of using the original p2p network stack, so that the code structure is clearer, the code coupling is lower, and is easy to maintain.

TVM

1. Add new instructions to support Stake 2.0

GreatVoyage-v4.7.0.1 (Aristotle) introduces Stake 2.0, TVM will support Stake 2.0 related stake and resource delegate instructions simultaneously. Users can perform stake and resource delegate operations through smart contracts, which further enriches the application scenarios of smart contracts on the TRON network. A total of 6 instructions from 0xda to 0xdf have been added to TVM:

ID TVM instruction Description
0xda FREEZEBALANCEV2 Performs the same operation as the system contract FreezeBalanceV2 for contract account
0xdb UNFREEZEBALANCEV2 Performs the same operation as the system contract UnfreezeBalanceV2 for contract account
0xdc CANCELALLUNFREEZEV2 Cancel all pending unfreeze balances for contract account
0xdd WITHDRAWEXPIREUNFREEZE Performs the same operation as the system contract WithdrawExpireUnfreeze for contract account
0xde DELEGATERESOURCE Performs the same operation as the system contract DelegateResource for contract account
0xdf UNDELEGATERESOURCE Performs the same operation as the system contract UnDelegateResource for contract account

A total of 11 precompiled contracts from 0x100000b to 0x1000015 have been added to TVM:

ID Precompiled Contract Description
0x100000b GetChainParameter Query the specific chain parameters
0x100000c AvailableUnfreezeV2Size Query the size of the available unfreeze queue for target address
0x100000d UnfreezableBalanceV2 Query the unfreezable balance of a specified resourceType for target address
0x100000e ExpireUnfreezeBalanceV2 Query the withdrawal balance at the specified timestamp for target address
0x100000f DelegatableResource Query the amount of delegatable resources(unit: SUN) of the specified resourceType for the target address
0x1000010 ResourceV2 Query the amount of resources(unit: SUN) of a specific resourceType delegated by from address to target address
0x1000011 CheckUnDelegateResource Check whether the contract can recycle the specified amount of resources of a specific resourceType that have been delegated to target address, and return the amount of clean resource(unit: SUN), the amount of dirty resource(unit: SUN) and the restore time
0x1000012 ResourceUsage Query the usage of a specific resourceType of resources for target address, and return the amount of usage(unit: SUN) and the restore time
0x1000013 TotalResource Query the total amount of resources(unit: SUN) of a specific resourceType for target address
0x1000014 TotalDelegatedResource Query the amount of delegated resources of a specific resourceType for target address
0x1000015 TotalAcquiredResource Query the amount of acquired resources(unit: SUN) of a specific resourceType for target address

Stake 2.0 is a dynamic parameter in the TRON network. After GreatVoyage-v4.7.0.1 (Aristotle) is deployed, it is disabled by default and can be enabled by initiating a proposal vote.

2. Dynamic energy model

The dynamic energy model is a scheme to dynamically adjust the future energy consumption of the contract based on the known energy usage of the contract. If a contract uses too many resources in one cycle, then the next cycle in this contract, a certain percentage of punitive consumption will be added, and users who send the same transaction to this contract will cost more energy than before. When the contract uses resources reasonably, the energy consumption generated by the user calling the contract will gradually return to normal. Through this mechanism, the allocation of energy resources on the chain will be more reasonable, and excessive concentration of network resources on a few contracts will be prevented.

For more information about the dynamic energy model: Introduction to Dynamic Energy Model

The dynamic energy model is a dynamic parameter in the TRON network. After GreatVoyage-v4.7.0.1 (Aristotle) is deployed, it is disabled by default and can be enabled by initiating a proposal vote.

3. Optimize the return value of the chainId opcode

Starting from the GreatVoyage-v4.7.0.1 (Aristotle) version, the return value of the chainid opcode is changed from the block hash of the genesis block to the last four bytes of the block hash of the genesis block, keeping the return value of the chainid opcode consistent with the return value of the java-tron JSON-RPC eth_chainId API.

The return value optimization of the chainId opcode is a dynamic parameter of the TRON network. It is disabled by default after GreatVoyage-v4.7.0.1 (Aristotle) is deployed, and can be enabled by initiating a proposal.

API

1. Add APIs to support Stake 2.0

GreatVoyage-v4.7.0.1 (Aristotle) adds 10 APIs to support Stake 2.0:

API Description
/wallet/freezebalancev2 Stake TRX to obtain resources
/wallet/unfreezebalancev2 Unstake TRX
/wallet/delegateresource Delegate resources to other account
/wallet/undelegateresource Undelegate resource
/wallet/withdrawexpireunfreeze Withdraw the funds that has expired the N lock-up period
/wallet/getavailableunfreezecount Query the remaining times of available unstaking operation
/wallet/getcanwithdrawunfreezeamount Query the withdrawable balance at the specified timestamp
/wallet/getcandelegatedmaxsize Query the amount of delegatable resources of the specified resource type for target address
/wallet/getdelegatedresourcev2 Query the resource delegate amount from an address to the target address (unit: sun)
/wallet/getdelegatedresourceaccountindexv2 Query the resource delegate amount from an address to the target address (unit: sun)

For detailed information of new APIs, please refer to: What is Stake 2.0?

2. Add energy estimation API

In versions prior to GreatVoyage-v4.7.0.1 (Aristotle), users can estimate the energy consumption for executing smart contract transactions through the /wallet/triggerconstantcontract interface, and then set the feelimit parameter of the transaction according to the estimated consumption. However, since some smart contract transactions may call other smart contracts, it is possible that the estimated feelimit parameter is inaccurate.

Therefore, the GreatVoyage-v4.7.0.1(Aristotle) version adds an energy estimation interface /wallet/estimateenergy, and the feelimit estimated by this interface is reliable in any case. The energy_required field in the return value of this interface indicates the estimated amount of energy required for the successful execution of this smart contract transaction. So user can calculate the feelimit parameter based on this field: feelimit = energy_required * energy unit price, currently the unit price of energy is 210 sun.

If the execution of the estimated interface call fails for some reason, the value of the energy_required field will be 0, and this field will not be displayed in the return value. At this time, you can check the reason for the execution failure for the estimated interface call through the result field.

After the GreatVoyage-v4.7.0.1 (Aristotle) version is successfully deployed, this API is closed by default. To open this interface, the two configuration items vm.estimateEnergy and vm.supportConstant must be enabled in the node configuration file at the same time. The default values of vm.estimateEnergy and vm.supportConstant are both false.

An example of /wallet/estimateenergy call is as follows:

curl --location --request POST 'https://api.nileex.io/wallet/estimateenergy' \
--header 'Content-Type: application/json' \
--data-raw '{
     "owner_address": "TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",
     "contract_address": "TXLAQ63Xg1NAzckPwKHvzw7CSEmLMEqcdj",
     "function_selector": "transfer(address,uint256)",
     "parameter": "0000000000000000000000002EEF13ADA48F286066F9066CE84A9AD686A3EA480000000000000000000000000000000000000000000000000000000000000004",
     "visible": true
}'

Other Changes

1. Optimize Gradle compilation parameters

GreatVoyage-v4.7.0.1(Aristotle) optimizes the compiling parameters of Gradle, configuring JVM minimum heap size to 1GB, which improves the compilation speed of java-tron.

2. Optimize node conditional stop function

In order to facilitate data backup or data statistics for node deployers, starting from GreatVoyage-v4.5.1 (Tertullian), nodes support stopping under specific conditions. Users can set the conditions for node stopping through the node configuration file, and the node will stop running when the conditions are met. It supports three stop conditions to be set at the same time, and the node is stopped when any condition is met. These three conditions include block time, block height, and the number of blocks that need to be synchronized from the start to the stop of the node. However, since multiple stop conditions are allowed to be set at the same time, when the user only needs one condition, the other 2 conditional configuration items in the configuration file need to be deleted, so if the user forgets to delete, the node may stop on an unexpected block. However, there are actually no application scenarios that require multiple conditions to be set at the same time. Therefore, the GreatVoyage-v4.7.0.1 (Aristotle) version optimizes the node conditional stop function. The optional configuration parameters remain unchanged, but only one valid parameter is allowed to be set at the same time. If the node deployer sets multiple parameters, the node will report an error and exit run. This optimization simplifies the complexity of users’ settings.

In versions prior to GreatVoyage-v4.7.0.1 (Aristotle), there are two versions of the database, v1 and v2. Users can choose from them through the configuration item db.version. Since the v2 version adopts the memory + disk database mode, it supports the expansion of the underlying database, the correct data recovery function under abnormal conditions, etc., and has obvious advantages compared with v1. Therefore, in order to make the code structure clearer, starting from GreatVoyage-v4.7.0.1 (Aristotle), the code related to the database v1 version and the database version configuration item db.version has been deleted. Users no longer need to configure the database version, only v2 is available from now on, which reduces the complexity of configuring nodes.

4. Optimize database log output

In versions prior to GreatVoyage-v4.7.0.1 (Aristotle), the node logs do not include the underlying logs output by LevelDB or RocksDB itself, making it difficult to troubleshoot database read and write problems. Therefore, the GreatVoyage-v4.7.0.1 (Aristotle) optimizes the database log and redirects the output of the underlying log of the LevelDB or RocksDB data module to the node log file, which simplifies the difficulty of database troubleshooting and improves the reliability of node operation and maintenance efficiency.

5. Make snapshot flush speed configurable

Nodes newly added to the network need to synchronize block data from other nodes, and the nodes will first save the synchronized block data in memory, and then store it on disk. In versions prior to GreatVoyage-v4.7.0.1 (Aristotle), when a node synchronizes the blocks, a flush operation will write the data of 500 blocks from the memory to the disk, so more than 500 blocks data will be kept in the memory, and each block data is associated through a linked list. When querying data, it will first search in these more than 500 blocks in sequence, and then query the disk database when the data to be queried is not found, but traversing more than 500 block data reduces the efficiency of data query.

Therefore, starting from the GreatVoyage-v4.7.0.1 (Aristotle) version, the number of snapshot flush can be configured, and the maximum number of snapshot flush at one time can be set through the configuration item: storage.snapshot.maxFlushCount to maximize the efficiency of database query and improve block processing speed. If the configuration item is not set, the maximum number of snapshots flush into the dish is the default value of 1.

6. Toolkit.jar Integration

DBConvert.jar is a database conversion tool, which can convert LevelDB into RocksDB; LiteFullNodeTool.jar is a light FullNode tool, which can convert FullNode data into LiteFullNode data. Starting from GreatVoyage-v4.7.0.1 (Aristotle), DBConvert.jar and LiteFullNodeTool.jar have been integrated into the Toolkit.jar toolbox, and a database copy function is added which can realize fast Node database copy. In the future, the tools around java-tron will be gradually integrated into the Toolkit.jar toolbox in order to facilitate tool maintenance and developer use. The commands for using the new functions of the Toolkit.jar toolbox are as follows:

// Convert LevelDB data to RocksDB data
java -jar Toolkit.jar db convert -h
// convert FullNode data into LiteFullNode data
java -jar Toolkit.jar db lite -h
// Database copy
java -jar Toolkit.jar db copy -h

Courage is the first of human qualities because it is the quality that guarantees others.

--- Aristotle

GreatVoyage-v4.6.0 (Socrates)

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.

Core

1. Optimize delegate relationship index structure

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.

Therefore, GreatVoyage-v4.6.0 (Socrates) optimizes the index storage structure of the resource delegate relationship and changes it from a list to a key-value pair, so as to complete the querying and modification of its data in a constant time, which greatly speeds up the execution speed of the delegation related transactions and improves network throughput.

The delegate relationship storage optimization is a dynamic parameter of the TRON network. It is disabled by default and can be enabled by initiating a proposal.

2. Add transaction memo fee proposal

Starting from GreatVoyage-v4.6.0 (Socrates), a memo fee will be charged for transactions with a memo. By increasing the cost, the fee will reduce the number of low-value transactions, so as to improve the security and reliability of the TRON network.

The memo fee is a dynamic parameter of the TRON network. After GreatVoyage-v4.6.0 (Socrates) is deployed, the default value is ‘0’, and the unit is ‘sun’. It can be enabled by specifying a non-zero value by initiating a proposal, for example, ‘1000000’, indicating that the transaction with memo will require an additional 1 TRX fee.

3. Add optimized reward algorithm proposal

Many voters in the TRON network will accumulate rewards for a long time before withdrawing them. The interval between two withdrawals of rewards is often very long. In versions prior to GreatVoyage-v4.6.0 (Socrates), for the transaction to withdraw rewards, it will calculate and accumulate rewards for each maintenance period since the last withdrawal of rewards, so the longer the time since the last withdrawal of rewards, the more time-consuming it will be to calculate the reward. Therefore, GreatVoyage-v4.6.0 (Socrates) optimizes the calculation algorithm of voting rewards. Instead of accumulating the rewards of each maintenance period, the sum of unwithdrawn rewards can be obtained by subtracting the total number of rewards recorded in the maintenance period of the last reward withdrawal from the total rewards recorded in the previous maintenance period. This algorithm realizes the calculation of the total number of unclaimed rewards in a constant time, which greatly improves the calculation efficiency and speeds up the execution of reward calculation, thereby improving the throughput of the network.

The optimized reward algorithm is a TRON network parameter and is disabled by default once GreatVoyage-v4.6.0 (Socrates) is deployed, and can be enabled by voting through a proposal.

4. Upgrade checkpoint mechanism to v2 in database module

The Checkpoint is a recovery mechanism established to prevent database damage caused by the exceptional shutdown. java-tron uses memory and multi-disk databases for data storage. The data of the solidified block will be stored in multiple business databases. Unsolidified data is stored in the memory. When a block is solidified, the corresponding memory data will be written to relevant databases. However, since the writing to multiple business databases is not an atomic operation, if there is an unexpected downtime due to some reason, then all the data in the block may not be able to be written to the disk, and the node will not be able to restart due to database corruption.

Therefore, before the memory data is written to the disk, a checkpoint would be created. The checkpoint contains all the data that needs to be written to each business database this time. After the checkpoint is created, first writes the checkpoint data to an independent Checkpoint database, and then performs the operation of writing the business database, and the Checkpoint database always retains the latest solidified block data. If the business database is damaged due to system shutdown, after the node restarts, the business database will be recovered through the data previously saved in the checkpoint database.

At present, the Checkpoint mechanism can deal with the vast majority of downtime situations, but there is still a small probability that the business database will be damaged due to downtime. At present, the data writing of LevelDB is asynchronous. The program calls LevelDB to request to write the data to the disk. In fact, the data is only written into the cache of the operating system, and then the operating system will decide when to actually write to the disk according to its own strategy. If an unexpected downtime occurs at the time when the node just finished writing to the Checkpoint database and continues to write to the business database, it is possible that the data written to the Checkpoint database is not actually written to the disk by the operating system. In this case, the node would fail to restart properly because the Checkpoint database has no recovery data.

In order to solve this problem, GreatVoyage-v4.6.0 (Socrates) upgrades the V2 version of Checkpoint implementation. The Checkpoint mechanism V2 will store multiple solidified blocks data. So that even if the latest solidified block data is not written successfully to the Checkpoint database due to abnormal shutdown, the historical solidified block data can be used to restore the business database when the node restarts.

The Checkpoint mechanism V2 is disabled by default in the configuration file. This function can be enabled by modifying the configuration. It should be noted that if a node has enabled the checkpoint V2 and has been running for a certain period of time, it would not be able to roll back to V1 anymore.

5. Optimize block production priority between active and backup nodes

If the super representative deploys the active and backup nodes, the connection between the nodes will be maintained. When the active and backup nodes are temporarily disconnected due to network problems, the backup node will consider that the active node is invalid and take over the block production. This will cause a duplicate block production process as both the active and backup nodes will produce blocks at the same time. In versions prior to GreatVoyage-v4.6.0 (Socrates), when the active and backup nodes receive blocks of the same height block generated by each other, both of them will suspend for 1-9 block production cycles. That is, the super representative will miss 1-9 blocks.

The GreatVoyage-v4.6.0 (Socrates) optimizes the priority of block production logic. When the situation above happens, both nodes will compare the hash value of the block produced by the other node. The node with a larger block hash will continue to produce blocks, and the node with smaller block hash will suspend a block production cycle, then continue to produce blocks, and compare the block hash again. A total of 27 super representatives will generate blocks sequentially, so it takes 81 seconds to skip a block production cycle. During this period, if the connection problem between them is a short-term network failure, there will be enough time to recover it. In addition, after receiving these two blocks, other nodes will also choose the block with a larger hash and discard the one with a smaller hash. This implementation will significantly improve the block production efficiency during obstructed network connections between active and backup nodes and network stability.

6.Optimize the Kademlia algorithm for the network module

The java-tron node ID is a random number, which will be regenerated every time the node is started. In the implementation of the Kademlia algorithm of java-tron, the distance of the node will be calculated according to the node ID, and then the node information will be put into the corresponding K bucket according to the distance. If the node in the K bucket is restarted for some reason, the node ID will change. When it is detected that the node is offline again, the distance calculated according to the latest node ID has been unable to locate the original K bucket, therefore it is not able to delete the node from the bucket. Too many such nodes restarted will cause too much invalid data to be stored in the K bucket of the node.

Therefore, the GreatVoyage-v4.6.0 (Socrates) optimizes the Kademlia algorithm, and uses a hash table to record the discovered nodes. The distance of a node is only calculated once when it is written into the K bucket for the first time and is assigned to the ‘distance’ field of the node, and then the node is added to the hash table. In the future, the node distance will be obtained directly through this field. Even if the node ID changes after the node is restarted, the distance of the node in the Hash table will not be updated. When the node is detected to be offline, the corresponding node can be found from the hash table according to the node IP, and then the distance to the node can be obtained through the node distance field, at last the node information can be deleted from the K bucket.

Other Changes

1. Merge ArchiveManifest.jar into Toolkit.jar

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.

2. Add prometheus metrics for network module

GreatVoyage-v4.6.0 (Socrates) adds three new Prometheus metrics related to the network module: block fetching delay, block receiving delay, and message processing delay. New metrics help with network health monitoring of the node.

3. Add the --help command option

GreatVoyage-v4.6.0(Socrates) adds ‘help’ command line options to check all parameters and instructions. Please check the example below, 

$ java -jar FullNode.jar --help

Name:
    FullNode - the java-tron command line interface

Usage: java -jar FullNode.jar [options] [seedNode <seedNode> ...]

VERSION:
4.5.2-d05f766

TRON OPTIONS:
-v, --version           Output code version
-h, --help              Show help message
-c, --config            Config file (default:config.conf)
--log-config            Logback config file
--es                    Start event subscribe server

DB OPTIONS:
-d, --output-directory          Data directory for the databases (default:output-directory)

WITNESS OPTIONS:
-w, --witness               Is witness node
-p, --private-key           Witness private key

VIRTUAL MACHINE OPTIONS:
--debug         Switch for TVM debug mode. In debug model, TVM will not check for timeout. (default: false)

4. Optimize LiteFullNodeTool.jar

LiteFullNodeTool.jar is a light node tool of java-tron. Its main function is to convert the fullnode database into a light node database. GreatVoyage-v4.6.0 (Socrates) optimizes the tool and improves the convenience and stability of the tool.

5. Optimize the return value of eth_getBlockByHash and eth_getBlockByNumber APIs

In order to be better compatible with Ethereum's JsonRPC 2.0 protocol interface, GreatVoyage-v4.6.0(Socrates) changes the unit of the timestamp field in the return value of the eth_getBlockByHash and eth_getBlockByNumber APIs from milliseconds to seconds, making the return values of these two APIs fully compatible with Ethereum Geth.

To move the world we must move ourselves.

--- Socrates

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

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 Source Code: https://github.com/tronprotocol/java-tron/pull/4551

2. Optimize transaction cache

The node uses the transaction cache to determine whether the newly received transaction is a duplicate transaction. In versions prior to GreatVoyage-v4.5.2 (Aurelius), the transaction cache is a hashmap data structure, which saves transactions in the latest 65536 blocks. The hashmap allocates memory for each transaction separately. Therefore, the transaction cache will occupy nearly 2GB of memory during program runtime, meanwhile, frequent memory requests will trigger frequent JVM garbage collection which indirectly affects the performance of the node. To solve this issue, the GreatVoyage-v4.5.2 (Aurelius) version optimizes the implementation of the transaction cache, using the bloom filter instead of the hashmap, the bloom filter uses a fixed and extremely small memory space to record recent historical transactions, which greatly reduces the memory usage of the transaction cache and improve the node performance.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-440.md Source Code：https://github.com/tronprotocol/java-tron/pull/4538

3. Optimize nodes connection strategy

In versions prior to GreatVoyage-v4.5.2 (Aurelius), when the number of remote nodes connected by a node has reached the maximum value, the node will reject connection requests from new remote nodes. With the increase of such fully connected nodes in the network, it will become more and more difficult for the newly added nodes to establish connections with other nodes in the network.

In order to speed up the connection process between nodes in the network, the GreatVoyage-v4.5.2 (Aurelius) version optimizes the P2P node connection strategy. It will periodically check the number of TCP connections of the node. When the number of connections is full, a certain disconnection strategy is adopted to disconnect one or two nodes to increase the possibility of a newly added node in the network successfully connecting to it, thereby improving the efficiency of establishing connections between P2P nodes in the network and improving network stability. Please note that the nodes configured in the node.active and node.passive lists in the configuration file are trusted nodes and will not be disconnected.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-425.md Source Code: https://github.com/tronprotocol/java-tron/pull/4549

4. Optimize block generating logic

In versions prior to GreatVoyage-v4.5.2 (Aurelius), for pre-executed normal transactions, they may encounter JVM GC pauses during packaging which can result in transaction execution timeout and being discarded. Therefore, the GreatVoyage-v4.5.2 (Aurelius) version optimizes the block generating logic. For a pre-executed normal transaction, if it executes time out during packaging, a retry operation is taken to avoid transaction discard caused by JVM GC pause during the packaging.

Source Code：https://github.com/tronprotocol/java-tron/pull/4387

5. Optimize fork switching logic

Micro-forks occur in the TRON network occasionally. The chain switching behavior will occur when a micro-fork happens. The chain switching will roll back blocks, and the transactions in the rolled back block will be put back into the transaction pending queue. When these transactions are repackaged and executed, the execution results may be inconsistent due to chain switching. In versions prior to GreatVoyage-v4.5.2 (Aurelius), the entire process refers to the same transaction object, so chain switching may lead to the transaction result in the rolled back block being changed. When the chain switching occurs again and the original chain is switched back, the transaction on the original chain will be executed again, at this time, it will report a Different resultCode error, which will cause the node to stop synchronizing.

Therefore, the GreatVoyage-v4.5.2 (Aurelius) version optimizes the chain-switching logic. When a block is rolled back, a new transaction object is created for the transaction in the rolled-back block, so as to avoid the modification of the transaction result and improve the node's stability for fork handling.

Source Code：https://github.com/tronprotocol/java-tron/pull/4583

6. Add database storage partition tool

As the data on the chain grows, the disk space of the FullNode may be insufficient, and a larger capacity disk needs to be replaced. So starting from the GreatVoyage-v4.5.2 (Aurelius) version, a database storage partition tool is provided, which can migrate some databases to other disk partitions according to the user's configuration, so users only need to add disks according to capacity requirements, no need to replace the original disk, that is convenient for users to expand the disk capacity, and at the same time reduces the cost of running a node.

Source Code：https://github.com/tronprotocol/java-tron/pull/4545 https://github.com/tronprotocol/java-tron/pull/4559 https://github.com/tronprotocol/java-tron/pull/4563

API

1. New block header query API

From the GreatVoyage-v4.5.2 (Aurelius) version, a new block header query API is added, which only returns the block header information, not the transaction information in the block. Users can obtain the block header information without querying the entire block. This not only reduces the network I/O load of the node, and since the block does not carry transaction information, the serialization time is reduced, the interface delay is reduced, and the query efficiency is improved.

Source Code：https://github.com/tronprotocol/java-tron/pull/4492 https://github.com/tronprotocol/java-tron/pull/4552

2. New historical bandwidth unit price query API

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

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 https://github.com/tronprotocol/java-tron/pull/4540

2. Optimize eth_estimateGas and eth_call API

The GreatVoyage-v4.5.2 (Aurelius) version optimizes the eth_estimateGas and eth_cal JSON-RPC interfaces; they can return error information when smart contract transaction execution is interrupted.

Source Code：https://github.com/tronprotocol/java-tron/pull/4570

3. Enhance the fault tolerance of the interface

The GreatVoyage-v4.5.2 (Aurelius) version optimizes multiple API interfaces, enhances its fault tolerance for parameters, and improves the stability of API interfaces.

Source Code：https://github.com/tronprotocol/java-tron/pull/4560 https://github.com/tronprotocol/java-tron/pull/4556

The universe is change; our life is what our thoughts make it.

--- Aurelius

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

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.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-383.md Source Code: https://github.com/tronprotocol/java-tron/pull/4319

2. Optimize account TRC-10 asset storage structure

In versions prior to GreatVoyage-v4.5.1 (Tertullian), when there were too many TRC10 assets in the account, the content of the account stored in the database was large, resulting in the deserialization of the account during the transaction execution process is very time-consuming , therefore, the GreatVoyage-v4.5.1 (Tertullian) version adds a new proposal to optimize the asset structure of the account, allowing TRC-10 assets to be separated from the account and stored separately in a key-value data structure. That will reduce the content of the account structure, speed up the deserialization operation of the account and reduce the execution time of the transaction, thereby increasing the network throughput and improving the network performance.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-382.md
Source Code: https://github.com/tronprotocol/java-tron/pull/4392

3. Optimize light node synchronization

Since light nodes do not store complete block data, there is a possibility that a node connects to a light node which does not have the block the node wants to synchronize with, in this situation, the light node will actively disconnect the connection. In versions prior to GreatVoyage-v4.5.1 (Tertullian), nodes may repeatedly establish connections with such light nodes, and then be disconnected by the other part, which greatly affects the efficiency of synchronizing blocks between nodes. Therefore, in the GreatVoyage-v4.5.1 (Tertullian) version, the logic of establishing a connection with light nodes has been optimized, and the two fields of "node type" and "node's lowest block" are added to the handshake message between nodes, and the nodes will save the handshake messages with each node. If the highest block of the current node is lower than the lowest block of the light node, it will actively disconnect from the light node, and the next time it establishes a connection with the node, it will filter out such nodes to avoid more invalidations connection, which improves the efficiency of synchronization between nodes.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-388.md Source Code: https://github.com/tronprotocol/java-tron/pull/4323

4. Optimize block broadcasting

The GreatVoyage-v4.5.1 (Tertullian) version optimizes the block broadcast logic, so that the fast forward node only broadcasts the block to the three super representative nodes that will produce blocks next (the number of broadcasted super representative nodes can be changed through the configuration file) to ensure that the super representative node can obtain the latest block in time, which improves the efficiency of block production.

Source Code: https://github.com/tronprotocol/java-tron/pull/4336

5. Optimize fetch block process

Due to network reasons, the node may not receive the new broadcasted block. In versions before GreatVoyage-v4.5.1 (Tertullian), when the block acquisition times out, the node will acquire the block through the P2P synchronization process, but the process is complicated and time-consuming. Therefore, the GreatVoyage-v4.5.1 (Tertullian) version optimizes the process of obtaining the latest block. The node will first select a node according to the status of each node, and then directly send the block obtaining message FetchInvDataMessage to this node to obtain the latest block, which saves most of the time in the block synchronization process, speeds up the acquisition of the latest block, and improves the stability of the node.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-391.md Source Code: https://github.com/tronprotocol/java-tron/pull/4326

6. Support prometheus metric protocol interface

Starting from the GreatVoyage-v4.5.1 (Tertullian) version, the node provides an open source system monitoring tool - prometheus’s protocol interface, and users can monitor the health status of the node more conveniently.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-369.md
Source Code: https://github.com/tronprotocol/java-tron/pull/4337

7. Support node stop at specified condition

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

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 Source Code: https://github.com/tronprotocol/java-tron/pull/4375

2. Optimize the cache structure of TVM

In versions prior to GreatVoyage-v4.5.1 (Tertullian), the cached data in TVM is stored in the form of a byte array. When the data in the cache needs to be changed, the data must first be converted from the form of a byte array to a protobuf object by performing a serialization operation, then change a field of the object (such as account balance, etc.) to generate a new object, then serialize the newly generated protobuf object to byte array, and at last write the result byte array to TVM cache. Since the serialization and deserialization of protobuf is time-consuming, the GreatVoyage-v4.5.1 (Tertullian) version optimizes the data structure in the cache when TVM is executed, and directly saves the protobuf object data to reduce the serialize/deserialize operations when accessing the data in the cache, speeding up TVM execution of bytecode.

Source Code: https://github.com/tronprotocol/java-tron/pull/4375

Hope is patience with the lamp lit.

--- Tertullian

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

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

*Beauty in things exists in the mind which contemplates them. *

---David Hume

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

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

No one can give you better advice than yourself.

---Cicero

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

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 Source Code: https://github.com/tronprotocol/java-tron/pull/4254

2. Optimize memory usage

In order to avoid repeatedly broadcasting a transaction, the node will cache the transaction data into the broadcast data buffer. However,due to the limitation of the JVM's recycling policy, old cached data cannot be deleted in time until the buffer is full. Therefore, a buffer with a larger capacity will occupy a large amount of memory space. Before the GreatVoyage-v4.4.4 (Plotinus) version, the buffer pool size was 100000 transactions. In order to release the memory occupied by expired transactions in time , the GreatVoyage-v4.4.4 (Plotinus) version changed the buffer size to 20000 to reduce memory usage.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-362.md Source Code: https://github.com/tronprotocol/java-tron/pull/4250

3. Optimize the block-producing thread

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

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

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

2. Optimize network service shutdown logic

The GreatVoyage-v4.4.4(Plotinus) version optimizes the network service shutdown logic, closing the synchronization service first, and then closing the TCP connection service to ensure that all P2P connection related services exit safely.

Source Code：https://github.com/tronprotocol/java-tron/pull/4220

3. improve the java-tron upgrade mechenism

For upgrade mechanism of java-tron,Before the GreatVoyage-v4.4.4 (Plotinus) version,all 27 super representative nodes need to complete the code upgrade, TRON network can be upgraded to the new version,TRON is a completely decentralized governance network,Sometimes the 27 super representative nodes cannot complete the code upgrade within a certain period of time, making the version upgrade process slow.In order to achieve more efficient decentralized governance, in GreatVoyage-v4.4.4 (Plotinus), the upgrade mechanism of java-tron has been improved, only 22 super representative nodes are needed to complete the code upgrade, and the TRON network can complete the upgrade.

Source Code：https://github.com/tronprotocol/java-tron/pull/4218

The world is knowable, harmonious, and good.

--- Plotinus

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

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 Source Code：https://github.com/tronprotocol/java-tron/pull/4157

API

1. Newly Adding ETH compatible log filter for JSON-RPC APIs.

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

1. LevelDB Databases Performance Optimization

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

Patience is the companion of wisdom.

--- Augustinus

GreatVoyage-4.4.0(Rousseau)

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

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 Source Code:https://github.com/tronprotocol/java-tron/pull/3986

2. Optimize the query performance of dynamic store

During the block processing, The frequency of visits to dynamic store is very high. The GreatVoyage-v4.4.0(Rousseau) version optimizes the query performance of the dynamic store by loading all the data of dynamic store into the first-level cache, the cache hit rate of the dynamic store is improved and the block processing speed is also improved.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-290.md Source Code：https://github.com/tronprotocol/java-tron/pull/3993

3. Optimize the transaction broadcasting interface

The GreatVoyage-v4.4.0 (Rousseau) version optimizes the processing flow of the transaction broadcast interface. The transaction broadcast is changed from asynchronous to synchronous, and the result will be returned after the broadcast is successful, making the return result of the broadcast more accurate.

Source code：https://github.com/tronprotocol/java-tron/pull/4000

4. Optimize the parameters of the database

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

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. - The try/catch-statement supports catching all types of TVM exceptions. - Forbid the system contract “TransferContract” to transfer TRX to the smart contract account.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-272.md Source Code：https://github.com/tronprotocol/java-tron/pull/4032

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.

2. Adapt to Ethereum London Release

In the GreatVoyage-v4.4.0 (Rousseau) version, TVM is also adapted to the Ethereum London upgrade: introduce the BASEFEE opcode; the deployment of new contracts starting with 0xEF is prohibited.

TIP: https://github.com/tronprotocol/tips/blob/master/tip-318.md Source Code：https://github.com/tronprotocol/java-tron/pull/4032

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.

3. In constant mode, Energy limit supports customization and the default value is increased

Before the GreatVoyage-v4.4.0 (Rousseau) version, the energy limit in constant mode was a fixed value(3,000,000). The GreatVoyage-v4.4.0 (Rousseau) version changed it to configurable, and increase the default value to 100,000,000. after upgraded to the latest version, Energy limit can be configured in startup parameters(--max-energy-limit-for-constant) or in the configuration file(vm.maxEnergyLimitForConstant).

Source Code：https://github.com/tronprotocol/java-tron/pull/4032

API

1. Support Ethereum compatible JSON-RPC API

Starting from the GreatVoyage-v4.4.0 (Rousseau) version, the FullNode supports JSON-RPC APIs. For details, please refer to: https://developers.tron.network/reference#json-rpc-api

Source Code：https://github.com/tronprotocol/java-tron/pull/4046

2. FullNode supports disabling APIs

In order to make the FullNode customizable, starting from GreatVoyage-v4.4.0 (Rousseau) version, FullNode supports disabling specific APIs through the configuration file.

Source code：https://github.com/tronprotocol/java-tron/pull/4045

3. Optimize the TriggerConstantContract API

In GreatVoyage-v4.4.0 (Rousseau), the following optimizations have been introduced to the TriggerConstantContract interface: - Execute contract creation when ContractAddress is empty - Remove the check of the incoming parameters callvalue and tokenvalue - The log list and internal transaction list are added to TransactionExtention

Source Code： https://github.com/tronprotocol/java-tron/pull/4032

Changes

1. Upgrade event plugin to support BTTC data

The event plugin has been upgraded in GreatVoyage-v4.4.0 (Rousseau) to support BTTC.

Source code: https://github.com/tronprotocol/java-tron/pull/4067

2. Increase the upper limit of the MaxFeeLimit network parameter.

In the version before GreatVoyage-v4.4.0 (Rousseau), the value range of MaxFeeLimit is [0,1e10] sun, in GreatVoyage-v4.4.0 (Rousseau) the value range of MaxFeeLimit is expanded to [0, 1e17] sun.

Source Code： https://github.com/tronprotocol/java-tron/pull/4032

NOTICE： By default, this feature is disabled, it will be enabled after the London upgrade proposal takes effect.

3. Optimize the quick start script start.sh

The quick start script tool is also upgraded in the GreatVoyage-v4.4.0 (Rousseau) version, please refer to the latest user guide from: https://github.com/tronprotocol/java-tron/blob/release_v4.4.0/shell.md

The world of reality has its limits; the world of imagination is boundless.

--- Rousseau

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

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].

  • TIP: https://github.com/tronprotocol/tips/blob/master/tip-292.md
  • Source Code: https://github.com/tronprotocol/java-tron/pull/3917

NOTICE The account's daily free bandwidth quota is not changed now. The super representative or super partner will initiate a vote request to change the value in the future.

2. Add a proposal to adjust the total net limit.

Prior to GreatVoyage-v4.3.0 (Bacon), the total bandwidth obtained by staking TRX throughout the entire network was fixed at 43,200,000,000. The GreatVoyage-v4.3.0 (Bacon) version incorporates proposal #62 TOTAL_NET_LIMIT, which allows for configuring the total bandwidth available by staking TRX over the entire network. Super representatives and super partners may initiate a voting request for Proposal 62, which amends TOTAL_NET_LIMIT. TOTAL_NET_LIMIT has a range of [0, 1000000000000].

  • TIP: https://github.com/tronprotocol/tips/blob/master/tip-293.md
  • Source Code: https://github.com/tronprotocol/java-tron/pull/3917

NOTICE The total net limit is not changed now. The super representative or super partner will initiate a vote request to change the value in the future.

3. Optimize the Account Data Structure

Account is a database that receives numerous accesses during the node's operation, necessitating frequent deserialization operations on the account data structure. Prior to GreatVoyage-v4.3.0 (Bacon), Account contained not only the account's basic data, but also user TRC-10 asset data. However, for TRX transfers and smart contract-related transactions, only the Account's basic data is used. An excessively large TRC-10 asset list will have a significant impact on the Account data structure's deserialization performance. GreatVoyage-v4.3.0 (Bacon) improves the Account database's storage structure by separating TRC-10 asset data from the Account and storing it independently in the AccountAssetIssue. Reduce the amount of data that is deserialized during Account deserialization and increase the deserialization speed.

  • TIP: https://github.com/tronprotocol/tips/blob/master/tip-295.md
  • Source Code: https://github.com/tronprotocol/java-tron/pull/3906

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

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.

  • TIP: https://github.com/tronprotocol/tips/blob/master/tip-271.md
  • Source Code: https://github.com/tronprotocol/java-tron/pull/3921

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.

2. Add a New Type: Error in Smart Contract ABI

GreatVoyage-v4.3.0 (Bacon) provides a new ABI type Error, which is a custom error type that is compatible with Ethereum solidity 0.8.4's new features.

  • TIP: https://github.com/tronprotocol/tips/blob/master/tip-306.md
  • Source Code: https://github.com/tronprotocol/java-tron/pull/3921

API

1. Add a New Field: energy_used in TransactionExtention

Users cannot forecast the energy usage of smart contract transactions in versions earlier to GreatVoyage-v4.3.0 (Bacon). The version of GreatVoyage-v4.3.0 (Bacon) adds the energy_used field to the TransactionExtension. When the user invokes the contract method via TriggerConstantContract, a sandbox environment based on the most recently synchronized block at the current node is created to supply TVM with this method call. Following the execution, the actual energy consumption figure is written to the energy_used field(this operation will not generate an on-chain transaction, nor will it change the status of the current node).

  • Source Code: https://github.com/tronprotocol/java-tron/pull/3940

Changes

1. Change the Cryptography Library to Bouncy Castle

Since SpongyCastle is no longer maintained, BouncyCastle is utilized as the encryption library starting with GreatVoyage-v4.3.0 (Bacon).

  • Source Code: https://github.com/tronprotocol/java-tron/pull/3919

2. Modify the Calculation of net_usage Value in the Transactioninfo when Creating New Accounts

When a new account is created in GreatVoyage-v4.3.0 (Bacon), the method for calculating net_usage is altered.

  • Source Code: https://github.com/tronprotocol/java-tron/pull/3917

3. Optimize the Block Verification

When a node checks a block prior to GreatVoyage-v4.3.0 (Bacon), it verifies each transaction included inside it, regardless of whether it has been verified previously. The transaction verification procedure consumes roughly one-third of the total time required to process a block. The GreatVoyage-v4.3.0 (Bacon) release optimizes the block verification logic. If non-AccountUpdateContract transactions in the block have been validated previously (AccountUpdateContract transactions entail account permission changes), they will no longer be verified to expedite block verification.

  • TIP: https://github.com/tronprotocol/tips/blob/master/tip-276.md
  • Source Code: https://github.com/tronprotocol/java-tron/pull/3910

4. Optimize the Node Startup

Prior to GreatVoyage-v4.3.0 (Bacon), during node startup, transaction cache and block data from the database are read to complete the RAM transaction cache initialization. The RAM transaction cache initialization process has been streamlined in GreatVoyage-v4.3.0 (Bacon), and some superfluous parsing processes have been deleted. The speed of node startup will be increased following optimization.

  • TIP: https://github.com/tronprotocol/tips/blob/master/tip-285.md
  • Source Code: https://github.com/tronprotocol/java-tron/pull/3907

5. Optimize Transaction Processing Flow to Reduce Memory Usage

The transaction processing flow is streamlined in GreatVoyage-v4.3.0 (Bacon), unneeded objects are released in advance, and memory utilization is optimized.

  • Source Code: https://github.com/tronprotocol/java-tron/pull/3911

6. Add New Plugins to Optimize the Performance of levedb Startup

In the version before GreatVoyage-v4.3.0 (Bacon), with the running of levedb, the manifest file will continue to grow. Excessive manifest file will not only affect the startup speed of the node but also may cause the memory to continue to grow and lead to insufficient memory and the service was terminated abnormally. GreatVoyage-v4.3.0 (Bacon) introduces the leveldb startup optimization plug-in. The plug-in optimizes the file size of the manifest and the startup process of LevelDB, reduces memory usage, and improves node startup speed.

  • TIP: https://github.com/tronprotocol/tips/blob/master/tip-298.md
  • Source Code: https://github.com/tronprotocol/java-tron/pull/3925
  • Plug-in Usage Guide: https://github.com/tronprotocol/documentation-en/blob/master/docs/developers/archive-manifest.md

Knowledge is power.

--- Francis Bacon

GreatVoyage-4.2.2.1(Epictetus)

We have just released the version of GreatVoyage-v4.2.2.1(Epictetus). The main new features and modifications are as follows:

Core Protocol

1. Optimize the processing logic of pending transactions.

In the versions before GreatVoyage-v4.2.2.1(Epictetus), if the node has enabled the event subscription service, there will be a small probability of abnormal node synchronization.

The GreatVoyage-v4.2.2.1(Epictetus) version optimizes the processing logic of pending transaction, fixes the synchronization exception, and improves the stability of the event subscription service.

The update introduced by the GreatVoyage-v4.2.2.1(Epictetus) version optimizes the processing logic of pending transaction, which will greatly improve the stability of the event subscription service, bring a better experience for TRON users, and further prosper the TRON ecosystem.

No great thing is created suddenly.

--- Epictetus

GreatVoyage-4.2.2(Lucretius)

The version of GreatVoyage-v4.2.2 (Lucretius) introduces three important optimizations. The optimization of block processing effectively improves the execution speed of the block, thereby significantly improving the performance of the TRON network. Efficient HTTP/RPC query and excellent TVM performance will bring a better experience to TRON DAPP users and further prosper the TRON ecosystem.

Core Protocol

1. Block Processing optimization

In the versions before GreatVoyage-v4.2.2 (Lucretius), to obtain the witness list during block processing, multiple database queries and deserialization operations were performed, which took up nearly 1/3 of the block processing time.

The GreatVoyage-v4.2.2 (Lucretius) version simplifies the query of witnesses. In the block processing process, the witness list can be obtained by only one query. After testing, this optimization has dramatically improved the block processing performance.

2. Data Query optimization

In the versions before GreatVoyage-v4.2.2 (Lucretius), multiple HTTP or RPC queries for data on the chain are mutually exclusive. If a query request is being processed, a new query request will keep waiting until the previous request is completed.

However, data query methods never use shared data, and no lock operation is required. This optimization removes unnecessary synchronization locks in the query process and improves the performance of internal queries, HTTP and RPC query requests of nodes.

3. Smart Contract ABI Storage optimization

In the version before GreatVoyage-v4.2.2 (Lucretius), the ABI other data of the smart contract are stored together in the contract database, and some high-frequency instructions (SLOAD, SSTORE, Etc.) will read all the data of a smart contract from the contract database. However, the execution of the contract does not use these ABI data, and these frequent readings will impact the execution efficiency of these instructions.

In the version of GreatVoyage-v4.2.2 (Lucretius), smart contract ABIs are transferred to a particular ABI database. The ABI data will no longer be read during the execution of the contract, thus significantly improving the performance of TVM.

Other Changes

1. System Contract BatchValidateSign Initialization Process optimization

--- Truths kindle light for truths.

--- Lucretius

GreatVoyage-4.2.0(Plato)

The GreatVoyage-4.2.0 (Plato) version introduces two important updates. The optimization of the resource model will increase the utilization rate of TRON network resources and make the resource acquisition method more reasonable. The new TVM instructions make the use scenarios of smart contracts more abundant and will further enrich the TRON ecosystem.

Core Protocol

1. Optimize the resource model

Before the GreatVoyage-4.2.0 (Plato) version, while users obtained a large amount of TRON power by staking TRX, they also obtained a large amount of energy and bandwidth. The utilization rate of these energies and bandwidth is extremely low, and most of them are not used at all, which increases the cost of obtaining resources. In order to improve the utilization rate of these resources, the GreatVoyage-4.2.0(Plato) version proposes an optimization of the resource model, where staking TRX can only obtain one of the three resources, namely bandwidth, energy, and TRON power. After optimization, users can obtain the corresponding resources based on their own needs, thereby improving the utilization rate of resources.

Notes: * This feature is disabled by default and can be enabled through the proposal system. * After the feature is enabled, the user's previously obtained resources remain unchanged. The TRON power obtained before the proposal passage will be cleared when the user triggers an unstake transaction (unstake bandwidth, energy, or TRON power).

TVM

1、Add Freeze/Unfreeze instructions in TVM

In the TRON network, one non-contract account can stake TRX to obtain resources such as bandwidth, energy, TRON power, and reasonable use of these resources can bring certain benefits to users. At the same time, although smart contract accounts do have TRX, there is no way to stake these TRX to obtain resources. In order to solve this inconsistency, the GreatVoyage-4.2.0(Plato) version introduces Freeze/Unfreeze instructions in TVM, so that smart contracts can also support staking TRX to obtain resources.

Notes: * This feature is disabled by default and can be enabled through the proposal system. * The TVM freeze instruction can obtain bandwidth and energy. For TRON POWER, it can be obtained and used after the TVM supports the voting instruction. * The receiving address/target address used in the Freeze/Unfreeze instructions must be address payable type, and the receiving address/target address cannot be a contract address other than itself. * The inactive account will be automatically activated if the account is the receiver of TVM Freeze instruction, and 25,000 energy will be deducted as the account activation cost.

Other Changes

1、Optimize the block synchronization.

The beginning is the most important part of the work.

--- Plato

GreatVoyage-4.1.3(Thales)

GreatVoyage-4.1.3(Thales) is released with the following new features and modifications:

Core Protocol

1.Sorting the transactions in pending pool, SR will prioritize the transactions with high packing fee

In GreatVoyage-4.1.2 and earlier versions, SR packaging transactions are carried out in accordance with the time sequence of the arrival of the transaction.This will easily be attacked by low transaction fees.

After this optimization, block producers sort the transactions to be packaged according to the cost, and then prioritize the transaction with high cost to prevent low-cost transaction attacks.

API

1.Add new API to support transaction query in pending pool.

It is currently impossible to query the intermediate state information of a certain transaction from after it is issued to before it is on the chain.After a transaction is sent, if it is not on the chain, we cannot know whether it is waiting for packaging or has been discarded.

In this upgrade, the Fullnode node provides 3 API to obtain detailed information about the pending pool: - /wallet/gettransactionfrompending: Obtain the transaction information from pending pool through the - transaction ID - /wallet/gettransactionlistfrompending: Get all transactions from the pending pool - /wallet/getpendingsize: Get the number of transactions in pending pool

The optimization of transaction packaging logic of GreatVoyage-4.1.3(Thales) will effectively reduce low-cost attacks and greatly improve the security of the TRON public chain.

Great Voyage - v4.1.2

GreatVoyage-version 4.1.2 is released with the following new features and modifications:

I. Core Protocol

1、Reward SRs with the transaction fees charged for bandwidth and energy.

After this feature is turned on, the transaction fee from burning TRX which charged for bandwidth/energy (except OUT_OF_TIME) will be transferred to TRANSACTION_FEE_POOL. At the end of each block, the fee of all transactions in this block is rewarded to the block SR and its voters. At the same time, in "transactioninfo", the "packingFee" field is added to indicate the available fees to the current SR and SR voters.

2、Support account history balance query.

The account historical balance query function can facilitate developers to query the account balance information at a specific block height. Developers can obtain the account historical balance information through the following two APIs.

  • /wallet/getaccountbalance ：query account balance at a specific block.
  • /wallet/getblockbalance ： Query the balance-changing operations in a specific block.

Note: 1. This function is disabled by default and can be enabled through the node configuration file. 2. After the function is enabled, users can only query the historical balance after the enabled time. If users need to query the complete historical balance information, they can use the data snapshot which contains the historical balance information to resynchronize the node.

  • Source Code：#3538
  • Guide ： https://github.com/tronprotocol/documentation-en/blob/master/docs/api/http.md

3、Optimized the blackhole account to improve transaction execution speed

After the feature is turned on, the transaction fee from burning TRX which charged f for bandwidth and energy will no longer be transferred to the black hole address but will be directly accumulated and recorded in the database.

II. TVM

1、Adopt to solidity0.6.0.

After this upgrade, TRON will be fully compatible with the new features introduced by solidity 0.6.0, including the new virtual and override keywords, and supporting try/catch. For details, please refer to the TRON Solidity release note: https://github.com/tronprotocol/solidity/releases/tag/tv_0.6.0

2、Make MAX_FEE_LIMIT configurable as a chain property.

After the new version, SR and SRP can initiate a voting request to modify MAX_FEE_LIMIT. The range of MAX_FEE_LIMIT is [0,10000000000].

III. Others Changes

1、Use the jitpack repository to provide dependency support and make it easy for developers to use java-tron as a dependency for their projects.

GreatVoyage-v4.1.1

GreatVoyage-version 4.1.1 is released with the following new features and modifications:

I. Core Protocol

1. New Consensus Protocol

The new consensus mechanism combines TRON's existing DPoS consensus with the PBFT consensus mechanism. PBFT's three-phase voting mechanism is adopted to confirm whether a block should be solidified. It will take an average of 1-2 slots (a slot equals 3s) from creation to confirmation of a TRON block, much shorter than the previous 19 slots. This signifies a remarkable increase in the block confirmation speed. TIP: TICP-Optimized-PBFT Source code: #3082

2. New Node Type

We added another type of node to the existing FullNode: Lite FullNode. Lite FullNode executes the same code with the FullNode. What sets it apart is that its launch is based on the status data snapshot, which contains all the status data and data history of the latest 256 blocks. The status data snapshot can be acquired by executing LiteFullNodeTool.jar (please see: Use the LiteFullNode Tool). - TIP: TIP-128 - Source code: #3031

II. TVM

Achieved compatibility with Ethereum Istanbul upgrade

a. Added new instruction CHAINID to fetch the genesis block ID of the current chain, which avoids possible replay attacks of one transaction being repeated on different chains. - TIP: TIP-174 - Source code: #3351

b. Added new instruction SELFBALANCE to fetch the balance of the current contract address in the smart contract. For obtaining the balance of any address, please stick with instruction BALANCE.SELFBALANCE is safer to use. Energy consumption of using BALANCE might rise in the future. - TIP: TIP-175 - Source code: #3351

c. Reduced Energy consumption of three precompiled contract instructions, namely BN128Addition, BN128Multiplication, and BN128Pairing. BN128Addition: from 500 Energy to 150 Energy BN128Multiplication: from 40000 Energy to 6000 Energy BN128Pairing: from (80000 * pairs + 100000) Energy to (34000 * pairs + 45000) Energy - TIP: TIP-176 - Source code: #3351

III. Mechanism

  1. Added two new system contracts, namely MarketSellAssetContract and MarketCancelOrderContract, for on-chain TRX/TRC10 transactions in decentralized exchanges.
  2. TIP: TIP-127
  3. Source code: #3302

IV. Other Modifications

  1. Added a few node performance indicators.

  2. Source code: #3350

  3. Added market order detail in the original transactionInfo interface.

  4. TIP: TIP-127

  5. Source code: #3302

  6. Improved the script for docker deployment.

  7. Source code: #3330

GreatVoyage-v4.0.0

Release 4.0.0 has implemented the shielded TRC-20 contract, which can hide the source address, destination address, and the token amount for TRC-20 transactions and provide users with better privacy. The shielded TRC-20 contract has three core functions: mint, transfer and burn. mint is used to transform the public TRC-20 token to shielded token; transfer is used for shielded token transactions; burn is used to transform the shielded token back to the public TRC-20 token. To support the shielded TRC-20 contract, four new zero-knowledge instructions (verifyMintProof, verifyTransferProof, verifyBurnProof and pedersenHash) are add in TVM, which make it convenient to provide privacy for arbitrary TRC-20 contract.

Notices

Forced upgrade

New features

  • Add 4 new instructions (verifyMintProof, verifyTransferProof, verifyBurnProof and pedersenHash) in TVM to support TRC20 shielded transactions based on zk-SNARKs (#3172).
  • verifyMintProof: used to validate the zero-knowledge proof for mint function.
  • verifyTransferProof: used to validate the zero-knowledge proof for transfer function.
  • verifyBurnProof: used to validate the zero-knowledge proof for burn function.
  • pedersenHash: used to compute the Pedersen hash.
  • Update the initial parameters of zk-SNARKs scheme generated by the MPC Torch (#3210).
  • Add the APIs to support shielded TRC-20 contract transaction (#3172).

1. Create shielded contract parameters 

rpc CreateShieldedContractParameters (PrivateShieldedTRC20Parameters) returns (ShieldedTRC20Parameters) {}
2. Create shielded contract parameters without ask 
rpc CreateShieldedContractParametersWithoutAsk (PrivateShieldedTRC20ParametersWithoutAsk) returns (ShieldedTRC20Parameters) {}
3. Scan shielded TRC20 notes by ivk 
rpc ScanShieldedTRC20NotesByIvk (IvkDecryptTRC20Parameters) returns (DecryptNotesTRC20) {}
4. Scan shielded TRC20 notes by ovk 
rpc ScanShieldedTRC20NotesByOvk (OvkDecryptTRC20Parameters) returns (DecryptNotesTRC20) {}
5. Check if the shielded TRC20 note is spent 
rpc IsShieldedTRC20ContractNoteSpent (NfTRC20Parameters) returns (NullifierResult) {}
6. Get the trigger input for the shielded TRC20 contract 
  rpc GetTriggerInputForShieldedTRC20Contract (ShieldedTRC20TriggerContractParameters) returns (BytesMessage) {}
- Support the ovk to scan the transparent output of burn transaction (#3203). - Support the burn transaction with zero or one shielded output (#3224). - Add data field in transaction log trigger class for future memo note (#3200).

The following TIPs are implemented in this release: - TIP-135: Shielded TRC-20 contract standards, guarantee the privacy of the shielded transfer of TRC-20 tokens. - TIP-137: Implements three zero-knowledge proof instructions in TVM to support the shielded TRC-20 contract (#3172). - TIP-138: Implements the Pedersen hash computation instruction in TVM to support the shielded TRC-20 contract (#3172).

Changes

  • Check if null before getInstance when get transaction info from DB to fix exception of getTransactioninfoByBlkNum (#3165).

Odyssey-v3.7

Odyssey-v3.7 is a non-mandatory upgrade, includes the following new features and improvements.

Modularization

Odyssey-v3.7 has modularized the code organization structure, making it much easier for developers to develop customized module，several mainly modules are listed as follows：

Framework

As the core module, Framework performs as both a gateway to the blockchain and an adhesive that effectively connects all other modules. In other words, the framework module initializes each module and facilitates communication between modules.

Protocol

The decentralized TRON protocol can be implemented by any teams without limitation of programming languages. Any clients in accordance with the TRON protocol can communicate with each other. A concise and efficient data transfer protocol is essential to a distributed network, even more for the blockchain. So, the implementation of the protocol is based on the Protocol Buffers, an open-source and excellent software protocol maintained by Google. The specific business logic of the blockchain defined by the protocol includes: - the data format of message，including block, transaction, proposal, witness, vote, account, exchange and so on. - the communication protocols between blockchain nodes, including the node discovery protocol, the node data synchronization protocol, the node scoring protocol and so on. - the interface protocols that the blockchain provides to the external system or clients

Consensus

The consensus mechanism is an essential part of the blockchain. The TRON blockchain chooses the DPoS as the core consensus mechanism and it has been running steadily for a long time. But replaceable consensus module is essential if we want to redefine the java-tron as the powerful infrastructure for building application-specific blockchains. The developers of blockchain should determine to choose the consensus mechanism that considered to be most suitable to the specific application scenario. The ultimate goal of the replaceable consensus module is that the consensus mechanism can be determined by configuring some necessary parameters. In addition, the developers can implement a customized consensus module as long as several essential interfaces implemented.

Crypto

Encryption is also one of the core modules of the blockchain. It is the foundation of the blockchain data security. such as public and private key deduction, transaction verification, zero-knowledge proof, etc. The java-tron abstracts the encryption module and supports the replacement of encryption algorithms. A suitable encryption algorithm can be chosen according to different business needs.

Actuator

Actuator is the core module used for handling various kinds of transactions. As you know, every transaction in the TRON blockchain contains a contract. On a high level, there are two types of contracts in the TRON blockchain, the system contract and the smart contract. A large number of applications are implemented by the smart contracts and ran in an internal virtual machine of the blockchain. Unfortunately, smart contracts are constrained in terms of their functions and not flexible enough to accommodate the needs of complex applications. Customized actuators offer application developers a brand new way of development. They can choose to implant their application codes into the chain instead of running them on virtual machines.

Chainbase

Chainbase is specially designed for data storage in the blockchain. Nodes always consider the longest chain to be the correct one and will keep working on extending it. So switching to the longest chain is a common scenario for the blockchain unless it uses a deterministic consensus algorithm like PBFT. For this reason, supporting data rollback is the most distinctive feature of the chainbase module. Several well-designed abstract interfaces are defined in this module. So, the developers can choose the storage engine freely and then implement corresponding interfaces. The LevelDB and RocksDB are two existing implementation.

New event subscription trigger for solidified block

Added a subscription trigger for the updating a solidified block, which triggers the solidified block update event to the message queue, so that users can get the latest solidified block information on time. A solidified block is a block that regarded as can not be revocable. So, when the block becomes a solidified block, it means that the transactions packed in this block are accepted by the blockchain.

Two new HTTP APIs added

gettransactioninfobyblocknum

This api is both added in the context: /wallet & /walletsolidity. * Description: Query the list of information of transactions in a specific block. * Parameter num: the height of the block. * Return: The list of transaction information.

broadcasthex

/wallet/broadcasthex * Description: broadcast signed transaction with the format of the hex string * Parameter: signed transaction with the format of the hex string * Return: the result of the broadcast

A new RPC API added

Adding the GetTransactionInfoByBlockNum method both in Wallet WalletSolidity services： 

rpc GetTransactionInfoByBlockNum (NumberMessage) returns (TransactionInfoList) {
}
a code snippet： 
NumberMessage.Builder builder = NumberMessage.newBuilder();
builder.setNum(blockNum);
TransactionInfoList transactionInfoList = blockingStubFull.getTransactionInfoByBlockNum(builder.build());

Odyssey-v3.6.5

Odyssey v3.6.5 Update includes the following new features and improvements

1. New delegation mechanism

The new delegation mechanism enables SRs to set commission rates by themselves, which will serve as a reference for users when they vote for SRs. Meanwhile, traceability of the SR’s commission rate on the chain makes the amount of rewards that users receive through voting more transparent. Moreover, the new delegation mechanism lays a foundation for more complex consensus mechanisms and incentive schemes in the near future.

2. Fairer and more efficient staking rewards mechanism

Staking rewards are now distributed in a fully-decentralized way, a step forward from the old partially-decentralized mechanism. With this change, staking rewards are now distributed entirely through the blockchain, ensuring complete supervision from the chain and thus true decentralization. Moreover, the new mechanism cuts unnecessary reward distribution transactions, signaling lower bandwidth consumption and higher efficiency on the TRON network.

3. Fairer incentive mechanism

Block rewards decreased from 32 TRX to 16 TRX, while voting rewards increased from 16 TRX to 160 TRX. The adjustment will boost voter turnout in the community, with more TRX locked up by users in the TRON ecosystem. This move is accompanied by the new staking rewards mechanism to guarantee real staking revenues to users.

4. Improvement and optimization of TVM

(1) Added a new VM instruction ISCONTRACT(0xd4), which has made smart contract development more flexible by allowing developers to identify the type of the target address in VMs when writing contracts. batchvalidatesign(bytes32 hash, bytes[] memory signatures, address[] memory addresses)

(2) Adopted a multi-thread method for VMs to verify signatures, which is faster than ecrecover of Ethereum while cutting Energy consumption by half. Contract address: 0x09. To use it in solidity: batchvalidatesign(bytes32 hash, bytes[] memory signatures, address[] memory addresses) validatemultisign(address accountAddress, uint256 permissionId, bytes32 content, bytes[] signatures)

(3) Added a new pre-compiled contract to boost multi-signature verification in TVM, speeding up the verification process and reducing Energy consumption.

(4) Banned transfer TRX to smart contract address by two system contract TransferContract and TransferAssetContract. The transfer would fail if the target address is a smart address when using TransferContract and TransferAssetContract. This can prevent general users from transferring assets to smart contract address by mistake, avoiding users’ asset loss.

(5) Allowed automatic activation of inactive accounts when transferring TRX/ TRC10 tokens to accounts in smart contracts.

(6) Added triggerConstantContract feature for SolidityNode and FullNode so as to improve the functionality of node APIs.

5. Improvement of the dynamic adjustment scheme of Energy upper limit

The method of calculating Energy consumed per unit of time shifted from only calculating the staked Energy consumed to all Energy consumed. With this change, statistics of Energy consumption will be more accurate and effective, providing reference for adjusting Energy upper limit, saving users’ costs of using TRON blockchain network and improving network efficiency.