Tron Mainnet Periander Launching
Tron Mainnet Periander launching has been announced. The TRON developer community has released the GreatVoyage-v4.7.2(Periander) version, this is a mandatory upgrade. Please complete your upgrade to the new version before 23:59, July 11th, 2023 (SGT).
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.
Significant 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.
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.
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.
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 №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.
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 №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.
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.
