Merge pull request tronprotocol#146 from vivian-kang/reorganize-the-doc

Release history

Author: ethan1844

docs/releases/GreatVoyage-v400.md

@@ -0,0 +1,50 @@
+# 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
+  ```protobuf
+  rpc CreateShieldedContractParameters (PrivateShieldedTRC20Parameters) returns (ShieldedTRC20Parameters) {}
+  ```
+  2. Create shielded contract parameters without ask
+  ```protobuf
+  rpc CreateShieldedContractParametersWithoutAsk (PrivateShieldedTRC20ParametersWithoutAsk) returns (ShieldedTRC20Parameters) {}
+  ```
+  3. Scan shielded TRC20 notes by ivk
+  ```protobuf
+  rpc ScanShieldedTRC20NotesByIvk (IvkDecryptTRC20Parameters) returns (DecryptNotesTRC20) {}
+  ```
+  4. Scan shielded TRC20 notes by ovk
+  ```protobuf
+  rpc ScanShieldedTRC20NotesByOvk (OvkDecryptTRC20Parameters) returns (DecryptNotesTRC20) {}
+  ```
+  5. Check if the shielded TRC20 note is spent
+  ```protobuf
+  rpc IsShieldedTRC20ContractNoteSpent (NfTRC20Parameters) returns (NullifierResult) {}
+  ```
+  6. Get the trigger input for the shielded TRC20 contract
+  ```protobuf
+    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](https://github.com/tronprotocol/tips/blob/master/tip-135.md): Shielded TRC-20 contract standards, guarantee the privacy of the shielded transfer of TRC-20 tokens.
+- [TIP-137](https://github.com/tronprotocol/tips/blob/master/tip-137.md): Implements three zero-knowledge proof instructions in TVM to support the shielded TRC-20 contract (#3172).
+- [TIP-138](https://github.com/tronprotocol/tips/blob/master/tip-138.md): 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).

docs/releases/GreatVoyage-v411.md

@@ -0,0 +1,47 @@
+# 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](https://github.com/tronprotocol/tips/blob/master/tp/ticp/ticp-optimized-pbft/ticp-Optimized-PBFT.md)
+Source code: [#3082](https://github.com/tronprotocol/java-tron/pull/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](https://tronprotocol.github.io/documentation-en/developers/litefullnode/)).
+- TIP: [TIP-128](https://github.com/tronprotocol/tips/blob/master/tip-128.md)
+- Source code: [#3031](https://github.com/tronprotocol/java-tron/pull/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](https://github.com/tronprotocol/tips/blob/master/tip-174.md)
+- Source code: [#3351](https://github.com/tronprotocol/java-tron/pull/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](https://github.com/tronprotocol/tips/blob/master/tip-175.md)
+- Source code: [#3351](https://github.com/tronprotocol/java-tron/pull/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](https://github.com/tronprotocol/tips/blob/master/tip-176.md)
+- Source code: [#3351](https://github.com/tronprotocol/java-tron/pull/3351)
+ 
+## III. Mechanism
+1. Added two new system contracts, namely MarketSellAssetContract and MarketCancelOrderContract, for on-chain TRX/TRC10 transactions in decentralized exchanges.
+- TIP: [TIP-127](https://github.com/tronprotocol/tips/blob/master/tip-127.md)
+- Source code: [#3302](https://github.com/tronprotocol/java-tron/pull/3302)
+ 
+## IV. Other Modifications
+1. Added a few node performance indicators.
+- Source code: [#3350](https://github.com/tronprotocol/java-tron/pull/3350)
+ 
+2. Added market order detail in the original transactionInfo interface.
+- TIP: [TIP-127](https://github.com/tronprotocol/tips/blob/master/tip-127.md)
+- Source code: [#3302](https://github.com/tronprotocol/java-tron/pull/3302)
+ 
+3. Improved the script for docker deployment.
+- Source code: [#3330](https://github.com/tronprotocol/java-tron/pull/3330)

docs/releases/GreatVoyage-v412.md

@@ -0,0 +1,51 @@
+# 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. 
+
+- TIP: [TIP-196](https://github.com/tronprotocol/tips/issues/196)
+- Source Code:  [#3532](https://github.com/tronprotocol/java-tron/pull/3532)
+
+
+### 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](https://github.com/tronprotocol/java-tron/pull/3538)
+- Guide ： https://github.com/tronprotocol/documentation-en/blob/master/docs/api/http.md
+
+###3、Optimzed 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.
+
+- Source code： [#3617](https://github.com/tronprotocol/java-tron/pull/3617)
+
+## 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 
+
+- TIP:  [TIP-209](https://github.com/tronprotocol/tips/issues/209)
+- Source Code： [#3351](https://github.com/tronprotocol/java-tron/pull/3535)
+
+###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,10000_000_000].
+
+- TIP： [TIP-204](https://github.com/tronprotocol/tips/issues/204) 
+- Source code：  [#3534](https://github.com/tronprotocol/java-tron/pull/3534)
+ 
+## 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. 
+
+- Source code: [#3554](https://github.com/tronprotocol/java-tron/pull/3554)

docs/releases/GreatVoyage-v413.md

@@ -0,0 +1,22 @@
+# 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.
+
+
+---

docs/releases/GreatVoyage-v420.md

@@ -0,0 +1,41 @@
+# 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.
+
+- TIP： [TIP-207](https://github.com/tronprotocol/tips/blob/master/tip-207.md)
+- Source Code:  [#3726](https://github.com/tronprotocol/java-tron/pull/3726)
+
+**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.
+
+- TIP: [TIP-157](https://github.com/tronprotocol/tips/blob/master/tip-157.md)
+- Source Code： [#3728](https://github.com/tronprotocol/java-tron/pull/3728)
+
+**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.
+
+- Source code：[#3732](https://github.com/tronprotocol/java-tron/pull/3732)
+
+
+
+
+--- 
+*The beginning is the most important part of the work.* 
+<p align="right"> --- Plato</p>

docs/releases/GreatVoyage-v422.md

@@ -0,0 +1,42 @@
+# 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.
+
+
+- TIP: [TIP-269](https://github.com/tronprotocol/tips/blob/master/tip-269.md)
+- Source code: [#3827](https://github.com/tronprotocol/java-tron/pull/3827)
+
+## 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.
+
+- TIP: [TIP-268](https://github.com/tronprotocol/tips/blob/master/tip-268.md)
+- Source code: [#3836](https://github.com/tronprotocol/java-tron/pull/3836)
+
+# Other Changes
+
+## 1. System Contract `BatchValidateSign` Initialization Process optimization
+
+- Source code: [#3836](https://github.com/tronprotocol/java-tron/pull/3836)
+
+
+
+
+ --- *Truths kindle light for truths.* 
+<p align="right"> --- Lucretius</p>
+

docs/releases/GreatVoyage-v4221.md

@@ -0,0 +1,17 @@
+# GreatVoyage-4.2.2.1(Epictetus)
+GreatVoyage-v4.2.2.1(Epictetus) 版本已发布， 主要新功能和修改如下：
+
+# 核心协议
+##1、优化`pending transaction`的处理逻辑。
+
+在GreatVoyage-v4.2.2.1(Epictetus) 之前的版本中，如果节点如果开启了事件订阅服务，会有小概率发生节点同步异常的问题。
+
+GreatVoyage-v4.2.2.1(Epictetus) 版本对`pending transaction`的处理逻辑进行了优化，修复了该同步异常的问题，提升了事件订阅服务的稳定性。
+
+- 源代码:  [#3874](https://github.com/tronprotocol/java-tron/pull/3874 )
+
+GreatVoyage-v4.2.2.1(Epictetus) 版本引入的更新优化了`pending transaction`的处理逻辑，将大幅提升事件订阅服务的稳定性，将为TRON用户带来更好的体验，进一步繁荣波场生态。
+
+ --- 
+*No great thing is created suddenly.* 
+<p align="right"> --- Epictetus</p>